Many mobile apps are now released simultaneously for Android and iOS. At first glance, the two versions appear almost identical. But does that mean they perform equally well in terms of accessibility?
Is it sufficient to test only one platform, or are there hidden barriers for users with disabilities beneath the surface?
Since many mobile apps are developed in variants for both Android and iOS and often look and work similarly, the question arises for many providers whether it is not enough to check the accessibility on only one of these systems – especially if a development environment such as Flutter or React Native is used to generate so-called cross-platform apps – i.e. variants for both operating systems.
For many requirements that relate to visual properties such as the contrast of text and graphics, the target size of the interactive elements, information conveyed through the use of colour, or requirements for embedded media (like captions for videos), there are actually often the same or very similar results.
The situation is different when examining barriers that appear in non-visual use with the screen reader – this is the tool integrated in the accessibility settings of the operating systems that outputs visual information as speech. There are often serious differences here when you examine the iOS version of the app with the screen reader VoiceOver and then the Android version with the screen reader TalkBack, and beyond that, when you interact with the apps with the screen reader activated. For example, some graphical user interface elements may be unnamed in one version but not in the other. The availability of role and status information on such elements can also differ.
There are also significant differences for keyboard users, especially when it comes to tab order. When integrating so-called web views into native apps, there is often inconsistent behaviour; a content area may not be accessible when the view first called up, but becomes accessible later. Such problems are not always reproducible.
If you are now wondering: Wait, why do you even test apps with the keyboard, aren’t they used via touch gestures? – I have to ask you to wait for a later post of this blog series.
Short question: are there no operating system alternatives? Why just iOS and Android? OS alternatives have been developed, and new contenders appear from time to time, mostly based on Linux / Android, but so far, they do not play a significant role in the market for end users, at least not in Europe. The development of Windows Mobile was discontinued, support ended in 2019. Android and iOS share the market in Germany – in other countries such as China, the Android-based operating system HarmonyOS has a significant market share. Huawei has also developed its own (presumably TalkBack-based) screen reader called NEXT. In addition, there are still attempts to develop alternatives to Android. The article Open Source Mobile OS Alternatives to Android provides a fairly up-to-date overview. However, due to the dominance of Android and iOS, we focus on these two platforms in this blog series.
If you serve both OS platforms and want to use a BIK BITV-Test + WCAG 2.2 (App) to determine a list of existing issues in order to improve accessibility and work towards compliance with the European Accessibility Act (EAA) or one of its national implementations, you have no choice but to test both app versions. This is also important when a cross-platform development environment such as Flutter or React Native has been used, because the translation to the target platforms iOS and Android often result in differences in terms of accessibility.
All fields are mandatory