An introduction to WAI-ARIA

NOTE: This article was originally published on January 18th 2012, but was lost during the site redesign. Re-publishing as the information should still be relevant.

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 some discussion about how HTML5 and WAI-ARIA sit together. This is a subject that I have not yet fully grasped. 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.


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


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 further reading for supplementary 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.


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.


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.

Further reading

Juicy studio accessibility toolbar
WAI-ARIA drag and drop
HTML5 drag and drop model
WAI-ARIA and HTML5 confusion
WAI-ARIA overview
Landmark roles
Intro to WAI-ARIA
WAI-ARIA List of roles
WAI-ARIA specification
WAI-ARIA Supported states and properties
A brief intro to WAI-ARIA

Simplicity series - Design principles

In the first part of the simplicity series we looked at some methods of shifting the focus on to simplicity, discussing some of the challenges you may encounter in an organisation. Next we are moving on to look at some design principles for achieving simplicity.

Image of a simple lego character Photo credit to: Emma b

It may be relatively straight forward to make something look simple but does it still achieve its goals? In part 1 we will be looking at some of the barriers to taking a simplicity focussed approach to design. In part 2 we will look at some of the methods we can apply to achieve simplicity.

We prefer simplicity over complexity

Users are better able to process information when it is presented in a simplified form. Structuring your content in a logical and hierarchical way can add clarity to complex information. Many of the methods of organising content are based around the Gestalt principles of perception. One of the fundamental Gestalt principles is that of “pragnanz”. This states that we as humans are looking for regularity and simplicity in our world. For example we see a series of circles in the Olympic Rings, rather than an arrangement of more complex shapes.

5 overlapping rings - showing how we perceive the simplest shapes
[Simplicity - Illustration of how we perceive the rings in the simplest form rather than more complex shapes]

Gestalt principles of perception provide us with further methods that can be used to inform everyday design decisions and there are a wide variety of methods you can use to enhance the simplicity of a design. Let’s take a look at some of these:

Closure and proximity

Two common principles that are used on almost every website you visit are those of closure and proximity. Elements can be shown to be related by containing them inside another element. A basic example of this would be containing your related elements inside a box. Example of closure
[ChallangePost - Example of closure]

Example of proximity
[Bootstrap - Example of proximity in use]


We perceive elements that are similar in their appearance to be related. Again this is another common concept used throughout design. Whether it’s styling headings, links or iconography - by using consistent styles for related items we can make a design much easier for users to interpret. You can find numerous examples on almost any site you visit. In the example below we can see distinct styles for links, iconography used to provide further context and consistent heading styles for article titles, published date etc.

Example of consistent element styling
[Smashing magazine - Example of Consistent element styling]

Focal points

We are drawn to elements that are in contrast to their surroundings. This approach is often used on primary calls to action, as seen in the example below. Be aware that the more focal points you use the less effective they are. This is of particular importance when you are trying to provide a clear path for users.

Example of a focal points
[ - Example of a focal point on primary Call To Action]

Progressive disclosure

Only show the user what they need to see, when they need to see it. It’s a simple concept but your design needs to match the user’s expectation. Consider the task(s) the user is trying to complete. Is everything they need available? Is there a clear call to the secondary or advanced features?

A good example of progressive disclosure can be found within Gmail. Gmail offers “just in time” alerts that offer the user control and allow them to easily undo mistakes.

Example of just in time messaging
[Google mail - Providing just in time messaging]

If you remove something the user is expecting to see and don’t offer the right cues to find it, you may create more problems than you solve. This happened when Microsoft hid rarely used options in their Office suite of products: “Most of the requests for Office 2003 were for features that were already there, just hidden away.”

Limit the number of choices

Users can easily feel confused and overwhelmed when you throw too many choices at them. We have limited attention and decision making powers.

Research has shown that the more options that are provided to a user, the less likely they are to make a decision. To exacerbate this issue, having more options also leads to less reported user satisfaction with their chosen option (Lyengar, 2000).

Examples of this in action can be seen in the pricing and membership options of services. Typically the user is presented with three options.

Example of providing a limited number of options
[Mailchimp - Limited number of options provided when signing up]

To conclude

Throughout the series we have looked at some of the barriers we can face when wanting to design for simplicity and how to overcome them. We then moved on to look at some of the principles and methods you can employ to help achieve simplicity in your design. This series hopefully provided a good introduction to simplicity in design, take a look at the links and references for further reading.

Further reading

The complexity of simplicity - UX Matters
Progressive disclosure - NNgroup
Simple and Usable - LukeW
Smart defaults
Design principles - Smashing magazine
Laws of Simplicity - John Maeda
Refining Simplicity - UXmag
Simple and Usable - Giles Colborne
Simplicity is not overrated


Iyengar, S. (2000) When choice is demotivating, [Online], [Jan 2014]

Next on the Calendar

No events on the horizon.