ARIA role=”application” and mobile screen readers

Number of words: 947.

(Loaded 1500 times)

There are some limited resources on ARIA role application, but I missed more information for mobile screen readers and just quickly checked the situation on Android and iPhone. It seems that support is not there, besides some small quirks. Be even more careful with role = application!

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.

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: