Sep 12, 2022
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications, often referred to as simply ARIA) is a technical specification intended to improve accessibility. By understanding how these attributes function, you can build content that works for a wider range of users. However, it’s important to remember that native HTML is always preferable to ARIA. In other words, you should only use ARIA if it’s absolutely necessary for defining the semantics of your content.
If you’re new to ARIA, we recommend reviewing common ARIA misconceptions and reading the W3C’s Using ARIA guide before writing markup. Some mistakes can create additional barriers for people who use AT, so you’ll need to test carefully. Working with an accessibility partner can ensure that your content works predictably.
What are ARIA roles, states, and properties?
A role defines the type of user interface element. A state or property supports those roles by providing extra information about any changes that occur.
In other words, an element’s role won’t change, but its state or property might change. Generally, the state changes frequently, while the property changes much less often.
ARIA Roles: A Brief Overview
WAI-ARIA roles define the structure of content when native HTML cannot. Once again, that’s an extremely important point: If you can use native HTML to define an element, you should always do so.
ARIA roles fall into one of six categories:
- Document Structure roles, which describe the structure of a section of content.
- Widget roles, which define interactive patterns (especially JavaScript widgets).
- Landmark roles, which identify the organization and structure of a web page.
- Live Region roles, which define elements of content that will change dynamically.
- Window roles, which define dialog boxes, alerts, and other sub-windows to the main document window.
- Abstract roles, which are only used by browsers and should not appear in HTML markup.
Developers will only use ARIA roles from the first five categories.
Since roles change the presentation of content for AT users, they must be used correctly — misusing the “application" role, for example, might prevent screen reader users from regaining control of their computers.
Related: Avoid Accessibility Issues When Using ARIA's "Application" Role
ARIA States & Properties
ARIA states are often updated with JavaScript, and as we discussed above, they may change frequently. Properties typically describe relationships between the element and other elements, so they’re often less dynamic.
States and properties fall into one of four categories:
- Widget attributes
- Live region attributes
- Drag-and-drop attributes
- Relationship attributes
States and properties may be associated with the ARIA role of the element. However, global attributes such as aria-live apply to all HTML elements, regardless of whether those elements have an ARIA role.
This is another reason to test your content — states and properties need to be correctly applied to elements to improve accessibility.
Related: 4 Questions to Ask Before Using ARIA
A Quick Example of ARIA Markup
To understand how roles, states, and properties work together, here’s an example of a progress bar widget from the Mozilla Developer Network’s ARIA resource page:
<div id="percent-loaded" role="progressbar" aria-valuenow="75"
aria-valuemin="0" aria-valuemax="100">
</div>
In this example, the “progressbar" role tells the user that they’re encountering a progress bar.
For many purposes, the HTML <progress> element could be used instead. However, in this case, the progress bar uses the <div> element, which has no semantic value. ARIA is necessary to make the progress bar accessible for assistive technologies.
The aria-valuenow, aria-valuemin, and aria-valuemax attributes convey the current value, minimum value, and maximum value of the slider, respectively. Without these attributes, the user might not understand how to use the element.
Related: How ARIA Can Help Make Your Website Accessible
Before using ARIA, make sure it’s essential — and test your work
Many developers treat WAI-ARIA as an afterthought. This is a mistake: Your ARIA implementation will affect the experiences of AT users, and if you don’t test your content, you’re taking a major risk.
The W3C recommends using ARIA in three specific circ*mstances:
- The feature is available in HTML but it is not implemented or it is implemented, but accessibility support is not.
- The visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.
- The feature is not currently available in HTML.
If your website doesn’t have dynamic content, you might not need ARIA at all — but once you’ve made the decision to use ARIA, you should commit to using it appropriately.
Automated accessibility audits can be helpful for identifying certain ARIA issues. However, some ARIA issues require human judgment and expertise. An experienced accessibility partner can help you avoid mistakes, test your content against the W3C’s Web Content Accessibility Guidelines (WCAG), and provide your users with an optimal experience.
For assistance with ARIA, contact the Bureau of Internet Accessibility or test your content with our free automated WCAG 2.1 Level AA compliance summary.
