2.5.6 Concurrent Input Mechanisms

WCAG 2.2 · 2.5.6 AAA Operable

What it requires

Content must not restrict the use of input modalities available on a platform, except where the restriction is essential, required to ensure the security of the content, or needed to respect user settings. In plain terms: if a device supports keyboard, touch, mouse, stylus, and voice at the same time, your page must let people switch freely between them. A user who starts with touch and then reaches for a keyboard — or who pairs a keyboard with a touchscreen tablet — should never be locked out because the page assumed a single input method.

The criterion targets pages that detect one input type and then disable or ignore the others (for example, switching to a “touch-only” mode and dropping keyboard support). It does not require you to add input methods the platform lacks — only to avoid taking away the ones it offers.

  • People with motor disabilities who pair multiple input devices — such as a switch, head pointer, or keyboard used alongside a touchscreen — and need to alternate as fatigue or context changes.
  • Assistive technology users whose tools emit keyboard or pointer events; locking to one modality can break the AT entirely.
  • Anyone on hybrid devices (2-in-1 laptops, tablets with keyboards) who moves between touch and keyboard mid-task.
  • Voice-control users who supplement speech with occasional keyboard or pointer input.

How to detect it

Checks for Concurrent Input Mechanisms
Check How Catches
Mid-task switching Operate the page with touch, then immediately try the keyboard (Tab, Enter, arrows) without reloading. Modes that disable keyboard after touch is detected.
Keyboard then pointer Tab to a control, then click or tap it; confirm both still work. Handlers bound to only one event family.
Hybrid device Test on a 2-in-1 or tablet-plus-keyboard; alternate inputs. Single-modality assumptions from device sniffing.
Code review Look for input/touch detection that swaps event listeners or hides controls. Logic that drops a modality after a feature/UA check.
Automated tools Run axe or similar. Largely cannot detect this — manual testing is required.

How to fix it

  1. Use native interactive elements (<button>, <a>, form controls) so the browser handles all input modalities for you.
  2. Avoid switching the interface to a single-input “mode” based on the first detected input or on user-agent sniffing.
  3. Prefer pointer events or pair mouse, touch, and keyboard handlers so every modality is supported at once.
  4. Never remove keyboard support when touch is detected, or vice versa.
  5. Re-test by alternating inputs mid-session on a hybrid device.
<!-- Native button: keyboard, mouse, touch and voice all work -->
<button type="button" class="play">Play</button>

<!-- Prefer pointer events over touch-only handlers -->
<script>
  el.addEventListener('pointerdown', activate);
  el.addEventListener('keydown', onKey); // keep keyboard too
</script>

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule for 2.5.6 — tools cannot tell whether your code drops a modality after detecting another. This criterion needs manual review, using the console check and steps below.

Run this in the browser console

console-2-5-6.js 
// Read-only: surfaces elements that may lock to one input modality.
const suspects = [...document.querySelectorAll('*')].filter(el => {
  const a = el.getAttributeNames();
  return a.includes('ontouchstart') || a.includes('ontouchend') ||
         (a.includes('ontouchmove') && !a.includes('onkeydown'));
});
console.table(suspects.map(el => ({
  tag: el.tagName, id: el.id, cls: el.className
})));
suspects.forEach(el => el.style.outline = '2px solid orange');
console.log('Touch-only handler candidates:', suspects.length);

What to check manually: operate the page with touch, then immediately try the keyboard without reloading — no script can confirm a modality still works after another is used, or that device sniffing did not silently swap event listeners.