Keyboard testing: the fastest accessibility check QA can run

If you only ever do one accessibility check, do this one. Put the mouse down and operate the whole feature with the keyboard. It takes a few minutes, needs nothing installed, and catches a startling share of the accessibility bugs that reach production — because keyboard access is the foundation everything else (screen readers, switch devices, voice control) is built on. If a thing can't be done with a keyboard, it can't be done with assistive tech either. This is the single check from my accessibility smoke test, expanded, because it earns the space.

The five keys

That's the whole toolkit:

• Tab — move forward to the next interactive element
• Shift+Tab — move back
• Enter — activate links and buttons
• Space — activate buttons, toggle checkboxes, scroll
• Arrow keys — move within a component (menu items, radio groups, tabs, sliders)

1. Can you reach everything?

Tab through the page start to finish. Every interactive thing — every link, button, field, toggle, custom control — should be a stop. The classic failure: a "button" built as a <div onClick>. It looks and works fine with a mouse and is completely unreachable by keyboard, because a plain div isn't focusable. If you can't tab to it, a keyboard user simply cannot use it.

2. Can you activate everything you reach?

Reaching isn't enough. On each control, try Enter and Space. A real <button> responds to both for free; a faked one (<div>/<span> with a click handler) often responds to neither, so it's a dead end even once focused. Custom dropdowns and date pickers are where this breaks most.

3. Can you always see where you are?

As you tab, the focused element should have a visible focus indicator — a ring or outline. The most common regression here is a stylesheet doing outline: none to "clean up" the design without providing a replacement. Lose the indicator and a keyboard user is navigating blind, guessing what's focused. If you can't see focus at any step, that's a bug — note where.

4. Does focus go in a sensible order?

Focus should follow the reading order — generally left to right, top to bottom. When the DOM order doesn't match the visual layout (often after a CSS reorder), focus jumps around unpredictably, which is disorienting and sometimes traps people. Tab slowly and watch the path.

5. Modals: the trap test

Open any modal, dialog, or menu and check two things. First, does Tab stay inside it, cycling through its controls, or does it leak to the page behind (where you can focus things you can't even see)? Second, does Esc close it, and does focus return sensibly to where you were? A modal that lets focus escape or won't close from the keyboard is one of the most reported accessibility defects there is.

What this won't catch

Keyboard testing is the foundation, not the whole house. It won't tell you whether a screen reader announces things usefully, whether colour contrast passes, or whether an image's alt text is meaningful. For those, run axe and do the rest of the smoke test. But every one of those higher checks assumes keyboard access works first — so this is where you start.

Where this fits

This is the highest-leverage slice of accessibility QA, cheap enough to run every release. The full pass is in my accessibility smoke test; the accessibility checklist goes deeper; and the glossary defines focus order, accessible name, and the ARIA terms that come up when you report these.

The keyboard pass

• Tab reaches every interactive element (watch for unreachable div "buttons")
• Enter / Space activate everything you can reach
• A visible focus indicator is present at every step
• Focus order follows the reading order, no wild jumps
• Modals trap focus inside and close on Esc, returning focus sensibly
• Anything you couldn't reach or activate is logged as a bug