Current Edition 12: Accessibility

Leading Article

Leading Article: About the Accessibility Edition

SAP and Accessibility

For Your Reference

Links & More

	Print version
Related Links
	Accessible Rich Internet Applications (ARIA) – Part 1: Introduction
Background Links
	SAP's Public Accessibility Website
	Accessibility on SAP's Service Marketplace

Accessible Rich Internet Applications (ARIA) – Part 2: ARIA

By Dr. Stefan Schnabel, Architecture Governance and Standards, SAP AG – March 9, 2012

The second part part of the article describes what ARIA is, its specifications, its support regarding user agents, assistive technologies, and development toolkits, its basic concepts, and its design patterns. It concludes with a brief discussion of future challenges.

Introduction to ARIA

Because HTML4/HTML5 has some limitations for creating rich Web applications (as described in last chapter) and to address the needs for better accessibility, the WAI-PF working group of W3C developed a new concept for Accessible Rich Internet Applications (WAI-ARIA).

ARIA is a metadata specification that provides a means of describing roles, states, and properties for custom widgets so that they are recognizable and usable by assistive technology users. WAI-ARIA also provides a mechanism to ensure that users of assistive technologies are aware of updates in the application.

Specifications

There are currently three key documents for ARIA available by W3C:

Accessible Rich Internet Applications (WAI-ARIA) 1.0 (ARIA Specification)
WAI-ARIA 1.0 User Agent Implementation Guide
WAI-ARIA 1.0 Authoring Practices

The key documents to read for Application Developers are the ARIA Specification and the ARIA Authoring Practices.

Support

ARIA has formed up already a new industry standard for HTML application accessibility and is supported already in common User Agents (Browsers) and Assistive Technology (Screen Readers), as been described in this excellent overview article.

OS and User Agents

ARIA support (see also this comparison article) is provided in major browsers and even already in some mobile operating systems (OS):

Figure 7: Support for ARIA in different user agents and versions (click image for larger version)

Assistive Technologies

ARIA support is provided in major screen readers, e.g. in the screen reader Jaws 11/12 for Windows.

Development Toolkits

Major companies and organizations have incorporated full or partial ARIA support in their toolkits/frameworks/plugins already:

The most mature ARIA implementation seems to have currently Dojo (for they started first). Yahoo enables their widgets with ARIA roles, Google is supporting ARIA in their toolkit and uses ARIA Live Regions to indicate page updates ("Please wait..."). JQuery UI ARIA-enabled plugins are also available.

Reference Examples

There are already many examples for ARIA-enabled custom elements available in the Web. The quality and maturity of these examples differ considerably. A main "definitive" reference W3C example site is mandatory but not yet available. A currently well recommended example reference site is http://oaa-accessibility.org/examples/.

Basic Concepts

Roles

One of the major problems with Web applications is that any element can be used to make a widget. HTML elements already have predefined roles. The role of an element is what it does – the part it plays in the structure. For example, the role of a heading is well understood by assistive technology. When widgets are built with existing elements, the role of the element is what is revealed to assistive technology, rather than what it visually represents in the widget. For example, if the thumb for a slider control is created using an image element with appropriate alternative text, then a screen reader will likely announce the control as, "Graphic, thumb", as opposed to something more meaningful, such as "slider, value 16 percent".

ARIA resolves this by defining

role property values for common graphical user interface widgets and other typical components of user interfaces
respective states and properties for roles
the mapping of the role, states and properties properties values to the respective platform accessibility API (see next chapter)

ARIA is basically RDF-based metadata information about roles, states and properties. The metadata roles are organized in an object-oriented like manner as depicted in the class diagram figure below:

Figure 8: Class diagram of the relationships described in the role data model (click image for larger version)

Roles are categorized as follows:

Abstract Roles
Widget Roles
Document Structure Roles
Landmark Roles

ARIA metadata definitions currently take precedence over the host language in all implementations in user agents. For example:

If role="button" is used on an <img> element, the result will be the same as if <button> would have been declared instead of <img> (The role declaration overrides the 'native' AccessibleRole in the platform accessibility API).
If aria-labelledby is used together with <label for="">, aria-labelledby will take precedence.

