Keyboard Navigation
Also Known As
tab order
focus management
keyboard accessibility
TL;DR
Ensuring all interactive elements are reachable and usable with keyboard alone — essential for users who cannot use a mouse and required for WCAG compliance.
Explanation
Keyboard navigation relies on tab order (set by DOM order, modified by tabindex), focus indicators (visible outline on focused elements), keyboard shortcuts (Enter/Space to activate buttons, Escape to close modals), and no keyboard traps (user can always navigate away). Focus management is critical in SPAs — when a modal opens, focus should move to it; when it closes, focus should return to the trigger. ARIA roles ensure screen readers announce the correct element type.
Diagram
flowchart TD
USER[Keyboard user] --> TAB[Tab key]
TAB --> FOCUS{Element focusable?}
FOCUS -->|yes| INDICATOR[Focus indicator visible<br/>outline ring]
FOCUS -->|no - div span| BROKEN[Inaccessible<br/>cannot reach element]
INDICATOR --> INTERACT{Element type}
INTERACT -->|button| ENTER_SPACE[Enter or Space activates]
INTERACT -->|link| ENTER2[Enter follows link]
INTERACT -->|input| TYPE[Type text]
INTERACT -->|select| ARROWS[Arrow keys choose option]
BROKEN -.->|fix with| TABINDEX[tabindex=0<br/>+ keyboard handler]
style BROKEN fill:#f85149,color:#fff
style INDICATOR fill:#238636,color:#fff
style TABINDEX fill:#d29922,color:#fff
Common Misconception
✗ Keyboard navigation is only needed for users without mice — power users, form-heavy workflows, and accessibility auditors all use keyboard navigation regularly.
Why It Matters
Interactive elements that are mouse-only lock out keyboard users, screen reader users, and switch device users — a significant portion of your audience.
Common Mistakes
- outline: none on :focus — removes the only visual indicator of keyboard focus; use outline: none only with a custom focus style.
- tabindex > 0 — positive tabindex overrides natural DOM order, creating confusing navigation for keyboard users.
- Click-only event handlers on non-button elements — divs with onclick are not keyboard-activatable without tabindex and keydown handling.
- Not managing focus in modals — focus must move to the modal and be trapped within it until closed.
Code Examples
✗ Vulnerable
/* Removing focus indicator — keyboard users cannot see where they are: */
* { outline: none; } /* Never do this */
/* Non-keyboard-accessible interactive element: */
<div onclick="openMenu()" style="cursor:pointer">Menu</div>
<!-- Not in tab order, no keyboard activation -->
✓ Fixed
/* Custom focus styles instead of removing outline: */
:focus-visible {
outline: 2px solid #0066cc;
outline-offset: 2px;
}
<!-- Use native interactive elements: -->
<button type="button" onclick="openMenu()" aria-expanded="false">Menu</button>
<!-- Natively: tab-focusable, Enter/Space activates, ARIA state communicated -->
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
42
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Amazonbot 16
Perplexity 9
Ahrefs 3
SEMrush 3
Majestic 1
Unknown AI 1
Google 1
Also referenced
How they use it
crawler 34
Related categories
⚡
DEV INTEL
Tools & Severity
🟠 High
⚙ Fix effort: Medium
⚡ Quick Fix
Test your entire application using only the keyboard: Tab to move forward, Shift+Tab backward, Enter/Space to activate, Escape to close — every interactive element must be reachable
📦 Applies To
html HTML5
web
🔍 Detection Hints
Interactive elements not reachable by Tab; focus trapped with no escape; custom dropdown not operable with arrow keys; outline:0 removing focus ring
Auto-detectable:
✗ No
axe
wave
nvda
keyboard-testing
⚠ Related Problems
🤖 AI Agent
Confidence: High
False Positives: Medium
✗ Manual fix
Fix: Medium
Context: File
Tests: Update