Keyboard operability – why is it important? (part 3)

Usage scenarios of mobile apps are diverse – including the use of a keyboard

While touch operation is certainly the most typical mode, for many people it is not the only way of using the app. On the one hand, there are mobile apps not only on the mobile phone, but also on tablets, some of which are used with a keyboard. Some people also prefer tablets to laptops, both because of their lower weight and because of the simpler interface and workflows of mobile app variants when compared to equivalent desktop applications. If you want to write down your thoughts or write a longer e-mail on the way home after a meeting, you can benefit from keyboard accessibility. You just connect a small foldable keyboard to your mobile phone instead of having to use the virtual keyboard, and text input will be a lot more comfortable - and the alternative of voice input is not realistic in many situations (just think of a fully occupied train car). Another reason: Mobile platforms are getting ever closer to desktop platforms. Apps can now often also be used on desktop operating systems, and here, the keyboard is the usual input device next to the mouse anyway.

Keyboard operability also supports other input options

For people with motor impairments for whom touch operation is difficult or not possible, keyboard operation is of course particularly important. If the keyboard operability of an app is successfully implemented, it usually also supports switch control, screen reader usage and voice control.

Not all keyboards are the same

For mobile testing, an external standard keyboard can be connected directly to the smartphone via USB C. With iOS, there is the alternative of testing apps on the iPad with a docked Magic Keyboard. However, there are sometimes small differences in support: the Magic Keyboard does something that does not work with the standard keyboard, or vice versa. The keyboards themselves may also be different: for example, some control keys are missing, and there is no escape key on older Apple Magic Keyboards. Differences may also be due to the fact that Apple is now developing different operating systems for iPhones and iPads: iOS and iPadOS. These are very similar, but not always identical in keyboard behaviour. If both types of keyboard are used, a test report should record differences in support when discovered.

What devices are best?

In the BIK BITV-Test (App), the keyboard operability of a mobile app is usually tested on a current iPhone or Google Pixel mobile phone, connected to a standard keyboard paired via USB or Bluetooth - with the screen reader turned off.

Why Google Hardware instead of Samsung Huawei and Co? Google's Pixel phone guarantees that the unchanged Android ("Vanilla Android") is used and that the system is up to date. Other device manufacturers sometimes change the system interface (use their own Android "skin"), update with delay, possibly use other virtual keyboards and possibly not the current version of the screen reader TalkBack (even if this can probably be reinstalled).

If the customer wants a test of the app on a tablet in addition to the test on the smartphone or wants to ensure that the app will be accessible also on older devices with older versions of the OS, this is useful, but the effort increases significantly.

Apps often show barriers for keyboard users

When testing with the keyboard connected, there are significant differences in both operating systems. Traditionally, Android has the better keyboard operability, but here too it often happens that interactive elements of the app cannot be reached and activated at all with the keyboard. This is then a violation of the requirement 11.2.1.1 Keyboard.

On iOS, keyboard operation often requires switching between the tab key and the arrow keys to reach all the elements. And some elements are even only accessible with CTRL + Tab. This is sometimes cumbersome and requires a lot of trial and error. Nevertheless, in our test, the keyboard operability would be given a pass if it is somehow possible - because the underlying normative requirement does not determine by which keys the keyboard operation should be supported. However, if the keyboard focus order is unclear, visually not detectable or counterintuitive, the issue would be recorded as a violation of another requirement, 11.2.4.3 Focus order.

Poor keyboard focus indication

Mobile keyboard operation is generally made more difficult by the fact that the standard keyboard focus indication on both iOS and Android is very weak: usually only a semi-transparent subtle darkening of the elements in focus. Is this a failure of the contrast requirement for graphic elements (i.e. requirement 11.1.4.11 non-text contrast)? It is not, because the normative requirement has an exception for native elements, i.e. elements (including focus indicators) not changed by the developer. Therefore, our test only records an error if developers themselves influence the focus highlighting and then the contrast is not sufficient. If there is no visible focus at all, however, this is clearly a failure of requirement 11.2.4.7 Focus visible.

Conclusion

I hope we have shown that keyboard operability is also relevant for mobile apps and should not be omitted. For a conformity test that is based on the relevant European standard, EN 301 549, it would be mandatory anyway – because requirements for keyboard operability are laid down in Chapter 11 Software which also forms the basis for testing mobile apps. That so many problems with keyboard operation still appear in our tests is certainly due to the fact that in the absence of legal obligations, this user group (and other groups that indirectly benefit from good keyboard use) have not been considered since a large majority of users operate their devices by touch. For people with disabilities, however, keyboard operation is a critical topic also for apps – and non-disabled people benefit from it too, as our examples may have shown.