← Go Back

Keyboard Navigation

What is keyboard navigation?

Keyboard navigation means users can reach and operate all interactive elements and complete key tasks using only the keyboard (Tab, Shift+Tab, Enter, Space, arrows, Escape). No mouse or touch required. It’s essential for accessibility and required by WCAG (e.g. 2.1.1 Keyboard).

Use it when: you’re building or auditing any web or app interface. Keyboard access is non-negotiable for many users (motor, vision, power users) and is part of WCAG conformance.

Copy/paste checklist

  • [ ] Tab through all interactive elements – Buttons, links, inputs, custom controls; nothing is skipped.
  • [ ] Visible focus – The focused element has a clear focus indicator (outline or other); don’t remove it.
  • [ ] Logical order – Tab order follows visual/logical flow (left-to-right, top-to-bottom in LTR).
  • [ ] No keyboard traps – User can always leave a component (Tab, Escape, or other key).
  • [ ] All actions keyboard-operable – Click, open, close, select, submit; no mouse-only actions.
  • [ ] Focus management – When opening modals or dynamic content, focus moves there and is trapped until closed. See focus management.

Why keyboard navigation matters

  • Required for many users with motor or vision impairments who rely on keyboard or switch devices.
  • Screen reader users typically navigate by keyboard; if it doesn’t work, they’re blocked.
  • WCAG 2.1.1 (Keyboard) requires that all functionality be keyboard operable.
  • Power users work faster with keyboard; good keyboard support helps everyone.

What good keyboard navigation includes

Checklist

  • [ ] All focusable elements reachable – No “skip” unless intentional (e.g. decorative). Use tabindex="0" for custom interactive elements; avoid positive tabindex.
  • [ ] Focus visible – Never outline: none without a visible replacement (e.g. border, ring). See WCAG 2.4.7.
  • [ ] Tab order matches logic – Tab order follows reading order; no random jumps. Fix with DOM order or (rarely) tabindex only when necessary.
  • [ ] No traps – User can Tab out of modals, menus, and custom widgets; Escape or other key closes them.
  • [ ] Focus moved on open/close – Open modal → focus inside; close → focus returns to trigger. See focus management.
  • [ ] Custom widgets – Follow ARIA patterns (e.g. menu, dialog) so keyboard behaviour is correct.

Common formats

  • Native elements: Buttons, links, inputs are keyboard operable by default. Prefer them.
  • Custom controls: Add tabindex="0", key handlers (Enter, Space, arrows), and ARIA so they behave like their native equivalent.
  • Modals/dialogs: Focus trap inside; Escape closes; focus returns to trigger on close.

Examples

Example (the realistic one)

You audit the sign-up flow with keyboard only. Issue 1: “Sign up with Google” is a div with click handler; it’s not focusable. Fix: Use a button or make it focusable with tabindex="0" and key handler for Enter/Space. Issue 2: Focus outline was removed globally. Fix: Restore visible focus (e.g. outline: 2px solid or design system focus ring). Issue 3: Modal doesn’t trap focus. Fix: On open, move focus to modal; trap Tab inside; on close, return focus to trigger. You retest with Tab, Shift+Tab, Enter, Space, Escape and confirm WCAG 2.1.1 and 2.4.7.

Common pitfalls

  • Removing focus outline: “It looks better without.” → Do this instead: Keep focus visible; style it to match your design (e.g. 2px ring) but never remove it.
  • Unfocusable custom controls: Div or span with click only. → Do this instead: Use button/link where possible; otherwise add tabindex="0" and keyboard handlers.
  • Keyboard traps: User Tabs into a modal or menu and can’t get out. → Do this instead: Trap focus inside until close; Escape (and optionally Tab from last element) closes and returns focus.
  • Wrong tab order: Order doesn’t match layout or logic. → Do this instead: Fix DOM order first; use tabindex only when necessary and document why.
  • Mouse-only interactions: Hover to reveal; no keyboard alternative. → Do this instead: Make all actions available via keyboard (e.g. focus to reveal, or separate button).
  • Keyboard vs focus management: Focus management is where focus goes (e.g. into modal, back to trigger); keyboard navigation is that all actions are possible via keyboard. Both are needed.
  • Keyboard vs tab order: Tab order is the sequence of focus when using Tab; keyboard navigation is the full set of keyboard-operable behaviour.
  • Keyboard vs screen reader: Screen reader compatibility often depends on keyboard access; many screen reader users navigate by keyboard.

Next step

Test one critical flow (e.g. sign-up or checkout) with keyboard only: Tab through every control, use Enter/Space where needed, open and close any modal. Fix anything that’s unreachable, unfocusable, or trapping. Then read Focus management for modals and dynamic content.

Related Terms