This article first appeared in issue 235 of .net magazine – the world's best-selling magazine for web designers and developers.
By now you’ll be familiar with ARIA landmark roles such as search, main and navigation. They identify the purpose of a section of content on a page so that people who use assistive technologies (ATs) like screen readers can access information that’s obvious to sighted people at a glance. The role of application does a bit more than act as a landmark on the page: it causes ATs to change the way they behave, so it’s important to understand the implications of using it first.
The application role tells an AT to treat the section of the page like a desktop application, rather than as a conventional web page. To understand what this means, it’s necessary to look at the way many screen readers handle web pages.
When a page loads in the browser, some Windows screen readers grab a copy of the page and store it in a virtual buffer. It’s this copy of the page that the user interacts with. This is known as ‘browse’ or ‘virtual cursor’ mode, and makes it possible to walk the page using the arrow keys, and for semantic information to be spoken about the content.
Another effect of the virtual buffer is that certain keystrokes are captured by the AT instead of being passed through to the browser. This enables navigation by headings, lists and other HTML features. When it’s necessary for keystrokes to be passed through to the browser, these screen readers invoke a different mode known as ‘forms’ or ‘focus’ mode.
It’s worth noting at this point that Mac OS/iOS ATs don’t use this interaction model. When role="application" is encountered on that platform it’s treated in the same way as any other ARIA landmark role.
When you apply role="application" to an element it causes screen readers that use browse/ virtual cursor mode to automatically invoke forms/focus mode, and treat the contents of the container as a desktop application rather than a web page. More importantly, it isn’t easy for those screen readers to go back to browse mode once forms/focus mode has been triggered by role="application".
This begs the question: when should (or shouldn’t) role="application" be used? If you’re using standard HTML5 elements you shouldn’t need to use role="application". This includes headings, paragraphs, links, lists and form fields. The same is true if you’re using composite widgets made from standard HTML elements and marked up with other appropriate ARIA roles; for example slider, treview or alertdialogue. ATs know how to handle these things already.
If you’re using mashup widgets intended to behave like a desktop application, then it may be appropriate to use role="application". The truth is that the times when you’ll genuinely need to use it will be few and far between. One of the few examples where role="application" is used appropriately and effectively is Yahoo web mail. It uses a combination of role="application" and role="document" to emulate the behaviour of a desktop email client.
Discover 60 amazing examples of HTML5 at our sister site, Creative Bloq.