All override definitions are given in detail for roles and for states and properties in the WAI-ARIA 1.0 User Agent Implementation Guide.

Also in the User Agent Implementation Guide, additional precedence considerations among individual ARIA properties (with host language as fallback concept) are discussed.

Layers

It is long-term known in the Web development community that the terms

Content itself, coming from a server storage location, e.g. disk or a data base
HTML – for describing and displaying content (markup, Structure layer)
CSS – for design (styling, Presentation layer)
JavaScript – for functionality (behavior, Interaction layer).

ARIA can be applied on each of these "layers", as shown in the following figure:

Figure 9: Content with structure, presentation, and interaction layers. Metadata can be applied on each layer. (Click image for larger version)

In structure, by inserting metadata into the host language:

<li id="ml1" role="menuitemcheckbox" aria-checked="true">Sort by Last Modified</li>

In presentation, by adding to CSS class definitions:

[aria-checked="true"] { font-weight: bold; }
[aria-checked="true"]:before { background-image: url(checked.gif); }

Note that this does not apply the property to the node with the CSS class assigned, it just advises nodes with the respective property set in markup to be styled according to the CSS class definitions.

In interaction, by dynamically assigning, for example, state changes in Java Script code:

function checkbox_select(el) {
    if (el.getAttribute("aria-checked") == "false") {el.setAttribute("aria-checked", true);}
    else {el.setAttribute("aria-checked", "false");}
}

Interoperability

ARIA metadata is always mapped to the respective platform accessibility API by the user agent or can be retrieved from the documents DOM and Accessibility Trees.

Assistive Technology (for example, a screen reader) binds to the API and consumes roles, states, properties, hierarchy information and state /property events (for example, value changes).

The situation is depicted in the figure below:

Figure 10: Relationships between user agents, accessibility API and assistive technologies (click image for larger version)

In this excellent article of the Pacielleo Group, a general Accessibility API and Specification support table is given. For convenience, the results are also listed below:

Table 1: Practical Accessibility API support by browser and OS as of 06/10/2011

	Chrome	Firefox	Internet Explorer	Opera	Safari
MSAA
IA2
UI Automation
AXaccessibility
AT-SPI
ARIA 1.0
UAAG 1.0

Legend:

"good support" means implemented to a level that provides support for the majority of features.
"partial support" lacks support for some important features.
"not applicable" means the browser does not run on the OS for which the Accessibility API is designed.
"not supported" means the browser does not have practical support for the specification or Accessibility API on the OS.

The actual mapping definitions are documented in much more detail in the W3C HTML to Platform Accessibility APIs Implementation Guide.

Host Language Implications

Native host language (HTML4/HTML5) elements with their roles, states and properties should be always be used for HTML-based UI's. Native host language support can be expected from user agent and assistive technology, addressing basic accessibility requirements.

Because of

ARIA metadata precedence over the host language
The "bridging" nature of ARIA (the lack of elements in older HTML4-based code)
The current non-maturity of the HTML5 implementation in user agents (ARIA is ahead of HTML5 in the support!)

the question came up what ARIA roles, states and properties are generally "OK" to be used as supplement or element replacement for respective HTML4/5 elements.

To address this important topic, the HTML5 specification gives an overview in this section.

Keyboard and Focus Management

ARIA uses the concept of negative values of the HTML tabindex property so that it can be used on all visible elements to set the focus programmatically (using Java Script). In the ARIA specification chapter "Managing Focus", this is prerequisite for the idea that any rich Web application is responsible for managing the keyboard focus. This includes the complete control of focus handling, the focus traversal inside Ui elements, focus restoring and focus movement within the entire user interface.

The "Supporting Keyboard Navigation" section in the WAI-ARIA 1.0 User Agent Implementation Guide defines the basic requirements user agent have to met for supporting this.

The WAI-ARIA 1.0 Authoring Practices Keyboard and Structural Navigation chapter explains this concept in fine granularity. Based on the ground-breaking work of DHTML Style Guide, the Authoring Practices define also keyboard usage patterns for common UI elements (e.g. for a tab strip element).

Widgets

Many ARIA role property values help to define "custom" accessible graphical user interface widgets.

The following roles act as standalone user interface widgets or as part of larger, composite widgets.

