Accessibility review
A keyboard walkthrough for your most important user journey
UxerProof Editorial · · 3 min read
Pressing Tab through a homepage is a starting check. A more useful walkthrough attempts a complete task: finding a record, opening it, making a permitted change and confirming the saved result.
The purpose is to identify obstacles in the tested keyboard path. It is not to declare the entire product accessible after one successful run.
Define the task and starting conditions
Choose an authorized environment and safe records. Record the browser and any assistive technology involved. If the review uses a keyboard without a screen reader, label it that way; these are related but different assessments.
Begin without a mouse. Follow the product's supported keyboard behavior to reach the first action. If you must use a pointer to continue, record where and why before deciding whether to inspect later steps separately.
Watch where focus goes
The person needs to identify which control will receive the next keyboard action. W3C's Focus Visible guidance addresses a visible indication of keyboard focus. Check that indication on the actual controls used in the journey, rather than only on the first navigation link. W3C Focus Visible guidance.
In an illustrative record editor, inspect the transition from the list to a dialog, the order through the form and the return after the dialog closes. Note any point where focus disappears, lands somewhere unexpected or becomes difficult to find.
Test the controls in context
A button receiving focus does not prove that the task works. Activate it and inspect the resulting state. Review menus, selection controls, dialogs and error recovery as part of the sequence.
Use a concise record:
| Moment | Evidence to capture |
|---|---|
| Entering the task | How the first relevant control is reached. |
| Opening a dialog | Where focus moves and whether the dialog can be used. |
| Correcting an error | How the error is noticed and the affected control reached. |
| Completing the action | Confirmation and the next focus location. |
Preserve the limits of the review
If a control blocks progress, the later steps may remain unassessed. Do not report them as passing because no additional issue was observed.
Keep keyboard findings separate from contrast, screen-reader semantics, zoom, motion and other accessibility concerns not included in the session. Use an appropriate broader evaluation process before making conformance claims.
After a repair, repeat the task under the same input conditions. A CSS change may make focus easier to see while leaving an interaction problem unresolved. Verify the action and the next state as well as the appearance.
The useful outcome is a clear account of whether the tested task can be completed by keyboard, where obstacles remain and what still needs evaluation.
Next step: Read AI usability testing: evidence and limits for the distinction between a journey result and a broad accessibility claim.
Put the evidence structure to work
Inspect UxerProof's fictional sample report, or use the free readiness check to prepare your next journey. External Circuit execution is not yet activated; see current launch status for availability.