The ability to interact with an interface entirely using a keyboard — typically Tab to move between focusable elements, Enter or Space to activate them, and arrow keys to navigate within components like menus and tabs. Keyboard navigability is a fundamental accessibility requirement: users with motor impairments, power users, and anyone without a pointing device depend on it.
Common contexts
- Conducting a keyboard-only audit of a complex multi-step form before an accessibility compliance review
- Designing a custom dropdown component that maintains arrow-key navigation and focus trap behavior
- Testing a data table with keyboard users to verify that row selection and inline editing are reachable without a mouse
Use when
Test keyboard navigation for every new interactive component at the component level — catching focus trap failures and missing keyboard shortcuts here is far cheaper than discovering them in an accessibility audit.
Avoid when
Don't assume a visually clean focus indicator is sufficient — without testing with an actual keyboard-only user, you can miss logical tab order issues that make the interface navigable on paper but confusing in practice.
Keyboard navigation is the canary in the coal mine for overall accessibility — if Tab order is broken, the screen reader experience is almost certainly broken too.
Real-world examples
- GitHub documents 30+ keyboard shortcuts accessible via the ? key, enabling power users to navigate repositories, review PRs, and triage issues without lifting their hands from the keyboard.
- Slack's 20+ keyboard shortcuts (Cmd+K for quick channel switch, Cmd+/ for all shortcuts) are a key reason developer and power-user retention outpaces casual messaging apps.
- WCAG 2.1 Success Criterion 2.1.1 requires all functionality to be operable by keyboard alone; failing this criterion blocks an estimated 26 million people globally who use keyboards or keyboard-emulating assistive technology.