WCAG 2.5.6: Concurrent Input Mechanisms
People do not use one input method — they use whichever works for them, moment to moment: touch, then keyboard, then stylus, then voice. This criterion requires that your content never restricts the input modalities the platform makes available. Detecting a touchscreen is not permission to ignore the keyboard; detecting a mouse is not permission to block touch.
The success criterion, in full
Web content does not restrict use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or required to respect user settings.
“Input modalities” means the ways a user can provide input — keyboard, mouse, touch, stylus, voice, switch devices. The three exceptions are narrow: a restriction must be essential to the activity, genuinely required for security, or made to respect a setting the user chose. “We designed for touch” is none of these.
Who this helps and why
The assumption this criterion attacks is “one device, one input.” Real setups are hybrid: touch laptops, tablets with keyboards, phones driven by switch access, desktops with voice control. For many disabled users, the combination is the accommodation — and content that hard-binds itself to a single modality breaks exactly that.
People using adaptive hardware
External keyboards, switch devices, head pointers, and eye-gaze systems are routinely paired with phones and tablets. A 'touch-only' page shuts them all out.
People with tremor or fatigue
May tap large targets by touch but type via keyboard, or start with a mouse and switch to keyboard as fatigue builds during a long session.
Voice control users
Dragon and built-in voice access simulate clicks and keystrokes. Handlers wired to touch coordinates or hover states alone leave nothing for voice to trigger.
Everyone with hybrid devices
Touchscreen laptops and convertibles are mainstream. Users flow between trackpad, screen, and keys without thinking — until a page stops responding to one of them.
What counts as a restriction
A restriction is anything that makes functionality unavailable to an input mechanism the platform supports. It is usually accidental — a byproduct of event-handler choices or device detection rather than a deliberate lockout:
- Listening only for touch events (touchstart/touchend), so mouse clicks and keyboard activation do nothing.
- Listening only for mouse events (mousedown/mouseover), so touch and keyboard users cannot operate the control.
- User-agent or screen-size sniffing that disables keyboard handlers, hover menus, or shortcuts on 'mobile' — even when a keyboard is attached.
- Removing focusability (tabindex="-1", deleted outlines, keydown handlers stripped) on touch devices as a 'cleanup'.
- Requiring a modality the user may not have: hover-only reveals with no focus/click equivalent, or keyboard shortcuts as the sole path to a feature.
- Interaction that stops working when the user switches mid-task — e.g., a drag begun with touch that cannot be completed or cancelled with the keyboard-accessible alternative.
What is not a restriction: adapting presentation to the likely input (bigger targets when touch is in use, hover niceties when a fine pointer is present) — as long as every modality can still operate everything. Enhancement per modality is good design; exclusivity per modality is the failure.
Code examples
Prefer input-neutral events
click on a real button fires for mouse, touch, stylus, keyboard, and voice control alike. Pointer events unify all pointing devices when you need lower-level control.
// ✗ Touch-only: mouse, keyboard, and voice get nothing
el.addEventListener("touchstart", activate);
// ✓ One neutral handler serves every modality
button.addEventListener("click", activate);
// ✓ Need pointer-level detail? pointer events cover
// mouse + touch + stylus in a single code path
canvas.addEventListener("pointerdown", startStroke);
canvas.addEventListener("pointermove", continueStroke);
canvas.addEventListener("pointerup", endStroke);Detect capabilities, never devices — and keep both paths alive
Media queries like pointer and hover may be used to enhance for the current input — but the interaction must keep working when the user switches.
/* ✗ Assumes coarse pointer means 'no keyboard exists' */
// if (isMobileUA) removeKeyboardHandlers(); // never do this
/* ✓ Enhance sizing for coarse pointers; restrict nothing */
@media (pointer: coarse) {
.toolbar button { min-width: 44px; min-height: 44px; }
}
/* ✓ Hover is an enhancement; focus/click path always exists */
.menu-panel { display: none; }
.menu:hover .menu-panel,
.menu:focus-within .menu-panel,
.menu[data-open="true"] .menu-panel { display: block; }Custom widgets: wire pointer and keyboard together
Anything draggable or gesture-driven needs a concurrent keyboard path — the same requirement 2.1.1 and 2.5.7 impose, kept switchable at any moment.
<!-- ✓ Slider operable by any modality, at any moment -->
<div role="slider" tabindex="0"
aria-valuemin="0" aria-valuemax="100" aria-valuenow="50"
aria-label="Volume">
</div>
<script>
slider.addEventListener("pointerdown", beginDrag); // mouse/touch/pen
slider.addEventListener("keydown", (e) => { // keyboard, always on
if (e.key === "ArrowRight") step(+1);
if (e.key === "ArrowLeft") step(-1);
});
</script>Common failures
- touchstart/touchend as the only activation events, leaving buttons dead to mouse clicks and keyboard Enter/Space.
- User-agent sniffing that serves a 'mobile' experience with keyboard support stripped out — breaking phones paired with keyboards or switch devices.
- Disabling touch handling when a mouse is detected (or vice versa) instead of leaving both registered.
- Hover-only menus and tooltips with no focus or tap equivalent, making content unreachable for touch and keyboard alike.
- Canvas or game UIs that read only mouse coordinates, ignoring touch, stylus, and keyboard entirely.
- Virtual keyboards or PIN pads that block hardware keyboard input without a genuine security requirement.
- Tearing down event listeners on resize/orientation change on the assumption that the input modality changed with the viewport.
- Onboarding flows that force a gesture ('swipe to continue') with no button or key alternative.
How to test for 2.5.6
- 1
Test each modality end-to-end
Complete the page's key tasks three times: keyboard only, mouse/trackpad only, and touch only (real device or DevTools touch emulation). Every task must be completable in each mode.
- 2
Switch modalities mid-task
Start a form by touch, finish with a keyboard; open a menu with the mouse, choose an item with arrow keys. Nothing should break, reset, or refuse the second input method.
- 3
Attach a keyboard and mouse to a touch device
Pair a Bluetooth keyboard (and mouse, where supported) with a phone or tablet and use the page. This is the single most revealing 2.5.6 test — it exposes 'mobile means touch-only' assumptions immediately.
- 4
Audit the event-handler code
Search for touchstart/touchend, mousedown/mouseup, and user-agent checks. Each occurrence should either be paired with equivalents for the other modalities or replaced with click/pointer events.
- 5
Scrutinize any claimed exception
For each deliberate restriction, verify it is essential to the activity, genuinely required for security, or honoring a setting the user chose. Document the justification — 'the design assumed touch' does not qualify.
Relationship to 2.1.1 and the 2.5.x family
2.1.1 Keyboard (Level A) guarantees the keyboard specifically: all functionality must be keyboard-operable. 2.5.6 generalizes it: no modality the platform offers may be restricted, and users must be free to combine them. Meeting 2.1.1 gets you the keyboard path; 2.5.6 asks you not to take the others away.
Within Guideline 2.5, this criterion complements 2.5.1 Pointer Gestures (complex gestures need single-pointer alternatives), 2.5.2 Pointer Cancellation (accidental presses must be abortable), and 2.5.7 Dragging Movements (dragging needs a non-drag alternative). Together they describe one philosophy: accept input however the user can give it.
Frequently asked questions
What does WCAG 2.5.6 Concurrent Input Mechanisms require?
It requires that web content does not restrict use of the input modalities available on a platform, except where the restriction is essential, required to ensure the security of the content, or required to respect user settings. If the user's device offers touch, keyboard, mouse, stylus, or voice input, your page must let them use any of those — and switch between them at any moment — rather than locking interaction to the one modality you assumed. It is a Level AAA criterion under Guideline 2.5 Input Modalities, introduced in WCAG 2.1.
Who actually switches input methods mid-task?
More people than most teams assume. A user with tremor may navigate a tablet mainly by touch but plug in a keyboard for text entry. A wheelchair user may pair a phone with a switch device. A laptop user with a touchscreen alternates between trackpad, screen, and keyboard constantly. Someone using voice control dictates into the same form they scroll by touch. The point of 2.5.6 is that the availability of one modality never justifies disabling another — users combine them in whatever way their bodies and situations require.
What are the allowed exceptions in 2.5.6?
Three: essential (the restriction is fundamental to the activity — a drawing app that interprets stylus pressure can legitimately be stylus-centric for the canvas itself), security (for example, restricting input in ways genuinely needed to protect content), and user settings (respecting a preference the user themselves chose, such as an on-screen keyboard being suppressed because the user configured a hardware keyboard). Convenience, design simplicity, and 'we only tested touch' are not exceptions.
Does detecting 'mobile' and hiding features violate 2.5.6?
Serving a responsive layout is fine — the criterion is about input, not screen size. The failure pattern is inferring input capability from device sniffing: assuming a small screen means touch-only and therefore removing keyboard interactivity, disabling hover-dependent features without alternatives, or blocking mouse events. A phone with a paired Bluetooth keyboard and mouse is a normal setup for many disabled users, and a 'mobile' page that ignores keyboard events restricts a modality the platform provides — exactly what 2.5.6 forbids.
How do pointer events help meet 2.5.6?
The Pointer Events API (pointerdown, pointerup, pointermove) fires uniformly for mouse, touch, and stylus, so one code path serves every pointing modality without sniffing. Combine pointer events for pointing input, standard click handlers (which fire for taps, clicks, and keyboard activation of buttons and links), and keydown handlers for widget-specific keys, and your interface naturally supports concurrent modalities. Problems arise when code listens only to touchstart or only to mousedown — each of those silently excludes the other family of devices.
How is 2.5.6 different from 2.1.1 Keyboard?
2.1.1 (Level A) guarantees one specific modality: all functionality must be operable through a keyboard interface. 2.5.6 (Level AAA) generalizes the principle to every modality the platform offers: don't restrict any of them, and don't force the user to stay in one. A page could pass 2.1.1 (keyboard works) yet fail 2.5.6 by suppressing touch interaction when a keyboard is detected, or by disabling keyboard handlers on touch devices. Related criteria in the same guideline include 2.5.1 Pointer Gestures and 2.5.2 Pointer Cancellation, which govern how pointer input itself must behave.
Related Success Criteria
Functionality that uses multipoint or path-based gestures has alternatives.
Functions triggered by single pointer can be cancelled or undone.
The accessible name contains the visible label text.
Functionality triggered by device motion can be disabled and has alternatives.
Target size is at least 44 by 44 CSS pixels except in specific cases.