WCAG 2.1.1 Keyboard

Success criterion 2.1.1 makes sure people can use a site without a mouse: blind visitors with a screen reader, people with tremors or limited hand movement, people using switch devices or voice control that emulate a keyboard, and power users who simply prefer the keyboard. It is level A and part of EN 301 549 (clause 9.2.1.1), which the European Accessibility Act relies on.

What the criterion requires

All functionality of the content must be operable through a keyboard interface, and it must not depend on specific timings for individual keystrokes (for example "press twice quickly").

The only exception is when the underlying function requires input that depends on the path of the user's movement and not just the endpoints — freehand drawing, for instance. The exception is about the function, not the input technique: entering text by handwriting uses a path, but text input itself does not, so it must still work from a keyboard.

Offering mouse, touch or other input methods in addition is fine and encouraged.

Typical failures on an online shop

• a mega menu or category dropdown that opens only on mouse hover;
• product image galleries, colour swatches or size pickers built from div elements with click handlers and no keyboard support;
• price range sliders and quantity steppers that cannot be moved with the arrow keys;
• a "quick view" or mini-cart that opens on click but cannot be opened or closed from the keyboard;
• a cookie banner or chat widget whose buttons are not reachable with Tab;
• a scrollable area (size table, reviews list) that cannot get focus, so keyboard users cannot scroll it.

How to check it

Automated: our checker flags several keyboard patterns: scrollable regions that cannot receive focus, iframes with interactive content that is removed from the tab order, and server-side image maps (rules in our rule library). It cannot tell whether every function works from the keyboard, so the main test is manual.

By hand: put the mouse away and go through a real purchase. Use Tab and Shift+Tab to move, Enter to follow links and press buttons, Space for buttons and checkboxes, arrow keys inside menus, sliders and radio groups, and Esc to close dialogs. Open the menu, filter a category, pick a variant, add to cart, apply a coupon and reach the payment step. Every action you can do with the mouse must be possible this way.

How to fix it

• Use native HTML elements — <button>, <a href>, <input>, <select> — they are keyboard-operable by default.
• If you must build a custom widget, give it tabindex="0", an ARIA role and key handlers that follow the WAI-ARIA Authoring Practices pattern for that widget.
• Make hover menus also open on focus or with Enter, and keep them open while focus is inside.
• Check theme apps and plugins (reviews, chat, wishlists) — many keyboard problems come from third-party widgets.

Related criteria

• 2.1.2 No Keyboard Trap — keyboard focus must always be able to leave a component.
• 2.4.3 Focus Order — the order of Tab stops must make sense.
• 2.4.7 Focus Visible — users must see where the keyboard focus is.

Frequently asked questions

What does WCAG 2.1.1 Keyboard require?

Every function of the content must work through a keyboard interface, without needing specific timings for individual keystrokes. Mouse and touch input can be offered as well, but not instead.

Is there any exception to the keyboard requirement?

Only for functions where the underlying task depends on the path of the movement, not just the start and end points, such as freehand drawing or a signature. Typing text by handwriting does not count, because text input itself does not need a path.

Can an automated tool test keyboard accessibility?

Only partly. A checker can find some patterns, such as scrollable areas that cannot get focus. Whether every menu, filter and checkout step really works with Tab, Enter, Space and the arrow keys has to be tried by hand.