# Keyboard and focus review worksheet

SaaS Mirror · Worksheet version 2026-09-07
Guide: https://saasmirror.com/guides/record-where-keyboard-focus-goes
Release review tool: https://saasmirror.com/tools/release-review

An original manual recording aid prepared with AI-assisted drafting. Fill this local file with your own observations. It does not run tests or establish accessibility conformance. Use fictional test data and remove private details before sharing a completed copy.

## Blank review conditions

- Review date and time zone:
- Release/build identifier:
- Environment and starting URL:
- Account role and fictional sample record:
- Operating system and version:
- Browser and version:
- Keyboard navigation settings:
- Viewport and zoom mode/level:
- Open panels, scroll position, and other starting conditions:
- Journey and expected outcome:
- Routes included (complete, cancel, error, other):
- Routes or technologies excluded and reason:

## Blank transition record — repeat as needed

- Record identifier:
- Initial page state:
- Control holding focus before the action:
- Exact key or sequence:
- Expected result and logical focus destination:
- Observed result and actual focus destination:
- Visible focus indicator:
- Is the control covered? By what, and how much?
- Available keyboard exit and instructions, if applicable:
- Evidence reference and explanation:
- Outcome (observed pass / needs follow-up / not checked / not applicable):
- Reason for an exclusion or uncertainty:
- Follow-up owner or issue reference:

## Blank retest — preserve the original record

- Original record identifier:
- Changed release/build:
- Retest date and conditions:
- Steps repeated, including the original failing condition:
- Actual result:
- Evidence reference:
- Remaining unchecked conditions:
- Final disposition and reason:

## Fictional worked finding — not an actual test result

This entire example is invented. In a real record, supply actual browser and operating-system versions; those are deliberately not invented as evidence here.

- Record identifier: FICTIONAL-FOCUS-01
- Fixture: a reading-list edit dialog using a sample item titled Lantern notes.
- Starting condition: persistent help panel open over the lower part of the dialog; the reviewer would record the actual viewport and zoom.
- Action: move from the title field to Save using Tab.
- Expected: identify the Save control and its keyboard focus indicator.
- Illustrative observation: focus reaches Save, but the help panel covers the entire button.
- Evidence: none; this is a fictional teaching example.
- Outcome: Needs follow-up in the fictional scenario.
- Proposed retest: repeat with the same panel open; record the actual viewport, zoom, browser, and resulting focus visibility. Separately check the ordinary view and cancel route.
- Retest result: Not checked. No repair or successful retest is claimed.

## References for interpreting observations

- Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html
- Focus order: https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html
- Focus visible: https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html
- Focus not obscured (minimum): https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html
- Modal dialog pattern: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
- No keyboard trap: https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html

## Use and privacy

Reuse permissions and resource limitations: https://saasmirror.com/terms

How the publication handles website visits and tool inputs: https://saasmirror.com/privacy