Keyboard Navigation Audit Checklist
For: Frontend developers, QA engineers, accessibility auditors
The keyboard audit is the fastest way to find accessibility bugs — unplug your mouse and try to do every flow on the site. If you get stuck, that's a bug. This checklist covers the canonical patterns: tab order, focus visibility, custom widgets, and the keyboard shortcuts that the WAI-ARIA Authoring Practices document for each control type.
References: WCAG 2.2 SC 2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11 · WAI-ARIA Authoring Practices
Want to audit color contrast against this checklist on real screens — instantly, from your phone?
Use AccessAudit AI — runs offline, captures photo evidence per item, exports a sharable PDF.
Basics
Every interactive element reachable by Tab
WCAG 2.1.1
No keyboard trap — Tab cycles forward, Shift+Tab cycles back, Esc dismisses overlays
WCAG 2.1.2
Focus indicator visible on every focusable element
WCAG 2.4.7
Focus order matches visual order (DOM order = visual order)
WCAG 2.4.3
Skip-to-main-content link as first focusable element
Custom Widgets (per WAI-ARIA APG)
Tabs — Tab moves into tablist, Arrow keys move between tabs, Enter/Space activates
Menus — Esc closes, Arrow keys navigate items, Enter activates
Dialogs (modals) — Tab traps inside, Esc closes, focus restored on close
Disclosure (accordion) — Enter/Space toggles expanded state
Combobox — Arrow keys navigate options, Enter selects, Esc closes
Date picker — Arrow keys navigate dates, PgUp/PgDn navigate months
Focus Visibility
Default browser focus ring NOT removed unless replaced with equally-visible custom indicator
WCAG 2.4.11
Focus indicator contrast ≥3:1 against unfocused state
WCAG 2.4.11
Focus persists across sticky elements (nav, footers don't hide it)
:focus-visible used (not just :focus) so mouse-click doesn't show focus ring
Focus survives JS DOM updates — not lost on AJAX-loaded content
Run this on your phone
Point your iPhone camera at any color pair to see WCAG contrast ratio + pass/fail in real time. 100% on-device.