An introduction to WAI-ARIA

by Sheff - Jan 18th, 2012

What is WAI-ARIA

WAI-ARIA is a technical specification published by W3C that specifies how to increase the accessibility of web pages, particularly those of a dynamic nature. It stands for Web Accessibility Initiative - Accessibility Rich Internet Applications

NOTE: There is confusion about how HTML5 and WAI-ARIA sit together. This is a subject that I have not yet fully understood. My current understanding is that they can and should be used together where appropriate.

Who should use WAI-ARIA?

People who will potentially find understanding and using WAI-ARIA useful include: content creators, web editors and front end developers. When referring to the different users who implement WAI-ARIA we will use the term developers from now on.

and what does it actually do?

It provides a semantic structure for the different elements of the page; Enhances accessibility support particularly for dynamic content; Better support for keyboard accessibility, it allows elements that otherwise could not receive focus receive it. Assistive technologies (will be referred to as AT in future), such as screen readers along with most modern web browsers can read the information provided by WAI-ARIA and present it to the user.

WAI-ARIA is made up of Landmark roles, roles, states and properties. Roles define different areas of the page. States and properties provide specific information about objects/elements on the page. There are subtle differences between the two but W3C refers to both as attributes, so we will follow their lead.

WAI-ARIA provides a list of landmark roles that can be used. You can add a landmark role to your document by including: role=”banner” into your element. A list of landmark roles is provided below:

  • Application
  • Banner
  • Complimentary
  • Contentinfo
  • Form
  • Main
  • Navigation
  • Search

These are pretty self explanatory and it’s outside the scope of this article to go into further detail. Generally landmark roles would contain more than one element.

Roles

As well as defining landmark roles for the document, roles can also be used to define the function of individual elements. Within the context of e-learning most of the roles will be used at some time or other. Below are details on the most commonly used roles. A full list of roles is available.

  • Alert
  • Button
  • Checkbox
  • Combobox
  • Definition
  • Heading
  • tooltip

Attributes

I have tried to categorise the attributes into a list of groups and go in to a little more detail of how they can be used. There are many others not mentioned here, these are just a selection.

Attributes add details to elements, such as properties and relationships. So you can declare relationships between elements and also set their properties. For example you can set a text input to be related to a button and set it as a required element. Take a look at the useful links for further information about attributes.

Keyboard focus

WAI-ARIA extends the tab index property. By allowing focus to be set on elements that traditionally could not receive focus. Setting the property tabindex=”0” on an element puts it into the tab order of the document. Setting a value of -1 removes it from the tab order but still allows access through scripted means.

Forms

You can set form elements to be optional or mandatory using the “aria-required” attribute. Another common issue with forms is relating the labels to their inputs, aria-labelledby and aria-describedby can be used to create these relationships.

Drag and drop

This interactivity is used extensively in e-learning materials. In the past it would be implemented using javascript and would be made keyboard accessible. The main issue here is lack of consistency. WAI-ARIA adds further standards to the approach by providing two properties: “aria-grabbed” and “aria-dropeffect” which can have the following values set:

  • Aria-grabbed=”true” – element has been selected for dragging.
  • Aria-grabbed=”false” – element is not currently selected for dragging.
  • Aria-dropeffect=”none” – the target will not accept the source.
  • Aria-dropeffect=”copy” – The source is copied and dropped on the target.
  • Aria-dropeffect=”move” – The source is moved from its previous location and dropped on the target.
  • Aria-dropeffect=”reference” – A reference to the source is created in the target.
  • Aria-dropeffect=”execute” - A function supported by the target is executed using the drag source as the input.
  • Aria-dropeffect=”popup” – A dialog appears and presents the user with various choices.

HTML5 also provides a model for drag and drop interactions. This could be used in tandem with the WAI-ARIA properties. For example HTML5 allows you to set a property of an element to be draggable which would work nicely with the aria-grabbed property.

Live region

WAI-ARIA gives you the ability to identify regions of the page that change dynamically, this is done by adding the property “aria-live” to the desired element. There are various values for the property. These are: off, polite, assertive, or rude. These values control the characteristics of how the user is alerted of the change:

  • Aria-live=”off” – The AT doesn’t announce the update.
  • Aria-live=”polite” – The AT announces the update when the user completes the current task.
  • Aria-live=”assertive” – AT announces update immediately.
  • Aria-live=”rude” – AT announces the update immediately and shifts focus to the element.

Review

WAI-ARIA is only a small part of web accessibility and the article above describes only parts of it. I have included many useful links below which should hopefully fill in the areas I haven’t covered. As browsers and assistive technologies become better at considering accessibility it is important that we at least try to use the tools they provide us with. I have been working on an example page to demonstrate some of these principles. I hope to continue to develop the page to provide more examples.

useful links

blog comments powered by Disqus