Just recently I did some accessibility auditing of mobile applications and noticed how developers faked accessibility, so I decided to point out briefly why this is wrong on many levels in this post. I get it, applying WCAG to native mobile applications can be overwhelming. Especially when WCAG refers to web quite often. And EN 301 549 just refers to WCAG with additional criteria.
I believe we need to respect the platform and it’s possibilities and not abuse them to fake semantics and states.
Dangers of faking roles in native mobile applications
It’s simple to just use the accessibility name or description to fake the role of the component with hard-coding it. Please, please don’t to that as you make things difficult for screen-reader users and sometimes also voice control users. Hard coding role into accessibility name or description will not enable standard screen reader navigation by role (typical for buttons, headings and links) and will really confuse screen reader users that will explore the interface from one element to another.
At the same time faking alone may be a problem for keyboard users as such controls will not get keyboard focus without further coding.
Checking for fake accessibility on native mobile platforms is difficult as we often don’t have the source code to check what is going on. Therefore we need to trust screen readers. But if I would only check the component in isolation it would maybe seem properly coded, so contextual testing is also required. In this case – can I reach the element with role button when I select button navigation in my screen reader?
Activating custom interactive elements needs to take care of keyboard as well
I’ve also stumbled on custom interactive element, faking textarea component where I could activate it with space key on the keyboard. But the problem was typing sentences. When I wanted to make a new sentence with space key the component just refocused and focus was sent to the start of the field. So sending a message was actually not possible as space re-activated the component instead of making a space between words.
Developers need to use physical keyboard and screen reader at least
These problems (that are only some selected) would be easily prevented if developers would have screen reader and keyboard users in mind. Even better to have in mind is to test. If custom components were tested with screen reader and keyboard all problems would get required attention long before production releases and me auditing.
Again – shifting left – saves a lot of time and money and especially prevents user barriers before they reach the user.
