The keyboard walk

The walk, in rules

The keyboard walk has three rules and one notebook. Rule one: Tab only — no mouse, no trackpad, no touch. Rule two: narrate every stop — where am I, what is this, what will it do? Rule three: the walk must reach everything a mouse can reach and leave nothing a keyboard cannot. A page fails the walk the moment Tab stops on something invisible, skips something important, or traps you in a widget with no way out.

• Trap 1 — the invisible stop: focus lands on an off-screen element or a hidden control. Fix: check what has focus styling at every stop; if you cannot see where you are, the user cannot either.
• Trap 2 — the skipped hero: the primary CTA is a div with onClick, so Tab walks past the most important action on the page. Fix: real <button> or an anchor with href — interactive things must be focusable things.
• Trap 3 — the modal prison: focus enters a dialog and Tab cycles forever inside, or worse, escapes behind the scrim. Fix: focus management — trap within the dialog while open, return to the trigger on close.
• Trap 4 — the scroll requirement: content expands on hover, so a keyboard user never sees it. Fix: hover-reveal must also open on focus-within.
• Trap 5 — the radio maze: custom dropdowns and tab widgets that swallow arrow keys or announce nothing. Fix: use native controls first; only build custom widgets when you also build their keyboard contract.

The order is the design

Tab order is DOM order unless you reorder it with tabindex, and DOM order should follow reading order — which should follow visual order. The walk exposes disagreements: a visually left-to-right layout whose DOM stacks the sidebar first, a skip-link that is missing so every page visit starts with the nav, a focus that jumps to the footer after a filter. These are not keyboard bugs; they are layout bugs seen from the keyboard. The walk finds them in about ninety seconds.