WCAG 2.2 Demo Suite

Keyboard testing

The highest-value accessibility test there is. It needs no software, takes five minutes a page, and catches failures that affect blind users, users with motor disabilities, switch users, and everyone driving the page by voice — because voice control and switch devices operate the keyboard interface underneath.

Before you start

Physically move the mouse out of reach. Every accessibility professional has caught themselves nudging the pointer out of habit, and it invalidates the test.

On macOS, first turn on System Settings → Keyboard → Keyboard navigation. Without it, Safari and Chrome will not Tab to links and buttons, and you will report failures that are really a system setting.

The keys

Keyboard interactions and what should happen
KeyExpected behaviour
TabMove to the next focusable control, in reading order
Shift+TabMove backwards. Must work everywhere Tab does
EnterActivate a link or a button; submit a form from a text field
SpaceActivate a button, toggle a checkbox, open a select. Never scrolls while a control has focus
Arrow keysMove within a composite widget: radio group, tab list, menu, slider, select
EscapeClose a dialog, menu, or popover, returning focus to whatever opened it
Home / EndJump to the first or last item in a widget or a slider's range

The test script

  1. Press Tab once from the top of the page. A skip link should appear and be visible. Activate it and press Tab again — focus must now be inside the main content, not back at navigation item two. 2.4.1
  2. Tab through every control on the page. Say out loud where focus is at each stop. If you cannot tell, that is a failure. 2.4.7
  3. Compare the focus order with the visual order. It should move left to right, top to bottom, and never jump unexpectedly. 2.4.3
  4. Check that you can reach everything you could click. Anything operable with a mouse but not the keyboard fails outright. 2.1.1
  5. Open every dialog, menu and popover. Focus must move into it; Escape must close it; focus must return to the trigger. 2.1.2 2.4.3
  6. Try to get stuck. Tab into custom widgets, embedded players and third-party iframes, then try to leave in both directions. 2.1.2
  7. Watch for focus disappearing under sticky headers or cookie banners. Do this at 100% and again at 200% zoom. 2.4.11
  8. Tab past every control without activating anything. Nothing should submit, navigate, or open. 3.2.1
  9. Change every select and checkbox. Nothing should navigate or reload without an explicit submit. 3.2.2
  10. Submit a form with errors. Focus should move somewhere useful, and the error must be reachable and readable. 3.3.1

What you will find, in order of frequency

  1. outline: none with no replacement — no visible focus anywhere.
  2. A div or span with a click handler, unreachable by Tab.
  3. A modal that opens without moving focus, so the keyboard user is left behind it.
  4. A modal that does not return focus to its trigger when closed.
  5. A custom dropdown that traps focus, or that arrow keys do not drive.
  6. Focus scrolling underneath a sticky header.
  7. A positive tabindex scrambling the order.

Practise on these demos