ARIA and accessibility: Navigation

  • Author: Richard Corby
  • Date: 14 Feb 2013

This four-part series explores different accessibility issues that can be solved by using Accessible Rich Internet Applications (ARIA).

On modern websites, interface controls such as show/hide and controls to select personal preferences are very common. However, these types of features are often inaccessible to users who can't use a mouse or an alternate pointing device — typically screen reader users.

A screen reader understands standard HTML code very well but interface controls (also called rich internet applications) are created using JavaScript or Ajax. These technologies have no standard way to tell another program, like a screen reader, what that behaviour is.

This is where ARIA (Accessible Rich Internet Applications) comes in. ARIA is used to give meaning, or semantics, to interface controls so a screen reader can use them. As we become more familiar with these kinds of interactive controls and start to expect them, these features become crucial for being able to use a website, so it's extremely important that they are made accessible.

Media Access Australia's article Introduction to WAI-ARIA: It's accessibility but not as we know it says that accessibility guidelines like WCAG 2.0 focus on design principles and aim "to be technology-neutral so they could apply to more situations".

On the other hand, ARIA uses specific commands to tell assistive technology, such as screen readers, what's going on. For example, if an event happens on a webpage such as an updated sports score, the assistive technology program being used to help a person with a disability will notice the change and provides the user with access to the new content."

ARIA solves these main areas of accessibility problems with web applications:


The problem

Websites have common elements such as a top banner, search function, navigation, main content area and footers. There is no way using HTML to add semantic information to different regions of a webpage, which identifies that region as, for example, the navigation area or main content area.

A common solution is to include skip to content link at the start of a webpage, which when activated, take the user to the start of the main content area. Some websites also include hidden headings that mark these regions, allowing a screen reader user to navigate to these sections via headings. However, these solutions are simply work-arounds in light of the fact that there is no way to describe the purpose or type of a region within a webpage, and have this communicated to a user via assistive technology.

The solution

ARIA provides Landmark Roles that can be inserted as attributes in the page's code to describe the purpose of the following common types of content:

  • application — region declared as a web application, as opposed to a web document
  • article — stand alone web content such as a blog post
  • banner — for site-wide information such as the site's name, logo and search for a site
  • complementary — supporting content for the main content on the page such as related posts for a blog article or session times for a movie
  • contentinfo — metadata about the main content such as footnotes or copyright statements
  • main — the main content of the page
  • navigation — the navigation menu links for a site or page
  • search — the search functionality for the site

These roles can be implemented into div elements in the following ways:

<div role="search">, <div role="navigation"> and so on.

Landmark roles give a greater ability for screen readers to convey structural meaning of a website or webpage to blind users, presenting them with a better overview where they are on the site so they can navigate it effectively.

View ARIA Landmark roles voiced by NVDA (close captioned) on YouTube.


This is the first article in a four-part series by Richard Corby, web accessibility expert and partner at Webbism.