What is ARIA?
ARIA is shorthand for Accessible Rich Internet Applications. ARIA is a set of attributes you can add to HTML elements that define ways to make web content and applications accessible to users with disabilities who use assistive technologies (AT). When accessibility issues cannot be managed with native HTML, ARIA can help bridge those gaps.
What can ARIA do?
There are three main components used in ARIA: Roles, States, and Properties.
Roles are used to define a type of user interface (UI) element (i.e. role=“ROLE_NAME”). Once a role is set for an element, it does not change.
Brief Description: While acting as the foundation for all other roles, abstract roles are utilized by browsers and should not be used in code. Instead, they are used to give roles their meaning in context and help with the addition of new roles.
How does it get used by the AT user? Abstract roles are in the background and shouldn’t be adjusted.
DOCUMENT STRUCTURE ROLES
Brief Description: Document structure roles aren’t normally interactive, but instead provide descriptions for sections within a page.
Commonly used examples: Examples include img, document, heading, list, listitem, and toolbar (i.e. role=“toolbar”). You can see a full list on the W3C’s ARIA 5.3.3 Document Structure Roles page.
How does it get used by the user? Users of AT use document structure roles to identify content while navigating through a page, which helps give them the context of the content they’re taking in. While HTML 5 may provide much of this context on its own, screen reader support for HTML 5 is sometimes missing. For this reason, the most robust choice is to use both.
Brief Description: Created for easier navigation, landmark roles identify each section of content within a page.
Commonly used examples: Examples include banner, contentinfo, form, main, navigation, search (i.e. role=“search”). You can see a full list on the W3C’s ARIA 5.3.4 Landmark Roles page.
How does it get used by the user? Users of AT use landmark roles to navigate through a page. For instance, a screen reader will announce the start and end of each landmark role set on a page, and its web rotor will display a list of these roles/regions.
Brief Description: Used when HTML doesn’t define elements, widget roles add semantic meaning to elements and user interfaces (UIs), small and large. According to W3C’s ARIA 5.3.2 Widget Roles, standalone UI widgets are part of larger, composite widgets, while composite UI widgets act as containers that manage other contained widgets.
Commonly used examples: Examples of standalone UI widgets include alert, button, checkbox, link, menuitem, tab, and tabpanel (i.e. role=“tabpanel”). Commonly used examples of composite UI widgets include combobox, grid, listbox, menu, radiogroup, and tablist (i.e. role=“tablist”). You can see a full list on the W3C’s ARIA 5.3.2 Widget Roles page.
How does it get used by the user? Users of AT use widget roles to interact with the page to get things done. This can include completing forms, opening and closing tabs and panels, and navigating a main or sidebar menu.
States and Properties
Commonly used examples include aria-describedby, aria-haspopup, aria-hidden, aria-label, and aria-labelledby (i.e. aria-labelledby=“uid-123”). You can see a full list on the W3C’s ARIA Global States and Properties page.
In addition, there are also four categories of states and properties:
- Drag-and-Drop Attributes
- Live Region Attributes
- Relationship Attributes
- Widget Attributes
Note: Widget Attributes are not to be confused with Widget Roles.
Brief Description: Conveys information to AT about drag-and-drop elements, including draggable elements and their drop targets.
Commonly used examples: Examples include aria-dropeffect and aria-grabbed (i.e. aria-grabbed=“true”). You can see a full list on the W3C’s ARIA Drag-and-Drop Attributes page.
How does it get used by the user? Users of AT use drag-and-drop attributes to interact with drag-and-drop components using various methods regardless of their disability.
LIVE REGION ATTRIBUTES
Brief Description: Indicates changes in content for a user’s AT, such as setting whether a message will be read aloud with the flow of content (i.e. aria-live=“polite”) or instead will interrupt the flow of content and be read aloud immediately (aria-live=“assertive”). These elements don’t need to have focus, and can include information on how the user can proceed.
Commonly used examples: Examples include aria-atomic, aria-busy, and aria-live (i.e. aria-live=“polite”). You can see a full list on the W3C’s ARIA Live Region Attributes page.
How does it get used by the user? AT use live region attributes to inform users what’s happening on a page with regular messages as things change on the page. Live region attributes are also used to provide notifications to users after forms have been submitted.
Brief Description: These attributes add relationships between elements that can’t be determined otherwise.
Commonly used examples: Examples include aria-describedby and aria-labelledby (i.e. aria-labelledby=“uid-123”). You can see a full list on the W3C’s ARIA Relationship Attributes page.
How does it get used by the user? Users of AT use relationship attributes to understand when information is related when navigating the page and gathering additional data from various elements like forms, menus, and tabs/panels.
Brief Description: Used for commonUI elements that receive input from users while processing those actions and information.
Commonly used examples: Examples include aria-autocomplete, aria-checked, aria-disabled, aria-label, and aria-required (i.e. aria-required=“true”). You can see a full list on the W3C’s ARIA Widget Attributes page.
How does it get used by the user? Users of AT use widget attributes to more easily utilize interactive UI elements, like forms and overlays/modals/popups. This helps to avoid confusion during the input process.
When shouldn’t I use ARIA?
It’s funny you ask. W3C actually created the Rules of ARIA Use to help to guide us in this question. There are five of them, starting with:
First Rule of ARIA Use:
The first and most important rule of ARIA is to use native HTML at all times, unless it’s absolutely, positively impossible to make an element accessible otherwise. When in doubt, choose native HTML. Some examples of when this may not be possible include:
When the HTML5 element doesn’t have accessibility support. That status should always be checked on the HTML5 Accessibility site.
If the design doesn’t allow for a specific native element because of limitations on styling.
When the wanted feature isn’t available in HTML.
That status should always be checked on the Paciello Group’s ARIA roles and properties not available in HTML5 page.
Second Rule of ARIA Use:
The second rule of ARIA is do not change native HTML semantics unless you absolutely have to. In almost all cases, native HTML will work just fine. This is because ARIA does not get added to the document object model (DOM), so any objects created in the browser will not automatically become what they are trying to emulate. For example, a button:
Instead of this:
<span role=“button” onClick=“submitForm();”>Submit</span>
<button type=“submit” onClick=“submitForm();”>Submit</button>
Third Rule of ARIA Use:
All interactive ARIA controls must be keyboard accessible. For elements that don’t normally receive keyboard focus, add tabindex=“0” to the element to add it to the logical tab order. Here’s an example:
<div tabindex=“0”>ARIA is awesome!</div>
Fourth Rule of ARIA Use:
For all elements that are focusable, do not ever add role=“presentation” or aria-hidden=“true”. This is because for some users, this will result in them focusing on nothing, causing confusion. Elements that are automatically focusable include links and form elements. Any element that has tabindex=“0” added to it is also included in that list.
Fifth Rule of ARIA Use:
You must give all interactive elements an accessible name. This only happens when the interactive element (<input>) accessible name property has a value (aria-label=“Search” or <label>).
Instead of this:
Search: <input type=“text” id=“search” />
<label for=“search”>Search</label>: <input type=“text” id=“search” />
<input type=“text” id=“search” aria-label=“Search” />
When should I use ARIA?
Some of the most common uses for ARIA include:
When you need to add more descriptive labels to HTML elements like buttons or links (i.e. Read More, Learn More, etc.), you can use the ARIA aria-label to accomplish this:
<a href=“/path/to/your/page”>Read More</a>
<a aria-label=“Read More about how awesome ARIA is” href=“/path/to/your/page”>Read More</a>
In order for events to get announced to screen readers, you must add ARIA live regions and alert messages to those elements for them to be detected and read aloud.
<div class=“alert-message”>You’ve successfully completed the contact form and you will soon receive a confirmation email.</div>
<div class=“alert-message” role=“alert”>You’ve successfully completed the contact form and you will soon receive a confirmation email.</div>
To create a relationship between elements (parent/child), you’ll need to add ARIA attributes to each of the elements. Here’s an example:
<button id=“menu-button-1” aria-haspopup=“true” aria-controls=“menu-list-1”>Menu List 1</button>
<ul id=“menu-list-1” role=“menu” aria-labelledby=“menu-button-1”>
<li role=“none”><a role=“menuitem” href=“…”>Link 1</a></li>
<li role=“none”><a role=“menuitem” href=“…”>Link 2</a></li>
<li role=“none”><a role=“menuitem” href=“…”>Link 3</a></li>
To make forms accessible for users of screen readers, add ARIA attributes to form elements so that they become easier to interact with.
<label for=“first-name”>First Name</label><input type=“text” id=“first-name” aria-required=“true” aria-autocomplete=“on” />