The ARIA and Assistive Technologies Community Group (ARIA-AT) and ARIA Authoring Practices Task Force announced the first “Assistive Technology Support” tables in the ARIA Authoring Practices Guide (APG). These support tables show how well the examples for the patterns are supported by screen readers such as NVDA, Jaws, and VoiceOver. Only a few patterns and assistive technologies have support tables right now, but more are coming. This initial release includes support tables for Button Examples, Link Examples, Radio Group Example Using aria-activedescendant, and Alert Example. Read the W3C Announcement for further details.
What is ARIA-AT and why is this important?
Several years ago, it was common for a CSS property to result in different visual renderings across major browsers and platforms. That’s because these CSS properties were not well supported across browsers, and there wasn’t always a consensus on how they should affect the visual experience. The same held true for other web platform features that developers needed to use and resulted in developers needing to implement a lot of workarounds and fallbacks to support the major browsers.
Since then, a lot of work has been done to build consensus, test expectations (such as web platform tests), and improve support for web platform features. Now, it’s much less common to find support gaps in web platform features. And there are resources like caniuse.com to reveal gaps in support that do exist.
This consistency in support empowers people to use whichever browser they want, without having to switch between browsers, spend time learning new browsers, or otherwise deal with gaps in support. It also empowers developers to deliver faster with more consistency and less technical debt.
However, it’s still common for people with disabilities to encounter gaps in support when using assistive technologies. The same HTML and ARIA often behave very differently from one screen reader to the next, if it is even supported at all. Additionally, it can be difficult for developers and testers to know if these differences in behaviors are expected or if there really is a problem.
ARIA-AT aims to improve this by proposing support expectations for assistive technologies, testing those expectations, building consensus around those expectations and test results by partnering with assistive technology developers, publishing those results, and then scaling with automated testing.
How this helps development teams
These support tables, along with other ARIA-AT data and resources, can help designers, developers, testers, and consultants in various ways. For example, they can help to answer these questions:
- Designers: I want to select a pattern that has robust support – but how do I know what those patterns are? What are the accessibility consequences of using one pattern over another?
- Developers: Is this bug a problem with my code or something else? How can I code this in a way that will be well-supported?
- Testers: Is the screen reader behaving in the expected way?
- Consultants: How do I give advice that will be supported by many screen readers and other assistive technologies?
What’s next?
In the future, ARIA-AT will be:
- Adding AT support tables to more APG examples.
- Adding support results for more screen reader and browser combinations.
- Adding more types of assistive technologies.
- Testing more than just the examples in the APG.
- Automating the testing and creating an assistive technology driver, much like WebDriver, to facilitate this testing.
To learn more about how you or your organization can participate in or support the project, see the “Get Involved” section of the ARIA-AT Home page.
