2.5.6 Concurrent Input Mechanisms

Web content does not restrict use of input modalities available on a platform, except where the restriction is essential, required for security, or required to respect user settings.

Last reviewed: September 9, 2026

Understanding 2.5.6

Many users rely on more than one input method at once, or switch between them depending on fatigue, task, or context: for example, using touch most of the time but plugging in a keyboard for extended typing, or using a mouse alongside an on-screen switch scanner. If a page detects a touchscreen and disables keyboard focus, or detects a mouse and suppresses touch handling, it strands users who depend on the input method the page decided to turn off.

How to Meet It

Avoid feature-detecting one input type and disabling handlers for others. Support pointer, keyboard, and touch event handling concurrently rather than switching modes based on the last detected input type. Where a restriction is genuinely required (for example, disabling keyboard input during a kiosk-mode security screen), document and scope it as narrowly as possible.

Frequently Asked Questions

What's a real-world violation of this criterion?

A web app that detects touch events and then disables all keyboard event listeners for the rest of the session, even though the device has a physical keyboard attached; this locks out anyone who prefers or needs to switch to keyboard control.

Related Success Criteria

2.5.1 Pointer Gestures 2.5.2 Pointer Cancellation 2.5.3 Label in Name 2.5.4 Motion Actuation

Quick Facts

Criterion2.5.6
LevelAAA
IntroducedWCAG 2.1

Automate Compliance

AccessiSight automatically scans and identifies 2.5.6 issues in your codebase.

Try Scanner Free