Skip to content Skip to navigation


The Web Accessibility Initiative has created techniques and guidance to help developers make web applications, widgets, and other JavaScript-based functionality accessible. Together, this collection of techniques is known as WAI-ARIA, or typically ARIA, for short. ARIA (the term we will use on this site) stands for Accessible Rich Internet Applications.

Generally, ARIA provides the "hooks" that assistive technologies need to work successfully with JavaScript content such as tabs, accordions, carousels, date-pickers, sliders, and the like. For example, ARIA permits a screen reader to speak content in "live regions" -- areas of the page where content changes, but where an end-user may not be focused when a change is made.

Rules of ARIA

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:

  • Do not change native semantics, unless you really have to.
  • All interactive ARIA controls must be usable with the keyboard.
  • Do not use role="presentation" or aria-hidden="true" on a visible focusable element.
  • All interactive elements must have an accessible name. (Note that this fifth rule of ARIA is a work in progress).

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.

ARIA Roles, States, and Properties

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.

Who Does ARIA Help?

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.

How Can I Learn More

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.

What's Next?

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 Patterns page on the SOAP site includes many sets of ARIA examples. The ARIA example sets focus on "vanilla" JavaScript; please consult the Frameworks page, as needed. You can use AViewer to inspect your code for ARIA-related issues; it is only available for Windows. You may find that other tools you use begin to add this capability, so be sure to ask your colleagues and check the SOAP site's Tools pages for the latest news.

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.

Current Documents from the Web Accessibility Initiative

WAI-ARIA 1.1 Drafts

Target Audience: 
Last modified: 
June 27, 2015