What is ARIA?

What is ARIA?

ARIA in an acronym for "Accessible Rich Internet Applications." It is a set of HTML attributes which allow web application developers to create accessible, custom components or interaction patterns using non-semantic or non-native HTML elements. Assistive technologies consume these attributes and announce their presence to users who in turn are able to understand and interact with the components.

In other words, ARIA acts as a bridge between non-native HTML elements and assistive technologies by generating semantic meaning for custom components. ARIA helps to answer the question of, "What is this thing and what does it do?" for custom components.

How does ARIA accomplish this?

The ARIA set of HTML attributes get applied to various elements. From here, when a screen reader user comes in contact with an element featuring one or many aria-* attributes, screen readers will recognize the supplied attributes and their values and announce this information out loud.

ARIA can be broken down into:

  • Roles — define what an element is or does
  • Properties — express characteristics or relationship of an element
  • States — define the current conditions or data values associated with the element

Let's take a peek at a few of the attributes available:

Attribute Purpose Example
role Used to add or alter the base semantic meaning of an element. <div role="button"></div>
aria-label Adds an accessible name to an element. <div role="button" aria-label="Fake button"></div>
aria-disabled Announces the element as in a "disabled" state. <div role="button" aria-label="Fake button" aria-disabled="true"></div>

Refer to the Accessible Rich Internet Applications (WAI-ARIA) 1.1 document for more information.

What ARIA does not do

It's important to note what ARIA does (above) and also what it doesn't do.

When you apply aria-* attributes, roles, and state properties to an HTML element, this does not automatically allow the element to be keyboard focusable or add all the expected keyboard interactivity. These are things that you as the developer need to implement yourself.

In the previous example, the div element with its role="button" attribute would announce the element as, "button", but this will not make the div keyboard focusable. It will also not provide the expected keyboard interaction via Enter or Space keys. Again, this functionality is to be added after the fact.

Custom components

As previously mentioned, one thing ARIA is capable of is adding semantic meaning to custom components. Let's look at how to create a checkbox using native HTML, then once again using ARIA.

HTML

The HTML checkbox will need to have:

  • A label element explaining its purpose
  • The input element along with appropriate attributes to convey what it is
  • A clearly defined state, "checked" or "unchecked"

Typical HTML for a checkbox would look like this:

<label for="apple-checkbox">
  <input type="checkbox" id="apple-checkbox" name="apple">
  Apple
</label>

When someone navigates to this checkbox, a screen reader would announce,

"Apple, checkbox, not checked."

In doing so, the user would know they're currently focused on a checkbox element, its text label is "Apple," and the current state is not checked. They can either interact with the checkbox (by pressing the Space key) or move on.

ARIA

Now, let's re-create the same checkbox using div elements and ARIA attributes. The checkbox will need to have:

  • An accessible name or label explaining its purpose
  • A role to convey what it is
  • A clearly defined state, "checked" or "unchecked"

Let's review at the HTML code to accomplish this:

<div class="checkbox__wrapper">
  <div
    class="checkbox__checkbox"
    role="checkbox"
    tabindex="0"
    aria-checked="false"
    aria-labelledby="apple-checkbox"
  ></div>
  <div class="checkbox__label" id="apple-checkbox">Apple</div>
</div>

Let's dive a little deeper into the code here.

  • The div with class="checkbox__checkbox" would represent the checkbox visual, typically with an SVG icon or CSS.
  • This div also features role="checkbox". This is the attribute required for screen readers to announce this component as a "checkbox." Without it, it would appear as a generic container.
  • The div features the tabindex attribute with its value set to 0. This allows non-focusable elements to receive keyboard focus when the user navigates to the element.
  • The aria-checked attribute is present which conveys the current state of the checkbox. When interacted with, the value of this attribute would need to toggle from false to true.
  • Finally, the div has the aria-labelledby attribute with its value set to the id of the element which holds the text label. When this div receives keyboard focus, the aria-labelledby attribute will make the connection with the element which matches its value and adds the matching element's content to the announcement of the checkbox.

As you may be able to tell, using the ARIA method is quite a bit more code to write and maintain. And keep in mind, this is only the HTML needed to create the ARIA version of a checkbox. There's also the CSS code to visually style the checkbox as well as the JavaScript to handle the Space keypress event to toggle the aria-checked value.

For this reason, it's recommended to use native HTML elements. This way there's less code to write and maintain, as well as the built-in keyboard support and semantic meaning that comes with each native element.

Non-standard components

ARIA can also be used to create common "desktop" interface patterns that are non-native on the web or in the browser environment.

For example, complex desktop applications may feature a tree view or a tab interface as a means to navigate content within the app. As of this writing, there is no tree or tab element available in HTML. Therefore, if your web app design calls for such a component, one can be created and implemented using a combination of HTML and ARIA to convey the meaning and structure of the pattern, and then add CSS and JavaScript to apply the necessary styling and functionality.

Other example patterns include:

These patterns are documented on their implementation and expected interactions in the WAI-ARIA Authoring Practices guide, including:

  • Written descriptions which explain the expected keyboard keystrokes one might use to interact with custom components
  • Lists the appropriate ARIA attributes (roles, states, and properties) to be used with each component in order to convey the component's meaning and purpose
  • Provides fully working examples to study and test using assistive technology

When creating a custom component, reference this guide to ensure what you're producing is accessible and usable for the widest audience possible.

Live region components

One other unique feature that ARIA adds is the ability to create a live region. With a live region, you're able to send an audible message out to screen reader users, when appropriate, in order to inform them of a change in state upon interaction or a timed message.

<div role="status" aria-live="polite">5 minutes remaining.</div>

For example:

  • When sending or deleting an email from a list, it would be ideal to let the user know when the message was either sent or removed from their inbox.
  • When adding an item to a cart, make the user aware of the successful addition.
  • If someone has a limited amount of time to complete a task, announce the amount of time remaining in semi-regular intervals.
  • If an app is currently in a loading state displaying a loading animation, include screen reader users aware of this context as well.

The purpose of a live region is to help provide an equal user experience for those who are unable to see the user interfaces we create and make sure they're made aware of the current context.

The first rule of ARIA use

It's important to point out the 5 Rules of Using ARIA. These are rules the W3 and the WAI group have created in an attempt to avoid ARIA overuse or abuse. It is possible to misuse and create a poor user experience when aria-* attributes are used incorrectly.

Let's highlight the First Rule of ARIA Use:

"If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so."

In other words, don't use ARIA if you can help it. Use native HTML instead.

Resources:

Back to blog