ARIA 1.1 Candidate Recommendation Implementation Information

How to test WAI-ARIA

The markup language features defined by WAI-ARIA are processed by user agents in accordance with the Core Accessibility API Mappings and Accessible Name and Description: Computation and Accessiblity API Mappings, which defines how WAI-ARIA features are exposed to platform accessibility APIs. Because there are several accessibility APIs on several operating systems that each have several user agents, the goal is to demonstrate that there are at least two interoperable passing examples for each test on any two combinations of user agent plus operating system plus accessibility API. Two implemenations of each feature are required, but not two implementations of each mapping.

WAI-ARIA will be tested by examining how user agents that consume ARIA-enhanced HTML content directly represent and respond to it in accessibility APIs. Implementations are discrete combinations of:

• a user agent,
• on a given operating system,
• exposing content to a given accessibility API.

A given user agent, operating system, or accessibility API may participate in several combinations that form discrete implementations.

Most assistive technologies interact with ARIA-enhanced content via the accessibility API in the same manner as they do with desktop applications. Specific rules for this are out of scope for WAI-ARIA and assistive technology behavior will not be tested as a formal part of the Candidate Recommendation process. Some assistive technology testing may be performed to provide advisory information for Web content authors.

The following types of tests will be executed:

• Unit tests for proper handling of each ARIA role, state / property, and state / property value, separately from each other. Error conditions, such as use of unknown or abstract roles, invalid values, invalid application of states and properties, etc. will also be tested.
• Feature tests for specific objects that require several WAI-ARIA roles, states, and properties together to assemble the feature, such as widgets that require several states or properties in addition to the role, and complex objects that require several elements with various ARIA roles to work together. Specific features include each widget that uses states and properties beyond global ones, and features that require the interaction of two or more elements with ARIA roles.
• Dynamic tests that modify document roles, states, properties, and associated HTML content, and verify that these are reflected correctly in accessibility API mappings, and that user agents generate the appropriate accessibility API events in response to these changes.
• Any normative statement using the RFC2119 MUST keyword that is not covered by the above categories.

Only features that are new or changed in ARIA 1.1 (from ARIA 1.0) will be tested. Test cases are identified in ARIA 1.1 Testable Statements.

Testing procedure

For ARIA 1.1, the Working Group hopes to perform automated testing. This testing depends on development of Accessible Technology Test Adapters. If ATTAs are not available for certain platforms, manual testing will have to be performed. Test results will be aggregated in the Web Platform Tests report.

At any time, you can send any questions about this process or your implementation experience to public-aria@w3.org.