Accessibility prompts: test keyboard and dialog focus paths

Last updated: 5 Oct 202611 min read

tutorial

A keyboard review prompt should name the starting control, input sequence, expected focus target, and exit path. Test Tab, Shift+Tab, activation, Escape where the component promises dismissal, and visible focus indication. A modal task may need focus containment while open and a deliberate return target when closed. Do not ask a model to infer a focus sequence from DOM order alone when scripts change focus at runtime. Record the observed active element after every meaningful transition.

Operational case

The Harbor reviewer opens the confirmation dialog from the 'Review booking' button, tabs through two actions, then presses Escape. The dialog closes, but focus jumps to the top of the page. The finding names the opener and final active element, so an engineer can reproduce it. A repair that only adds a visible outline would miss the lost-focus path; the reviewer repeats the full sequence after the code change.

Start: Review booking button
Enter: activate; focus moves into dialog
Move: Tab across dialog actions
Exit: Escape
Observed focus: page top; expected: Review booking button

Performance and review cost

A linear focus walk across N interactive elements takes O(N) key presses; checking multiple state paths multiplies that cost by the number of paths. Capture a short trace at transition boundaries rather than every incidental keystroke. A shared dialog fix is still subject to regression checks on every distinct opener and close action.

Common Mistakes

Do not equate DOM order with observed runtime focus order.
Do not leave focus inside a hidden dialog.
Do not mark a dialog fixed after testing only pointer dismissal.

Connected lessons

prompt engineering

accessibility review