See all posts

What is WAI-ARIA and When to Use It

by Marja Peltopihko | 23 Sep 2024
WAI-ARIA ● ARIA ● Accessibility ● HTML

WAI-ARIA is not directly mentioned in the WCAG 2.2 guidelines. So, what does it have to do with accessibility?

What is WAI-ARIA?

WAI-ARIA stands for “Web Accessibility Initiative - Accessible Rich Internet Applications” and is commonly referred to as ARIA. ARIA is developed and maintained by the W3C.

ARIA provides a set of rules and attributes that allow developers to define more refined semantics for UI elements. When JavaScript is added to enhance user interactions, extra guidance is often needed for screen readers and other assistive technologies. ARIA enables the use of non-semantic HTML, though this doesn’t mean developers should aim to write non-semantic HTML. ARIA helps accessibility tools communicate what’s happening on the page and what interactions are possible.

HTML vs. ARIA: Which Should You Use?

When comparing HTML to ARIA, ARIA should always be a last resort. If a semantic HTML element is available, use that. For instance, there’s no need for HTML like this: <div role="navigation">...</div>. Instead, use the native HTML element <nav>...</nav>.

Before using ARIA, check the native HTML elements to ensure none apply to your situation. A lot can be achieved with HTML alone.

How to Use ARIA

ARIA consists of roles and attributes. Let’s explore their purposes.

Roles

ARIA roles make it possible to describe an element’s function in a way that HTML can’t. HTML elements have no role unless one is specifically assigned, except for form elements like which automatically has the role of “radio.”

ARIA includes roles such as tooltip, tab, and dialog. The roles can be divided into six categories: (1) document structure roles, (2) widget roles, (3) landmark roles, (4) live region roles, (5) window roles, and (6) abstract roles. You can find the full list of roles on MDN.

Many roles have HTML equivalents, so typically there’s no need to use role="article" when you can use the native <article> element. However, in certain cases, assigning a role is necessary. For example, live region roles help alert screen readers to elements that require the user’s immediate attention.

That said, it’s crucial to use role="alert" only when the user’s immediate attention is genuinely required. Misusing it can disrupt the user experience by diverting the screen reader’s focus. Just because you, as a developer, think something is urgent doesn’t mean the end user will feel the same way.

Attributes

ARIA attributes modify an element’s state or properties. ARIA attributes may be used to modify the styles with e.g. [aria-hidden="true"] { display: none }. Most often ARIA attributes are targeted towards the accessibility tree. Simply adding attributes like aria-hidden="true" or aria-expanded="true" won’t impact the visual appearance of the page, but will update the accessibility tree. This allows elements to be hidden from assistive technologies or signals that one element controls another that is currently expanded.

Like roles, attributes are divided into categories: (1) widget attributes, (2) live region attributes, (3) drag-and-drop attributes, and (4) relationship attributes. ARIA attributes follow the format aria-something, such as aria-hidden or aria-valuemax. These attributes require specific value types, such as boolean (true/false), predefined sets of values, or specific types like integer. The full list is available on MDN.

Some attributes are global. For instance, aria-label and aria-labelledby are global and can be used with any element. Non-global attributes, however, must be paired with specific ARIA roles. For example, aria-autocomplete must be used with either combobox, searchbox, or textbox.

The Five Rules of ARIA

Along with roles and attributes, ARIA has rules that guide its use:

  1. Always use semantic HTML instead of ARIA roles.

  2. Never change native semantics with ARIA roles.

  3. Ensure all interactive elements are keyboard-accessible.

  4. Do not set role="presentation" or aria-hidden="true" on focusable elements.

  5. Interactive elements must have an accessible name.

For a complete list of rules with examples, visit W3C’s “Using ARIA” page. Some exceptions to these rules are also noted there.

I won’t go into further detail in this post, as some of these rules deserve dedicated blog posts. Hopefully, more on this topic will follow in the future.

So, When Should You Use ARIA?

Here are a few examples, though the list is far from exhaustive.

aria-hidden

If a visual element is purely decorative, it should always be marked with aria-hidden="true", letting screen readers and other tools know to ignore it. Even when a logo functions as a link to the homepage, the actual SVG should be marked as aria-hidden. I checked the dev blog’s logo and the SVG isn’t marked as aria-hidden.

<a href="https://www.solita.fi" aria-label="Solita's website">
  <svg width="46" height="56" xmlns="http://www.w3.org/2000/svg">
    <path d="M0 56V28h14v28H0zm32-28V0h14v28H32zM16 56V0h14v56H16z" fill="#282828" fill-rule="evenodd"></path>
  </svg>
</a>

The correct way for the SVG:

<svg width="46" height="56" xmlns="http://www.w3.org/2000/svg" aria-hidden="true">
  <path d="M0 56V28h14v28H0zm32-28V0h14v28H32zM16 56V0h14v56H16z" fill="#282828" fill-rule="evenodd"></path>
</svg>

Any visual element should either be marked as aria-hidden or given a descriptive, textual alternative. For <img> element, an empty alt-text alt="" works the same as aria-hidden.

aria-valuenow, aria-valuemin, and aria-valuemax

For elements like sliders, users can visually infer the range, but those using assistive technologies require more explicit information. Aria-valuenow indicates the current value, while aria-valuemin and aria-valuemax define the allowable range.

<p id="x-label">How many [things of X] do you want?</p>
<div
  role="slider"
  id="x"
  aria-valuenow="10"
  aria-valuemin="0"
  aria-valuemax="100"
  aria-labelledby="x-label">
  ...
</div>

The same kind of element could be created with native HTML without any ARIA attributes:

<label for="x">How many [things of X] do you want?</label>
<input type="range" id="x" min="0" max="100" value="10" />

aria-selected and aria-multiselectable

Aria-selected can be used with ARIA roles gridcell, option, row, and tab to indicate which option is selected.

While users can visually tell if multiple selections are allowed, assistive technologies require aria-multiselectable="true" to indicate that more than one selection is possible.

<p id="frosting-color-options">What color frosting you want for your cake?</p>
<ul
  tabindex="0"
  role="listbox"
  aria-labelledby="frosting-color-options"
  aria-multiselectable="true">
  <li id="red" role="option" aria-selected="false">Red</li>
  <li id="orange" role="option" aria-selected="false">Orange</li>
  <li id="yellow" role="option" aria-selected="true">Yellow</li>
  <li id="green" role="option" aria-selected="false">Green</li>
  <li id="blue" role="option" aria-selected="false">Blue</li>
</ul>

By ARIA’s first rule, a native <select> component with the multiple attribute should be used. However, there may be cases where using an unordered list with ARIA attributes is more appropriate.

Conclusion

So, should ARIA roles and attributes be avoided? Not entirely.

ARIA is a powerful tool that aids users who rely on assistive technologies. However, it should be used sparingly and only when necessary. Improper use of ARIA can do more harm than good.

In fact, a survey of over one million home pages by WebAIM found that pages using ARIA had, on average, 34% more detected errors than pages without it. As W3C’s read-me-first guide advises: “No ARIA is better than bad ARIA.”