Assistive Technology Support Tables
As the ARIA and Assistive Technologies Project makes reports on assistive technology interoperability for APG examples available, the APG Task Force adds summaries of assistive technology support to the relevant example pages. This page explains how to interpret and use the assistive technology support summaries.
Purpose of AT Support Tables
The purpose of the support tables is to provide an actionable summary of the interoperability tests performed by the ARIA-AT project.
Meaning of Support Levels
The assistive technology support tables present two percentages for each assistive technology and browser combination that have been tested: "Must-Have Behaviors" and "Should-Have Behaviors". A behavior designated as “Must-Have" is essential; if not provided, users could be blocked from using the UI element. Failure to provide a “Should-Have” behavior could impede users. Learn more about ARIA-AT’s definitions of Must and Should on the project wiki.
Examples of Must-Have Behaviors
- Convey the name of a radio button.
- Convey the state of a checked radio button.
Examples of Should-Have Behaviors
- Convey the position of a radio button in a radio group, e.g., the button is 1 of 3.
- Convey the number of radio buttons in a radio group.
Important Constraints
- Unless otherwise noted, all testing is done using the assistive technology vendor's default configuration of an assistive technology.
- ARIA-AT interoperability tests do not prescribe exactly how to satisfy a need. For example, they do not specify exactly what a screen reader should speak. Two different screen readers may convey the same information in different ways.
Recommendations
Don’t Code to the Bugs
ARIA-AT is working with assistive technology vendors to increase their support levels. This means that assistive technologies that align with ARIA-AT interoperability tests will change over time. Exercise caution when implementing a pattern where support levels are less than 100%. Avoid modifying code to accommodate an assistive technology bug unless you are confident the modified code provides an experience that:
- Works equally well when using assistive technologies that do not exhibit the bug.
- Will work equally well after the assistive technology bug is fixed.
When possible, test implementations of APG patterns with an assistive technology that provides 100% support for both must-have and should-have behaviors.
Design to Mitigate Critical Support Failures
Where feasible, avoid designing experiences that rely on features of APG patterns that have less than 100% support for must-have behaviors. If the must-have support level is less than 100% for one example implementation of a pattern, that does not mean every other way of implementing that pattern will present assistive technology users with the same problems. In these cases:
- If there are multiple implementation examples of the pattern, compare support levels across examples to discover whether another method of implementation provides better support.
- learn about the specific aspects of an example implementation that are not fully supported by navigating to the detailed report with the View Complete Report button.
- If possible, use the guidelines of the pattern to design interactions such that they avoid the problematic features.
Perform Your Own Tests
A primary purpose of ARIA-AT data is to help assistive technology vendors coordinate interoperable rendering of ARIA. While the ARIA-AT summary tables on APG example pages can be used as a guide of where to prioritize testing, the data is not as a final verdict on whether a feature in a web application will work. It is essential for all developers to test applications with multiple assistive technologies to ensure a good user experience.