The short answer
Choose a concrete owned-page task, then navigate, read, open the relevant source and reach the download using the keyboard. Check visible logical focus, usable controls and a way to leave every component. Record the actual environment and failed step. A small keyboard journey can find barriers; it is neither a screen-reader study nor proof of full accessibility across devices.
What you’ll take away
- Test a real task from entry through result and recovery.
- Use native control conventions and inspect focus rather than guessing.
- Keep browser-emulated, assistive-technology and human-reader evidence separate.
Choose the task and environment before the keys
Use a page and data you are permitted to inspect. A practical task is to find one declared outcome rate, identify its denominator, open its source and download the complete example. Record browser/version, operating system, width, keyboard-navigation settings and the starting URL. Do not substitute an unrelated button click for the whole promised task.
Some environments require a keyboard-navigation setting before all relevant controls participate in focus movement. Check the actual current environment without changing someone else’s preferences merely to hide a failure. A narrow viewport check and a browser zoom check are different observations; neither alone is a physical-phone test.
Follow entry, source, result and return
Begin from the browser/page entry, put the pointer aside and use Tab and Shift+Tab through the meaningful path. Check that focus is visible and that the sequence preserves the task’s meaning. A skip link should lead to the intended content. A visible button hidden from keyboard access needs repair or a genuinely equivalent keyboard route.
Activate native controls using their actual conventions: an ordinary link commonly uses Enter, while native buttons commonly support Enter and Space. Arrow-key behavior depends on the widget. Do not expect Space to activate every link or force a single custom key scheme onto every control. Record what actually happens, including the URL or downloaded file.
Check departure as well as entry
Every component entered by keyboard needs a keyboard way out. A modal may temporarily contain focus while open, provided a usable known exit exists and the user can continue afterward. Esc is common in many environments, not a universal substitute for a visible functioning Close or Cancel control. Document a nonstandard exit before it is needed.
Test cancel, close, failed input and return to the original task. A confirmation should not strand focus somewhere unrelated or require a pointer to recover. For a wide table, focus its named scroll region, use the browser’s keyboard scrolling and then Tab or Shift+Tab away. Do not turn every static cell into a separate stop just to increase the tab count.
Resolve three constructed journey failures
K1 — Constructed download: its control appears only while a pointer hovers and cannot be reached by keyboard. Decision: provide a visible native control or equivalent operable path and rerun the whole task. Outcome: a specified barrier repair, not a universal accessibility pass from a single focus event.
K2 — Constructed dialog: focus enters a preview but neither a working keyboard close nor an explained exit can be found. Decision: repair the exit and meaningful focus return, then test opening and leaving again. Outcome: no “pass” merely because the first button could be activated.
K3 — Constructed data table: the table is wider than the display and the necessary last column cannot be reached without a pointer. Decision: supply a named reachable scroll region or another complete usable presentation, then test scrolling and departure. Outcome: retain the full data without shrinking it into unreadable text.
Keep the observed result at its real scope
W3C’s Easy Checks explicitly describe a first review, not a complete evaluation. A route that works in one browser can still have other barriers. Screen-reader output, voice input, contrast, captions, meaning and a human reader’s completion need their own appropriate evidence. Do not fill those result fields with a simulated persona or an automated score.
Record the failed step, expected behavior, actual observation and exact changed file/page, then repeat the affected complete path after a real correction. A DOM text match can coexist with a visually broken number or unreachable control. Inspect the actual reading state and use a clear unresolved result when the task cannot be completed.
Save a reproducible task and truthful outcome
The worksheet records task, allowed source/page, environment, entry, key sequence, focused control, result/reference, exit/recovery and unresolved assistive-technology checks. The table example supplies a concrete own-file path for practicing scroll and exit. Practice with fictional values rather than private account data.
Primary W3C keyboard, no-trap and first-review guidance was read on 1 November 2026. All K-cases are constructed. Any accompanying browser check concerns the owned example and its recorded environment only; it is not independent reader preference, a clinical assessment or physical-device proof.
Sources & product references
Product details reflect the publication date. External features and interfaces may change.



