keyboard-accessible
Web validation
Users must be able to reach and operate every interactive component with the keyboard alone, without a mouse, touchscreen, or voice command. This helps people with mobility disabilities who rely on switch devices, voice recognition, or other assistive technology to navigate independently. It also helps power users who prefer the keyboard. Links, buttons, menus, and form inputs should be reachable with the Tab key. Custom widgets should add keyboard interactions that mirror the behavior of native controls.
Pass Patterns
Native button
A native <button> is reachable with Tab and activates with Enter or Space.
<button>Submit</button>Custom control with keyboard support
A <div> is given a role, tabindex, and key handlers so it works like a button, activating with both Enter and Space.
<div
role="button"
tabindex="0"
onclick="submitForm()"
onkeydown="if (event.key === 'Enter' || event.key === ' ') { event.preventDefault(); submitForm(); }">
Submit
</div>Fail Patterns
Clickable element not reachable by keyboard
The <div> has a click handler and looks like a button, but it is not focusable, so the keyboard cannot reach or activate it.
<div onclick="submitForm()" style="cursor: pointer">Submit</div>WCAG techniques
Sufficient techniques
- G202: Ensuring keyboard control for all functionality
- G90: Providing keyboard-triggered event handlers
- H91: Using HTML form controls and links
- SCR20: Using both keyboard and other device-specific functions
Advisory techniques
Failure techniques
- F54: Failure of Success Criterion 2.1.1 due to using only pointing-device-specific event handlers (including gesture) for a function
- F55: Failure of Success Criteria 2.1.1, 2.4.7, 2.4.13, and 3.2.1 due to using script to remove focus when focus is received
Try It Yourself
Using a keyboard
- Open the page in a browser.
- Use the Tab key to move focus through the interactive elements.
- Try to activate each item with Enter or Space.
Expected results: Every interactive element can be reached and activated with the keyboard alone.
Actual results: Some elements are skipped or cannot be activated without a mouse.
Inspecting the browser dev-tools
- Open your browser's dev tools and go to the Accessibility panel.
- Select each interactive element.
- Check its role, name, and keyboard focusability.
Expected results: Each interactive element appears in the accessibility tree with a proper role and is keyboard focusable.
Actual results: Some elements are missing from the tree or are not keyboard focusable.
FAQ
How does this issue relate to 2.1.1 Keyboard?
SC 2.1.1 requires all functionality to be available through a keyboard interface. When an interactive element cannot be reached or operated with the keyboard, that functionality fails the criterion.
Why is this issue marked as Critical?
Keyboard inaccessibility is a complete barrier for people who navigate with a keyboard or keyboard-emulating assistive technology. It can make core site functionality, such as submitting a form, impossible to use.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 2.1.1 Keyboard (A) | All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. |
| EN 301 549 | 9.2.1.1 Keyboard | Same as the WCAG text. |
| Section 508 | 1194.21(a) | When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually. |
| 508 Trusted Tester | 2.1.1-keyboard-access, 4.A | All functionality can be accessed and executed using only the keyboard. |