Keyboard Navigation Coverage: The Accessibility Metric Your Tab Key Reveals

2026-10-27

Some accessibility metrics require specialist tools. This one requires a keyboard, a list of journeys, and the discipline to keep your hand off the mouse. Keyboard navigation coverage is crude, binary, and brutally informative.

It also maps directly to real users. Keyboard only and switch device shoppers experience your site as a sequence of stops. Coverage tells you how far through the money journeys that sequence actually reaches before it dead ends.

Defining the metric cleanly

Choose a fixed set of journeys: browse to a product, configure and add to cart, check out, manage an account task, and complete a return. Coverage is journeys fully completable by keyboard divided by journeys attempted, reported per journey rather than as one blended number.

Binary scoring is the point. A journey that fails at the payment step is not eighty percent accessible to the person who cannot pay. Partial credit belongs in your internal notes about where it broke, not in the headline metric.

How to measure it without tooling

Unplug the mouse or put it in a drawer, then walk each journey with Tab, Shift Tab, Enter, Space, and arrow keys. Log three things per stop: whether focus was visible, whether the control could be activated, and whether focus ever vanished or trapped.

Two testers, one of them new to the exercise, catch more than one expert, because experts unconsciously compensate. Time each journey too. A journey that is technically completable in nine minutes of tabbing has a coverage problem wearing a success costume.

Where journeys usually break

The recurring failure points are modals that do not trap or release focus correctly, custom dropdowns that ignore arrow keys, cookie banners that swallow the first fifty tabs, and checkout widgets embedded in frames nobody tested.

Each break has a location signature. Plotting breaks by component rather than by page usually reveals that two or three shared components account for nearly every failed journey, which turns an overwhelming metric into a short engineering list.

Setting a target and holding it

Checkout, cart, and account journeys should sit at one hundred percent coverage as a standing requirement, retested on every release that touches them. Lower priority journeys can carry a dated remediation plan, but the money paths do not get exceptions.

Add a lightweight keyboard pass to the release checklist for any changed component. Coverage decays through ordinary development, not malice, and the only metrics that survive are the ones wired into the process that breaks them.

Frequently asked questions

Which keys should a proper keyboard test use?

Tab and Shift Tab to move, Enter and Space to activate, arrow keys inside menus and radio groups, and Escape to leave dialogs. If a journey needs a key outside that set, the journey has a bug.

Does visible focus count inside coverage?

It should. A control that is technically reachable but whose focus is invisible is not navigable in practice. Score journeys as failed when focus disappears, and record invisibility as the break reason.

How often should coverage be remeasured?

On every release touching navigation, cart, or checkout components, and as a full sweep quarterly. Component level changes are where coverage quietly dies between annual audits.

Can automated tools measure keyboard coverage?

Partially. Scanners flag missing focus styles and unreachable controls, but they cannot judge whether a journey hangs together. Manual walkthroughs remain the measurement of record for this metric.