WCAG 2.5.6 Concurrent Input Mechanisms: Support Multiple Input Methods Simultaneously

Last updated: 2026-04-10

Level AAA Operable WCAG 2.5.6

What This Criterion Requires

WCAG 2.5.6 Concurrent Input Mechanisms requires that web content does not restrict the use of input modalities available on a platform, except where the restriction is essential, required to ensure security, or necessary to respect user settings. In practical terms, this means websites and applications must allow users to freely switch between and simultaneously use different input methods such as keyboard, mouse, touchscreen, stylus, voice commands, and other assistive input devices at any point during their interaction. Many people use multiple input mechanisms depending on the task at hand. A user with a motor disability might primarily navigate with voice commands but switch to a mouse for precise clicking, or use a touchscreen for some actions and a keyboard for text entry. Someone using a tablet with an attached keyboard might alternate between touch and key presses throughout a session. This criterion ensures that when a user begins interacting with one input method, they are not locked into that modality. Content must not assume that because a touch event was detected, the user is on a mobile device and should no longer receive keyboard focus indicators. Similarly, detecting a mouse hover must not disable touch event handlers or hide touch-optimized controls. The web platform inherently supports concurrent input through its event model, where pointer events abstract over mouse, touch, and pen input. Problems arise when developers explicitly restrict input based on device detection, user-agent sniffing, or input-type assumptions. JavaScript that disables keyboard listeners when touch is detected, CSS that uses media queries to hide controls for certain device types, or frameworks that switch to entirely different interaction patterns based on initial input all potentially violate this criterion.

Why It Matters

People with disabilities frequently rely on multiple input methods, often switching between them based on fatigue, context, or task requirements. A person with limited hand mobility might use voice commands for navigation but a head-mounted pointer for precise interactions. Someone with a repetitive strain injury might alternate between mouse and keyboard to manage pain levels throughout the day. Users of switch scanning devices may supplement their primary input with occasional touchscreen taps when physically able. Beyond disability, concurrent input use is simply how modern computing works. People use laptops with touchscreens, tablets with keyboards, phones with Bluetooth mice, and desktop computers with voice assistants. Restricting input to a single detected modality creates unnecessary barriers and degrades the experience for everyone. When websites lock users into one input method, those who depend on switching between methods may find entire features or workflows inaccessible. This is especially harmful on assistive technology setups where the detected input type may not reflect the user primary interaction method.

Common Failures and How to Fix Them

Inaccessible
Accessible

Inaccessible
Accessible

Inaccessible
Accessible

Inaccessible
Accessible

Inaccessible
Accessible

Inaccessible
Accessible

How to Test

  1. On a laptop with a touchscreen, begin navigating with the keyboard (Tab key), then switch to touch, then switch to mouse. Verify that all three input methods work at every point and that switching does not break focus management or hide interactive elements.
  2. On a tablet with an attached keyboard, alternate between touch taps and keyboard navigation. Confirm that keyboard focus indicators appear when using the keyboard and that touch targets remain responsive when switching back to touch.
  3. Use browser developer tools to emulate different device types and verify the website does not serve a reduced-functionality version based solely on detected input capabilities.
  4. Test with voice control software (Dragon NaturallySpeaking, Voice Control on macOS) while also using a mouse. Verify that voice-triggered actions and mouse-triggered actions can be used interchangeably.
  5. Inspect JavaScript event handlers for any code that removes or disables event listeners for one input type when another is detected. Search for patterns like removeEventListener called inside touch event handlers.
  6. Check that the site does not force redirect to a mobile subdomain (m.example.com) without providing an easy, persistent way to access the full-featured version.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

Further Reading

Related WCAG Criteria