This note aims to clarify the use and requirements of using ARIA. ARIA is a W3C specification for the creation of Accessible Rich Internet Applications. ARIA aims to provide support to users of assistive technology in three main areas that were not previously addressed by the (X)HTML specifications: indicating main structural areas of a page, creation of roles and properties of user interface elements, and as a method to indicate alerts, page changes and dynamically updating information.
- ARIA is a formal recommendation of the W3C as of March 20 2014.
- ARIA is not required to meet WCAG 2.0 success criteria.
- ARIA techniques are sufficient methods to meet a number of WCAG 2.0 success criteria
- Use of ARIA is an advisory technique for certain success criteria
- Native HTML semantics should be used where the semantic structure is available.
- Use of ARIA is important and will become more important in the future.
- In order for ARIA to work fully and correctly it must be supported by the assistive technology and the browser.
- ARIA is supported in multiple degrees with different browsers, but even browsers that support ARIA may not fully support ARIA.
- Some older browsers may not support ARIA yet some ARIA features are available to users of assistive technology such as JAWS or NVDA. This occurs because the screen reader can pull some ARIA information from the document object model (DOM). However, MSAA properties and events will not be triggered.
- Assistive technology support for ARIA is not complete.
- Some assistive technologies such as Window-Eyes (prior to version 8.0) and Dragon (prior to 13) do not support ARIA.
- Other assistive technologies support certain ARIA roles or properties but not others.
- Some ARIA techniques do not currently work as desired with assistive technology. For example, ARIA role=”dialog” or role=”application” may prevent the user from using the virtual cursor for navigation; thus when using these roles careful consideration must be taken.
- We do not require our clients to use ARIA unless a solution is not possible without ARIA.
- We generally advise our customer when an ARIA implementation does not have a non-ARIA fall back implementation.
- For example, the use of aria-labelledby to label a form field without using explicit labels or title attributes is a case to advise our customer as assistive technologies that do not support ARIA would not work correctly with this implementation.
- If a client can guarantee (and we can confirm) that the assistive technology stack and browsers that are required to be used with their product support ARIA fully then we do not need to advise on these techniques for that particular audit.
- If a client uses ARIA incorrectly, the improper implementation should be flagged.
- We recommend that clients use ARIA when needed.
- ARIA landmarks are a good first start at using ARIA.
- Dynamically updating content is a good area to start using ARIA.
- When ARIA and older techniques are combined caution should be used not to cause “double speaking” of information by ARIA supported assistive technologies. The aria-hidden attribute can be used to prevent double speaking.
- For example, if ARIA is used to indicate the role and state of page tabs and off-screen text is also used to indicate this information for non-ARIA assistive technologies the off-screen text should have the aria-hidden attribute set. aria-hidden and role=”presentation” may be useful in these situations. The role of presentation will obscure the native role of elements.
Relevance in AMP
- AMP contains an ARIA media type under the Web technology platform.
- This media type contains ARIA best practices related to grammar, syntax and semantics of ARIA use.
- ARIA roles, states, and properties are described in most best practices across the web technology platform.
Our policies on ARIA are evolving over time and will continue to be updated. This policy is similar to our policy regarding HTML 5.
If you have any questions please ask.