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:
||Used to add or alter the base semantic meaning of an element.||
||Adds an accessible name to an element.||
||Announces the element as in a "disabled" state.||
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
Space keys. Again, this functionality is to be added after the fact.
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.
The HTML checkbox will need to have:
labelelement explaining its purpose
inputelement 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.
Now, let's re-create the same checkbox using
div elements and ARIA attributes. The checkbox will need to have:
- An accessible name or
labelexplaining its purpose
roleto 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.
class="checkbox__checkbox"would represent the checkbox visual, typically with an SVG icon or CSS.
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.
tabindexattribute with its value set to
0. This allows non-focusable elements to receive keyboard focus when the user navigates to the element.
aria-checkedattribute is present which conveys the current state of the checkbox. When interacted with, the value of this attribute would need to toggle from
- Finally, the
aria-labelledbyattribute with its value set to the
idof the element which holds the text label. When this
divreceives keyboard focus, the
aria-labelledbyattribute will make the connection with the element which matches its value and adds the matching element's content to the announcement of the checkbox.
Space keypress event to toggle the
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.
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
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>
- 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.