# Check a complete reading journey without relying on a pointer

Original constructed teaching cases with full context. No actual accounts, rights grants, signed credentials, detector tests, human studies or customers.

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.

## 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.

## Primary sources

- [W3C: keyboard operation and control conventions](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html)
- [W3C: a known keyboard exit](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html)
- [W3C WAI: first-review keyboard and visible-focus checks](https://www.w3.org/WAI/test-evaluate/preliminary/)