Use of WAI-ARIA: 3 lessons in online accessibility

What blind users taught us

The use of WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) in the source code of online content can make a real difference to its level of accessibility. However, experience with blind users shows that it can also generate additional issues when not used correctly.

What is WAI-ARIA?

If you’re a developer interested in web content accessibility, you have probably come across WAI-ARIA. It’s a really useful specification that describes how you can greatly improve website and application accessibility by adding a few ‘keywords’ (i.e. WAI-ARIA roles, states and properties) to source code.

We recently conducted several user testing sessions to check the accessibility of clients’ digital products, and we observed first hand how the use of WAI-ARIA benefits many blind users. For example, we saw blind participants operating with ease sliders, tabs and collapsible panels whose functionality and status had been described via the use of WAI-ARIA roles, states and properties.

At the same time, we noticed how in some cases the inaccurate or inappropriate use of WAI-ARIA can generate – rather than solve – accessibility issues.

3 practices to avoid in the use of WAI-ARIA

1. Unnecessary inclusion of WAI-ARIA

Some developers seem to believe that the more WAI-ARIA mark-up you add to HTML code, the better. For example, we came across instances where the ‘application’ role had been used for web content that did not in fact represent an application. This not only confused all blind users, but also made the content difficult to operate with some screen readers.

2. Use of WAI-ARIA in place of standard HTML elements

WAI-ARIA does not replace HTML, it complements it. However, often we find that simple web components that could be coded with HTML elements are implemented with WAI-ARIA roles, states and properties instead. Note that even when WAI-ARIA mark-up is used correctly, this inevitably increases the risk of screen readers not interpreting and conveying content correctly.

In fact, not all browsers and assistive technologies fully support WAI-ARIA yet, which can result in blind users missing out on important information. We experienced this first hand, when some screen reader users who took part in a recent testing session could not recognise which radio buttons were selected, as they had been identified with ‘aria-checked’, which was not supported by IE11.

3. Misspelling of WAI-ARIA roles, states and properties

Unless spelt correctly, WAI-ARIA ‘keywords’ are not recognised by screen readers. A simple spelling mistake such as ‘politive’ (instead of ‘polite’), for example, caused important content not to be read out during some recent testing sessions.

Summary

Avoiding the three key mistakes above and using the WAI-ARIA mark-up according to the specification, will ensure that your websites and applications are more accessible to blind users. If you need further specialist guidance on the use of WAI-ARIA or testing content for accessibility, please get in touch!