The following roles act as composite user interface widgets. These roles typically act as containers that manage other, contained widgets.

We will only present some examples for selected roles here (for complete information, please consult the ARIA specification).

Example 1

An input element has a role property of slider, the role exposed to assistive technology is slider, rather than input.

Figure 11: A slider element

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

Example 2

The following code fragment repurposes an HTML list into a tree by assigning a tree role to the <ul> element.The <li> element containing fruits is repurposed into a tree node by assigning a treeitem role to it. When a blind user navigates to the fruits node, a screen reader announces that the fruits node is expanded.

<ul id="tree1" role="tree" tabindex="0">
<li role="treeitem" tabindex="-1" aria-expanded="true">
Fruits
</li>
...
</ul>

States and Properties

ARIA defines a variety of states and properties. We will only discuss some selected properties here (for complete information, please consult the specification).

Some states and properties are applicable to all host language elements or ARIA roles regardless of whether a role is applied (if existing, the respective HTML5 property counterpart is given in brackets):

For instance, the aria-required property helps with HTML4-based markup to indicate the required state of a text field and helps avoiding user input errors. A number of other properties cover element relationships and will be discussed in subsequent chapters.

Other properties are only available to specific host language elements or ARIA roles (they "belong" to them):

For instance, the aria-autocomplete property is used with the ARIA combobox role to indicate that user text input in the text field in the combo will be automatically completed when the item is in the list of available items.

A number of additional properties cover special topics (Live Regions, Drag and Drop) and are discussed in subsequent chapters.

Structural Roles

The following roles describe structures that organize content in a page:

Again, we will only discuss some selected roles here.

ARIA knows different concepts of element "groupings" that may not be confused with each other. Group is intended to group similar elements for a concept, for example, different elements with role=radio for a radiogroup.

In contrast to this, region used together with a heading role is used to identify different "sections" of a screen (in fact, the HTML5 <section> element is the counterpart, see Landmarks chapter). It can be used to group e.g. different elements in a single container.

A more specialized region is the form element (similar to the HTML4/5 <fieldset>, see also Landmarks chapter).

Regions and forms with heading roles applied will be available as labeled Landmarks in user agents and assistive technology.

Landmarks

For ease of use, it should be possible for blind people and people using the keyboard only to navigate directly to any Website or Web Application Region in a user agent (browser) at will. This will greatly enhance the "usability of accessibility" and will be recognized as a plus in user experience regarding application navigation.

The upcoming HTML 5 specification offers a number of elements that can serve for typed structuring of content:

For these are real standard elements, any HTML5-enabled user aAgent will know them and can provide internally means to navigate on request to the respective areas (for example, set the focus in the area when user presses a respective navigational key). In addition, assistive technology parsing the DOM can access them and provide separate navigational mechanisms.

Because there is no HTML5 support in older browsers (IE 7, FF 3 etc.), ARIA offers the set of Landmark Roles (as values of the (XHTML) role property) for easy navigation within Web Pages in a user agent (browser). Because the role is interpreted and exposed as custom property in older browsers, assistive technology is able to parse semantics of the individual property values even in older user agents and to provide this information to the end user by offering separate navigational mechanisms.

The following landmarks are available:

Landmarks are specialized regions derived from a role region, which is the generic (but not abstract) superclass. Landmarks can be nested (i.e. it is possible to have forms inside forms), forming up a hierarchical structure. Also, relationships to (visual) labels denoting the purpose of the landmarks can be defined.

ARIA Landmarks are already well supported in some common screen readers. For instance, Jaws presents the Landmarks and their DOM hierarchy in a separate dialog that can be used for direct navigation:

Landmarks Dialog in Assistive Technology

Figure 12: Landmarks dialog in assistive technology

The following region roles can also be used as landmarks, hence they also control the assistive technology behavior when declared:

If, for example, the application role applies to the entire Web page authors SHOULD set the role of application on the root node for content, such as the body element in HTML.

The both roles can be nested, that is, it is possible to have applications inside document regions and vice versa.

Finally, the following roles could be also used to denote specialized region features:

These element roles can be applied to individual elements, for example, role=alert to a designated Message Area element.

