According to Notes on Using ARIA in HTML (version dated May 21, 2015), the first rule of ARIA reads, in part:
If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
What this means, in practice, is that you should use native HTML whenever possible, such as for links and buttons. Other rules include:
You will certainly want to review Notes on Using ARIA, along with the other Resources included on this page, to understand the context of these rules. But they should give you a sense that ARIA needs to be implemented with care.
When you provide ARIA roles, states, and properties to build your web-based application#39's user interface, you are able to provide user of assistive technology with an accessible interactive experience. ARIA roles, states, and properties convey the semantics in a widget. For example, an end-user is able to know the state of a checkbox. Is it checked, unchecked, or partially checked? An end-user can identify which tab has been selected, whether a button to expand or collapse content has been pressed, or whether an option has been disabled.
At least at this time, WAI-ARIA is primarily helpful to screen reader users, although those who use voice input, such as Dragon Naturally Speaking, are beginning to be able to take advantage of it, too. Correctly implementing ARIA requires that the rendered output be tested. It is critical to assure that the assistive technology, browser, Document Object Model (DOM), and accessibility tree are all working together effectively. As a result, it will be important to conduct Screen Reader Testing on your ARIA content. In addition, browsers and assistive technologies handle some ARIA features differently, so if you do not get the results you expect, you may need to research the issue. Asking questions on the Web AIM discussion group is a good place to start.
This topic can be somewhat complicated, especially because the accessibility landscape continues to evolve. On this page, we are providing a very basic overview, with links to what are expected to be stable resources. But the best way to understand ARIA is to receive virtual or face-to-face hands-on training where you can work with code and test with desktop and mobile screen readers. Please consult the Training page and/or contact us to inquire about ARIA-related training on campus.
Before you leave this page, you will want to get a sense of the the current ARIA 1.0 documents from the W3C, as well as pointers to ARIA 1.1, which is on the horizon. Even if you find reading specifications dull and boring, especially when it comes to ARIA, you will benefit by familiarizing yourself by at least skimming some of the documentation. Simply copying and pasting from code samples is not a guarantee of success. The code samples will help you move in the right direction, but knowing what they mean and how to test them effectively is essential.
The WAI-ARIA Landmarks and WAI-ARIA Widgets pages address these two topics in a bit more detail. The WAI-ARIA Widgets page provides links to articles about several common widgets and can be useful instead of, or in addition to, the ARIA samples included on the Patterns page, depending on your needs.
While implementing ARIA can be a challenge, it is absolutely critical that you know when it is necessary and to implement it correctly. ARIA is not a "magic accessibility bullet," but when it is implemented strategically, it can turn a frustratingly unusable application into a delightful experience for end-users of assistive technologies.