2.1.1 Keyboard
Can you get around using the keyboard alone.
What is it?
Most functionality on a web page must be usable with just a keyboard. If someone can do it with a mouse, touch, or gesture, they should also be able to do it with the keyboard—with limited exceptions.
This success criterion ensures people who rely on a keyboard or keyboard-like input can operate all important functionality on a site. It allows exceptions for cases where full keyboard operation isn’t practical—like drawing programs or games requiring freehand input.
That means users should be able to:
- Navigate to all content
- Activate all buttons and links
- Fill out and submit forms
- Use controls like sliders or dropdowns
- Play videos or interactive media
And they shouldn’t need to rely on complex key combos or precise timing to do so.
Why does it matter?
Some users may not be able to use a mouse. These users might use an ordinary keyboard, or they might use different assistive technologies, such as speech input software, sip-and-puff software, on-screen keyboards, etc., to emulate a keyboard.
With that in mind, it’s important to ensure that all the functionality on a webpage is available through the keyboard alone so that everyone is able to interact and operate a web page and all its contents. Otherwise, some people may not be able to read all the content, fill out forms, play videos, or complete other basic tasks on a page.
Who is affected?
People with low or limited vision. People with limited hand mobility. People with fine motor control disabilities.
People with vision impairments, such as low or limited eyesight, require the use of a keyboard to navigate and operate web pages. When websites are not compatible with keyboards, they become unusable because the user can’t navigate through the content or interact with it.
People with mobility disabilities may find it difficult or impossible to use a mouse and may prefer to use a keyboard or alternate keyboard.
How to implement 2.1.1
Ensure All Functionality is Keyboard Accessible
Start by testing every part of your site with the keyboard alone:
- Use the Tab key to move forward through interactive elements
- Use Shift + Tab to move backward
- Use Enter or Space to activate links and buttons
- Use arrow keys to navigate menus, sliders, or tabs
Note: 2.1.1 does allow exceptions for certain types of functionality where full keyboard support isn’t practical—like drawing freehand or manipulating objects in a game. But most websites don’t rely on those kinds of interactions, so aim for full keyboard support wherever possible.
If you can’t reach or operate something with the keyboard, it needs to be fixed.
The easiest and most reliable way to ensure keyboard accessibility is to use semantic HTML elements whenever possible. Built-in elements like:
<a href="..."><button><input>,<select>,<textarea>
…are all keyboard-friendly by default. They support focus, interaction, and screen reader support automatically—no extra coding required.
Use Scripting and ARIA for Custom Components
If you are building a custom interactive component and there is no possible option to use semantic HTML elements to do so, you’ll need to manually add keyboard support. In these cases, tabindex="0" allows elements that aren't normally focusable—like <div> or <span>—to receive keyboard focus.
<div tabindex="0">Custom widget that accepts keyboard focus</div>
But this should be a fallback, not your first choice.
If you create custom components, you’ll need to:
- Manage keyboard focus with JavaScript
- Support key events (like arrow keys, Enter, or Space)
- Use ARIA roles and properties to describe behavior to assistive tech
Whenever possible, start with native HTML controls—they're far easier to make accessible and work more dependably for more users.
Conclusion
Most functionality must work with the keyboard.
That’s the bottom line for 2.1.1—users shouldn’t be forced to use a mouse. If any part of your site can’t be used with a keyboard, you’ll need to provide a keyboard-accessible alternative unless the interaction is truly an exception, like drawing or freeform input.
Supporting full keyboard access doesn’t just help screen reader users. It benefits anyone who uses alternative input methods, has limited mobility, or just prefers the keyboard. It’s a key part of making the web usable for everyone. It’s one of the foundational pieces of accessibility—and a great place to start.
