Accessibility Connections
- For accessibility in online learning and education, join the UDAT working group.
- Connect with us on ASU's #accessibility Slack channel.
- Subscribe to ASU's ITACCESS mailing list.
The Web Accessibility Initiative (WAI) defines Accessible Rich Internet Applications (ARIA) as:
a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.
Most HTML elements have a default role that's understood by browsers and assistive devices--a button has the role of button, for instance. Some have additional properties and states as well--for example, a link can be active or visted. But many elements, such as divs and spans, are without a role.
ARIA allows developers to define roles, states and properties that are not natively available in HTML and to override the HTML defaults of elements. ARIA is supported by most browsers and screen readers, and it is a powerful tool in a developer's accessibility arsenal.
Landmarks identify the major structural parts of a webpage and can be used by screen reader and other users for keyboard navigation. All content on a webpage should be contained inside landmarks.
There are two ways to define landmarks: with an HTML5 landmark element or an ARIA landmark role. Because some elements and roles are not yet supported by all browsers or screen readers, it's recommended to use both when possible. If no HTML5 landmark element is available (for instance, if you can only use a <div>
), an ARIA landmark role alone will define the landmark.
HTML5 landmark element | ARIA landmark role | Definition | Usage |
---|---|---|---|
<header> | role="banner" | Site-oriented content at the beginning of each page | Only one per page. Must be a top-level landmark. |
<nav> | role="navigation" | Groups of links intended for website or page navigation | If more than one, each should have a unique label. |
<main> | role="main" | Primary content | Only one per page. Must be a top-level landmark. |
<section> | role="region" | Content relevant to a specific, author-specified purpose | Must have an unique label. |
<aside> | role="complementary" | Supporting section that complements and is related to the main content but remains meaningful when separated from it | Must be a top-level landmark. If more than one, each should have an unique label. |
<footer> | role="contentinfo" | Common information at the bottom of each page | Only one per page. Must be a top-level landmark. |
<form> | role="form" | Collection of items and objects that together create a form | Must have an unique label. |
None | role="search" | Contains search functionality for the site | If more than one, each should have an unique label. |
<header role="banner">
...
</header>
<nav role="navigation">
...
</nav>
<main role="main">
...
</main>
<footer role="contentinfo">
...
</footer>
<div role="banner">
...
</div>
<div role="navigation">
...
</div>
<div role="main">
...
</div>
<div role="contentinfo">
...
</div>
Some HTML5 and ARIA landmarks require labels.
You can give landmarks (and other elements) unique labels using the aria-label, aria-labelledby, and title properties:
aria-label: Provides text that labels the current landmark when no other label exists; is visible only to assistive technologies.
<aside aria-label="Title for Complementary Area 1">
...
</aside>
aria-labelledby: Identifies the element that labels the current landmark.
<aside aria-labelledby="comp1">
<h2 id="comp1">Title for Complementary Area 1</h2>
...
</aside>
title: Identifies the element that labels the current landmark and may be available as a tooltip on some browsers.
<aside title="comp1">
<h2 id="comp1">Title for Complementary Area 1</h2>
...
</aside>
ARIA roles can be used to define otherwise meaningless HTML5 elements, such as divs and spans. Attaching a role gives assistive technologies information about how to handle each element. For example, the following seems to be a simple list:
<ul>
<li><a href="#bio">Bio</a></li>
<li><a href="#resume">Resume</a></li>
<li><a href="#awards">Awards</a></li>
</ul>
But it could be intended to represent tabs or a menu, both of which function quite differently. In the absence of visual cues, adding ARIA roles defines elements so assistive devices know how those elements should behave.
<ul role="tablist">
<li><a role="tab" href="#bio">Bio</a></li>
For content that changes dynamically without page reload, ARIA provides a way to alert assistive device users of those changes: the aria-live property.
<select>
<option> .... </option>
</select>
<div aria-live="polite">
...
</div>
Possible values for aria-live are:
aria-live="assertive"
is often used for dynamic error messages and is equivalent to role="alert"
.
An important component of keyboard accessibility is the ability to set focus on an element. By default only links, buttons and forms can receive focus. NOTE: An anchor with an empty HREF (an "empty link") is not focusable or keyboard accessible (see more in Javascript).
Setting tabindex="0"
on an element places the element in the logical navigation flow of the document and allows it to receive focus. For instance, tabindex will allow focus to be set on a normally unfocusable element, such as a <div>:
<div id="menu-container" tabindex="0">
The ARIA-role attribute can add a role to otherwise meaningless (or "role-less") elements such as spans and divs, thus allowing them to receive focus. For example:
<span id="checkbox" role=”checkbox” aria-checked=”false”>...</span>
<div class="button" aria-role="button">Go back</div>
ARIA provides for many states that can add, supplement or alter the current condition of an HTML5 element. For example:
<input aria-disabled="true">
<input aria-required="false">
<input aria-hidden="true">
<input aria-checked="false">
There are many aria states and properties to enhance the accessibility of HTML5 elements. See a list of all ARIA properties and states.
An excellent resource for learning ARIA is the Ryerson University online textbook, Web Accessibility for Developers.
For a table of ARIA roles and attributes, see the ARIA Role Matrices from WhatSock.
The A11y Project is a good source for accessible widgets. Additionally, the "Design Patterns and Widgets" section of the WAI-ARIA Authoring Practices 1.1 provides extensive documentation on creating accessible Javascript widgets, such as:
For more information on WAI-ARIA, see: