WAI-ARIA, an approach

Introduction to ARIA (Accessible Rich Internet Applications) an initiative of W3C that describes how to make accessible content and internet applications, specifically dynamic content and the advanced interface controls developed with Ajax and its related technologies.

Autor: Javier Fernández Rivera (web, contact)

Oginal version: WAI-ARIA, una aproximación

1.  Introduction


To understand ARIA it’s necessary to remember the context in which this initiative is developed: W3C, whose current slogan accurately reflects the commitment of this organisation:

Leading the web towards its full potential.

This includes a web accessible to people whether or not they have any kind of disability (Fernández Rivera; 2008).

In this way, the Web Accessibility Initiative (WAI) was born and was developed by the W3C, within which we can also situate the PFWG, the Protocols and Format Working Group, who are in turn the authors of:


The W3C defines ARIA as:

The way to create web content and applications that are accessible for people with disabilities.


One of the most recent problems of web accessibility arose with the arrival of Ajax, the moment in which the developers were “encouraged” to use this technology, motivated by the possibilities for the dynamic updating of content and the creation of different bespoke controls (widgets). All this with the aim of simulating a GUI that was more similar to desktop applications, obtaining as a result, richer and more interactive internet applications, but less accessible.

Let’s imagine for example the case of an advanced control like the slider. A screen reader will not be capable of giving a response to the following questions:

The solutions ARIA provides

ARIA will be able to respond to the previous questions and other issues, providing a complementary work frame.

  1. More semantic structures for functional zones.
  2. Improve navigation by means of the keyboard.
  3. More accessible complex controls (widgets).
  4. Accessibility for dynamically updated content.

For this ARIA has:

Therefore, we can intuit that ARIA does not work as a restricting or exclusive technology, but that it is a complement with which we can make rich internet applications more accessible.


ARIA is supported by the main browsers and assistive technologies, but nevertheless it is necessary to point out that at present documents that contain ARIA cannot be valid due to the HTML 4.01 specification and the current DTD Strict, Transitional and Frameset.

2.  Semantic structure of a document

With ARIA we can specify the roles of the different functional zone of a web document, making it more semantic and accessible.

For example, we are currently used to using a link to skip to content, whilst ARIA permits us, through Document Landmarks, to create a more semantic and accessible structure so that, amongst other things, the assistant technology can discern where it finds the principal content without the need to resort to a link.

To create an accessible semantic structure with just ARIA, we have to specify the roles of every functional zone going through the property role.

Document Landmarks

Example to indicate the navigation area

<div id="navigation" role="navigation">
               <li id="active"><a id="current" href="home">Home</a></li>
               <li><a href="blog">Blog</a></li>
               <li><a href="contacto">Contact</a></li>

We can even make use of the attribute role to personalise the style of the element by means of CSS.

div[role="navigation"] { color: blue; background-color: inherit; }

Note: The attribute selectors are only recognised by the current versions of the main browsers,

3.  Keyboard Navigation

By means of the keyboard and using the tabindex attribute we can navigate between the different elements of a site, but only some elements support this attribute and are capable of receiving the focus: A, AREA, BUTTON, INPUT, OBJECT, SELECT, y TEXTAREA. Therefore, a simple DIV element cannot be accessed via the keyboard.

It’s exactly here ARIA appears:

  1. Making it so that the attribute tabindex is supported by all of the visible elements of a site.
  2. Permitting the value “-1” in the attribute tabindex, which makes it possible to take out an element of the natural order of the navigation and of the tab order. An element with the attribute tabindex=”-1” will only be able to receive the focus through JavaScript (with the method focus ()).

4.  Accessibility in controls (widgets)

HTML was conceived to share documents on the web and not to create applications, which is why it does not offer advanced controls (widgets).

An example: slider widget (a classic)


The design and development of a control of this type can have the following appearance:

<div id="slider-bg" title="level">
        <div id="slider-handler">
               <img src="handler.gif" />

Accessibility problems with the slider

A person with no form of disability can move the slider (handler.gif) over the whole of the background image (class=”slider-bg”) and place it at the value they desire. Nevertheless, a person with a visual impairment will have problems with the accessibility of the image, they will not be able to move the slider from the keyboard, and, moreover, their screen reader will not be capable of discerning it.

  1. The role of the element (what is it?). For a reader it will be a simple DIV that cannot even be accessed by the keyboard.
  2. The state and what attributes it has (how does one find it?).
  3. The behaviour (what does it do?). The reader will not know that there are three written values in the background image (1. Easy, 2. Normal, 3. Difficult) that moreover, have been implemented with CSS, which is why they are situated on the presentation layer (not content, not behaviour)

