WAI-ARIA is perhaps the most significant Web accessibility technology to come along since the introduction of WCAG 1.0. It allows developers of Web applications or custom Web interactivity to define specific roles, states, and properties for custom made interactions that assistive technologies are able to understand. Though WAI-ARIA is aimed primarily at developers, others should at least understand where and when it gets used.

WAI-ARIA is a W3C specification that defines a collection of attributes that can be used within HTML elements to add semantic information. For example, a developer may want to create a navigation menu, often using HTML list markup to structure the menu items and JavaScript to control which elements of the menu to display at any given time. Without using WAI-ARIA, such a menu may be accessible in the sense that an AT user could navigate through its elements and open menu items, but they will be announced by the AT as a collection of nested lists. By adding ARIA menu roles to these list elements, AT will announce them as parts of a menu, whether they are opened or closed, and whether they have submenus, and so on.

When auditing custom Web interactivity, a screen reader like ChromeVox should be used to navigate through a tool or widget to determine whether WAI-ARIA has been used to add roles, states and properties to the feature. You can also examine the code using a tool like Firebug, to see what ARIA is being used to operate the tool and watch the ARIA update dynamically, as states and properties change. In audit reports, recommendations can be made to use ARIA to make elements more meaningful, thus more usable by AT users. Refer to Guideline 4.1.2 (Level A).

The full WAI-ARIA specification and WAI-ARIA authoring practices can be found on the W3C website. At least scan through these documents to familiarize yourself with their contents so you can refer back to them in your audits when making ARIA related recommendations.

Toolkit: Bookmark these two documents to add them to your tool kit.

Accessible Rich Internet Applications (WAI-ARIA 1.1) - Version published January 2016

WAI-ARIA Authoring Practices - Updated August 2019

WAI-ARIA in Action

The following is an HTML excerpt from a large main navigation menu that has been marked up with WAI-ARIA. The markup contains the basic ARIA attributes used to create an AT usable main menu. Read through the comments in the box below, and examine the markup it describes to develop your understanding of how WIA-ARIA is used.

Technical:

// An example of a main menu created with HTML unordered list markup

// The first line of markup below creates a container around the menu, gives it a role of

// navigation, is describe with the text in the menu_keys span element below referenced

// using aria-describedby, and is made keyboard focusable with tabindex=”0”.

// When accessed with a screen reader, it announces itself as navigation

// and describes to the user how to navigate through the menu

<span id="menu_keys" style="font-size:0;">Main Menu: Use arrow keys to move left and right and up and down through menus</span>

// The menu itself is a basic nested unordered list. JavaScript injects the ARIA dynamically.

// The ULs are given a role of menubar, list items are given a role of menuitem.

// Where a nested list occurs ( which is a submenu) aria-haspopout is set to true

// to indicate to the screen reader that a submenu is present. The aria-activedescendant

// is set to the ID of the parent element of the submenu that currently has focus.

<li id=”activeItem” role=”menuitem” aria-haspopout=”true”> Courses and Programs

<li role=”menuitem” aria-haspopout=”true”>Areas of Interest

<ul>

<li role=”menuitem” >Information Technology</li>

<li role=”menuitem” >Communication and Media</li>

<li role=”menuitem” >Business Systems and Strategies</li>

...

</ul>

</li>

...

</ul>

</li>

...

</ul>

</div>

To see the menu in action, view the following video. Listen closely to how the menu is announced by ChromeVox.

Main Menu with WAI-ARIA Enhancements (1:15)

The menu in the video above uses the MooTools accessible dropdown menu scripts to inject the appropriate ARIA attributes when they are needed. Fortunately many of the common interactions, like menus, accordion, and tabpanels for instance, have open source scripts available to quickly add in the appropriate ARIA.

Toolkit: Bookmark the open source WAI-ARIA Examples used in ARIA workshops for developers at Ryerson University. These examples can be referred to when making recommendations where ARIA is needed in Web accessibility audits.

When to Use ARIA

Though ARIA is a necessity for developers who create custom interactivity for the Web, there are times when it should and should not be used.

Do use ARIA:

When HTML is being used in a non-standard way (e.g., making a checkbox out of a div)
When within page navigation is needed (use ARIA landmarks)
When creating Web widgets like sliders, datepickers, tooltips, tabpanels, accordions, etc.

Do not use ARIA:

When there is a way to create the same interactivity with standard HTML
When HTML is being used in a standard way (e.g., an HTML form does not need role=”form” added because it has that role by default)

Key ARIA Attributes

Here are some WAI-ARIA attributes that are used often and are relatively easy to understand.

Technical:

ARIA Attribute

Description

aria-describedby

This attribute is very useful for adding instructions or descriptions of Web elements for AT users. In the menu example above, aria-describedby is used to provide instructions on using the menu, in that case referencing a hidden <span> element containing a description of keyboard navigation.

It could also be used to provide extra information about a particular feature, such as describing the format for a password form field. If the password must include numbers, letters, and special characters, that text might be positioned after the password field in a <span> element and through its ID attribute, referenced using aria-describedby in the <input> element for the password field. With the example markup below, a screen reader would announce the label for the password field, followed by format for the password. Without referencing the format <span> element, this information may go unnoticed by AT users.

<label for=”pass”>Password</label>

