Loading...
Loading content...
Loading content...
Every interactive element must be usable with just a keyboard (no mouse required).
Why it matters: Many users cannot use a mouse due to motor disabilities or blindness.
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.
What This Means: This success criterion requires that all functionality available through a mouse or other pointing device must also be available through keyboard input. Users must be able to navigate to all interactive elements using Tab, Shift+Tab, arrow keys, and other standard keyboard navigation, and activate them using Enter, Space, or other keyboard commands.
Why It's Important: Many users cannot use a mouse due to motor disabilities, blindness, or other conditions. Keyboard-only users rely entirely on keyboard navigation to access web content. If functionality is only available through mouse interaction, these users are excluded from using that functionality, making the content inaccessible.
Use semantic HTML elements (button, link, input) that have built-in keyboard support. For custom interactive components, add keyboard event handlers (onKeyDown, onKeyPress) and ensure they're focusable (tabindex). All interactive elements must be reachable via Tab key navigation and activatable via Enter or Space keys. Test by navigating the entire page using only the keyboard to verify all functionality is accessible.
This criterion ensures that blind users can access and understand the content, improving their overall experience and ability to use the website effectively.
This criterion ensures that users with motor disabilities can access and understand the content, improving their overall experience and ability to use the website effectively.
This criterion ensures that power users can access and understand the content, improving their overall experience and ability to use the website effectively.
Impact: When this criterion is properly implemented, it removes barriers for these user groups and creates a more inclusive web experience for everyone.
A custom-styled button that only responds to mouse clicks, not keyboard activation.
<div onclick="submitForm()" class="button">Submit</div>A button element that works with both mouse and keyboard (Enter/Space keys).
<button onclick="submitForm()" class="button">Submit</button>This success criterion benefits the following user groups:
Tip: Use this checklist during development and testing to ensure all requirements for 2.1.1 Keyboard are met. Check off items as you complete them.
To meet this success criterion, ensure the following requirements are met:
While meeting the minimum requirements ensures compliance, consider these enhancements for a better user experience:
If it works with a mouse, it's accessible.
Mouse accessibility doesn't guarantee keyboard accessibility. Many users rely solely on keyboards, and all functionality must work without a mouse.
I can use divs with onClick handlers instead of buttons.
Divs with onClick are not keyboard accessible by default. Use proper semantic elements (button, a) or add keyboard event handlers, ARIA roles, and tabindex.
Keyboard users can just use the mouse if needed.
Many users physically cannot use a mouse due to motor disabilities, blindness, or other conditions. Keyboard access is not optional.
Custom buttons using divs or spans with only onClick handlers.
Use proper <button> elements or add keyboard event handlers (onKeyDown), role='button', and tabIndex={0} to custom elements.
Interactive elements that don't receive keyboard focus.
Ensure all interactive elements are in the tab order. Use tabIndex={0} for custom elements, or use native focusable elements.
No visible focus indicator on keyboard navigation.
Add visible focus styles using :focus pseudo-class. Don't remove outline without providing an alternative focus indicator.
Functionality that only works with mouse (hover, drag-and-drop without keyboard alternative).
Provide keyboard alternatives for all mouse-only interactions. For example, use click/tap for hover actions, or provide keyboard shortcuts for drag operations.
Illogical focus order that doesn't match visual layout.
Ensure DOM order matches visual order, or use tabIndex to create logical focus sequence. Test focus order by tabbing through the page.
Note: These are official W3C resources for 2.1.1. For the most up-to-date information and detailed technical guidance, always refer to the official W3C documentation.
Implementing 2.1.1 Keyboard correctly requires understanding your specific context. Code solutions vary significantly based on multiple factors:
HTML, React, Vue, Angular, PHP, Python, and other frameworks each have different patterns and best practices.
Server-side rendering, client-side rendering, static generation, and hybrid approaches require different solutions.
Your existing components, styling approach, and UI library influence how accessibility must be implemented.
Your specific user base, content type, and interaction patterns determine the most appropriate implementation.
We provide tailored implementation guidance by analyzing your specific technology stack, coding patterns, design system, and project requirements. Our team reviews your codebase and provides custom solutions that integrate seamlessly with your existing architecture.
Get Custom Implementation HelpPart of
Operable PrincipleGuideline
2.1 Keyboard Accessible