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. +
+