2.5.6 Concurrent Input Mechanisms

What this rule means

WCAG 2.5.6 requires that web content does not restrict users to a single input modality when the platform supports multiple modalities. If a user can interact via touch, mouse, keyboard, stylus, or voice, the web content must not artificially limit which input methods are available.

Users frequently switch between input methods during a single session. A person might use a touchscreen to scroll, switch to a Bluetooth keyboard to type, and use a mouse for precise selections. Content must not assume or enforce a single input method.

Why it matters

Many assistive technology users depend on multiple input mechanisms. A user with limited hand mobility might use a mouth-operated stylus for some actions and voice control for others. Restricting input to touch-only, for example, would prevent keyboard or switch access users from interacting with the content.

Even users without disabilities regularly switch input mechanisms. Laptop users alternate between trackpad and keyboard. Tablet users switch between touch and an attached keyboard. Restricting input modalities creates unnecessary barriers for everyone.

Related axe-core rules

There are no automated axe-core rules for this criterion. Detecting input modality restrictions requires manual testing with multiple input devices and code review to identify any JavaScript that disables or blocks specific input types.

How to test

1. Connect multiple input devices (keyboard, mouse, touchscreen) to the same system.
2. Attempt to use each input method independently to complete all interactive tasks.
3. Switch between input methods mid-task and verify functionality is maintained.
4. Search the codebase for code that detects input type and disables alternative input methods.
5. Check for media queries like (pointer: coarse) that hide keyboard-focused UI elements entirely.

How to fix

Avoid restricting input modalities. Design interactions that work across all available input mechanisms.

Input detection — bad practice

// Bad: Disables mouse events when touch is detected
if ('ontouchstart' in window) {
  document.body.classList.add('touch-device');
  // All hover and mouse interactions disabled via CSS
}

// Bad: Removes keyboard support on touch devices
if (navigator.maxTouchPoints > 0) {
  document.removeEventListener('keydown', handleKeyboard);
}

Input detection — good practice

// Good: Use pointer events that work across all input types
element.addEventListener('pointerdown', handleInteraction);
element.addEventListener('pointerup', handleInteraction);

// Good: Keep keyboard support regardless of touch capability
document.addEventListener('keydown', handleKeyboard);

// Good: Adapt UI without removing functionality
// Show touch-optimized UI but keep keyboard shortcuts active
if (matchMedia('(pointer: coarse)').matches) {
  enlargeTouchTargets();
  // Keyboard navigation still works
}

CSS that preserves all input methods

/* Good: Use hover as enhancement, not requirement */
.dropdown-trigger:hover + .dropdown-menu,
.dropdown-trigger:focus + .dropdown-menu,
.dropdown-menu:hover,
.dropdown-menu:focus-within {
  display: block;
}

/* Good: Touch-friendly sizes that also work with mouse */
@media (pointer: coarse) {
  .interactive-element {
    min-height: 44px;
    min-width: 44px;
  }
}

/* Keep interactive elements accessible regardless of input */
.interactive-element {
  min-height: 32px; /* Works for mouse precision */
  min-width: 32px;
}

Common mistakes

• Detecting touch support and disabling mouse or keyboard event handlers.
• Using CSS media queries like (hover: none) to completely remove hover-triggered functionality without providing an alternative.
• Locking the interface to touch-only mode on tablets, preventing use of connected keyboards or mice.
• Disabling keyboard navigation in mobile views even when a physical keyboard is attached.
• Using JavaScript to block right-click, keyboard shortcuts, or other secondary input mechanisms.