2.1.1 Keyboard

1. What is the goal of this criterion?

Not everyone can use a mouse – for many different reasons. Blind people can’t follow a mouse pointer. People with motor impairments often find precise mouse movements hard to control. Others use assistive tools such as specialized keyboards, switch access or voice control, which behave like a keyboard as far as the website is concerned.

So the goal of Success Criterion 2.1.1 is crystal clear: everything you can do with a mouse must also work with a keyboard. That way, everyone can use your website – regardless of their input method.

In short: every function, every button, every interactive element must be reachable and operable without a mouse.

2. What exactly does it require?

The requirement is simple but far-reaching: all functionality of your website must be operable through a keyboard interface – without requiring specific timings for individual keystrokes.

In practice, this means for example:

• All links, buttons and form elements can be reached with the keyboard (usually with the Tab key)
• Interactive elements can be activated with the keyboard, for example with Enter or Space
• Custom components such as menus, tabs or sliders are fully keyboard-operable
• Drag-and-drop features have a keyboard alternative (such as move buttons or a selection menu)
• Nobody has to hold a key down for an exact length of time or press it repeatedly at lightning speed

The criterion doesn’t prescribe which keys to use (such as arrow keys in menus or Escape to close dialogs) – but these are established conventions that users are used to.

There’s one important exception: functions that inherently depend on the path of movement – such as freehand drawing or watercolor painting in a painting app – don’t have to be keyboard-operable. But note: this relates to the underlying function, not the input technique. Entering text by handwriting, for example, isn’t an exception, because text can also be typed.

3. Why does it matter for accessibility?

Imagine browsing the web with a broken mouse – frustrating, right? For many people, that’s everyday life. Blind people can’t see the pointer, people with tremors can’t control it precisely, and people with paralysis often use alternative input devices.

Keyboard accessibility enables real participation because it:

• Lets blind people use all functionality with screen readers
• Allows people with motor impairments to use alternative input devices that generate keyboard input
• Makes access easier for voice control users, since many voice commands map to keyboard commands
• Lets people with low vision navigate without hunting for the mouse pointer
• Helps people with temporary impairments (such as an arm in a cast)

And finally: many power users prefer the keyboard anyway – it’s often faster than the mouse.

4. How to meet the criterion

The good news: native HTML elements come with keyboard support built in. Problems mostly arise with custom-built components. Here are some proven tips:

The ground rules:

• Use semantic HTML: <button>, <a href>, <input>, <select> instead of clickable <div> or <span> elements
• Make sure the focus order is logical and follows the visual order (see Focus Order)
• Provide visible focus indicators – users need to see where they are (see Focus Visible)
• Offer skip links (“Skip to content”) for repeated navigation
• Don’t hide functionality behind hover-only effects

For interactive elements:

• Buttons: activate with Enter and Space
• Links: activate with Enter
• Forms: navigable with Tab and submittable without a mouse
• Dropdown menus and tabs: arrow keys to choose and Enter to confirm are the established pattern
• Modal dialogs: move focus into the dialog on opening and back to the trigger on closing; Escape to close is common

Technical implementation:

• A native <button> fires the click event on Enter and Space too – you don’t need extra keyboard handlers
• If you do build custom elements, you need tabindex="0", appropriate keyboard handlers (keydown) and a suitable role such as role="button" – ARIA alone doesn’t make anything operable
• Use tabindex sparingly and avoid positive values – they scramble the order
• For complex widgets, the patterns in the W3C’s ARIA Authoring Practices Guide (APG) or proven libraries such as React Aria help

How to test:

• Put the mouse aside and operate your page using only Tab, Shift+Tab, Enter, Space, Escape and the arrow keys
• Check that you can reach and activate every function – and that you can always see where the focus is
• Also test with a screen reader such as NVDA (free for Windows) or VoiceOver (macOS)

5. Why this criterion matters for businesses

Keyboard accessibility isn’t a nice extra – it’s a basic requirement for people to be able to use your website at all.

1. Reach a wider audience

According to the WHO, around 1.3 billion people worldwide live with a significant disability. Add people with temporary impairments, older people and power users who prefer the keyboard. Keyboard-operable websites don’t exclude anyone.

2. Boost productivity

Your own employees often work more efficiently with good keyboard support too – especially in data-heavy applications. Thoughtful keyboard navigation makes software faster and more pleasant to use.

3. Improve technical robustness

Keyboard accessibility goes hand in hand with clean, semantic code. That makes your website more robust across devices and assistive tools – and automated tests also benefit from clearly identifiable elements.

Last but not least: legal requirements. The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025 to many consumer products and services, such as online shops and banking services; in Germany it is implemented by the Barrierefreiheitsstärkungsgesetz (BFSG). The technical benchmark is the harmonised standard EN 301 549, which references WCAG 2.1 Level AA for web content – and 2.1.1 is part of that. Public sector bodies are covered by the Web Accessibility Directive (EU) 2016/2102. This section is general information, not legal advice.

6. The success criterion in the W3C’s words

Success Criterion 2.1.1 Keyboard (Level 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.

Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

In short: all functionality must be operable by keyboard without specific timing requirements – the only exception is functionality that inherently depends on the path of movement.