ARIA

Introduction

The WAI–ARIA specification (referred to as ARIA from here on) provides a means to increase the accessibility of dynamic content and user interface components (or “widgets”) by adding role, property and state information. There are different parts to ARIA to implement these different pieces of information:

Roles – for “widgets” and “document landmarks”
States and properties
Live regions

There are no negative side–effects of using ARIA and so we recommend it is implemented wherever possible and appropriate in all websites.

Keyboard navigation

Being able to interact with interface elements using the keyboard alone is one of the most basic accessibility provisions. Widgets may not be built with components that can receive focus, such as the img or div elements, and so are not immediately keyboard accessible.

ARIA extends the tabindex attribute so that it can be used on all visible elements and so it can be used on elements of widgets to ensure they can receive focus. ARIA also allows a negative value to be specified for elements that should not appear in the keyboard tab order, but can be programmatically focused (give focus to an element with scripting).

The following techniques must be used to ensure that all components on the website are accessible using all input devices.

Adding to the natural tab order

The following example uses a tabindex attribute value of 0 to put a div element into the tab order so that a keyboard user can navigate to the element.

<div tabindex="0">
...
</div>

Negative tabindex

The following example uses a negative tabindex attribute value, so that the element can receive programmatic focus.

<div id="progaccess" tabindex="-1">
...
</div>

In this example, the div element is not placed in the tab order, but having a tabindex attribute value of −1 means that it can receive programmatic focus. The following snippet of JavaScript selects the element defined above, and uses the focus method to place focus on the element.

var objDiv = document.getElementById(‘progaccess’);
// Focus on the element
objDiv.focus();

Roles

ARIA introduces the role attribute to help define extra information about what a document landmark (page section) or widget (user interface component) is and this should be used wherever possible.

Document landmark roles

These are used to indicate the role of individual sections of content on the page. The possible values are:

article: Content that makes sense in its own right, such as a complete blog post, a comment on a blog, a post in a forum, and so on.
banner: Site–orientated content, such as the title of the page and the logo.
complementary: Supporting content for the main content, but meaningful in its own right when separated from the main content. For example, the weather listed on a portal.
contentinfo: Child content, such as footnotes, copyrights, links to privacy statement, links to preferences, and so on.
main: Content that is directly related to or expands on the central content of the document.
navigation: Content that contains the links to navigate this document and/or related documents.
search: This section contains a search form to search the site.

These can be applied to page elements such as in the following example which includes banner (header area), navigation and main (page content).

<div role="banner">
	<h1>...</h1>
</div>
<ul role="navigation">
	<li>...</li>
</ul>
<div role="main">
	<h2>...</h2>
	<p>...</p>
</div>

Roles can be used as many times as needed on the same page except for banner, contentinfo and main, which should only be used once. So for example the navigation role can be placed on both the main navigation and a secondary navigation block.

Also be aware that some elements may not need specific aria roles assigning to them, as the roles are already implicit in the element tags themselves, for example:

<header> does not need <role="banner">
<nav> does not need <role="navigation">
<footer> does not need <role="contentinfo">
<fieldset> does not need either <role="group"> nor <role="radiogroup">

Widget roles

These are used to indicate the role of each user interface component used on the page. The complete list of all possible roles and their definitions for both document landmarks(sections) and widgets should be referred to for the possible values to use. The following example shows an image input being used as the control of a slider input. Assistive technology will then refer to this as a slider rather than a plain input.

<input type="image" src="thumb.gif" alt="Effectiveness" role="slider" />

Live regions

The discoverability of updated content is one of the biggest obstacles for screen reader users. ARIA live regions allow elements in the document to be announced if there are changes, without the user losing focus on their current activity. This means users can be informed of updates without losing their place within the content. For example, a chat application could announce the response from the person the user is chatting with, without moving focus away from the text entry field to add a line of chat.

The possible properties that can be used for live regions are:

aria–live: ARIA provides an aria–live property that has a value indicating the verbosity level for the region. This can be “off”, “polite” or “assertive”.
aria–atomic: The aria–atomic property is an optional property of live regions that can have the values “true” or “false” (the default if this property is not specified). When the region is updated, the aria–atomic property is used to indicate if assistive technology should present all or part of the changed region to the user. If this property is set to true, assistive technology should present the entire region as a whole; otherwise, the part of the region that changed might be announced on its own.
aria–busy: The aria–busy property is an optional property of live regions that can have the values “true” or “false” (the default if this property is not specified). If multiple parts of a live region need to be loaded before changes are announced to the user, the aria–busy property can be set to true until the final part is loaded, and then set to false when the updates are complete. This property prevents assistive technologies announcing changes before the updates are complete.
aria–relevant: The aria–relevant property is an optional property of live regions that indicates what changes are considered relevant within a region. This can take the values “additions”, “removals”, “text” or “all”.

The following example show how some these can be set on a list:

<ul aria-atomic="true" aria-busy="true" aria-live="polite">

States and properties

ARIA provides the capability to add information on the properties of a widget and also the state it is currently in that can be provided to assistive technology to help the user understand how to interact with the widget. The complete list of states and properties should be referred to for all possible values to use.

The following example shows how these could be added to a slider input. Information has been added to show the minimum and maximum values possible, as well as the current value in both numerical and textual forms.

<input type="image" src="thumb.gif" alt="Effectiveness" role="slider" aria-valuemin="0" aria-valuemax="100" aria-valuenow="42" aria-valuetext="42 percent" />