Audit a page using only the keyboard

A keyboard audit follows the same tasks a pointer user would perform using Tab, Shift+Tab, Enter, Space, and relevant control keys. Check whether focus is visible, the order makes sense, and every essential action can be reached and completed.

Start at the beginning of the task

Reload the page and put the pointer aside. Use the skip link if present, then navigate through the primary controls. Record where focus goes and whether the visible page follows it. Do not judge keyboard access by whether a button has a hover state.

Use a fictional booking sequence

Native links and buttons provide useful defaults. Custom controls require the corresponding semantics and behavior; adding tabindex alone is not a complete solution.

Check traps and disappearance

Open menus and dialogs, then use Escape where that is the expected close behavior. Try moving backward through the page. Filter a list while focus is inside an item and inspect what happens if that item disappears. A focused element removed from the DOM can leave the person unsure where they are.

Review this page's keyboard path for the stated task.
Record focus order, visible focus, accessible names, activation,
open/close behavior, and focus after content changes.
Distinguish observations from code-based concerns.
Do not call the page accessible solely because every element has tabindex.
Task and observed sequence: [notes]
Code or screenshots: [context]

Repeat on a small viewport

Sticky headers, overflow regions, and responsive menus can change the focus experience. Make sure a focused control is not hidden behind a fixed panel. Try the real form error and empty-state paths too.

Keep defects reproducible: which key, which starting state, where focus went, and where it should go. Automated accessibility scans complement this review but do not replace following the task. Use the relevant W3C pattern guidance for complex controls instead of inventing keyboard conventions.