WCAG Success Criterion 2.1.1 Keyboard (Level A) requires that all functionality on your page be operable through a keyboard interface, without needing precise timing for individual keystrokes. In plain terms: anything a mouse user can click, drag, or hover, a keyboard-only user must be able to do with keys alone. The lone exception is input that depends on the path of movement.

What WCAG 2.1.1 actually requires

The official W3C wording is precise: “All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints.”

Three phrases carry the weight:

  • “All functionality.” Not most. Every link, button, form field, menu, tab, accordion, modal, carousel, date picker, and custom widget must be reachable with Tab and operable with Enter, Space, or arrow keys.
  • “Keyboard interface.” This is broader than a physical keyboard. It includes anything that emits keystrokes — switch devices, sip-and-puff controllers, voice-control software, and on-screen keyboards. Crucially, W3C notes that operating-system MouseKeys does not count, because it drives the pointer, not the keyboard interface.
  • “Path of the user’s movement.” The one escape hatch. Freehand drawing or watercolor brush strokes, where the exact path and speed matter, are exempt. But the W3C is explicit that drawing a straight line, resizing a window, or dragging an object to a destination where only the endpoint matters is not exempt — those need a keyboard equivalent.

This is the difference between 2.1.1 and its stricter sibling 2.1.3 Keyboard (No Exception) at Level AAA, which removes the path-dependent exception entirely.

Who 2.1.1 affects

The thing that makes 2.1.1 different from “just be nice to keyboard users” is that for some people, a mouse-only control isn’t harder to use — it doesn’t exist at all. W3C names three groups, but the failure mode is distinct for each:

  • A screen reader user cannot find a mouse-only widget. This is the part developers most often miss. A blind user driving JAWS, NVDA, or VoiceOver moves through the page with Tab and reading-mode keys; the screen reader speaks each element the keyboard lands on. A clickable <div onclick> is never in the tab order, so the screen reader never stops on it and never announces it. The “Buy now” button isn’t slow or awkward for them — it is silent and unreachable, as if it were never coded. The W3C is explicit that MouseKeys (the OS feature that moves the pointer with the numeric keypad) does not rescue this, because it drives the mouse, not the keyboard interface a screen reader watches.
  • A switch or sip-and-puff user only emits keystrokes. Someone with quadriplegia operating the page through a single switch, a sip-and-puff straw, or scanning software is generating Tab/Enter events — not pointer coordinates. If your carousel arrows or your drag-to-reorder list only respond to mousedown, there is no input they can produce that will ever trigger them. There’s no “use it slowly” workaround; the action is simply off-limits.
  • A voice-control user calls elements by name and role. A person using Dragon or Voice Control says “click Buy now,” and the software needs a real, named, focusable control to target. A styled <div> with no role and no accessible name has nothing to click by voice, so the command fails — the same root cause as the keyboard failure, surfacing through speech.

That’s why 2.1.1 sits at Level A, the non-negotiable floor: it’s not a comfort improvement, it’s the difference between a function being available to these users and being absent entirely.

Concrete failures and how to fix them

These are the patterns we see most during remediation, each mapped to its official W3C failure code.

1. The clickable <div> (Failure F54 / F42). A developer styles a <div> or <span> to look like a button and wires up onclick. A mouse hits it fine; the keyboard skips right past it because non-interactive elements aren’t focusable.

<!-- Fails 2.1.1: not focusable, no keyboard activation -->
<div class="btn" onclick="checkout()">Buy now</div>

<!-- Fix: use the native element. It's focusable and
     fires on Enter and Space for free. -->
<button type="button" onclick="checkout()">Buy now</button>

If you genuinely can’t use a native element, you must add tabindex="0", an appropriate role, and a key handler for both Enter and Space — which is exactly the kind of work 4.1.2 Name, Role, Value also governs. Native HTML is almost always the better path.

2. Hover-only menus (Failure F54). A navigation dropdown that opens on mouseover and has no keyboard equivalent. Keyboard users can focus the top-level link but never reach the submenu items.

3. Mouse-only custom widgets (Failure F54). Carousels with click-only arrows, sliders that respond only to drag, star ratings that only register clicks, and lightboxes you can’t dismiss without the mouse. The fix is to bind key handlers (arrow keys for sliders and carousels, Esc to close overlays) alongside the mouse handlers.

4. Scripts that steal focus (Failure F55). Code that calls blur() the moment an element receives focus, bouncing keyboard users out. This also fails 2.4.7 Focus Visible and 3.2.1 On Focus.

