Record where keyboard focus goes

A keyboard review becomes useful when another person can follow the same route and find the same problem. “Focus is broken” leaves too much to reconstruct. Record which control had focus, the key pressed, the next control, and the page state. This guide turns those details into a worksheet for one journey.

Use the blank keyboard and focus worksheet alongside checks 10 and 11 in the release review tool. The example below is fictional. It illustrates a record format and does not report testing of a real product.

Define the journey and conditions

Choose an outcome such as opening an item, changing its title, and returning to the list. Identify the starting URL, release, account role, and sample record. Use a test environment and fictional input. Include the operating system, browser version, keyboard navigation settings, viewport, and zoom level. Those details help distinguish an application problem from a different starting condition.

Write the expected stopping point before testing. “The changed title appears in the list and focus has a sensible place to continue” is more useful than “the dialog works.” Include canceling as a separate route: saving and canceling may run different code.

Keep one row per meaningful transition

Copy these fields. Repeat the transition fields when a menu opens, a dialog closes, or the next focus location surprises you.

• Conditions: release, route, sample data, browser and operating system, viewport, zoom, keyboard settings.
• Starting state: open panels, selected item, scroll position, and focused control.
• Action: exact key or short sequence; include the control operated.
• Expected transition: intended result and a logical next focus location.
• Observed transition: result, focused control, visible indicator, and anything covering the control.
• Evidence: screenshot or recording reference, plus text explaining what it shows.
• Outcome: observed pass, needs follow-up, not checked, or not applicable with a reason.
• Retest: changed release, repeated conditions, new observation, and remaining uncertainty.

Keep the original observation when retesting. A new result should explain what changed, rather than replace the evidence that prompted the repair.

Check operation and order separately

Put the pointer aside. Use Tab and Shift+Tab for sequential navigation, and the keys appropriate to each control for operation. A composite widget may use arrow keys internally; pressing Tab alone does not test every action. Record any action that cannot be completed or exited through the keyboard. WCAG's Keyboard criterion addresses operation through a keyboard interface, with a specific exception for functions that depend on the path of movement. W3C: Keyboard

Read the focus trail as a sequence. Does it preserve the meaning of the task? Does it send you between unrelated sections? A logical sequence need not match every visual position exactly. Explain how an unexpected jump affects understanding or operation instead of calling every difference a failure. W3C: Focus Order

Distinguish a missing indicator from a covered control

An element can receive keyboard focus while giving no visible clue. Pause after a keypress and identify the indicator; do not infer visibility from the fact that Enter still activates the control. Focus Visible concerns a visible indication of keyboard focus. W3C: Focus Visible

A second problem is a control hidden behind page content, such as a sticky footer. Record the focused control and covering element separately. WCAG 2.2's minimum obscuration criterion concerns a component being entirely hidden by author-created content when it receives focus. Partial obstruction still deserves a clear usability observation; it is not automatically a failure of that minimum criterion. W3C: Focus Not Obscured (Minimum)

Review entry, containment, and exit

For a modal dialog, check where focus enters, how it moves through the dialog, and where it goes after dismissal. The WAI-ARIA dialog pattern describes an internal Tab sequence and Escape to close. Focus normally returns to the invoking control, with exceptions when that control disappears or the next workflow step makes another location appropriate. Record the reason for the expected destination. W3C: Modal Dialog Pattern

Keeping focus inside an open modal is intentional when a keyboard route lets the person leave it. A component that cannot be exited is a different issue. Record the attempted exit and any instructions shown. W3C: No Keyboard Trap

Write a finding that can be repeated

In a fictional reading-list fixture, a reviewer opens Edit title, enters “Lantern notes,” and presses Tab to reach Save. A persistent help panel covers the entire Save button. The sample finding records the open panel, viewport and zoom conditions, focus destination, and expected visible control. It stays at “Needs follow-up.” This is an invented example, not a browser test result.

The proposed retest repeats that sequence with the panel still open, then checks the normal view and cancel route. Closing the panel before retesting would skip the condition that produced the finding. Keep unperformed combinations marked “Not checked.”

Attach the record to the release

Paste observations into the evidence notes for check 10, “Finish with the keyboard,” and check 11, “Follow visible focus.” Export before leaving the tab. Keep a separate worksheet if you need more detail than the tool's note field holds. A keyboard walkthrough covers limited behaviors; it does not establish full accessibility conformance. W3C: Preliminary Accessibility Checks

Connect the finding to the broader review with evidence. Preserve the journey, the unresolved barrier, and the conditions of any successful retest.