There are not a lot of mobile devices that has a built in keyboard in this decade, so it’s easy to forget about keyboard support when testing native mobile apps. In most of mine native mobile app accessibility audits and usability testing keyboard support is still one of the most problematic parts and I wanted to provide some basic tips in this post.
I advocate that every native mobile developer should buy a physical external Bluetooth keyboard (if they do not have a mobile device with built in keyboard). Sure, some emulators or remote control software can pass desktop keyboard events to the mobile device, but I’ve sometimes experienced differences, and I also believe that dedicated physical keyboard serves as a good reminder to develop and test with keyboard in mind.
WCAG success criterion 2.1.1 Keyboard (Level A, opens in new window) states:
“All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes”
and then adds the exception:
“except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints.”
This basically means that if your app is not a drawing or painting app and is not an app or a game where a user needs to provide a complex path – you need to make it work with a keyboard. Besides that, WCAG does not define how to support the keyboard, but there are some common patterns that we can take as a guidance (mostly because things work like this on the web).
Tab and shift tab keys – move between interactive components
Buttons, links, form elements are all examples of interactive elements. And it should be possible to navigate to them (to focus them) with the tab key, when using the keyboard. Pressing and holding the shift key and then the tab key changes the direction of tabbing – so that it goes in reverse.
Arrow keys to move inside related group of related interactive elements
When your interactive component is actually grouping multiple interactive sub-components, then tabbing should focus the whole group (remember a group of related radio buttons from web).
And arrows should then be used to move focus inside the group (yes, just like when on the web you use the keyboard in a group of related radio buttons).
Ideally up arrow should go to the element above, down arrow to the element below, right arrow to the next element and left arrow to the previous element. But it depends on the positioning, screen size (element positions can change with screen sizes or zooming), so there is no general rules. Ideally, we need to be careful that order is logical. It should follow the reading order of the culture (left to right, top to bottom in western cultures) and be as logical as possible (if navigation sequences affect meaning or operation we also need to consider WCAG success criterion 2.4.3 Focus Order (Level A, opens in new window).
Space or enter key to activate element in focus
With buttons and links, space will activate / open them. And enter as well.
But, when we are already editing in text field, a space is just a normal space, of course. It also needs to activate “writing mode” when we are only focused on it.
When things are not so simple – what to do?
This post is trying to be an oversimplification, or at least trying to simplify things as much as possible. There are a lot of different scenarios and components out there and perhaps this will not help you a lot, but try to make things intuitive with this recommendations when possible.
If not possible – you should document keyboard interactions, even if you are not needing to conform to EN 301 549 (that requires it under 12.1.1 Accessibility and compatibility features, opens in new window). It will make things easier for users if they don’t need to guess what is needed.
And if you are using any abstraction model to code your native applications, like for example React Native – please check if there are any known issues with keyboard.
Document issues, help yourself and help others
If you find that there are issues when you test with keyboard – please open a bug, document it and try to provide a simple example.
It will help isolate the issue, and hopefully help remediation. Sometimes it will just make things more clear to you and your team.
We need more developers to open issues to make progress and opening issues is an important step for multiple people. As open accessibility issues serve also as an indication of accessibility awareness, how much attention accessibility gets in the project and also how (in)accessible can the end products actually be.
