Glossary · Code

Keyboard accessibility

Definition: Keyboard accessibility means every function of a website can be operated with the keyboard alone – without a mouse, and without individual key presses having to happen at a particular speed. WCAG success criterion 2.1.1 Keyboard requires it at Level A [1].

German: Tastaturbedienbarkeit · Also: keyboard operability · Last reviewed: 27 September 2026

To see how Reviseberg tests keyboard accessibility with real key presses, read agent testing.

Who depends on it

People with motor disabilities who use a keyboard, a switch or a mouth stick work without a mouse. Blind people operate their screen reader by keyboard. Voice control and many other assistive tools also end up sending keyboard input [2]. Add to that experienced users who are simply faster without a mouse – and anyone whose mouse is not to hand.

What it involves

  • Everything is reachable: every link, button and field receives focus with Tab.
  • Everything is operable: with Enter, Space, the arrow keys or Escape, as you would expect for that element.
  • Nobody gets stuck: no keyboard trap (WCAG 2.1.2).
  • You can see where you are: a visible focus indicator (WCAG 2.4.7).
  • The order makes sense: a logical focus order (WCAG 2.4.3).
  • You reach the content quickly: through a skip link, for example (WCAG 2.4.1).

Typical barriers

  • <div> or <span> elements with click handlers instead of real buttons and links.
  • Menus that only open on mouse hover [3].
  • Custom dropdowns, sliders and carousels with no keyboard support.
  • Features that only work by dragging with a mouse, with no simple alternative.

How Reviseberg handles it

The keyboard agent walks a user journey you define with real key presses: Tab, Shift + Tab, Enter, Space and Escape. Among other things it reports keyboard:unreachable for elements that behave like controls but cannot be reached with Tab, and keyboard:trap for traps. Where it cannot decide with certainty, it marks the step for a person. It tests the journey you define, not every widget on every page, which is why WCAG 2.1.1 counts as only partly automatable.

Keyboard trap · Focus order · Focus indicator · Skip link · Semantic HTML

Further reading

Frequently asked questions

How do I test my website for keyboard accessibility?

Put the mouse away and complete a typical task – placing an order, say – using only Tab, Shift + Tab, Enter, Space, the arrow keys and Escape. Wherever you get stuck, there is a barrier.

Can an automated scan find keyboard problems?

Only in part. A rules scan on its own never presses a key. You need a manual test or an agent that actually operates the page by keyboard.

Sources

  1. W3C, WCAG 2.2, Success Criterion 2.1.1 Keyboard – https://www.w3.org/TR/WCAG22/#keyboard
  2. W3C, Understanding SC 2.1.1 Keyboard – https://www.w3.org/WAI/WCAG22/Understanding/keyboard
  3. WebAIM, Keyboard Accessibility – https://webaim.org/techniques/keyboard/

See what a scan finds on your site

One page in about thirty seconds, no email needed. The full report covers up to 100 pages and a keyboard journey.