Skip to Content 
TranslationsARIA 1.0 Candidate Recommendation Implementation Information
Quick links: Test Plan, Implementer Instructions, Test Harness, Implementation Report
ARIA 1.0 was published as a W3C Candidate Recommendation on 18 January 2011. See the e-mail announcement and blog post.
How to test WAI-ARIA
The markup language features defined by WAI-ARIA are processed by user agents in accordance with the WAI-ARIA User Agent Implementation Guide, 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 4 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.
WAI Encourages a Broad Range of "Test Drives"
The primary purpose of this Candidate Recommendation stage is for developers and designers to "test drive" WAI-ARIA to demonstrate that it can be implemented in user agents. The Protocols and Formats Working Group now needs the Web development community to help with:
@@
Implementation experience from all sources is welcome to help demonstrate this diversity.
Working Together on Implementation Experience
Here's our plan to make the process effective and efficient for those sharing implementation experience, and for the Protocols and Formats Working Group:
@@
At any time, you can send any questions about this process or your implementation experience to team-wcag2-implementations@w3.org (an internal list, not publicly visible).