Practical framework / 5 MIN READ
Verify keyboard-only website journeys
Follow a real reader task without a pointer and report the exact control or state that prevents progress.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A keyboard review should test whether someone can complete the journey, not merely whether several buttons receive focus. Editorial components and embedded tools can break an otherwise usable page.
What you will leave with: Leave with a reproducible journey test and a prioritized set of interaction failures for the implementation team.
Use this when
- A new landing page includes custom menus or accordions.
- An embedded form or player has not been tested without a mouse.
- An automated accessibility scan passed but readers still cannot complete a task.
This is a focused manual check, not a complete accessibility audit or permission to perform irreversible actions while testing a live service.
Choose a bounded real task
Select a journey such as finding eligibility information, opening a comparison section or preparing a form submission. Define the starting point and safe stopping point. Use a test environment or approved test data where submission could create a real order, account or message. List the components on the route, including consent panels, navigation, dialogs and embedded tools. Record browser and operating-system conditions so a failure can be reproduced. Avoid choosing only the simplest page because it is likely to pass; include the controls that the intended audience must actually use.
Check actions rather than appearances
W3C's keyboard criterion concerns functionality operable through a keyboard interface, with a specific exception for inherently path-dependent input. That exception should not be used to excuse an ordinary button or menu implemented only for a pointer. Work through the journey using expected keyboard interactions and observe whether each required action is available. A visible outline proves only where focus is shown at that moment, not that the control works. Record what you pressed, what you expected and what occurred. Ask an accessibility specialist to investigate unfamiliar component conventions rather than guessing that any unexpected behavior is acceptable.
Inspect transitions and recovery
Open and close dialogs, expand content, move backward and recover from a validation error. Notice whether focus remains understandable and whether content overlays block the next action. Check that a reader can leave a component rather than cycling indefinitely inside it. These observations may involve accessibility criteria beyond keyboard operation, so describe the behavior instead of labeling every issue as the same violation. Include the route back to the page after an embedded interaction. A journey that works only when no mistakes are made is incomplete for real readers.
Report a failure the team can fix
Create one issue per meaningful failure with the page, starting state, key sequence, observed result and consequence. Attach a safe recording or screenshot if it clarifies the problem without exposing private data. Distinguish a blocker from friction and from an unfamiliar but documented interaction. Retest after repair using the same steps, then repeat the complete journey because a local change can affect later states. Keep the result scoped to the pages and conditions checked. Passing a keyboard journey is useful evidence, but it cannot establish screen-reader usability, visual accessibility or full conformance by itself.
Make the reasoning concrete.
A hypothetical training provider adds a course filter and a registration dialog to a course page.
Shallow check
Opening: The tester tabs through the header and sees focus on the registration button.
Hypothesis: The page appears keyboard-aware.
Risk: The course filter and dialog close action remain untested.
Journey check
Opening: The tester selects a course, opens the dialog, triggers a safe validation error and returns to the page.
Hypothesis: The team can locate the exact state where progress stops.
Risk: A real registration must not be submitted merely to complete an unauthorized test.
The tester reports the inaccessible filter action and dialog recovery separately, then retests the complete journey after repair.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Task
What real reader goal and safe stopping point define the test?
Conditions
Which browser, device and page state are used?
Sequence
What exact keys lead to the problem?
Consequence
Does the failure block completion or create recoverable friction?
Retest
How will the repaired component and whole route be verified?
Watch for the wrong conclusion.
- Testing focus appearance without activating controls.
- Ignoring embedded tools or error states.
- Submitting real transactions as casual test data.
- Calling one successful keyboard journey a full accessibility audit.
Your next action
Complete one safe reader journey without a pointer and write a reproducible issue for the first blocked action.
Sources & scope
The framework, examples and suggested checks are original editorial synthesis. Hypothetical examples are not measured results. Source checking is not an independent audit or a guarantee of business outcomes. No named human reviewer is claimed.
- W3C WAI: Understanding SC 2.1.1, Keyboard →Primary publisher guidance · Supports: Supports keyboard-operable functionality with the criterion-specific path-dependent exception. This journey check is not a complete WCAG conformance evaluation.