ARIA Guidance

Overview

This post provides some discussion about 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 HTML and other markup specifications: indicating main structural areas of a page, creation of roles and properties of user interface elements, a method to indicate alerts, page changes, and dynamically updating information. The ARIA specification adds attributes to the elements of a markup language providing the building blocks for complex user interface controls, indicating dynamic content, and for clarifying the structure of pages. The HTML 5.x specifications include the roles model ARIA as well as additional structural elements such as header and footers that coincide with but do not supplant the use of ARIA.

Use of ARIA is important and it continues to evolve — the latest version ARIA 1.1 is currently a candidate recommendation from the W3C. It is not required to meet WCAG 2 success criteria — in fact native HTML markup should be used whenever possible. However, ARIA may be needed when custom controls must be used or when there is no native language support for something ARIA provides such as live regions. The use of ARIA is an advisory technique for several success criteria. ARIA techniques can also be sufficient methods to meet a number of WCAG 2 success criteria (when ARIA is known to be supported by the assistive technology used with a site). Today most if not all modern assistive technology support ARIA albeit to different degrees.

Browser and Assistive Technology Support

In order for ARIA to work as designed it must be supported by the assistive technology and the browser. ARIA is supported in multiple degrees with different browsers. Even browsers that support ARIA may not fully support ARIA the specification. Some older browsers may not fully support ARIA yet some ARIA features are available to users of assistive technology such as users of the JAWS and NVDA screen readers. This occurs because the screen reader can obtain some ARIA information from the document object model (DOM). However, MSAA/UIA properties and events will not be triggered by the browser.

Assistive technology support for ARIA is not complete. Some assistive technology such as Window-Eyes and Dragon Naturally Speaking have support ARIA with limitations. 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 made

Use and Application

It is recommended to use ARIA whenever necessary. The use of HTML sectioning elements and main is strongly encouraged — or if not possible equivalent ARIA landmarks are a good starting point for use on any site or application. If the app or site uses dynamically updating content, that is another good area to start using ARIA. We continue to recommend use of techniques that support progressive enhancement to ensure that the site or app provides semantic information without ARIA. Progressive enhancement starts with standard semantic HTML markup and then adds additional enhancements such as ARIA on top of that structure. This approach ensures that the largest number of users can access the content.

When ARIA and older techniques are combined caution should be used not to cause “double speaking” of information by ARIA supported assistive technology. 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. This technique though may not be supported by some versions of screen readers.

Some solutions may only be practical using ARIA and in these cases ARIA alone may meet requirements on a particular environment – such as a closed system or within a given organization that has certain assistive technology and browser requirements and provides updates to these.

Evaluation Techniques

In our audits Level Access may occasionally flag any ARIA implementation that does not have a non-ARIA fallback (progressive enhancement technique) implementation. For example, the use of aria-labelledy to label a form field without using explicit labels or title attributes would be flagged when we know an assistive technology that does not support ARIA is used. 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 the ARIA techniques used then use of ARIA supports the conformance to WCAG and is not sufficient.

Just like any specification or language, ARIA can be used incorrectly, the improper implementation must be flagged. Types of ARIA issues range of syntax issues such use of multiple role types for element or an invalid role. Other semantic issues may occur such as applying aria attributes with non-sensible but valid or stale values or apply a user interface role that is not appropriate for a given control.
Level Access’ AMP (Accessibility Management Platform) 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 implementation techniques have already or will be weaved throughout most of the standard best practices across the web technology platform.

Conclusion

Level Access’ recommendations on ARIA and the latest version of the specification evolve over time and will continue to be updated as support for new ARIA versions increase.