WCAG 2.2 - Success Criterion
2.1.1 Keyboard
Description
All functionality of the content must be operable through a keyboard interface without requiring specific timings for individual keystrokes. This means any action that can be done with a mouse - clicking buttons, filling forms, activating links, operating custom widgets - must also be achievable using only a keyboard. The criterion does not require a keyboard-specific shortcut for every action, only that every action can be reached and executed via keyboard navigation.
How To Test
- Disconnect or set aside your mouse so only keyboard input is used.
- Press Tab to move forward through all interactive elements on the page, and Shift+Tab to move backward.
- Confirm every link, button, form field, and custom control receives visible focus.
- Attempt to activate each interactive element using Enter or Space, and use arrow keys inside composite widgets (menus, tabs, sliders).
- Identify any action that can be triggered by mouse (hover, click, drag) and verify an equivalent keyboard-only path exists.
- Test any time-based interactions to confirm they do not require precise timing of keystrokes.
- If a screen reader is available, navigate with NVDA or JAWS (Windows) or VoiceOver (macOS/iOS) and verify all functionality remains reachable.
Testing Tools
- axe DevTools — Browser extension. Install from official page, open DevTools, go to axe tab, run scan. Look for focus order, keyboard trap, and focus visible violations.
- NVDA — Free screen reader for Windows. Download and install, then open Firefox and navigate the demo using Tab, Shift+Tab, arrow keys, and Enter. Listen for focus announcements.
- Browser DevTools Accessibility Inspector — Built into all browsers. Right-click on a focused element, select "Inspect", open DevTools, go to Accessibility tab to see the accessibility tree and focus properties.
Demo 1: Native button vs styled div
Press Tab to try reaching the control below. The <div> is styled to look like a button but cannot receive keyboard focus:
The native <button> is keyboard focusable by default. Press Tab to reach it, then Enter or Space to activate:
Code
Demo 2: Custom widget keyboard support
Try clicking and using arrow keys on the slider below. Only mouse clicks work:
Keyboard keys do not work here.
Try clicking and using arrow keys on the slider below. Both mouse and keyboard work:
Use arrow keys ← → to adjust the slider.
Code
Demo 3: Image navigation with keyboard support
Try using Tab to reach the navigation arrow below. Using only the keyboard, you cannot navigate to the next item:
Current item: Item 1 of 5
Mouse hover or click the arrow to proceed.
Try using Tab and keyboard to reach and operate the button below. Both mouse and keyboard work equally:
Current item: Item 1 of 5
Press Tab to focus, then Enter or Space to advance.
Code
Custom dropdown built with divs — opens on click but keyboard users can't navigate options or close it. Found in 15 real-world audits (quantity selectors, country pickers).
Try keyboard: Tab reaches it, but Enter/Space/arrows don't work. Options are mouse-only.
Native <select> element — fully keyboard operable. Arrow keys navigate, Enter selects, Escape closes.
Native <select> provides keyboard support, screen reader announcements, and touch support for free.
Code
A "link" built with a <span> and onclick — cannot be focused or activated via keyboard. Found in real-world audits where navigation items were unreachable.
Try Tab — focus skips right past this "link".
A proper <a> element with href — keyboard focusable and activatable with Enter.
Native <a href> is focusable by default and activates with Enter key.
Code
WCAG Techniques
- Failures: F54 (Using only pointing-device-specific event handlers), F59 (Using script to make div or span a user interface control without role)
- Success Techniques: H91 (Using HTML form controls and links), G202 (Ensuring keyboard control for all functionality), ARIA6 (Using aria-label to provide labels for objects), ARIA9 (Using aria-labelledby to concatenate a label from several text nodes)
Fail Explanation
A failure occurs when one or more interactive elements or features are only reachable or operable via mouse, touch, or pointer input. For example, a drag-and-drop file upload widget that has no keyboard alternative, or a custom dropdown menu that opens only on mouse hover, will exclude keyboard-only users and screen reader users who cannot control a pointer device. This prevents access to essential content and tasks for people with motor disabilities, power users, and screen reader users.
Pass Explanation
A passing implementation ensures every interactive element can receive keyboard focus and be activated using standard keys (Tab to move focus, Enter or Space to activate, arrow keys for composite widgets). Custom JavaScript widgets such as carousels, date pickers, and accordions must implement appropriate keyboard interaction patterns - typically following the ARIA Authoring Practices Guide - so all functionality is reachable without a mouse.
Notes
This criterion applies to all functionality, not just navigation - operations like drag-and-drop, right-click context menus, and hover-triggered tooltips all require keyboard-accessible equivalents. The exception for "path-dependent" input (such as freehand drawing) is narrow and applies only when the path itself, not just the endpoints, is essential.
Techniques
WCAG techniques used in this demo: G59, G202, H91
Suggested Solutions & References
Curated from 61 real-world audit findings and official WCAG guidance.
Official W3C / WAI
- Understanding SC 2.1.1: Keyboard
- Technique G202: Keyboard control for all functionality
- Technique G59: Placing interactive elements in order