Level AAA

2.5.6 is satisfied when content does not restrict the input modalities a platform exposes, except where the restriction is essential, required for security, or required to respect user settings.

2.5.6 Concurrent Input Mechanisms

In Plain Language

2.5.6 Concurrent Input Mechanisms (Level AAA, new in WCAG 2.1) requires that content does not restrict the input modalities a platform exposes. If the operating system surfaces keyboard, pointer, touch, stylus, and voice, the page must accept all of them and must let the user switch between them at any point in a task[1].

Three exceptions are carved out in the normative text: a restriction is allowed when it is essential to the activity, required to ensure the security of the content, or required to respect a user setting[1].

Why It Matters

  • Users with disabilities routinely combine input methods in a single session -- typing with a keyboard, switching to voice when fatigue builds, reaching for a trackball when a tremor flares. A page that binds functionality to one modality cuts the user off from that rotation.
  • Assistive technologies emulate native input events. A switch interface may dispatch keydown for one action and pointerdown for another; head-tracking and eye-gaze drivers synthesise pointer events. Disabling a modality disables whichever AT was routing through it.
  • Users with fluctuating conditions (RSI, MS, long COVID) change input method mid-task as symptoms change during the day. A control that refuses keyboard after detecting touch forces those users to start the task over on a reload.
  • Modern devices expose multiple inputs concurrently: a touchscreen laptop has keyboard, trackpad, touchscreen, and often an external mouse attached at the same time. Detecting "the" input type is a category error -- there is no single type.

Examples

Do: Accept every modality the platform exposes

✔ This input works with keyboard, mouse click, touch tap, stylus, and voice dictation -- any input the platform supports.

<!-- Native input -- the UA routes every input modality to it -->
<label for="search">Search products:</label>
<input type="text" id="search"
       placeholder="Type, tap, or use voice input...">
<!-- No modality-specific handlers, no modality detection -->
Don't: Build a touch-only slider with tabindex="-1"
Volume:

✘ This custom slider only responds to touch/drag events and sets tabindex=-1. Keyboard users cannot operate it at all.

<!-- Fails 2.5.6: touch-only, keyboard removed from tab order -->
<div class="custom-slider" role="slider"
     aria-label="Volume"
     aria-valuemin="0" aria-valuemax="100"
     aria-valuenow="30"
     tabindex="-1">
  <!-- Only touch/drag handlers attached -->
  <!-- tabindex="-1" strips keyboard reachability -->
</div>
Do: Use the native control, or handle pointerdown + keydown

✔ Native range input supports keyboard arrows, mouse drag, touch swipe, and assistive technologies -- all input methods work.

<!-- Native range: the UA wires up every modality -->
<label for="vol">Volume: <span>30%</span></label>
<input type="range" id="vol"
       min="0" max="100" value="30" step="1">
<!-- Arrow keys, mouse drag, touch swipe, stylus,
     and AT-synthesised events all route through -->
Don't: Detect one modality and disable the others

Detected input: mouse

Touch events: disabled

Keyboard shortcuts: disabled

✘ After detecting a mouse movement, this page disables touch and keyboard input. Users cannot switch to another input method mid-session.

How to Fix It

  1. Reach for the native control first. <input type="range">, <button>, <select>, and <a href> are already wired to every modality the UA exposes. Custom widgets are where modality restrictions enter the codebase.
  2. Never branch on "is this a touch device" or "is this a mouse user." A single session can produce touchstart, mousemove, and keydown from the same physical user. Treat modality detection at page load as a bug pattern.
  3. Listen on pointerdown, not mousedown or touchstart. Pointer Events unify mouse, pen, and touch in one handler; pair them with keydown on a focusable element and the widget picks up every input the OS can deliver, including AT-synthesised events.
  4. Keep keyboard reachability on custom controls. A native-replaceable role="slider", role="switch", or role="button" must carry tabindex="0" (or be a real focusable element) and must respond to the key bindings the WAI-ARIA APG specifies for that pattern[2].
  5. Test with two inputs attached at once. Plug a USB keyboard into a tablet, or use a touchscreen laptop. Run the critical task, switching input mid-flow. If a control goes dead when you switch, the page is failing 2.5.6.
  6. Document the exception if you invoke one. The essential, security, and user-settings carve-outs are narrow. A signature-capture field may legitimately require a pointer; a WebAuthn step may legitimately require a biometric device. If you are relying on an exception, write down which one and why[1].

References

  1. [1] W3C (2023). Understanding Success Criterion 2.5.6: Concurrent Input Mechanisms. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/concurrent-input-mechanisms.html ↩ ↩ ↩
  2. [2] W3C (2024). WAI-ARIA Authoring Practices Guide. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/ARIA/apg/ ↩