Accessibility & Standards

Keyboard Navigation

Definition

WCAG treats this as a floor rather than an enhancement. Success criterion 2.1.1 Keyboard, at Level A, requires all functionality to be available from a keyboard; 2.1.2 No Keyboard Trap, also Level A, requires that focus can always move back out of a component; 2.4.3 Focus Order asks that the sequence preserve meaning; and 2.4.7 Focus Visible, at AA, requires that you can see where you are. WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum) at AA, because sticky headers and cookie bars routinely cover the element that just received focus. The people affected are not only blind users: keyboard operation is what motor impairments, switch devices, speech input and a sprained wrist all fall back on, and plenty of sighted users simply prefer it.

Why It Matters

A control that cannot be focused cannot be used, and nothing about the page looks wrong from a mouse. That is what makes this class of bug survive review. The consequences scale badly, too: a modal that does not trap focus lets a keyboard user tab invisibly through the page behind it, so their next keystroke does something they cannot see; a carousel that keeps off-screen slides focusable makes focus vanish for several presses. Both are fifteen minutes of work and both make the page unusable. In an audit, keyboard failures are usually the cheapest severe findings to fix and the most expensive to leave.

How It Works

A fixed set of elements is focusable with no help: a with an href, button, input, select, textarea, summary, iframe, anything with contenteditable, and audio or video with controls. Tab moves forwards through them in document order, Shift+Tab backwards. Activation differs by element — a button responds to both Enter and Space, a link to Enter only — which is one more reason to pick the right element rather than recreate it. Composite widgets follow a different pattern: the widget as a whole takes one tab stop, and arrow keys move within it, as a native select or radio group already does. A dialog needs three behaviours written by hand: focus moved into it on open, focus kept inside while it is there, Escape to close, and focus returned to whatever opened it.

Real-World Example

A prompted budgeting app, exported as one HTML file and published at budget.99helpers.site, shows two problems in a two-minute keyboard pass. The 'Delete row' controls are styled span elements, so Tab skips past them entirely and there is no way to remove a row without a mouse. The settings dialog opens with focus left on the button behind it, and Escape does nothing. Replacing the spans with button elements fixes the first; adding focus movement, a focus trap and an Escape handler fixes the second. Neither change alters a pixel of the layout, and the corrected file replaces the old one at the same 99helpers address.

Common Mistakes

  • Building interactive controls from div or span elements — they are not focusable, so Tab passes straight over the only way to perform the action
  • Opening a dialog without moving focus into it — the user carries on tabbing through the page behind the overlay with no idea where they are
  • Leaving hidden panels focusable — an off-canvas menu positioned off-screen rather than hidden keeps every one of its links in the tab order
  • Adding a mouse-only interaction such as hover-to-reveal or drag-to-reorder with no keyboard route — WCAG 2.2 added 2.5.7 Dragging Movements at AA for exactly this

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →