Answering “What ARIA can I use?”

New! AT support tables in the Authoring Practices Guide (APG)

The ARIA and Assistive Technologies Community Group (ARIA-AT CG) and ARIA Authoring Practices Task Force (APG TF) are excited to announce the launch of “Assistive Technology Support” tables in the ARIA Authoring Practices Guide (APG). This initial release includes tables showing JAWS, NVDA, and VoiceOver support levels on four pages that demonstrate pattern implementations, including Button Examples, Link Examples, Radio Group Example Using aria-activedescendant, and Alert Example. More are coming soon.

This “Can I Use…” like data showing how three screen readers support four UI pattern implementations represents a sea change in accessibility engineering. The data are the first taste of the fruits of nearly five years of collaboration, learning, community building, and process and infrastructure development.

That fruit makes predictable screen reader behavior possible. That possibility portends a world where any web developer can build rich web experiences that work well with any assistive technology as readily as they can create experiences that work in any browser for people who do not rely on assistive technology.

The problem of the “accessibility supported” puzzle

It has always been a struggle, often a monumental and expensive one, for web developers to find ways of coding experiences that are understandable by users of any assistive technology (AT). You get your site working with one AT and it ends up not working as well with another. Then the experience of your site with an important AT degrades because the latest version of that AT includes changes to better support a popular site that has encoded a similar experience in a different way. Of course, the degradation was unintentional. As is often the case, accessibility experts frequently have conflicting understandings of how to satisfy relevant specifications. Consequently, unintentional negative side effects are difficult if not impossible to avoid.

Web, browser, operating system, and AT developers are all attempting to cut pieces of a puzzle. Everyone hopes that, when assembled, the puzzle will picture a usable web built from accessibility supported experiences. Unfortunately, while browser and operating system developers get pretty clear and stable maps showing where to draw their cutting lines from specifications for ARIA, HTML, and various accessibility APIs, web and AT developers do not. They do their best, but the act of drawing moves the puzzle board, messing up the lines being drawn by others. What’s worse is they occasionally discover ink has randomly disappeared. So, the way the picture is divided constantly changes. Sometimes pieces fit together, giving users a good experience, but far too often, they don’t.

Understanding WCAG conformance defines what we need for a new technology, like an ARIA-enabled UI pattern, to be accessibility supported:

“When new technologies are introduced, two things must happen in order for people using assistive technologies to be able to access them. First, the technologies must be designed in a way that user agents including assistive technologies could access all the information they need to present the content to the user. Secondly, the user agents and assistive technologies may need to be redesigned or modified to be able to actually work with these new technologies.”

So, even when browsers and accessibility APIs are perfectly implementing their specs, we don’t yet have everything necessary to design and build web UI patterns that are “accessibility supported.” For that, we also need:

1. Consistent understanding across web development communities of “all the information assistive technologies need to present” a given pattern, which accessibility semantics best represent that information, and which ways of coding the pattern accurately express those semantics.
2. Consistent interpretation and rendering of accessibility semantics across the AT industry, such that there are shared expectations for acceptable AT responses to a given semantic in a given pattern.
3. All stakeholders having sufficiently similar understanding of the meaning of “actually works” for any given pattern.

In other words, web developers and AT developers need to be on the same page, and that page must not only synthesize information from a wide variety of specifications but also include information about what “actually works” for AT users that has not been available anywhere.

Helping map the rest of the “accessibility supported” puzzle

The ARIA-AT CG and APG TF have been jointly working to align the web development and AT developer communities. They are building missing pieces of the foundational infrastructure needed to generate the information and consensus that can make “accessibility supported” web UI patterns available to any web developer and users of any AT.

First, to foster harmonization of how accessibility semantics are used in practice by web developers, the APG TF has been transforming the Authoring Practices Guide into a platform that supports the multiple facets of that goal. To start, it provides thirty patterns for using ARIA semantics. To demonstrate how to apply those patterns in practice, it also includes more than 60 example implementations of the patterns. As of the time of this announcement, the APG also provides the equivalent of “can I use …” data, i.e., AT support tables, for four of the reference implementations.

That “can I use …” type of data comes from the ARIA-AT project. The objective of ARIA-AT stated in terms of “WCAG accessibility supported” is to build consensus for definitions of “actually works” that are specific to every accessibility semantic defined within a specification related to ARIA. It is starting with semantics employed in APG patterns.

The challenge of defining and testing AT behavior that “actually works”

Figuring out how to define, develop consensus for, and test baseline expectations for AT behaviors has proven to be as fantastically challenging as anyone might have imagined. In 2018, the ARIA-AT CG set a five-year goal of testing 60 APG examples with three desktop screen readers and two mobile screen readers. Even with the scope limited to a select few screen readers, the goal was more ambitious than we anticipated. Last year, we had to dial back our end of 2023 target to testing 30 examples with three desktop screen readers. The good news is that progress is solid, and the community group is proving that 1) AT interoperability is a realistic industry goal, and 2) if we can keep the work funded, universally available accessibility supported web sites can one day be a reality.

At a high level, the major elements of the APG TF and ARIA-AT CG AT interoperability work are:

1. Build the supply of sufficient, robust, and stable test cases that represent real-world usage of accessibility semantics. The initial source is the APG. There could be many more in the future.
2. Craft statements of expected AT behaviors in the form of test plans. This is very difficult work that is executed by community group members from Prime Access Consulting, which you can read about on the PAC blog.
3. Develop systems for managing the stakeholder consensus process, manually running tests, and serving reports. These systems are being delivered by community group members who work at Bocoup, and you can learn more about that work in this post on their blog.
4. Develop and implement an AT automation standard that enables tests to be re-run within continuous integration systems for every new version of an assistive technology or browser. As described in the two previously referenced posts, Bocoup is leading development of the AT Driver standard, and PAC is developing the NVDA implementation.

All that is enablement. The deliverables from those workstreams make it possible for community group members and stakeholders to run tests, gather feedback on test plans, define issues, negotiate consensus solutions, incorporate resolutions into test plans, and finally raise and resolve AT bugs.

Screen reader partnership

Given that the community group is kickstarting AT interoperability with an initial focus on the three most popular desktop screen readers, progress depends on effective collaboration with the developers of those screen readers. One of the critical enablers of today’s launch has been the involvement and responsiveness of Vispero and Apple.

Negotiating the details of how to test interoperability and adjusting screen reader behaviors to align with the expectations defined by the tests is substantive work. The community group is seeking ways of helping NVAccess (developer of NVDA) build the capacity it would need to support it as well.

What’s next

In coming months, AT support tables will be added to more APG example pages. The ARIA-AT CG is developing a quarterly schedule for covering the rest of the APG, and we plan to make it publicly available soon. Over the course of 2023, as we integrate automation into the process, the tables will include data for more screen reader and browser combinations.

In 2024, as we complete the first round of test plans for desktop screen readers, we plan to start adding test plans for mobile screen readers. Assuming continued success and funding, the project will expand to support more types of assistive technologies and test more accessibility semantics.

Get involved

To learn more about how you or your organization can participate or support the project, visit our wiki page about contributing to the project.