The old and new methods for organization of page structure are depicted below:

Figure 13: Headings, HTML5 sections and ARIA landmarks

In HTML4, there was the only option to structure content by explicit hierarchy using H1-H6 markup elements. Compared to that, HTML5 structural elements and ARIA Landmarks are a much more "semantic" improvement.

For convenience, the table below maps the counterparts of HTML5 and ARIA structural elements (background article):

Table 2: HTML5 and ARIA structural elements

HTML 5 Element	ARIA Role Property
html	document
-	application
article	article
body	main
section	region
nav	navigation
fieldset	form
input type=search	search
h1-h6	heading (+ aria-level)
header	banner
address / footer	contentinfo

Examples

In HTML5, a structural element is defined as follows (Method 1):

<header>

In HTML 4 with ARIA 1.0, a similar structure is defined this way (Method 2):

<div role="banner">

The role property for document landmarks should be generated directly into the markup:

<div id="ads" role="banner">
...
</div>
<div id="nav" role="navigation">
  <form id="searchform" role="search" ...>
  ...
  </form>
...
</div>
<div id="content" role="main">
...
</div>

Also, it is good practice to label the ARIA Landmarks, for example, as follows:

<div role="region" aria-labelledby="sh1">>
<span id="sh1" role="heading" aria-level="1">First level</span>
<div role="region" aria-labelledby="sh2">
	<span id="sh2" role="heading" aria-level="2">Second level</span>
</div>
</div>

This will (especially in nested scenarios) considerably enhance the navigation in the page content.

Finally, combinations of both approaches are possible (Method 3):

<header role="banner">

Sooner or later the question comes up what model has to be used best for exposing structural information, HTML5 or ARIA with HTML4.

The answer is quite easy for "instrumentation" of older code: Use Method 2. Apply ARIA landmark role properties together with the existing HTML4 markup and you're done. In addition, your code will still work both in recent AND slightly older browsers, so if you want "backward compatibility", this is the way to go.

For new projects from the scratch the answer is not so easy. If you decide not to use ARIA at all and fully rely on HTML5 markup (Method 1) you will lose some special ARIA landmarks (like "search" etc.), this may be not what you want.

