When Should You Use ARIA Role=”Application”?

This post originally appeared on the Yahoo! Accessibility blog.

ARIA roles give us much more control on defining how assistive technologies should interact with a page. The application role gives us complete control. But remember complete control can also lead to complete chaos. So how do you use this powerful role? When should it be used?

Application vs. Document

accessibility-205x85
Before diving into the application role it's useful to understand the difference between application and document based web pages. Your average web page is a document. The user expects to read content and it may feature some interactive behaviors. Applications are more like a desktop application. The user has expects tool sets, instant changes, dynamic interactions.

Wikipedia is a document based web site. Yahoo! Mail, on the other hand, is an application.

The "application" role establishes the context and helps set the user's expectations that this is an application. Screen readers may announce the 'application'. This also tells the screen reader that the application will take over the expected keyboard shortcuts and navigation functionality.

Application Navigation

Application with multiple tab optionsApplication with multiple tab options

Applications can have many focusable descendants. This makes moving between widgets in an application very slow.

The "application" role changes the navigation paradigm for the user. The application consists of widgets and the user will tab from widget to widget. They can then navigate within the individual widgets. The developer manages tab flow between widgets in the application chrome explicitly via the tabIndex attribute.

In application mode, the screen reader should yield control to the application and not any keyboard shortcuts for the purpose of navigation or interacting with UI controls.

Standard Browse Mode

Widgets within an applicationWidgets within an application

Following the guidance in the ARIA spec, each major widget in the UI chrome should have a single tab stop.

The standard browse mode is not effective for modern web application development for two main reasons:

  1. The UI is updating asynchronously, so you don't want the user interacting with a snapshot of the DOM, but rather the live DOM. The "application" role tells the screen reader to disable their virtual buffer.
  2. Applications have their own keyboard shorts, and we want those to be able to pass through.

Adding Application Role

Typically your web page will either be an application or a document. You can have a section within your application that behaves like a document as well as an application within a document. For the page-based application add role="application" on the body tag.


<body role="application">...</body>

Module level applications would have the role on a parent container.


<div role="application">
<div role="grid">...</div>
</div><!-- /application -->

Similarly, you would define a document section of your application by using the document role

<div role="document">
<div role="article">...</div>
</div><!-- /document -->

What you can do

The "application" role is a powerful setting, it is not meant for the vast majority of sites. It requires a significant commitment from the developer to establish the complete set of labels and navigation. However, when properly enabled, the role can make your web application accessible.

Related Links