The criterion behind it
2.1.1 Keyboard
Everything you can do with a mouse, you must be able to do with a keyboard.
Level A · EN 301 549 § 9.2.1.1
Why this check exists
Keyboard operation is the baseline that screen readers, switch devices and voice control all build on. A mouse-only control is unreachable for all of them.
What usually triggers it
- failsA `<div onclick>` with no `tabindex` and no key handler.
- failsA custom dropdown that opens on hover only.
- failsA drag-and-drop reorder with no keyboard alternative.
How to fix it
- doUse `<button>` and `<a href>`. They are focusable and key-activated for free.
- doIf you must use a custom element, add `tabindex="0"`, a role, and handlers for Enter and Space.
- doGive every drag interaction a keyboard path — move up / move down buttons are enough.
How it is reported
A11ySignal reports this at minor impact. Every failing element comes with its CSS selector and the markup that failed, so you can go straight to the line rather than hunting for it. Deque publishes the engine-level detail:
https://dequeuniversity.com/rules/axe/4.13/server-side-image-map ↗
Check implemented by axe-core 4.13.0, © Deque Systems, MPL-2.0.
Other checks for 2.1.1
seriousframe-focusable-contentFrames with focusable content must not have tabindex=-1
seriousscrollable-region-focusableScrollable region must have keyboard access