ARIA’s application role

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.

Thank you for reading 5 articles this month* Join now for unlimited access

Enjoy your first month for just £1 / $1 / €1

*Read 5 free articles per month without a subscription

Join now for unlimited access

Try first month for just £1 / $1 / €1

The Creative Bloq team is made up of a group of design fans, and has changed and evolved since Creative Bloq began back in 2012. The current website team consists of eight full-time members of staff: Editor Georgia Coggan, Deputy Editor Rosie Hilder, Deals Editor Beren Neale, Senior News Editor Daniel Piper, Digital Arts and Design Editor Ian Dean, Tech Reviews Editor Erlingur Einarsson and Ecommerce Writer Beth Nicholls and Staff Writer Natalie Fear, as well as a roster of freelancers from around the world. The 3D World and ImagineFX magazine teams also pitch in, ensuring that content from 3D World and ImagineFX is represented on Creative Bloq.