10 ways to ensure your online engagement portal is accessible
Ensuring your online engagement portal is accessible for all members of the community is an essential responsibility for organisations who engage online.
By implementing a few simple techniques, you can easily ensure that all members of your community can get involved in your consultations via an accessible online engagement portal.
This article looks at 10 ways to to make your online engagement portal accessible.
1. Use EngagementHQ as your online engagement portal
There are a plethora of content management systems and single use engagement tools available for hosting and running online engagement activities.
The problem with having such availability of tools and platforms, is that it can often get messy trying to plug them all together in an accessible way.
Using EngagementHQ overcomes this problem by ensuring all themes, templates and engagement tools are accessible.
This also applies to in-built elements of EngagementHQ, including information widgets, accessible tables and even video players which support closed captioning.
As a dedicated online engagement portal, EngagementHQ is compliant with all WCAG standards and is regularly run through accessibility testing to ensure its compliance.
This makes it the easiest and most accessible online engagement tool available to government and private sector organisations.
If you would like a copy of our latest report, please contact us email@example.com.
2. Use headings to organise your project description content
Participants who use screen readers will use heading structures in order to navigate the content on your site.
While EHQ already has built-in heading structures for its page templates, you should also use pre-defined heading styles in project description when engaging online.
By using headings (<h1>, <h2>, etc.) correctly and strategically, the content of your website is better organised and easily read by a screen reader for people with a visual impairment.
It’s important that you do not simply pick a header just because it looks good visually (which can confuse screen reader users); instead, use your headings to organise content.
Some things to consider;
- <H1> will be the primary title of your EHQ project page. Avoid using a <h1> for anything other than the title of the website and the title of individual pages. Don’t use it again in your project description.
- Use headings to indicate and organize your content structure.
- Do not skip heading levels in your project description (e.g., go from an <h1> to an <h3>), as screen reader users will wonder if content is missing.
3. Use alt-text for images
You should also use alt-text anywhere online where you are using images.
This is to enable participants using a screen readers to easily understand the messages being conveyed in those images.
To ensure your images have appropriate alt-text, you should think about the message you are trying to convey through your images.
If the image includes text you will also need to include that text in your alt-text description.
If an image is the only content of a link, the screen reader will read the filename if alt-text is not provided.
Always provide alt-text for images that are used as links.
You don’t want people using screen readers to see your poorly named image files. ie. image45_girl.jpg
Alt-text for images should be included in the following places in EngagementHQ;
- Project Images
- Homepage tile images
- Images in your project description or other WYSIWYG editors
- Custom widget
- Photo gallery widget
4. Use proper descriptive links
When including a hyperlink in a project description for one of your projects, ensure you use text that properly describes where the link will go.
Simply using “click here” is not considered descriptive and is ineffective for a user of a screen reader.
The best way to include descriptive links is to ensure the most important content related to the link is presented first.
For example, if you are pointing visitors to a page called “Project Overview”:
- Try not to say: “Click here for an overview of the project.”
- Instead, say: “To learn about the project, read the Project Overview.”
5. Think about your colours
While most organisations have clearly defined brand colours, which will need to be incorporated into your site, it’s essential you select the right combination and contrasts of colours to help participants with a visual impairment.
The most common form of colour deficiency, red-green colour deficiency, affects approximately 8% of the population.
Using ONLY colours such as these (especially to indicate required fields in a form) will prevent these individuals from understanding your message.
There are several tools you can use to evaluate colour contrast, which help you ensure you’re making your community engagement site as visually usable as possible for participants with low vision or varying levels of colour blindness.
If you need help changing colours on your EHQ site, please contact our support team via email firstname.lastname@example.org.
6. Make your registration form and surveys accessible
Ensuring that you have clearly labeled all form fields across your site is essential for creating an accessible site.
When this is not done, a screen reader will not have the same audible cues as a participant with no visual impairment and it could be extremely difficult for your users to understand what information to enter into a form field..
In EngagementHQ, forms field labels are most important on your registration form and wherever you are using a survey.
Ensure your form fields have a clear descriptive label.
For example, if the field is for a person’s name, it should be labeled appropriately as either “Full Name” or have two separate fields labeled as “First Name” and “Last Name.”
A participant using your survey should be able to tab through the form and fill out all the fields before getting to the “Submit” button, or they may not even realise that additional fields exist.
If you have fields that are related, consider grouping them together using the section heading question type.
Organising forms with section headings can help participants using a screen reader to keep track of their progress, and can provide extra context that might otherwise be lost.
It is also a best practice habit for developing a well structured survey so you can kill two birds with one stone.
All required fields in EngagementHQ are automatically marked with an asterix indicating to the participant using the screen reader that they are required.
7. Don’t use tables for page layout in your project description
While you can easily organise content inside of tables using EngagementHQ’s WYSIWYG editor, they shouldn’t be used to layout information on your project page.
Doing this can create confusion for screen readers and make it difficult for visually impaired participants to understand your content.
Instead, only use tables for setting out data that needs to be presented in a table format.
If you do utilise tables, you should always use headers for rows and columns to ensure there is a clear relationship between the cells.
For laying out project description information on your page we recommend using CSS and inline styles to achieve your desired outcomes.
This can be done using the HTML toggle (<>) on the WYSIWYG editor.
If you don’t understand CSS, we highly recommend you take this free course from Code Academy on “How to learn CSS”, found here.
8. Don’t use plugins which aren’t accessible
Although EngagementHQ allows you to plugin third party embeddable widgets and tools, we cannot guarantee that those tools will be accessible.
Since you already have access to the best range of online engagement tools and widgets already as part of EngagementHQ we recommend you don’t use other tools that might affect the accessibility of your site.
If you are going to use other tools, it’s up to you to understand whether they are complaint to accessibility standards.
9. Write in plain english
Not only should your site be accessible for people using screen readers, but you should also be aware of the different literacy and language barriers faced by your community.
Writing in plain english is the simplest way to make your project description text and instructions accessible for the widest audience possible.
This means avoiding jargon and long sentences and providing clear and concise instructions on your projects.
You can easily check the complexity of the web copy you have written using tools such as Hemmingway App, found here.
These tools can help you identify hard to read sentences and show you how to make them more simplified for your participants.
10. Provide a clear way for participants to get phone or chat support
Having easily accessible information on how to get further phone support will help your participants get further support if they need.
If you don’t have access to a translation or phone support service you might consider using a Who’s Listening widget.
Providing simple contact information in an already WCAG complaint widget means that your participants will be able to get help and support if they need it.