A friend of mine, in a work context, once interjected and said:

Why do you hate keyboard users?

I "don't remember" what project we were working on, but I do remember that we had gotten to the topic of Mobile Accessibility Testing processes. It always surprises teams when the first thing I tell them is to

Put your keyboard away. It's a waste of time.

Gasp, but what about the keyboard users?

Well... the rest of this blog post will explain why. But, if you trust me, you can summarize it in these 3 statements.

1. Switch Control Testing covers everything that Keyboard Testing covers.
2. Keyboard Testing DOES NOT cover things that Switch Control Testing does.
3. Actually doing Keyboard Testing properly on Android is very difficult and nobody, except me and a few Platform Engineers at Google, know how to. 🤷

Let's Go...

Switch Control Testing

The first very simple thing to note is that Switch Control Testing and Keyboard Testing from a functional point of view test exactly the same thing. Not a little bit the same, not kind of the same, not maybe sort of the same... it's literally the exact same code pathways.

I know... I helped architect them. The OS in AOSP stands for Open Source. I also know the Google Accessibility Platform Folks personally.

So, there's literally zero Accessibility reasons to test with both. I say that, because if you have a team big enough to think usability, there are subtle usability differences and I would never make fun of a team for doing both!

Keyboard Testing

I would, however, make fun of you for only doing Keyboard Testing. And that has a lot to do with the content of this demo video from one of the first implementations of Switch Control, the Assistive Scanning Keyboard.

Notice how it scans row by row.

This speeds up interaction greatly for users who can only send one signal to devices, and therefore rely on timing as their Tab Key. Imagine how long you'd have to wait to type a "Z" if items weren't grouped together. And yes, I made that a capital Z on purpose.

It's about 1 minute. ... 1 letter ... in 1 minute.

And there is the pot of gold at the end of the rainbow folks! Keyboard testing doesn't test for that grouping. If you can hit tab, you can scan forward fast enough where that grouping would actually become an inconvenience for you, so keyboard focus doesn't even respect that API. An entire API that you are not testing, an API that is the difference between usability and blocker.

SO... to my unnamed friend... I turn the question back to you:

Why do you hate severely physically handicapped users?

Because those are the users you are failing by doing Keyboard Testing. Because those are the additional users that Mobile Devices have brought accessible technology to.

Finally

Keyboard testing is very difficult. All of those people who say they "do keyboard testing on mobile" are doing it wrong and breaking things! Please Stop.

Note: If you are a keyboard only user and would like to learn about the Accessibility Testing you can do effectively on Android you are welcome to reach out!

For the rest of you, I highly recommend sticking to Switch Access or Voice Access. The testing process is much more straight forward in ways that would take you a very long time to learn about, let alone master in a testing capacity.

Conclusion

The Accessibility Industry's biggest obstacle is itself. It's like 20 years ago a committee got together and said: "this is our goal" and decided that was enough. Switch Control is more than that... it's the next layer of users. Let it be that, stop doing keyboard testing, and embrace the fact that we can do more than facilitate blind screenreader users.