5. Drag-and-drop with no alternative. A kanban board or file-upload zone that only works by dragging. Because the endpoint is what matters, not the path, you must provide keyboard moves — for example, focus a card, press Space to pick it up, arrow to the new column, Space to drop. WCAG 2.2 reinforces this with the new 2.5.7 Dragging Movements criterion, but the keyboard obligation already exists under 2.1.1.

How to test for 2.1.1

The single most reliable test costs nothing: put the mouse away.

  1. Tab through the whole page. Using only Tab and Shift+Tab, move through every interactive element from top to bottom. Note anything you can’t reach.
  2. Operate each control. On each stop, try Enter, Space, and arrow keys. Can you open the menu? Submit the form? Move the slider? Advance the carousel? Close the modal?
  3. Hit the hard widgets. Custom dropdowns, date pickers, tabs, accordions, modals, tooltips, and drag-and-drop are where failures hide.
  4. Check that focus is visible as you go — keyboard access is meaningless if you can’t see where you are, which is the job of 2.4.7 Focus Visible.

Automated scanners catch a clickable <div> here and there, but they cannot tell whether your custom carousel actually works by keyboard — that requires a human. The WebAIM Million 2026 report found that 95.9% of home pages had detected WCAG failures, and that of the home pages using an role="menu" ARIA menu, 22% of those menus introduced accessibility barriers for lack of the keyboard markup and interactions the role demands — precisely the kind of broken custom widget only manual testing surfaces. For a deeper walkthrough, see our keyboard navigation guide.

Why 2.1.1 matters legally

Of all the success criteria, keyboard operability is the one a plaintiff’s tester can prove fastest: they unplug the mouse, hit Tab, and screen-record the cursor skipping straight past your “Add to cart” button. There’s no expert-witness debate about contrast ratios or alt-text judgment calls — the control either takes focus and activates from the keyboard or it doesn’t, and the video shows which. That binary, demonstrate-it-in-30-seconds quality is exactly why keyboard failures (clickable <div>s, hover-only menus, drag-only widgets) appear so often in the complaint exhibits behind ADA web filings.

The volume of those filings keeps the risk concrete. Per UsableNet’s 2024 Year-End Report, plaintiffs filed 4,187 digital-accessibility lawsuits in 2024, about 2,400 of them in federal court. U.S. courts and the Department of Justice generally treat WCAG 2.1 AA as the practical benchmark for an accessible site under ADA Title III — and 2.1.1 sits below that line, at Level A, so a mouse-only control isn’t a near-miss on a stretch goal. It’s a failure of the most basic conformance tier, the hardest kind to argue away in front of a judge.

Overlays make this worse, not better, and the keyboard is precisely where they fail. The same UsableNet report found 1,023 businesses — about a quarter of all 2024 cases — were sued even though they had an accessibility overlay widget installed. A bolt-on script can flip color themes and resize text, but it cannot rewrite the event listeners inside your custom widgets: it can’t add an Enter/Space handler to a clickable <div>, can’t expose a hover-only submenu to Tab, and can’t graft arrow-key control onto a drag-only kanban board. So the exact mouse-only barriers that 2.1.1 targets survive the overlay untouched — and show up in the lawsuit anyway. That’s why Curbcut is deliberately anti-overlay: we add the real keyboard handlers and roles to the source so every control answers to the keyboard. (Overlay vs. manual remediation compares the two approaches in detail.)

This page is general information, not legal advice. For guidance on your specific exposure, consult a qualified attorney.

Get keyboard access right

2.1.1 is the rare criterion that’s nearly free if you start from native HTML and brutally expensive if you don’t. A <button> is focusable and fires on Enter and Space with zero extra code; the moment you reach for a <div onclick>, a hover dropdown, or a drag-only reorder list, you’ve signed up to hand-build tabindex, roles, and key handlers for every one of them — and to keep them working as the UI changes. Most sites that fail 2.1.1 fail it in a handful of repeating places: the custom select, the carousel arrows, the modal you can’t Esc out of, the kanban drag. Find those and you’ve usually found most of the criterion.

If you’re not sure where your site locks keyboard users out, run a free accessibility scan — we’ll flag the mouse-only divs, hover-only menus, and drag-only widgets specifically. When you’re ready, our team hand-wires the real keyboard handlers into the source so every control answers to Tab, Enter, Space, and the arrow keys — the part no overlay can do for you.