2.5.6 Concurrent Input Mechanisms
Level AAA · added in WCAG 2.1
Don't restrict which input methods people can use. If a device supports touch, a mouse, a keyboard or a stylus, accept all of them. People may switch between them at any time.
Who it helps
Many people combine inputs, such as a touch tablet with a keyboard or a switch device that acts like a mouse. Blocking one input because you detected another can lock them out entirely.
How to meet it
- Don't turn off mouse or keyboard handling when you detect a touch screen, or touch handling when you detect a mouse.
- Use click and pointer events, which work for mouse, touch and pen, instead of touch-only or mouse-only events.
- Let people switch inputs mid-task, such as starting with touch and finishing with a keyboard.
- Exceptions: a restriction is allowed when it is essential, required for security, or needed to respect the user's own settings.
- Level AAA isn't required by most laws or policies, which point to AA. It's still worth meeting, and device-agnostic events usually make it free.
Examples
<button type="button" ontouchend="addToCart()">
Add to cart
</button><button type="button" onclick="addToCart()">
Add to cart
</button>Can a scanner detect this?
No
axe-core has no rule for this criterion, because input handling lives in scripts and depends on the device. You need to test on a device with several inputs, such as a touch laptop, and use each input on every feature.
No automated rule tests this criterion. Check it by hand.
Common mistakes
- Detecting a touch screen and switching to a touch-only layout that ignores the keyboard.
- Calling preventDefault on touch events in a way that also stops the click event.
- Building a mobile site that assumes no physical keyboard is ever attached.
- Testing only on a desktop with a mouse, or only on a phone with touch.
Related criteria
Check your own page
See which automated WCAG checks your page fails, with the failing elements and how to fix them.
Reviewed November 2, 2026