How to do keyboard testing

If you don’t have a disability that affects how you interact with the web, and you don’t rely on assistive technology, the single best thing you can do to test an interface is… Test with the keyboard only!  (It’s also a great way to test if you do have a disability that affects how you interact with the web, or you do rely on assistive technology.)

Keyboard accessibility is a great proxy for lots of different input technologies. For example, you might not think that keyboard access does anything for speech control users if they aren’t physically typing. But speech users can speak simple commands like “Press Tab” or “Press Alt F4,” which are passed in as keystrokes. They can also create macros that replay a series of keystrokes.

Anyone who can use, or emulate, a physical keyboard can do keyboard testing. You don’t have to be a developer or any kind of expert.

Before you begin

Unplug any pointer devices that you have. Unplug your mouse or trackball, cover your touchpad, ignore that eraser thingie in the middle of your keyboard. You need to be testing with just a physical keyboard, or an input device that emulates one. You will be using more than just the Tab key; some controls use arrow keys, or the Escape key, and may use modifiers (shift, control, etc). Mac users may need to adjust their keyboard settings to be able to tab to all relevant elements.

What to look for

Everything on this list is an issue we’ve seen on real live sites during our web accessibility clinics.

  • Can you skip repeated content?
    • A skip link is a fine way to accomplish this. It should be the first tab stop on the page, and should take you to whatever the main content is when activated. Skip links need to be visible when you tab to them.
  • Are all controls fully operable?
    • Every interactive element has to be usable with the keyboard. Links, buttons, expand/collapses, tree views and sliders, modals and lightboxes and overlays - drag and drops - everything. Or there needs to be an alternative way to accomplish the action.
  • Can you tab in both directions?
    • We've seen some applications where tabbing forward through the page worked fine, but it was impossible to tab backward (using the Shift+Tab key combination), which created a keyboard trap. Make sure you can tab all the way through the interface in both directions.
  • Can you dismiss content that pops up or otherwise displays over the main content?
    • If there are any popups or overlays or modal dialogs, can you dismiss them with just the keyboard? If not, you’ve just created a keyboard trap.
  • Is your focus constrained when there is a modal dialog?
    • Not all popups/overlays are modal. When there is a modal dialog, your keyboard focus should be constrained within it. Otherwise, you might tab off it and be tabbing around the page behind the modal, unable to see where you are.
  • Is your focus always visible?
    • Browsers have built-in focus highlighting, but it is often inadequate. Create your own focus styles that work across browsers and work with the foreground and background colors you are using. Remember that unlike when using a pointer device, when using a keyboard there isn’t a moving indicator that shows you where you’re going. Focus highlighting needs to be noticeable enough to compensate for this.
    • Also be sure that you aren’t hiding content visibly but leaving it in the tab order. 
  • Are there equivalents to hover effects?
    • If you use a pointer device: Plug it back in for a sec and hover over all parts of the page. Is there an equivalent focus effect for all of your hover effects?

Test your responsive breakpoints

After you’ve done all those keyboard tests: Increase your browser zoom until you hit a responsive breakpoint, and do it all again. Anyone who is using a high level of magnification will be interacting with your “tablet” or “phone” version on their laptop. Mobile breakpoints aren’t just for touchscreen users!

Document any problems you find...

In order to fix a problem, it really helps when people can see it or reproduce it for themselves. Be ready to provide as much information as you can:

  • The location where it occurs
  • Information about your browser and operating system
  • Detailed steps and keystrokes to reproduce it
  • If possible, a screenshot or screen recording

Providing this information to whoever develops your website will help them fix it and also to test and verify the fix.

... or fix the problems yourself!

If you are handy with HTML, CSS, and/or Javascript, and you have access to the source code of your website or web-based application, you can diagnose and fix most of the common causes of keyboard accessibility problems yourself. The Keyboard tab of the DIY Accessibility checklist has more details.


This document was originally developed by Caroline Boyden for a hands-on accessibility session at DrupalCon 2019, and was updated by the Web Access team for WebNet later that year.