Accessible Rich Internet Applications (ARIA) offer a special role called application. Kind of logical to have a role specific for applications in a standard targeting (rich internet) applications. But we need to know that this powerful role is sometimes actually an accessibility issue, especially for desktop screen reader users, as it basically puts screen readers in a special mode (Léonies description explains it better, opens in external window) that behaves differently from other modes.
Most of resources will warn you not to use role="application"
if you don’t know what it really does, and I will try to summarize my own observations here.
Role of “application” basically means that developers need to be careful, because everything non-interactive wrapped inside it is not accessible to desktop screen-readers as it takes away virtual cursor that can be used to discover non-interactive elements.
To simplify – if we use a paragraph, a list, an image or a heading, and so on, inside role="application"
some screen reader users can’t reach them. They become practically inaccessible to screen reader. Native HTML interactive elements kind of work, with tab key, for example, but they are not necessarily exposed in Element list (NVDA) and similar views (basically again less accessible as user has to tab to the elements to discover them).
These facts, concerning desktop screen readers, are known and discussed for some time now (opens in new window), but I wasn’t able to find much about mobile screen readers and role=”application”, so I decided to check some basic things out…
Please be aware that things change, software has bugs and you should test yourself to be sure. I’ve used latest TalkBack for my Samsung Android device (TalkBack version 14, on Android 14, OneUI 6).
I just made a very very simple playground to check basics, having a div with role=”application” that contains a heading and some other elements…
Role=”application” and TalkBack (Android phones)
When using mobile screen readers we need to keep in mind that they support both touch and keyboard. And you can also use touch and keyboard at the same time. Some users prefer keyboards and some touch. Some phones offer both modalities, but current trends go towards phones without built in keyboards, so users have to rely on external keyboards if they want to have physical keyboard (or braille etc.).
TalkBack with touch
When I tested TalkBack with touch, I didn’t actually notice any difference – as if role="application"
was not even there. Reading controls set to headings, for example, worked as if heading was normal. Same goes for all other possibilities. And I was able to explore all content inside role="application"
with touch.
TalkBack with keyboard
I was able to reach role="application"
when navigating via ARIA landmarks, I was also able to reach button, checkbox, all controls and link inside with keyboard shortcut.
Reading controls were also working just like they work if role="application"
is not there at all. Quite a contrast comparing to NVDA…
Quick conclusion – TalkBack doesn’t really care
After my short tests I didn’t actually find any obvious differences between using role="application"
and not. I wanted to check the official repository for TalkBack if there are any indications of support and wasn’t able to find them (not an Android developer, so perhaps I’ve missed something). I was able to find a short pull request that may be related to adding the support (opens in new window), but it is opened from 2019 and has low activity, so we’ll have to wait and see…
Role=”application” and VoiceOver (iPhone, iPad,…)
VoiceOver (on mobile devices) also supports touch or keyboard, therefore we need to check both possibilities, just like with TalkBack.
VoiceOver with touch
Using rotor we can reach headings, form controls and links just like we would normally – basically I didn’t notice any differences. role="application"
was not available as a landmark (even when it was named with aria-labelledby
). Basically I concluded that role="application"
isn’t supported (or doesn’t make any difference) with VoiceOver in touch mode.
VoiceOver with keyboard
Tabbing to interactive elements worked normally.
Navigating with arrows worked just like with touch.
Single-key Quick Nav didn’t work quite as I would expect (couldn’t reach heading, link and button inside role="application"
, but I could access heading 2 directly. Aria landmark was not available (that corresponds with touch).
Quick conclusion – VoiceOver doesn’t care much
Besides Quick Nav differences I can’t really establish that VoiceOver supports role="application"
in this quick test. Will need to test more, with more advanced setup (real world app that is well documented could do the trick), but my experiment can’t really establish large differences.
Conclusion – be even more careful with using role=”application”
Differences (between screen readers and devices) are obviously there. Making a responsive web application and relying on role="application"
seems to be even large challenge when it comes to mobile devices. I believe that role="application"
is not supported on mobile screen readers, besides small quirks (like exposing it as a landmark in TalkBack and preventing the use of Quick Nav on VoiceOver).
This was just a quick test, with a minimal example, so – as always – I suggest you test your specific situation. There are a lot of things that needs to be tested, like keyboard shortcuts, support for aria-activedescendant
, aria-roledescription
and so on, so we just scratched the surface here, a very tiny surface.