Standards · WCAG 2.2

SC 2.5.6 Level AAA WCAG 2.1

Concurrent Input Mechanisms

Web content must not restrict use of input modalities available on the platform — except where the restriction is essential, required to secure content, or required to respect user settings.

What it asks

If the user’s device supports multiple input methods — touch, mouse, keyboard, stylus, voice, switch — the site must let the user switch between them freely. A user on a Surface who alternates between keyboard and touch through the day shouldn’t have to “pick” one. A user on an iPad with a Bluetooth keyboard and a connected switch shouldn’t get a UI that only listens to one.

Exempt cases: where the restriction is essential (a piano-input app), required for security (a CAPTCHA that must verify a specific input mode), or where the user themselves has restricted modalities through settings.

How to meet it

  • Don’t sniff input type at page load and lock the UI to it. A site that goes “touch device — hide all hover states and keyboard hints” breaks for hybrid laptops.
  • Don’t disable focus styles when a mouse is detected unless you have a robust way to re-enable them the moment the keyboard is used. :focus-visible solves this.
  • Don’t trap interaction inside drag-and-drop only, or swipe-only; pair gestures with keyboard and pointer equivalents (overlaps heavily with 2.5.1 and 2.5.7).
  • Test on a Surface, Chromebook, or iPad with a connected keyboard. Switch between input methods mid-task and confirm everything still works.

Common failures

  • Sites that hide focus rings the instant they detect “touch capable” — keyboard users on hybrid devices lose all focus indication.
  • Carousels that only respond to swipe even when the user is hovering with a mouse.
  • Modals built for touch that ignore Escape from the keyboard.
  • “Mobile mode” detection that disables the keyboard-shortcut palette on any device whose viewport happens to be narrow.

Why it matters

Many disabled users layer input devices — a head-pointer plus a keyboard, a switch plus voice, a trackball plus touch. Locking the UI to one assumed input mode breaks those combinations. It also hurts the growing population of users on convertible laptops and tablets-with-keyboards. As an AAA criterion it doesn’t carry the legal weight of AA, but the underlying behaviour (don’t sniff input, use :focus-visible, support keyboard alongside pointer) is design-system hygiene that pays for itself.