What the Heck is ARIA? A Beginner's Guide to ARIA for Accessibility

ARIA attributes bridge the gap to address accessibility issues that cannot be managed with native HTML. Join us as we explore what ARIA is, what it can do, when you should use it - and when not to.

Kat Shaw

October 9, 2019

Get a comprehensive accessibility audit using a combination of automated tools and manual review. We deliver you a full remediation plan.

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.

Where does ARIA come from?

The formal name for ARIA is “Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA).” WAI-ARIA is a technical specification published by the World Wide Web Consortium (W3C), who are an international community that develops web standards. It initially had a working draft on September 15, 2008, and became a completed W3C Recommendation on March 20, 2014. When W3C published it as a recommendation, WAI-ARIA then became a set of web standards.

The current W3C recommendation is WAI-ARIA 1.2. A WAI-ARIA 1.3 Draft is under development.

Who is ARIA for?

How people with disabilities use the web

In the simplest terms, ARIA was specifically created for screen reader users, and users who cannot use a mouse and must rely on their keyboard. W3C provides an excellent outline of ARIA's purpose and problems it addresses on its WAI-ARIA Overview site.

W3C WAI has created a wonderful resource within the Accessibility Fundamentals: How People with Disabilities Use the Web section of their site titled Tools and Techniques. According to W3C WAI, it “introduces some of the techniques and tools that people with disabilities use to interact with the web — web browser settings, text-to-speech, voice recognition, and many more.” I highly recommend checking this page out to get a deeper understanding of AT.

Support for ARIA

At this time, ARIA is not supported by all technologies. However, support for ARIA is most definitely growing. Those who do support ARIA include browsers, AT (i.e. screen readers, magnifiers, text-to-speech, etc.), applications, and JavaScript toolkits. It’s a very complex set of standards, so complete support is difficult to achieve. Even so, almost all current versions of the technologies mentioned do support at least some of ARIA.

ARIA and HTML5

Due to HTML5 not having 100% support with all browsers and screen readers, it’s very important to check the support status of the HTML5 elements you’re using:

Check which browsers and devices your site will support.
Check those against one or more of these resources:
In cases where HTML5 elements don’t have accessibility support, add both the HTML5 element and the ARIA role in order to cover those gaps in support.

What can ARIA do?

There are three main components used in ARIA: Roles, States, and Properties.

Roles

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.

Abstract roles

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 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.

Landmark roles

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 (i) will display a list of these roles/regions.

Widget roles

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

States and properties can be applied to elements and are used together to support ARIA roles existing on a page. States can change on their own or with user interaction (i.e. aria-checked and aria-disabled), usually with JavaScript. Properties rarely change once they’re set (i.e. aria-labelledby and aria-describedby).

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.

Drag-and-Drop Attributes

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.

Relationship Attributes

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.

Widget Attributes

Brief Description: Used for commonUI elements that receive input from users while processing those actions and information.

Commonly used examples: Examples include 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 ARIA role or property isn’t available natively in HTML5. 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 when creating a button:

Instead of this:

<span role=“button” onClick=“submitForm();”>Submit</span>

Do this:

<button type=“submit” onClick=“submitForm();”>Submit</button>

Otherwise, a user cannot activate the Submit button using standard keystrokes, making your application inaccessible.

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”>Lullabot is awesome!</div>

Never add a positive number to the tabindex attribute, because that will add the element to the tab order, making your application inaccessible.

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 getting keyboard focus on elements they cannot access, 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:

<span>Search</span>
<input type=“text” id=“search” />

Do this:

<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:

Descriptive labels

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:

Before

<a href=“/path/to/your/page”>Read More</a>

After

<a aria-label=“Read More about how awesome Lullabot is” href=“/path/to/your/page”>Read More</a>

Alerts

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.

Before

<div class=“alert-message”>You’ve successfully completed the contact form. Unfortunately you will not receive a confirmation email because this alert is not set up properly.</div>

After

<div class=“alert-message” role=“alert”>You’ve successfully completed the contact form and you will soon receive a confirmation email. Bravo!</div>

Relationships

To create a relationship between elements (parent/child), you’ll need to add ARIA attributes to each of the elements. Here’s an example:

<nav id=“main-nav”>
<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>
</ul>
</nav>

Forms

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” autocomplete=“on” />

How does Drupal use ARIA?

Thanks to the Accessibility Initiative that started in Drupal 7, there have been many advancements in both core and contributed modules to deliver accessibility to all users. Some of those achievements include:

Core

When Drupal 8 was created, accessibility was a top priority for the Drupal community. Because of this, there are several great built-in accessibility features.

Aural Alerts

Consistent aural alerts are now provided via Drupal’s Drupal.announce() JavaScript method, allowing users with visual disabilities to hear alerts using their AT. The two allowable values for the aria-live attribute used for the alerts are polite (will not interrupt the browser) and assertive (will generally interrupt any current speech).

Autocomplete

Drupal's autocomplete feature gives users the option to autocomplete form fields with their previously-entered data once they’ve started typing into a field.

Form Fieldsets

