Sweep Keyboard Navigation Regressions on a Bounded Route Set

Is the handoff ready?

Use these checks before access expands or the first ticket begins.

Fix the route set and the states under test

A keyboard sweep without a route list becomes an opinion. Write the screens, the states on each screen, the viewport widths, and the browsers. Include the empty state, the error state, and the state with a dialog open, because those are where focus behaviour changes.

A Philippines-based programmer can run the sweep on a defined list in a few hours. The value comes from repetition against the same list, so keep the list in the repository and version it.

State what is out of scope. A marketing page hosted elsewhere or a third party embed may be excluded, but the exclusion needs a name and a reason.

Write the sweep ticket with an acceptance rule

The ticket names the route list revision, the browsers, the viewport widths, the assistive technology if any, and the reviewer. Acceptance is a completed record for every route, not a claim that the site is accessible.

Ask for one pull request that fixes the defects found in the same pass, or a separate defect ticket per route when the fixes are large. Mixing a sweep record with a broad redesign makes review impossible.

Set the stop rule. If a defect blocks a checkout or a sign in flow, the sweep stops and the owner decides whether to hold the release.

Run the same steps on every route

Start at the browser address bar, press tab once, and record the first focusable element. Continue to the end of the page and record the order, the visible focus indicator, and any element that cannot be reached.

Then test the reverse order with shift tab, the skip link, and the escape key on every overlay. A focus indicator that disappears against the background is a defect even when the order is correct.

Record the element by role and accessible name, not by pixel position. A later reviewer should be able to find the same control after a layout change.

Note the scroll position at each step. A focus change that jumps the page can leave a keyboard user at the wrong part of a long form, and the screenshot alone rarely shows the jump.

• First tab stop and whether it is a skip link.
• Full forward order with visible focus at each step.
• Reverse order and shift tab behaviour.
• Escape and focus return for each overlay.

Keep a sheet a reviewer can rerun

The sheet has one row per step: route, state, key pressed, focused element, expected next element, observed next element, and result. Add the browser version and the viewport width.

Attach a short screen recording only where the focus indicator is hard to describe. A recording without the step table forces the reviewer to guess what was intended.

List the defects with the route and the step number so a fix can be verified against the original observation rather than a fresh interpretation.

Test overlays, dynamic content, and hidden inputs

Dialogs are the usual failure point. Focus should move into the dialog, stay inside it, and return to the trigger on close. A dialog that leaves focus behind lets a keyboard user operate the page underneath.

Dynamic content adds another case. A validation message, a toast, or a filtered list can remove the element that had focus. The record should show where focus went and whether the user can continue.

Custom controls built from divs need their own check. If a control is reachable but cannot be activated with enter or space, it fails even though it appears in the tab order.

• Dialog open, tab cycle, escape, and focus return.
• Menu open with arrow keys and escape.
• Validation error that removes the focused field.
• Custom control activated with enter and with space.

Triage with the owner, not with the tester

The programmer records the defect and a proposed severity. The company owner decides whether it blocks release. That split keeps a technical observation from becoming an unowned product decision.

Give the owner a short scale: blocks a task, makes a task difficult, or is cosmetic. Attach the route and the step so the decision is about a real path rather than an abstract rule.

If a fix needs a design change, stop and escalate. A programmer should not invent a new interaction pattern to close a defect.

Set a cadence and measures that survive reruns

Measure routes with a completed record divided by routes on the list, defects found per route, and defects verified fixed divided by defects reported. Report the browser and viewport for each number.

Repeat the sweep before a release that touches navigation, dialogs, or form validation, and on a monthly cadence otherwise. A sweep from six months ago describes an older interface.

Report the count of routes skipped and why. A completion rate that quietly drops three routes is less honest than a smaller list that was fully tested.

Track regressions that reappear after a fix. A repeated defect is a signal about the component or the review process, not about the individual tester.

Close with a route list, a sheet, and a fix log

The handoff contains the route list revision, the step sheet, the defect log with severities, the fix commits, and the verification rows. It also names the routes excluded and the reason.

Accept the work when a reviewer can follow the sheet on two routes and reproduce the recorded observations without a call, and when every reported defect has a verified row or an owner decision.

Store the browser versions in the sheet rather than in the pull request description, because the description changes and the evidence should not.

Frequently asked questions

Sources

1. CISA Secure by Design

   Design guidance that treats usability and safe defaults as product decisions.

2. OWASP Application Security Verification Standard

   Verification framing for client side controls and input handling.

3. Google Technical Writing

   Structure for a defect record another person can follow.

4. GitHub pull request reviews

   Review flow for the fix commits.