Accessible slider with ARIA

<p id="slider-description">Use left and right keys to change the level.</p> 
<span id="slider-label">Level:</span>
<div id="slider-rail">
        <button id="slider-handler" role="slider" aria-labelledby="slider-label" aria-describedby="slider-description" aria-valuemin="1" aria-valuemax="3" aria-valuenow="2"></button>

We can give life to this slider with JavaScript and reflect the changes that it suffers modifying the value of the attribute aria-valuenow.

5.  Accessibility in dynamic content updates

Another of the great problems with the accessibility in rich internet applications falls to the dynamic updating of content (or part of the content) that is realized through Ajax and on the “second level”.

ARIA designates “active regions” the elements/zones that can present these changes, and have the property aria-live with which to indicate the value of “misrepresentation” (off, polite, assertive or rude) about the current activity of the user.

For example, let’s suppose that we have an element TEXT INPUT with a maximum limit of 20 characters. Associated with this element we place SPAN, which serves as a container to show the user the number of characters he has left to write. Finally with JavaScript we can continue taking away and updating the content of the element, which acts as a counter.

<label for="user-name">
                Name (required)
                <input name="user-name" id="user-name" type="text" size="20" maxlength="20" />
                <span id="count"></span>

A user with a visual impairment will not have access to the information of this counter, given that the assistive technologies do not reflect updating of the element SPAN.

The solution with ARIA:

<label for="user-name">
                Name (required)
                <input name="user-name" id="user-name" type="text" size="20" maxlength="20" aria-required="true" />
                <span id="count" aria-live="polite"></span>

6.  Implementing ARIA

The difficulty implementing ARIA can be considered proportional to the grade of complexity of the internet application, although in the end it is always about managing roles, states and properties through JavaScript.

Independently of the complexity, another problem arises upon not being able to do something as essential as validate web documents with ARIA.

The problem comes from HTML 4.01 and DTD given that it does not take into account the specifications of ARIA. Nevertheless this technology boasts good support on the part of the industry, the principal organisations, browsers and assistive helps. Nor does its implementation present negative effects, and it even provides various benefits on behalf of accessibility.

Yet the problem with the validator remains… and what can we do? Personally I am inclined to inject the ARIA states and properties through JavaScript at the time of execution.

We will consider the following structure:

<div id="head">
                 <h1 id="logo">
                                <img src="aurea.gif" alt="title" />
                                <span id="tagline">description</span>
                 <ul id="nav">
                                <li><a href="/">home</a></li>
                                <li><a href="/blog">blog</a></li>
                                <li id="active"><a id="current" href="/contact">contact</a></li>
                 <form id="searchform" method="get">
                                                <label for="s">
                                                                <input type="text" name="s" id="s" value="Search" />
                                                <label for="srhsub">
                                                                <input type="image" name="srhsub" id="srhsub" src="search.gif" value="seek" alt="seek" />
 <div id="main">
 <div id="footer">
                 <p id="copy">&copy;2009 aurea webdesign</p>

Injecting ARIA with jQuery

$(document).ready(function() {
                $('#logo').attr('role', 'banner');
        $('#nav').attr('role', 'navigation');
                $('#searchform').attr('role', 'search');
                $('#main').attr('role', 'content');
                $('#footer').attr('role', 'contentinfo');
                $('.required').attr('aria-required', 'true');           

Injecting ARIA with mootools

window.addEvent('domready', function() {
                $('logo').setProperty('role', 'banner');
                $('nav').setProperty('role', 'navigation');
        $('searchform').setProperty('role', 'search');
                $('main').setProperty('role', 'content');
                $('footer').setProperty('role', 'contentinfo');
                $('.required').setProperty('aria-required', 'true');

We simply take the elements from their IDs (identifiers) and we inject the property role with the value that represents each of the functional zones role=”navigation”.

The last line injects the property aria-required=”true” if an element contains the class required.

Tools that can help us with the implementation of ARIA

<h1 id="logo" role="banner">