How to test keyboard-only navigation

Why keyboard access comes first

Screen-reader users drive pages from the keyboard, and so do many people who cannot use a mouse or trackpad. If a control cannot be reached with Tab or operated with a key, it does not exist for them — and no amount of good labelling fixes that.

WCAG 2.2 sets the floor at Level A: “All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes” (W3C, 2023).

The keys you will use

The WAI-ARIA Authoring Practices Guide describes the core convention: “the tab and shift + tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements” (W3C WAI-ARIA Authoring Practices Guide, 2026). Beyond that, each widget pattern has expected keys — buttons activate with Enter and Space (W3C WAI-ARIA Authoring Practices Guide, 2026), tab lists move with Left and Right Arrow (W3C WAI-ARIA Authoring Practices Guide, 2026), and modal dialogs close with Escape (W3C WAI-ARIA Authoring Practices Guide, 2026).

A step-by-step keyboard test

Run it on your most important pages and on every page of your most important task. Note what failed and exactly where.

1. 1Put the mouse and trackpad away

   Move the mouse out of reach and do not touch the trackpad for the rest of the test. Load the page fresh and press Tab once, so focus starts from the top of the page.

   Check that:

   • The first Tab lands on something visible near the top of the page, not somewhere mid-page or nowhere.

   WCAG 2.1.1

2. 2Check the skip link

   On a page with repeated navigation, the first Tab stop is usually a skip link, visible when focused. Activate it and press Tab again.

   Check that:

   • A skip link, or another way past repeated blocks, exists.
   • After using it, the next Tab lands inside the main content, not back in the navigation.

   WCAG 2.4.1

3. 3Tab forwards and backwards through the whole page

   Press Tab until focus leaves the page, then Shift+Tab back to the top. Note every stop.

   Check that:

   • Every link, button and form control can be reached.
   • The order follows the visual layout and the meaning of the page.
   • Nothing invisible, off-screen or disabled receives focus.

   WCAG 2.1.1 · 2.4.3

4. 4Watch the focus indicator at every stop

   At each Tab stop, find the focused element without guessing. Pay extra attention near sticky headers, cookie banners and chat widgets.

   Check that:

   • You can always see where focus is.
   • The focused element is never entirely hidden behind something the page drew on top of it.

   WCAG 2.4.7 · 2.4.11

5. 5Operate every control with the keys it expects

   Activate controls from the keyboard alone, using the keys the WAI-ARIA Authoring Practices Guide specifies for each pattern.

   Check that:

   • Buttons activate with both Enter and Space.
   • In a tab list, Left and Right Arrow move between tabs.
   • A menu button opens its menu with Enter or Space and puts focus on the first item.
   • Nothing works only on hover.

   WCAG 2.1.1 · 4.1.2

6. 6Open and close every dialog

   Open each modal dialog with the keyboard, Tab through it, and close it with Escape.

   Check that:

   • Focus moves into the dialog when it opens.
   • Tab and Shift+Tab stay inside the dialog while it is open.
   • Escape closes it, and focus returns to the control that opened it.

   WCAG 2.4.3 · 2.1.2

7. 7Look for keyboard traps

   Tab into every widget — date pickers, embedded video, maps, chat, rich text editors, third-party iframes — and try to Tab out again.

   Check that:

   • Focus can always be moved away using the keyboard alone.
   • If leaving needs something other than Tab or Shift+Tab, the page says what.

   WCAG 2.1.2

8. 8Trigger changes that do not reload the page

   Follow in-app links in a single-page app, load more results, delete an item from a list, submit a form with errors.

   Check that:

   • After a route change, focus lands somewhere sensible, not back on the page body.
   • When the focused element is removed, focus moves to a logical neighbour instead of vanishing.
   • Receiving focus never changes the page on its own.

   WCAG 2.4.3 · 3.2.1

9. 9Test single-key shortcuts

   If the site uses shortcuts made of a single letter, number or symbol, type in a search field and elsewhere on the page to see whether they fire unexpectedly.

   Check that:

   • Single-character shortcuts can be turned off or remapped, or only work while the relevant component has focus.

   WCAG 2.1.4

Expected keys come from the WAI-ARIA Authoring Practices Guide's button, tabs, menu button and modal dialog patterns (W3C WAI-ARIA Authoring Practices Guide, 2026 and the patterns cited above). Where a custom widget follows none of them, the test is simply whether it can be operated and left with the keyboard.

Dialogs are where keyboard tests fail most visibly — see focus management after a modal for the details of step 6. When the keyboard test passes, move on to testing with a screen reader.

The WCAG criteria behind the test

Criterion names and levels are from WCAG 2.2; the 2.1.4 and 2.4.3 requirements are shortened here, so read the full text in the Recommendation (W3C, 2023).

Common mistakes

• Testing with a mouse in reach. One click to recover hides the barrier you were about to find.
• Only testing forwards. Shift+Tab exposes traps and order problems that Tab alone does not.
• Testing the page before interacting with it. Menus, dialogs and loaded content create most keyboard failures, and they only exist after you act.
• Accepting a faint focus ring. If you had to hunt for it, a keyboard user will lose it.
• Skipping third-party widgets. Chat, payment and consent frames are part of your page as far as a user is concerned.

Where automation fits

Automated scans check markup, so they can flag some keyboard problems in code, but they cannot tell you whether focus order makes sense, whether a widget traps focus, or whether a task can be finished from the keyboard. That takes something that actually presses the keys.

• Journey testing runs a simulated screen-reader user through a task keyboard-only, checking where focus landed after every action, and reports the step it could not get past.
• Real user monitoring watches real sessions for focus traps, focus lost after a single-page-app route change, focus that is not visible, and repeated Tab presses that go nowhere — and counts keyboard-driven sessions separately.

Neither replaces the manual test above; they make sure it does not only happen once.