Keyboard Navigation Tester Guide

Keyboard Accessibility: The Foundation Everyone Skips

Walk into any team's accessibility retro and you'll hear the same sequence: 'axe says we're at 98', 'Lighthouse a11y score is 95', then someone actually unplugs their mouse and within thirty seconds finds three buttons they can't reach. Automated tools test what they can test, they cannot test the lived experience of driving a page with just a keyboard. That's where this checklist lives.

Why Keyboard First

Every assistive technology, screen readers, switch devices, voice control, eye-tracking, eventually translates user intent into keyboard events. NVDA's "form mode" emits Tab and Enter. Switch users emit a single key remapped to whatever step they're on. Voice control says "click submit" which becomes "find element, focus, Enter."

If your page works for someone with a keyboard, it works (or at least is operable) for everyone downstream. If it doesn't, no amount of ARIA labels saves you.

The WCAG conformance criteria most often violated are exactly the keyboard ones:

• 2.1.1 Keyboard. All functionality is operable through a keyboard interface.
• 2.1.2 No Keyboard Trap. Focus can move away from any component.
• 2.4.3 Focus Order. Focus moves in an order that preserves meaning.
• 2.4.7 Focus Visible. Keyboard focus has a visible indicator.

Four criteria, dozens of subtle ways to fail them.

The Checklist Structure

The audit walks four pillars in order; later pillars assume earlier ones pass.

1. Reachability. Press Tab through your entire page. Every interactive element, buttons, links, inputs, custom widgets, should receive focus. Common failures:

• <div onClick=...> used instead of <button>. Divs aren't in the tab order by default.
• tabindex="-1" on an interactive control. Removes from tab order.
• Hidden-but-not-display:none elements. visibility: hidden removes from tab order; opacity: 0 does NOT, invisible clickable buttons are an a11y nightmare.

2. Visibility. As you tab, the currently-focused element must show a clear visual indicator. Common failures:

• outline: none in CSS reset with nothing replacing it. Bare minimum: provide a :focus-visible style.
• Indicator too low contrast against background. WCAG requires 3:1 contrast for focus indicators (2.4.11 in 2.2).
• Indicator hidden under another element (sticky header, modal overlay).

3. Operability. Once focused, can you operate the control with the keyboard?

• Buttons: Enter and Space both activate.
• Links: Enter activates; Space scrolls (don't override).
• Checkboxes/radios: Space toggles; arrow keys move radio groups.
• Custom widgets (combobox, listbox, tree, slider): follow ARIA Authoring Practices Guide patterns.

The most common failure: a custom dropdown that opens on click but doesn't open on Enter/Space when focused.

4. Focus management. When the page state changes, a modal opens, a route changes, an error message appears, focus must move sensibly.

• Modal opens: focus moves into the modal (first focusable element, usually).
• Modal closes: focus returns to the trigger.
• Route change (SPA): focus moves to the new page's main heading or a designated "skip to content" target.
• Async error: focus moves to the error message, or it's announced via aria-live.

And focus traps, modals must trap Tab inside them so you don't tab to the page behind, but Escape must close the trap. A modal you can't escape from is the worst kind of keyboard trap.

The Actual Test, Step by Step

How to use the checklist effectively:

1. Open the page you're testing. Get to the state you care about (logged in, on the target route, with the relevant data).
2. Click into the address bar, then Tab. This resets focus to the top.
3. Tab through every interactive element. Watch where focus goes; note any element where focus disappears or skips.
4. For each interactive element, press the appropriate key (Enter for buttons/links, Space for checkboxes, arrows for menus) and verify behavior.
5. Trigger every modal, dialog, popover. Verify focus moves in on open and back on close.
6. Trigger every async update (form submission, search-as-you-type). Verify any new content is reachable.

Mark each checklist item as you go. The score updates live.

Common Patterns and Anti-Patterns

The "div button" trap. <div onClick={...} role="button"> looks like a button but isn't tab-reachable. Either add tabindex="0" and a keyDown handler for Enter/Space, or just use <button>. The latter is almost always right.

Focus rings disabled "for aesthetic reasons". button:focus { outline: none } is a WCAG fail unless you replace it. Use :focus-visible (mouse clicks don't show the ring, keyboard focus does) to satisfy both designers and users.

Modal without trap. A modal that doesn't trap focus lets the user tab "behind" it into the obscured page. They can interact with elements they can't see, confusing and often broken. Use a focus-trap library or hand-roll one.

Dropdown that requires hover. A dropdown that only opens on :hover is a desktop-mouse-only feature. Pair it with :focus-within so keyboard focus opens it too, or, better, use a click-based pattern with proper ARIA.

Skip link missing. Long pages with navs benefit from a 'skip to main content' link as the first focusable element. It's the difference between Tab-Tab-Tab-Tab-Tab-Tab and just one Tab.

Where Automated Tools Help

This checklist is manual by design, but automated tools complement it:

• axe DevTools catches ARIA misuse, contrast, alt text, code-level issues a static analysis can find.
• Lighthouse a11y audit catches the most common WCAG fails on a single page.
• Pa11y runs in CI for regression prevention.

A reasonable workflow: axe/Lighthouse first (eliminate the easy 40%), then this checklist (cover the 60% that requires a human).

Privacy

Checklist state lives in your browser's localStorage so you can pause and resume an audit across sessions. Nothing is sent anywhere, you can audit a private staging URL, a behind-VPN environment, an unreleased feature. To reset, clear localStorage for this site.