WCAG 2.1.1
Keyboard
24.6%
of the 609 sites we scanned fail this
Ranging from 10.8% of US local government to 52% of Shopify DTC stores. Pooled across five targeted cohorts, so treat it as a convenience sample rather than a rate for the web.
What it means and how to fix it
What 2.1.1 covers
- We detect this: Interactive controls that cannot receive keyboard focus at all
- We detect this: Scrollable regions that cannot be scrolled from the keyboard
- No engine can detect this: Controls that take focus but ignore Enter, Space or the arrow keysReachable is not the same as operable. Confirming a control responds to the keys its role implies means driving it, which a page scan does not do.
- No engine can detect this: Drag-and-drop, sliders and canvas interactions with no keyboard path
Of that, 2 failures are detectable automatically, and these are what the rates on this page measure. Each needs its own fix. The percentage is the share of all 609 scanned sites affected. These do not sum to the 24.6% above: a site can fail more than one of them, and most that fail any fail several.
- Some controls can't be reached by keyboard21%
Interactive elements that can't receive keyboard focus are completely unusable for keyboard-only and switch-device users.
- A scrollable area can't be reached by keyboard4.4%
Keyboard users cannot scroll content-rich regions that lack keyboard focus.
What it looks like in code
HTML<div onclick="addToCart()">Add to basket</div><button type="button" onclick="addToCart()">Add to basket</button>A div has no role, cannot receive focus, and does not respond to Enter or Space. Using the native button gives all three for free. If the element must stay a div, it needs role, tabindex and key handlers, which is three chances to get it wrong instead of none.
Shown for Some controls can't be reached by keyboard. Both halves are written rather than harvested: this failure lives in HTML rather than in the markup, so there is no page element to show.
For what the criterion formally requires, read the W3C Understanding document.
How often it fails
Share of scanned sites in each cohort. These are five targeted studies, not a random sample of the web, so read the contrast between cohorts rather than any one figure as a web-wide rate.
Who fails it most3 cuts by sector, state, retail vertical
By sector
By state
By retail vertical
Groups smaller than 8 sites are not shown: a rate over a handful of sites moves by tens of points on a single result.
What the numbers do not say
Keyboard failures concentrate in commerce rather than in government. The pattern behind the number is custom interactive components, carousels, filters, quick-add controls, built as click handlers on non-interactive elements. They work perfectly with a mouse, which is why they survive review.
What this does not measureLimits of these figures, and where the corpus came from
- These are five targeted cohorts, not a random sample of the web. Per-cohort rates are the figure to quote; the pooled rate is a convenience sample.
- Denominators count sites that produced a result. Sites that were blocked or errored are excluded rather than counted as passing.
- Occurrence counts are floors: the engine records at most 25 occurrences of a rule per page.
- The EU and Indian cohorts retained only the primary success criterion per finding, so a rule mapping to several criteria contributes to one of them in those two cohorts and to all of them in the other three.
| Cohort | Scanned | Attempted |
|---|---|---|
| Shopify DTC stores | 75 | 75 |
| US local government | 158 | 221 |
| US healthcare providers | 208 | 218 |
| EU e-commerce | 107 | 170 |
| Indian financial services | 61 | 72 |
Corpus generated 2026-09-18.
Check your own site
A free scan reports WCAG 2.1.1 alongside everything else, with the exact elements that fail.
Run a free scan