Common accessibility mistakes when following WCAG rules
The Web Content Accessibility Guidelines (WCAG) is a repository of rules and knowledge helping Product Markers build universal digital products. It is based on four main guiding principles of accessibility, represented by the acronym POUR: Perceivable, Operable, Understandable, and Robust.
But, as with all things, you have the theory and then you have the practice. There are certain things that you will only learn by practicing and testing. I recently spoke and ran user testing with screen reader users. This is what I learned.
Decorative elements are not the same for people using a screen reader
If you follow the WCAG guidelines, they will recommend adding an alt=text attribute for images. However, while some elements can be helpful for some users, such as decorative icons or logos, they can be very distracting for screen reader users.
Certain elements should be muted so that they can be ignored by screen readers and other assistive technologies. To mute an element, a null (empty) alt attribute should be used instead (e.g. alt="").
Creating a matrix of element importance can be helpful to identify which elements should be muted.
Ads* should be accessible to screen reader users, they must be able to the same opportunity as other users. As other users, if they don’t want to be bothered by ads they can use an ad blocker.
Another example is when a user has already signed into your app, you might want to consider muting the app logo. Being one of the top elements, it is repeated each time a new page is loaded. The user should already know what app they are in, and if they forget, they can check the page URL.
Do not describe images. Provide context.
You should always set the alt text for important images. Not having alt text for an image is one of the most frustrating things for the screen reader experience. However, a common misconception is that you should describe what you see in the image. If you are following the W3 guidelines, they will actually advise you to describe the image’s purpose.
The
alttext should be the most concise description possible of the image’s purpose. If anything more than a short phrase or sentence is needed, it would be better to use one of the long description methods discussed in complex images.
For example, it is common to use a gear icon to represent the app settings. If the screen reader says “gear” or “gear icon”, it would not be very helpful to the user. If it says “open settings”, on the other hand, it is much more useful.
The same rule also applies to links. Simply restating “read more” is not sufficient, as it does not include the context.
Skimming the page is not just visual
When you first land on a page, your first instinct may be to skim its contents to get an overview of the structure. Users with a screen reader are no different, but they are constrained by how the page is structured.
Try turning on the screen curtain on your computer and visit your app with only voice-over (see: Mac instructions, Windows instructions). You will likely see that simply following the page navigation structure can be tricky and may not be conducive to getting a good overview of the page.
According to Online & Search Behaviours of Blind Users by Kayla J. Heffernan:
💡 Only 5.4% of skilled users and 18.4% of novices listen to a web page in linear order, and typically only when using a page for the first time. The majority (75%) navigate through links and headings as their main strategy.
It is easier (and a lot quicker) to navigate off of context rather than follow the navigation order of the page. Navigating off of context allows you to:
- get an overview of the page or product,
- highlight the main structure,
- skip elements,
- jump directly to the action button, and
- have more freedom.
See how to navigate off context.
Using HTML headings tags is the best way to provide context. Check out the best practices for using headings tags, written by Komodo.
Do not leave sound design behind
When you first open a page, you will likely see a progress indicator to show that the page is loading. If the progress indicator is shown for too long, you would likely assume that something is wrong. Now, imagine the same experience but without visual feedback. What would you think is going on?
When an action is in progress or has been completed successfully, sound design can be a helpful tool to provide feedback. You can essentially apply sounds to all the micro-visual interactions that you are using. They are useful for loading, failure, items added to a cart, success, updates, and more.
Sound should be intuitive, functional, and understandable. Check out the Google Material guidelines if you want to learn more about this topic.
Note: Do not spam your user. While sound design can be a very useful tool, it should be used thoughtfully and sparingly.
Hunt your ghosts
Some examples of ghosts are:
- Residual code elements, e.g. from an old design that someone forgot to remove.
- Elements with the wrong focus order. This includes things like inactive drop-down menus, off-screen navigations, or modals.
- Elements that are not meant to be discoverable with focus.
Most of the time, these elements are not directly visible for non-screen reader users, but they are very annoying for screen readers.
Assistive technology will:
- Detect empty spaces and residual elements. This will leave the user wondering what is going on. Is it a bug? Is the content not accessible?
- Detect non-discoverable elements. This confuses the user even more, or worse leads them to a keyboard trap, which breaks the keyboard navigation. Here’s an example of a keyboard trap applied to a menu and another of a keyboard trap with a dialog.
- Focus on distracting elements. As the focus order is defined by the DOM, if you are not taking care of the element order you can easily mislead your screen reader users.
When you use screen readers, you can detect these ghosts in the design. In this sense, you are like a medium, and following these ghosts can lead you down the wrong path.
To avoid this, you should test your page using keyboard navigation after every update, review the ordering focus, and remove the ability to focus on elements that are not meant to be discoverable.
Do not work alone
If your product is built by multiple teams, you must be careful about what the other teams are building. One new element can ruin the accessibility of all the pages.
For example, a simple pop-up or help assistant can make your website not accessible anymore by hijacking the keyboard navigation. You can avoid this situation if the dependencies are clear for everyone. If you have a DesignOps team, they should reduce the risk by assuring that teams are connected and working together. If you don’t have a DesignOps team, you should regularly check the backlogs of other teams to catch possible dependencies.
A few last words
While WCAG covers a wide range of accessibility issues, it does not cover every single use case. There may be some specific accessibility issues that are not explicitly addressed in WCAG, such as:
- Support for older technologies: This can be an issue for users who rely on these technologies and may not be able to access web content that is not compatible with them.
- Accessibility of certain types of content, such as complex data visualizations and interactive games.
- Accessibility of web-based applications. Some issues specific to web-based applications may not be explicitly addressed in WCAG as it is primarily focused on the accessibility of web content.
- Emerging technologies, such as virtual and augmented reality, that may not have been widely adopted at the time the guidelines were written.
It is important for designers and developers to be aware of these and to consider them in their work. Usability testing is an essential part of the design process when you want to make sure that you are building the right solution. Including users using assistive technology will help you to catch important pain points. Learning the theory is sometimes quite different than using it in practice.
Resources:
- Vigo, M., & Harper, S. (2013). Coping tactics employed by visually disabled users on the web. International Journal of Human-Computer Studies, 71(11), 1013–1025.
- Theofanos, M. F., & Redish, J. G. (2003). Bridging the gap: between accessibility and usability. interactions, 10(6), 36–51.
