Keyboard focus: the five checks that catch most accessibility bugs in a form

Most keyboard problems in forms are visible in two minutes with nothing but the Tab key. Unplug the mouse and walk through the page.

What to check

1. Can you see where you are? Every interactive element needs a visible focus indicator. outline: none without a replacement fails WCAG 2.4.7 (Focus Visible). Prefer :focus-visible so mouse clicks stay quiet while keyboard users get a clear ring.
2. Does the order match the reading order? Tab follows DOM order. If CSS reorders things visually (flex order, grid placement, absolute positioning), keyboard order and visual order drift apart (WCAG 2.4.3).
3. Can you get out? A modal must move focus in on open, keep it inside, close on Escape, and return focus to the button that opened it. A focus trap with no exit is a hard blocker.
4. Is every control reachable and named? A div with a click handler is not focusable and has no role. Use button and a, and give icon-only buttons an accessible name (aria-label or visible text).
5. Do errors reach the user? On a failed submit, move focus to the first invalid field or an error summary, and tie each message to its input with aria-describedby. A red border alone is not enough.

Why a one-off pass is not enough

These bugs come back. A new component, a CSS reset or a design refresh can drop focus styles on a page that passed last month. The reliable habit is a repeatable check that runs on every release, not an audit you did once.

Which of these do you see broken most often?