Keyboard Navigation (WCAG 2.1.1)

What is it?

WCAG Success Criterion 2.1.1 (Keyboard) requires that all functionality available by pointer (mouse, touch) is also available by keyboard alone, without requiring specific timing for individual keystrokes — with an exception only for paths where the path itself is inherently keyboard-inoperable (e.g., freehand drawing). This ensures keyboard-only users, switch access users, and voice control users can use the product.

Why it matters

Motor impairments — from Parkinson's disease to repetitive strain injury to quadriplegia — may prevent users from using a mouse or touchscreen accurately or at all. Keyboard-only navigation is also used by power users who prefer keyboard shortcuts, developers working in code-heavy environments, and users of voice control software like Dragon NaturallySpeaking. If your product is only operable by mouse or touch, you are excluding a substantial user population.

Best Practices

• Use native HTML interactive elements: <button>, <a>, <input>, <select>, <textarea>. These are keyboard-accessible by default.
• Ensure all custom interactive widgets (dropdowns, sliders, date pickers, carousels) implement the appropriate ARIA keyboard interaction patterns from the ARIA Authoring Practices Guide.
• Tab order must follow a logical reading sequence. Test by pressing Tab repeatedly from the top of every page.
• No keyboard traps: users must be able to navigate into and out of all components using only the keyboard. Exception: intentional traps like modal dialogs must have a clearly documented keyboard exit (Escape key).
• Modal dialogs must trap focus internally — focus should not be reachable in the background while a modal is open.
• Arrow key navigation within composite widgets (menus, listboxes, tab panels, grids) must be implemented per ARIA patterns.
• Skip links ("Skip to main content") allow keyboard users to bypass repetitive navigation. Place one as the first focusable element on every page.
• Provide keyboard shortcuts for high-frequency actions in complex applications. Document them in an accessible help section.

Common Mistakes

• Using <div> or <span> as buttons with onClick handlers — not keyboard-accessible without tabindex and keydown handlers.
• Custom dropdowns that work by mouse hover but have no keyboard interaction pattern.
• Modal dialogs that do not trap focus — users can Tab to the background content behind the overlay.
• Modal dialogs that do not return focus to the trigger element on close.
• Positive tabindex values (tabindex="1", tabindex="2") that override natural document order — almost always the wrong approach.
• Keyboard traps: a component that can receive focus but cannot be exited by keyboard, stranding the user.
• No skip link — keyboard users must Tab through the entire header navigation on every page.
• JavaScript that removes keyboard focus on click: element.blur() called on interactive elements.

Checklist

Research & Theory

Real-World Examples