When you require as prerequisite an HTML5 compliant browser for your page, the best approach for now is Method 3 (in the author's opinion): Use HTML5 and ARIA together. You still will have backward compatibility of your code provided the fact that older browsers do not comply about the new HTML5 elements and you provide some easy JavaScript-based fixes for all Internet Explorer versions.

Please note: It is still not clear if arbitrary combinations of HTML5 elements and landmarks will always work and how in the various browsers and assistive technology combinations. As a consequence, this has always to be tested for a concrete implementation.

Live Regions

Live regions are parts of a Web page that the author expects to change. Examples of live regions include tables with dynamically updated content (sports stats, stock information), logs where new information is being added (chat transcript logs), notification areas (status, alerts), etc.

The aria-live property will denote Live Regions in the document. Content of these regions will change dynamically by DOM manipulations. By indicating that this region is "live", screen readers can react appropriately on these changes.

The aria-busy property should be used when the entire application or an individual element gets into a busy state. This is an invaluable concept to communicate the busy state to assistive technology.

The Implementing Live Regions chapter in the WAI-ARIA practices is the central source of more information for this topic.

Drag and Drop

WAI-ARIA introduces two new Drag and Drop properties that aide Web application authors with the drag and drop process, called aria-grabbed and aria-dropeffect.

The property aria-grabbed(state) is applied to the source(s) being dragged, while aria-dropeffect is applied to the target(s). Use of these properties – combined with best practices for enabling the user to select the appropriate drag operations and for assigning appropriate keyboard operations for dragging and dropping – will vastly improve the accessibility of drag and drop functionality.

The Drag-and-Drop Support chapter in the WAI-ARIA practices is the central source of more information for this topic.

Design Patterns

As seen in the preceding chapters, ARIA usage requires quite some background know-how. For developers who only want to implement without dealing much with the specification details, the WAI-ARIA 1.0 Authoring Practices are written.

Based on the basic role, state and property set, ARIA offers the opportunity to create more complex interfaces composed of a mix of basic roles in the set. This mix is called a design pattern in the ARIA Authoring Practices. For instance, a custom "Dialog Window" is such a pattern, but also the best way to label input fields depending on the use case applies here.

A few selected examples are given below. More information about design patterns can be found in the WAI-ARIA 1.0 Authoring Practices Design Patterns chapter.

Layout Tables

A "low hanging fruit" in ARIA is the support for screen reader identification of tables used for layout purposes (that is, to arrange, for example, form elements in a visually attractive manner).

All authors have to do is to add role="presentation" as part of the <table> tag:

<table role="presentation" ...>

This ensures that screen readers will ignore the table markup entirely and go directly to the elements inside the layout table.

Before this became possible, there was no standard reliable concept available for screen reader identification of layout tables, only implicit heuristic rules and custom properties dependant of the actual screen reader used.

Custom Dialogs

Web Applications use more and more custom dialog screens as part of the page:

A custom dialog

Figure 14: A custom dialog

To get the dialog role properly working with Assistive Technology, the following prerequisites have to be met:

Add to the dialog container element the role="dialog" (for example, <div role="dialog" )
Define a heading role for the document element containing the dialog title text (for example, <span role="heading">)
Label the dialog element with the heading using aria-labelledby (for example, <div role="dialog" aria-labelledby="ID_HEADING">)
When toggling dialog visibility: synchronize the aria-hidden state of the dialog accordingly.
Important: When showing the dialog, put the focus explicitly on an active (focusable) element within the dialog (for example, an "OK" button). Otherwise, chances are that the communication with the screen readers will not work flawlessly in actual implementations.

Messaging

ARIA offers the alert role that can be used e.g. for message handling in forms:

A simple custom message area

Figure15: A simple custom message area

All you have to do is to declare role="alert" for the document element containing the dialog title text, as implied in the following code snippet:

...
<div id="messageArea" role="alert" style="display:none"></div>
<br/>
<label for="age" >Text:</label><span class="required">*&nbsp;</span> 
<input type="text" id="age" aria-required="true" aria-describedby="descr8" 
onkeyup="if (helpers_getKey(event)==13) checkMe(event);"/>
<span id="descr8">&nbsp;(Press Enter to Check, then enter some text)</span> 
...

The message area is initially hidden. In case of error it is shown and any content updates will be spoken by assistive technology (for alert is a "live" region). The input focus can remain in the input field for instant correction of the issue.

Labeling of Input Fields

There are two "classic" ways to label input fields with labels in HTML.

By inclusion (not recommended)

<label>First Name: <input type="text" value=""/></label>

By explicit reference using the for property

<label for="t1">First Name:</label>
<input type="text" id="t1" value=""/>

Disadvantages of this approach is that the for property is only supported for HTML form elements and that it does not allow for multiple id references.

ARIA adds two additional possibilities for labeling:

aria-labelledby

ARIA offers the opportunity to handle arbitrary elements as label for other elements:

<label id="l1">First Name:</label>
<input type="text" aria-labelledby="l1"/>

Note that in opposite to for property, ARIA has the concept of inverse relationship for labeling (the element is labeled BY something else).

For ARIA takes multiple IDs there is also the opportunity to include multiple labels:

<label id="Label22" for="Text8">Amount:</label>
<input type="text" id="Text8" aria-labelledby="Label22 Span1" value="123"/>	
&nbsp;&nbsp;<span id="Span1">Dollar</span>

Note that the <label> element is still used, but its ID has been added explicitly to the aria-labelledby IDREF list. This is required due to the precedence rules mentioned earlier.

You could even use "hidden" labels using this technique:

<label id="Label25">Last Name:</label>
<input type="text" class="textinput" aria-labelledby="Label25 Label26" />
<label id="Label26" style="position:absolute; top:-1000px">This is text from hidden label</label>

Do not use display:none to hide the second label for this removes the DOM node entirely from the accessibility tree and as a consequence, screen readers will not find the respective information for the IDREF given in aria-labelledby (you may use visibility:hidden, though).

aria-label

As an additional alternative, ARIA adds the opportunity to add a label string to an element. This can be usedfor example, together with ARIA landmark roles, where additional hidden information may make sense for a blind user within a given context:

<div role="navigation" aria-label="Top">...</div>
<div role="navigation" aria-label="Side">...</div>

To summarize it up which labeling technique should be used:

For 1:1 input labeling use the classic for property and a <label> element
For 1:1 labeling of elements that do not support to be labeled using for, use aria-labelledby
For 1:n labeling (one input with multiple labels) you can use aria-labelledby together with for property as shown in code above
Use aria-label ONLY in exceptional cases (e.g. to give additional info for elements that have no visible label)

Element Descriptions

aria-describedby

ARIA offers the opportunity to relate visual descriptions with other elements of the HTML markup.

For example:

<table aria-describedby="desc1">...</table>
<p id="desc1">This table charts the number of cups of coffee 
consumed by each person, the type of coffee preferred (decaf or regular), 
and if the coffee is taken with sugar.</p>

Used in this way, it supplements effectively the summary attribute for the <table> element.

When it is necessary to reference an external document, the aria-describedby property needs to point to a hyperlink, which in turn references the external document.

For example:

<p><img src="histogram.png" alt="Histogram of Blackberry tree heights." 
aria-describedby="desc2"/></p>
<p><a id="desc2" href="blackberry-description.html">
Data for Blackberry Histogram.</a></p>

Attention: for title property and aria-describedby are mapped to the same API, also precedence rules apply.

Use title in all cases where additional explanatory texts should be only visible on request and not permanently
To associate explanatory texts on screen to specific elements, use aria-describedby
For images:
- Always use the alt property
- Fill the title property in case there is no visible image caption, otherwise associate the caption with the image using aria-describedby

An "aria-description" property similar to "aria-label" is missing in ARIA 1.0 but planned for ARIA 2.0.

As a workaround, you can use "hidden" elements related using aria-describedby:

<label for="Text4">First Name:</label>
<input type="text" id="Text4" aria-describedby="sh"/>
<span id="sh" style="position:absolute; top:-1000px">This is text from hidden span</span>

Note that this should be used only in exceptional cases. In case of doubt, consult the ARIA Authoring Practices.

Future Challenges

ARIA became initially accepted in the Web developer community and by the people and received praise for filling a definitive gap, but also caused constructive criticism and left room for open questions and improvements.

As time of this is being written, ARIA is still a very young standard. Chances are that the actual slightly different implementations in user agents will be harmonized by time, and so will the end user experience with various browser-screen reader combinations on the market.

The WAI-ARIA 1.0 specification is currently in the candidate recommendation phase of W3C. Actually there are no W3C reference implementations yet as basis for the next step (W3C Call for Implementations, this is scheduled for Q1/2 2012). The other two specifications are still in edit draft phase (although their content is already quite stable).

Some challenges related to ARIA 1.0 need still to be addressed (for example, different handling of the some of the concepts around focus management in Firefox and Internet Explorer, monitoring the ARIA support in user agents and assistive software, discussions with other W3C Working Groups etc.).

As already stated, ARIA is also covered in the HTML5 working draft. The HTML Working Group strives for completeness and for closing its gaps, and the different working groups of W3C are discussing frequently with each other. It can be expected that the HTML WG will pick up/address many of the issues ARIA currently addresses in the long run.

ARIA 1.0 roles are based on "classic" rich client UI standard roles with some extensions. As a major future enhancement for the next version of ARIA, it is planned to add a concept to declare completely"custom" roles (e.g. to identify a "stock ticker control" or something entirely custom ). This will represent a further enhancement of the possibilities for Web authors and is therefore in the true spirit of ARIA: being a flexible standard to develop accessible content in a fast-changing Internet world.

References and Acknowledgements

This article is partially based on the excellent Introduction to WAI ARIA article by Gez Lemon and was updated and extended with actual evolvements.

The IBM Human Ability and Accessibility Center offers central information about Accessibility and ARIA.

A valuable source is the Web site of the Paciello Group. Its blog section has many articles on Web accessibility and the ARIA topic.

The pages of the Illinois Center for Information Technology and Web Accessibility are a good address for HTML Best Practices and using ARIA.

I would like to express my special gratitude to former and actual members of the WAI-PF working group for many constructive discussions and deep insights in the process of developing standards for the Web.

top