Common Accessibility Errors in native Apps
Accessibility of native apps is playing an increasingly important role: only in recent years have specific testing tools and testing procedures reached a usable level. At this point I would like to summarize my most frequent findings as a blind user and tester of apps. This list is therefore subjective.
I am an Android-first user and currently use iOS more casually. That means I know both operating systems equally well.
General problems
Of course, the most common design errors in apps are the same as those found on the web or in software: insufficient contrast, information only via color, interactivity with background elements, non-controllable animations and multimedia, and so on. I don't want to go into this any further here so as not to make the article too long.
In general, I have noticed more technical errors in Android than in iOS. I cannot say whether this is due to the developer guidelines of the respective providers or because the developers assume that more disabled people use iOS and therefore neglect Android. Perhaps the iOS testing tools are better or Apple makes it easier to develop accessible apps. Specialization is also progressing in this area: Most develop for only one platform or are even specialized in certain frameworks that can automatically create apps for both platforms. Here too, it could be that the code for Apple is more accessible despite the same basis.
You also have to keep in mind that there are system-related limitations and problems. This means that the two systems are not 1:1 comparable. iOS may have an advantage in accessibility for the blind, but at least when it comes to VoiceOver, the software quality is poor. Every update can lead to important functions having bugs that are only fixed with the next update. 'Android Talkback has fewer configuration options and possibly other problems. iOS is completely and Android is partly a black box, because the provider of the OS is also the provider of the assistive technology and neither Google nor Apple are transparent about bugs and limitations of the assistive technologies.
It is generally said that the use of native components leads to fewer accessibility problems. However, not all native components are completely accessible.
Keyboard
Few people know that the same requirements for keyboard usability apply to native apps as to websites and software. This primarily means interactivity, keyboard focus and logical tab order. This was never fully met in the apps that I tested and was certainly not tested by the developers.
The background of the reuqirement is that the keyboard interface is also partly used by other assistive technologies. The keyboard is also important for the blind when entering numbers or complex character strings such as passwords.
Name, role, value
On Android, you often see elements that have no or no correct label. In the latter case, the automatic testing tools also fail, as they only see that a label such as "Android_Class_23_Btn" is present. The same applies to role and value. Very often, the status of an element such as activated/not activated is not displayed correctly when it is changed.
Elements without the correct role are also much more common on Android, but also at the level of the operating system itself. An entry in the menu is only read out as text, but not displayed as an interactive element such as a link or button. It is not enough here if it is clear from the context that something is clickable.
Both Android and iOS now have algorithms to recognize UI elements. However, this does not mean that these elements can be used, and it is not particularly reliable either.
I often come across UI elements that seem to be correctly implemented but are not comfortable to use. One example is Microsoft Teams on iOS: I have a thread in a team and only the first message is read out. Normally you could go to the next message in this thread by swiping right, but that doesn't work (it could also be a temporary bug). If there are different interaction patterns, these should be displayed for the screen reader user.
In the Android version, Deutsche Bahn uses an element that is not easy to use to set the times for the timetable information. You should put your finger on the screen and then drag up or down until the desired number appears. However, when using a screen reader, the currently focused number is not read out when you swipe. To be precise, the swipe gesture is not supported by Talkback at all, you have to hold and drag,
No event trigger with screen reader
Elements that react to normal taps often do not do so when the screen reader is activated, i.e. double tap. UI elements were probably not implemented natively.
Floating elements
Floating elements are often not in the focus order when using touch or keyboard. They are used on Twitter, for example, when new tweets are available.
On Android, it is often not possible to scroll comfortably in an endless scrolling area, an example is Twitter again. If you scroll through messages, the focus lands on a message that you have already read, because Talkback apparently cannot scroll down the list of messages on its own. However, I don't know if this is an accessibility or a talkback issue.
No support for landscape mode
Content should not force the user to use a specific screen orientation, usually portrait mode (1.3.4 Orientation (AA)). Unless a specific mode is necessary for functionality. However, many apps do not support landscape mode at all.
This is just a guess, but presumably the elements need to be designed so that they can float freely. In web design, you would say that you need a special stylesheet for landscape mode. It would of course look silly and not be helpful if you held the screen horizontally and all the elements were squeezed into the left third of the screen.
Lack of support for user settings
Chapter 11.7 of EN 301549 requires that user settings are supported, specifically the font size setting and the inversion of the screen. The latter is often not supported by either system, the larger font size set in the system is not adopted or there are overlaps.
The inverted state is often not supported by iOS, the app remains in the normal state. On Android, the colors are probably simply changed by the system, so that the apps cannot choose whether they want to be inverted or not.
Even if the mode basically works, it often happens that elements disappear or the contrast is suddenly no longer sufficient, perhaps because the font color remains the same even though the background has been changed.