In my previous post, I suggested that the best place to begin if you want to produce accessible websites, apps or documents is to start testing with keyboard-only input and with a screen-reader.
In part 1 of this post, I’d like to explore the effectiveness of accessibility testing in a bit more depth, and cover the basics of keyboard-only testing. In part 2, I’ll cover using a screen-reader for testing.
Why Testing is an Effective Place to Start
One of the challenges of achieving accessibility is that most people don’t relate to it, since they are so used to accessing computers visually with a mouse or touchscreen. They can’t imagine what a different approach would look like. This can make the rules of accessibility seem like abstract red tape that “doesn’t really matter”, or something which everyone has good intentions towards, but without knowing how to make sense of the applicable rules.
Testing solves this problem by giving a practical way for people new to accessibility to experience first hand the impact of inaccessible products. It also gives them a concrete goal to work towards that doesn’t require learning the subtleties of the WCAG standard up front.
Even if you do master the rules of the standard, testing is the most essential component for practical accessibility, because it is entirely possible to build a product that could be argued by a lawyer with weaselly technicalities to be compliant to the standard, but which still fails completely to be usable by the target audience.
So starting to learn testing techniques sooner in the process is also the best for the long run.
Keyboard-only Testing
For most people who are visual users of websites, apps or documents, keyboard-only testing is a relatively small adjustment. All you have to do is perform your normal test plan or test activities using only the keyboard. The one thing I would recommend is, until you get used to eschewing the mouse, it helps to physically set your mouse aside, out of easy reach, so that you don’t unconsciously grab it when you hit a snag. Using the mouse to bail you out would of course defeat the purpose of the testing, which is to ensure you don’t ever need a mouse to access functionality, or to solve a navigation problem. It is surprising how automatic much of our computing behaviour is. I’ve seen many people new to accessibility automatically revert to using the mouse midway through testing without realizing it!
The main keys that you will typically use for keyboard testing are page up and page down for accessing content, tab to access active elements in order, and likely cursor keys to manipulate active elements, such as drop downs.
Overall you want to make sure that all content and functionality is perceivable and operable just with the keys, that you don’t get stuck in any of the functionality (e.g. active elements you can’t tab out of), and that the tab order is logical and follows the visible ordering. It should also be visually obvious which item has the current focus in the tab order when tabbing.
When you start, I would recommend doing the keyboard-only testing as a separate step to make sure you cover all the bases. Once you have mastered it, and have also mastered screen-reader testing (covered next post), you can often do both kinds of testing at the same time if you want streamline the process. If you can afford the extra steps, or want to split up the work across the team, doing them separately is never bad, since it makes it easier to focus on a subset of the potential issues, which might allow more problems to be caught more quickly.
I would expect that anyone with some experience at testing should be able to master keyboard-only testing after two or three sessions, since it really is quite straightforward, and is still a primarily visual approach to interacting with the product under test.
These basic keyboard-only skills will be built upon with screen-reader testing, which I’ll cover in the next post.
Practical Accessibility 