2.1.1 Keyboard

What does it mean?

Anything a visitor can do with a mouse or a finger must also be possible with the keyboard: opening menus, using sliders, closing dialogs, filling in and sending forms, playing media. The keyboard user must not need to press keys at a particular speed or rhythm.

The only exception is a function where the result depends on the path of the movement itself, such as freehand drawing or a signature pad. Even then, related controls (choosing a colour, saving, clearing) must still work by keyboard.

Who does it help?

• Blind people who use a screen reader and navigate by keyboard
• People with tremors or limited hand movement who cannot use a mouse precisely
• People who use switch devices, sip-and-puff controls or voice control that emulate keystrokes
• Power users who simply prefer the keyboard

Common failures

• A menu built from a div with a click handler that cannot receive focus
• A dropdown or mega menu that opens only on mouse hover
• A custom slider or date picker that reacts to mouse drag but not to arrow keys
• A cookie banner whose buttons are images with click handlers and no keyboard access
• Elements given tabindex="-1" or hidden from focus while they still need to be used

How we test it

• axe-core Automatic: axe-core finds typical violations. A violation is pre-filled as “fails”.
• evidence Evidence: our scanner collects material such as screenshots, lists and measurements.

Test question: Can every function be reached and used with the keyboard alone (menus, sliders, dialogs, forms)?

A person decides every criterion. No criterion ever passes automatically.

How to fix it

<div class="menu-toggle" onclick="toggleMenu()">Menu</div>

<button type="button" class="menu-toggle"
        aria-expanded="false" aria-controls="main-menu">Menu</button>

<script type="module">
  const btn = document.querySelector('.menu-toggle');
  btn.addEventListener('click', () => {
    const open = btn.getAttribute('aria-expanded') === 'true';
    btn.setAttribute('aria-expanded', String(!open));
  });
</script>

A native button is focusable and fires its click event on Enter and Space, so the keyboard support comes for free.

Practical tips

• Put the mouse aside and use the whole site with Tab, Shift+Tab, Enter, Space, Escape and the arrow keys.
• Prefer native elements (button, a href, input, select, details) over custom widgets; they bring keyboard handling with them.

Guides and patterns on this

• Getting there without a mouseMany people use the web without a mouse: with a keyboard, switches, voice control or a screen reader. Here is what has to work for them and how to manage focus properly in modern web apps.
• EAA compliance check: how to get your website tested for accessibilityThe European Accessibility Act asks for accessible services, not for a particular test. This guide explains what each kind of check can tell you, how an audit works, what ours costs, and what you hold at the end.
• The EAA for small businesses: where the exemption endsMicroenterprises that provide services are exempt from the European Accessibility Act. The exemption is narrower than many think, and growing businesses can grow out of it.
• Cookie banners that lock no one outThe cookie banner is often the first thing visitors meet, and for some the last: if it cannot be used with a keyboard or screen reader, the site is closed to them. Here is how to get it right.

Official source

Understanding WCAG 2.2 at the W3C: 2.1.1 Keyboard