Concurrent Input Mechanisms
Content must not restrict which input methods somebody can use, unless the restriction is essential, needed for the security of the content, or needed to respect the reader's own settings. That security exception is rare in WCAG and it is the one an authentication or payment flow will reach for. The essential one has a worked example. A web app teaching touch typing can legitimately require the keyboard.
Why it matters
People switch input constantly, and disabled users switch more than most. W3C's own examples run in every direction. A mouse and keyboard paired to a phone. Somebody with tremor using the keyboard and trackpad on a touchscreen laptop. A speech input user turning speech off when a colleague walks in. A second touchscreen monitor attached halfway through a session. That last one is the case teams never plan for. A page that decided which input you had at load time is wrong about you the moment you plug something in.
Who this rule protects
Anybody who alternates input methods, which covers most touchscreen laptop users and most assistive technology users. W3C's own examples name a reader with a mobility impairment pairing a keyboard and mouse to a phone, somebody with hand tremors or limited dexterity reaching for the keyboard when a target is too small for the touchscreen, and a speech-input user switching to the mouse when a colleague starts talking.
How to check it yourself
- On a touchscreen laptop, use touch first, then immediately switch to the keyboard.
- Attach an input mid-session. Pair a keyboard to a phone, or plug in a touch monitor, and check the page accepts it.
- Check that hover-dependent content has both a touch route and a keyboard route.
- Read the code for a device-class branch. The failure W3C documents is a page deciding, on detecting a touchscreen, that touch is all there will ever be.
Failures we see most often
- Touch detection swaps in touch-only handlers, so a keyboard on the same device cannot operate the page.
- A mobile layout gets served to a touchscreen laptop, losing the keyboard interface it needs.
- Drag works only for a mouse and swipe works only for touch, with no overlap. That one also engages criterion 2.5.7 at Level AA, which is what an auditor would cite.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
- Voice controlpeople who operate the page by speaking to it
How to fix it
- Build on input-agnostic handlers. Focus, blur and click fire for mouse, touch and keyboard alike, and that is W3C's own first suggestion here.
- Feature-detect capability with the pointer and hover media queries rather than guessing at a device class.
- Support pointer events without switching keyboard handling off at the same time.
Step-by-step fix guides (1)
Passes vs. fails
Passes
The same page handles click and focus, so the keyboard, the mouse and the touchscreen all keep working.
Fails
A page decides on the first touch event that it is a touch device and stops listening for keys.
In audits and lawsuits
This is Level AAA and the least tooled criterion in the standard. There is not one numbered sufficient technique for it, only two placeholders, and no automated rule either. So there is genuinely nothing to test it with, which is a large part of why nobody tests it. The failure W3C does document is exactly the pattern we see. A site detects a touchscreen and builds a touch-only interface on that basis, and the reader with a keyboard plugged into that same device is locked out. Note the boundary too. Stripping focus styles on a touch event is a real bug and it belongs to criterion 2.4.7 at Level AA, because losing the focus ring does not stop the keyboard working.