Rules for Using ARIA in HTML

24 January 2017

The Web Accessibility Initiative's Accessible Rich Internet Applications Suite (WAI-ARIA, or just ARIA) is a set of tools and guidelines for making web content and applications more accessible. Most notably, it includes a suite of attributes we can add to HTML elements to embed in them more semantic information that can be read by assistive technologies.

Although ARIA can be incredibly useful, we have to be careful of when and how we use it. Thus, there are 5 rules to take into account when using ARIA in HTML.

1. Use Semantic HTML5 in Favour of ARIA #

If you can use a native HTML element or attribute with the semantics and behaviour 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.

The number one rule for using ARIA in HTML, is to try not to use ARIA in HTML (if it’s not needed). HTML5 semantic elements provide us a wide range of elements that come with implicit meaning to them, similar to the explicit meaning we can define using ARIA.

So, wherever possible, we should use a semantic HTML element in place of an ARIA attribute.

Instead of creating a button using a <div> and ARIA role like this -

<div role="button">Click Me</div>

Incorrect method

We should just use an actual <button> element, like this -

<button>Click Me</button>

2. Don’t Alter the Meaning of Semantic Elements with ARIA Roles #

Do not change native semantics, unless you really have to.

As I mentioned, many HTML semantic elements have implicit meaning to them. When we use a <button>, for example, it is implied to user agents that this is an interactive element (interacted with through the cursor click, enter key, or space bar) that will trigger some interaction on the page. On the other hand, if we use a <a> element, it is implied to user agents that interacting with this element (through a cursor click or enter key) will navigate the user away from the page, or to a different location on the same page.

Because of the implicit meaning that many of these elements have, it is advised that we do not change them with ARIA roles.

<h1 role="button">Heading Button</h1>

Incorrect method

Instead of repurposing semantic elements, we should either use the appropriate element.

<h1><button>Heading Button</button></h1>

Preferred method

Or, as a last resort, we can apply the ARIA role to an element that doesn't carry such meaning.

<h1><span role="button">Heading Button</span></h1>

3. Interactive ARIA Elements must be Accessible by all Mediums #

All interactive ARIA controls must be usable with the keyboard.

Using an ARIA role on an element is not enough to really change the role of an element. If we are trying to change, for example, a <div> to a <button>, we need to manually add the interaction capabilities appropriate for a <button>.

In the ARIA Guidelines, there is a list of capabilities each element should have. For example, a valid button must satisfy the following requirements -

Must be clickable with a cursor
Must be clickable with the enter key
Must be clickable with the space bar

When using ARIA roles, we need to be aware of these requirements. Making an element look like a button doesn't make it one. We need to take into account how users in all mediums interact with the element.

4. Use Appropriate Roles for Visible Focusable Elements #

Do not use role="presentation" or aria-hidden="true" on a visible focusable element .

The ARIA attribute, role="presentation" implies that the element is for visual purposes only, and is not interactive in any way. The attribute, aria-hidden="true" implies that the element should be not be visible.

When we use these attributes, we need to be aware of the elements they are being applied to and what their visibility and interactive states are. For example, both these buttons will result in some users focusing on an element that doesn't exist to them.

<button role="presentation">Click Me</button>
<button aria-hidden="true">Click Me</button>

Incorrect method

These attributes should only be applied to elements who are non-interactive or not visible.

<button role="presentation" tabindex="-1">Don't Click Me</button>
<button aria-hidden="true" style="display: none;">Don't Click Me</button>

5. Interactive Elements must have an Accessible Name #

All interactive elements must have an accessible name.

Elements that can be interacted with, for example buttons and links, needs to have an "Accessible Name". The Accessible Name is determined when the Accessibility API accessible name property has a valid value.

The Accessible Name for an element can be specified depending on the type of element it is. Form inputs, for example, typically get their Accessible Name from a corresponding <label> element (see Labelling Form Elements).

<label>
  Username
  <input type="text">
</label>

<label for="password">Password</label>
<input type="password" id="password">

Other elements, for example buttons and links, can get their Accessible Name from their text content, or a label attribute (See HTML for Screen Readers).