Within the Form API, fieldsets are used to organize related sections in a form into their own sub-sections. Groups of checkboxes and radiobuttons are automatically grouped within fieldsets, and other elements can be grouped within a fieldset as well.

Inline Form Errors

With the addition of the Inline Form Errors (IFE) module, form errors are now in Drupal core. When users fill out a form, a linked summary of errors appears above the form, along with inline form errors below each form field. This addition ends up making it easier for all users to complete a form, and it especially helps users of AT drill-down on what items they need to correct to complete a form.

Semantic Code

Drupal uses HTML5 elements and ARIA to deliver more semantic meaning to its content. This allows users of AT the capability to use their own browser customizations to navigate the web without being forced to use what’s been set for a specific site.

Tab Order for Keyboard Accessibility

For users who choose or must use a keyboard to navigate the web, tab order of a web page is a top priority. Drupal’s Tabbing Manager provides a solution to this by allowing a developer a way to add or remove tab constraints from a page using controlled tab order, like a modal/overlay/popup window for example. Drupal has also set up key elements in Twig templates that must automatically receive keyboard focus, like the “Skip to main content” link, for example.

Views

Views can be used to add several ARIA attributes. A good example would be when you need to add a more descriptive label to an HTML element. Once you’ve opened a view, you can select a field, open the “Rewrite” section, and add a bit of custom code combined with tokens to create a descriptive label like this:

<a aria-label=“Read More about {{ title }}” href=“{{ link }}”>{{ title }}</a>

Note: See a full writeup of Drupal’s commitment to Accessibility on its own About Drupal > Accessibility page.

Contributed

In addition to the built-in accessibility features, several contributed modules in Drupal offer additional accessibility features and functionality.

Block ARIA Landmark Roles

This module gives the site builder the capability to add landmark roles to any block on the site.

CKEditor Abbreviation

This module adds an abbreviation button to the toolbar of the Rich Text Editor (WYSIWYG). When users click this button, it creates an accessible abbreviation at the location of the user’s cursor.

High Contrast

This module adds a toggle behavior to the user’s keyboard, allowing the user to toggle a high contrast view of the site. This is especially helpful for users with visual disabilities.

Text Resize

For users with low vision, this module adds a tool contained within a block that allows users the ability to resize the text to fit their needs. The tool includes two buttons: + (increase text size) and - (decrease text size).

...and look out for the future use of artificial intelligence within Drupal to aid in accessibility.

Is there any confusion on how/if/when to use ARIA in the developer community?

Yes! There’s some confusion and even controversy around the use of ARIA for several reasons. Several of them include:

Adding `role=“button”` to a link, expecting it to work as a button

This issue comes down to how AT uses a button versus how they use a link. A link can be activated by an AT user by pressing Enter/Return, while a button can be activated when they press the Spacebar. If you add a link with role=“button”, the AT is going to detect it as a button. However, the user can become confused when they try to press the Spacebar with no result. This is why it’s best to keep links as links, and buttons as buttons.

Keep in mind that which element you use is a structural decision, not a decorative one. You should use a button instead of a link when:

The link is empty or has no href attribute: <a id=“123”>Link<a>
The link has scripting attached using an onclick attribute: <a onclick=“doThis();>Link<a> or similar event listeners

Adding redundant ARIA landmark roles to HTML5 elements

I’ve seen several sites where with good intentions, they’ve added ARIA attributes to HTML5 elements. The issue is that those HTML5 elements already have the landmark role built into them, so adding them becomes redundant. Here’s a list of HTML5 elements and their paired HTML4 landmark roles.

HTML4 Landmark Role	HTML5 Element
role=”banner”	<header>
role=”complementary”	<aside>
role=”contentinfo”	<footer>
role=”form”	<form>
role=”main”	<main>
role=”navigation”	<nav>
role=”region”	<section>

Using aria-controls attribute, which isn’t widely supported

There’s a lot of confusion in the accessibility world as to which screen readers support aria-controls. A couple of great articles on the subject can be found at “Aria-controls is Poop” by Heydon Pickering aka @heydonworks, and “Using the aria-controls attribute” by Leonie Watson aka @LeonieWatson. After a lot of research, I became even more confused on the subject myself, so I just continue to keep track of its support status on the Accessibility Support > aria-controls attribute (aria) status page. I also enjoy experimenting with the aria-controls design pattern examples from ARIA Authoring Practices Guide (APG).

Some say “never use ARIA!”

It’s understandable that some feel this way, mostly because of the overuse of ARIA. However, according to the Paciello Group’s own ARIA roles and properties not available in HTML5, several of them are needed to make the web easier to navigate and use for users of AT. It’s all about sticking with native controls whenever possible, and using ARIA as a last resort when an element cannot be made accessible otherwise. It’s a balancing act.

General confusion on using HTML5 + WAI-ARIA

This is one of the biggest areas of confusion for developers, and it relates to the First Rule of ARIA Use: “use native HTML at all times unless it’s absolutely, positively impossible to make an element accessible otherwise.” An example would be HTML5 required vs. WAI-ARIA aria-required. Luckily, there is now a W3C HTML Accessibility Task Force that is addressing these issues as we speak.

ARIA resources

Published in: