Web accessibility guide for editors
Accessibility requirements can, and should, be well understood by web designers when building a website from the ground up. It should sit at the core of the process – websites should be accessible to everyone, from fully abled people to the visually impaired and people with learning disabilities.
From 2025, it will be mandatory for businesses to comply with the EAA (European Accessibility Act) by following the Web Content Accessibility Guidelines (WCAG).
Although web agencies should do everything possible to keep web designs thoroughly accessible, the torch will inevitably be passed onto web editors to maintain this once a website is handed over. It sometimes gets tricky because of the flexible nature of a content management system (CMS) and the inexperience some editors may have with the software.
With that in mind, the following is a guide for web editors who need to know how they can continue to adhere to accessibility best practices.
Ensure the page hierarchy is maintained
During the design stage, we ensure the typographical structure is cohesive from a visual perspective. However, it is up to the website editor to maintain it in the CMS after completing the handover. This is not just for visual purposes, as screen reader technology also relies on the site hierarchy to convey the information accurately to the user, as well as to give a page overview or to provide the ability to skip to the desired content. As a plus, correct hierarchy improves understanding of the website for search engines and provides a better user experience, therefore benefiting all online users.
Pages should always have the page title in Heading 1, followed by Heading 2, then Heading 3 and so on. An incorrect page entered in CMS by the website editor could look like this:
Images & Alt text
Often overlooked, text alternatives for images are essential for people with disabilities. Many visually impaired people rely on screen readers, so ensuring they have access to the same information as abled individuals is important.
From our side, we create a field in the CMS labelled ‘Alternative text’. As a website editor, you should make sure all images have this populated correctly.
Images should have a clear and concise description. This should be context-tailored; take this image for example. On a page discussing the Ragdoll breed, the alt text should be along the lines of ‘Ragdoll kitten with blue eyes’. On the other hand, if this would be featured in an article about protecting wildlife by attaching a bell to your pet, then this alt text would say ‘Domestic cat wearing a collar with a bell attached to it’.
Specific context examples
Images that contain text should not be featured as they are generally inaccessible. For example, they often won’t scale well if the user has zoomed in with their browser settings. However, if they must be used, the text should be repeated word for word in the alt-text.
Content
Different audiences require different types of communication.
During the research stage of our projects, our team discovers the appropriate language and messaging that should be used. We then apply this information to the site architecture and the way we name pages.
As a website editor, those discoveries should also be kept in mind when writing the content. Information on the site should be presented in suitable language for your audience; any unclear terminology or abbreviations should be explained.
Descriptive links
Buttons should feature descriptive text; otherwise, non-descriptive link text (buttons such as ‘Learn more’, ‘View more’, etc) become an issue for screen readers, especially when they don’t have the necessary title attributes that would inform the user where the link will be going; on top of this, screen readers might read out all the links on a page out of context at once. In this case, the screen reader would read out something similar to “Link 1: Read More, Link 2: Read More, Link 3: Read More”. As we can imagine, this does not convey a great user experience.
Custom HTML
It might be tempting to embed code from social media or galleries or other websites. Those plugins are sometimes convenient to implement on the site, however, they often don't match the same standards that we strive for. Our advice would be to seek guidance from your web development team before embedding any HTML code.
Colour contrast
Some content management systems will allow you to change colours. If you do this, please be aware of standards around contrast. It's worth noting here that these standards are continually changing. Currently, the official standard of contrast and accessibility is the Web Content Accessibility Guidelines (WCAG). It’s based on an algorithm that determines whether the values pass contrast checks or not; but as with many algorithms, it’s not always perfect.
A new standard, the Accessible Perceptual Contrast Algorithm (APCA), approaches accessibility differently: it’s a more complex algorithm that relies on human perception rather than simple numbers.
Although it sounds like a promising alternative, APCA has not been recognised as a worldwide standard. WCAG should still be regarded as the safest guideline so use APCA with care. It’s important to be aware of the progress developing in the industry.
Summary
When handing over the website from our team to the client’s web editors, Liquid Light always ensures that the latter is prepared to take over and has all the necessary knowledge to do so. Even so, it’s not uncommon for editors to make mistakes when handling the CMS. Keep an eye on the page hierarchy, the content being uploaded, and ensure images have alternative text and buttons have useful descriptions. When in doubt, revert to this article as a reference or ask your development team for guidance.
Further reading
-
Ioana Barbulescu
UI/UX Designer