When to use ARIA

In 2014, the W3C officially published the HTML5 recommendation. With it came some big changes, including the addition of landmark elements such as <main>, <header>, <footer>, <aside>, <nav>, and attributes like hidden and required. With these new HTML5 elements and attributes, coupled with increased browser support, certain parts of ARIA are now less critical.

When the browser supports an HTML tag with an implicit role with an ARIA equivalent, there is usually no need to add ARIA to the element. However, ARIA still includes many roles, states, and properties that aren't available in any version of HTML. Those attributes remain useful for now.

This brings us to the ultimate question: When should you use ARIA? Thankfully the WAI group has developed the five rules of ARIA to help you decide how to make elements accessible.

Rule 1: Don't use ARIA

Yes, you read that right. Adding ARIA to an element does not inherently make it more accessible. The WebAIM Million annual accessibility report found that home pages with ARIA present averaged 70% more detected errors than those without ARIA, primarily due to the improper implementation of the ARIA attributes.

There are exceptions to this rule. ARIA is required when an HTML element doesn't have accessibility support. This could be because the design doesn't allow for a specific HTML element or the wanted feature/behavior isn't available in HTML. However, these situations should be scarce.

Don't

<a role="button">Submit</a>

Do

<button>Submit</button>

When in doubt, use semantic HTML elements.

Rule 2: Don't add (unnecessary) ARIA to HTML

In most circumstances, HTML elements work well out of the box and do not need additional ARIA added to them. In fact, developers using ARIA often have to add additional code to make the elements functional in the case of interactive elements.

Don't

<h2 role="tab">Heading tab</h2>

Do

<div role="tab"><h2>Heading tab</h2></div>

Do less work and have better-performing code when you use HTML elements as intended.

Rule 3: Always support keyboard navigation

All interactive (not disabled) ARIA controls must be keyboard accessible. You can add tabindex= "0" to any element that needs a focus that doesn't normally receive keyboard focus. Avoid using tab indexes with positive integers whenever possible to prevent potential keyboard focus order issues.

Don't

<span role="button" tabindex="1">Submit</span>

<span role="button" tabindex="0">Submit</span>

Caution: Remember, people with and without visual impairments use keyboard navigation. Don't add unnecessary tab stops to headings and paragraphs, as these can add additional challenges for some users who navigate by keyboard alone.

Rule 4: Don't hide focusable elements

Don't add role= "presentation" or aria-hidden= "true" to elements that need to have focus—including elements with a tabindex= "0". When you add these roles/states to elements, it sends a message to the AT that these elements are not important and to skip over them. This can lead to confusion or disrupt users attempting to interact with an element.

Don't

<div aria-hidden="true"><button>Submit</button></div>

Do

<div><button>Submit</button></div>

Rule 5: Use accessible names for interactive elements

The purpose of an interactive element needs to be conveyed to a user before they know how to interact with it. Ensure that all elements have an accessible name for people using AT devices.

Accessible names can be the content surrounded by an element (in the case of an <a>), alternative text, or a label.

For each of the following code samples, the accessible name is "Red leather boots."

<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>
<!-- A linked image, where the image has alt text. -->
<a href="shoes.html">
    <img src="shoes.png" alt="Red leather boots">
</a>
<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>

There are many ways to check an element's accessible name, including inspecting the accessibility tree using Chrome DevTools or testing it with a screen reader.