<span id=”format”>must contain numbers, letters, and special characters</span>

aria-live vs role=”alert”

The aria-live, often referred to as a live region, must be used in places where information is dynamically updating on a page, without the page itself reloading. Otherwise AT users are unlikely to notice that changes are occurring. The aria-live attribute can be set to “polite,” as seen in the code snippet below, in which case a screen reader will wait until a break in the screen reader’s output to read the content. Or, aria-live can be set to “assertive” in which case a screen reader will interrupt whatever is being read to read the changes within the live region. Live regions are useful for things like news feeds (e.g., Twitter or news sites), live chat applications, social media streams, rotating banners or other kinds of auto-updating information.

//updating content goes here

<div>

On the other hand, the role=”alert” attribute, often called an ARIA alert, is a special type of assertive live region, that should be used in places where feedback is being presented. If, for example, a required field in a form is left empty, and an error message is injected immediately below the field to indicate the error (like that in the code snippet below), these types of feedback messages are good candidates for ARIA alerts. Otherwise such messages may go unnoticed by AT users. Or, after successfully submitting a form to register, for instance, the message that appears on the page after submitting the form indicating the registration was successful, would also be a good candidate for an ARIA alert.

<p style=”color:red;”>Username field cannot be empty.</p>

</div>

roles and landmarks

ARIA provides a whole range of roles that can be used to assign a functional application to particular HTML elements. You have already been introduced to the the “alert” role, and the roles associated with a navigation menu.

There is a particular set of roles that are referred to as landmarks. These should be used carefully throughout a user interface to define regions throughout that UI. Screen readers are able to list these landmarks and users can jump to any one of them to navigate directly to a relevant area of a page.

Where landmarks are used, all areas of a page should be contained within a landmarked region. These regions, introduced back in Unit 2 (2.4.1 Provide Ways to Navigate), are presented again here:

Full list of landmark roles:

banner: Associated with the header area of a page. There should only be one banner landmark per page.
complementary: A section of content that complements the main content but also retains its meaning when separated from the main content. Often used with a region containing advertising or promo items aligned down the right side of the page. There can be multiple areas defined as complementary.
contentinfo: Contains the content usually found in the footer of a page, like copyright and privacy statements. There should only be one contentinfo landmark per page.
form: Contains form input elements that can be edited and submitted by the user. Multiple elements can have the form role.
main: The main content of the page. There should only be one main landmark per page.
navigation: A collection of navigation links used to navigate the site or page. There can be multiple elements with the role navigation.
search: A search tool.
application: Represents a unique functional unit, and keyboard commands are handled by the application rather than the browser or the assistive technology itself. An embedded movie player, a calendar widget, or other customized software embedded in Web content are examples where the application role might be used. This role should be used sparingly as it can create some confusion for screen reader users when key commands begin working differently.

tabindex

Though the HTML tabindex attribute has been around since HTML4, for use with specific HTML elements, with HTML5 it can be used with any element to add keyboard focus to elements that do not normally receive focus, using tabindex=”0”.

In the code for the menu above, you will notice tabindex in the opening <div> element. Normally <div>s do not receive keyboard focus. In the case of the menu, adding focus to the container <div> is needed for the description referred to by aria-describedby to be read. When the <div> receives focus, the screen reader will announce “Main Menu: Use arrow keys to move left and right and up and down through menus.”

aria-expanded

The aria-expanded state is used for menus that have toggles to open and close submenus, and also to inform AT users whether a menu item has a submenu, and whether that submenu is open or not.

The following markup is from a side menu, with toggles to open and close sections of the menu. You will notice that aria-expanded is set to true, indicating to AT that a submenu is open following this element. If the submenu were closed, aria-expanded would be set to false, updated dynamically by the JavaScript that controls interactivity of the side menu.

<span id="acc_tab_2170"

class="navtoggler active"

tabindex="0"

aria-expanded="true"

role="tab"

aria-selected="false">Archived Calendars</span>

Examine the following example treemenu from the Open Ajax Accessibility Initiative (OAA).

Treemenu example using aria-expanded

aria-label

When forms are formatted in a way that prevents the use of the HTML <label> element to explicitly associate a label with a form field, only then should aria-label be used to label the form element. If <label> can be used, it should be used instead of the ARIA version.

A good example of a case where aria-label might be used is on a search form. These forms usually do not include a <label> element.

<form>

</form>

aria-labeledby

This attribute can be used with non-standard forms to associate a label or multiple labels with a form field. For example, you may have a data entry form laid out in a table, like that in the figure below, in which the content of the table header cells provides labels for multiple input fields.

Consider the following table, in which the content of the header cells provides labels for each form input field in the column below. In the markup that follows the figure, you can see how aria-labelledby has been used to assign the values in the header cells as labels for each form element.

Name	Email	Login
John Smith	js@smail.com	jsmith

Figure: A table used to layout a data entry form.

<table>

<tr>

<th id=”email_label”>Email</th>

<th id=”login_label”>Login</th>

</tr>

<tr>

</tr>

…

</table>

If there is the option to use the <label> element over using aria-labelledby, then <label> should be used. If both <label> and aria-labelledby are used on the same input element, aria-labelledby will override the <label>.

"WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications)" by Greg Gay of Ryerson University, Change School of Continuing Education, is licensed under CC BY-NC-SA 4.0