WCAG 2.5.6 — Concurrent Input Mechanisms

What this requires

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. In practice, this means don't disable keyboard handlers when a touch device is detected, and don't disable touch when a mouse is connected.

How AI coding tools fail this

When asked to "build mobile-specific interactions", AI tools sometimes branch logic on user-agent string or pointer-type detection, disabling alternative paths in each branch. A hybrid-device user (touchscreen laptop, keyboard-attached tablet, voice-input on a desktop) finds entire interaction paths missing based on which input the page guessed first.

The second pattern: gesture libraries that respond only to touch and ignore equivalent mouse-drag input — or vice versa. The pointer abstraction in modern browsers handles both, but custom code that listens for touchstart only locks out mouse users.

The third: keyboard handlers disabled "on mobile" via media-query JavaScript. A user with a Bluetooth keyboard paired to a phone is told via UA detection that they're on a touch-only device, and the keyboard shortcut they tried to use does nothing.

Failing examples

Branching on user agent and disabling input paths:

const isTouch = /Mobi|Android/i.test(navigator.userAgent);

if (isTouch) {
  // disable keyboard shortcuts
} else {
  // disable touch gestures
}

Passing examples

Use pointer events (which abstract over mouse, touch, and pen) and keep keyboard handlers always-on:

<div
  onPointerDown={startDrag}
  onPointerMove={moveDrag}
  onPointerUp={endDrag}
  onKeyDown={(e) => {
    if (e.key === "ArrowLeft") move(-1);
    if (e.key === "ArrowRight") move(+1);
  }}
  tabIndex={0}
>
  {/* ... */}
</div>

Detect capability (e.g. 'ontouchstart' in window) only when necessary to add an additional input, not to remove an existing one.

Edge cases

Pointer Events (onPointerDown, etc.) normalise mouse, touch, and pen into a single API. Prefer them over touch-specific handlers.
pointer: coarse and hover: none media queries describe capability, not exclusivity. Use them for affordances (showing a tooltip on hover) but never to disable interactions.
Security-driven restrictions (e.g. PIN entry blocking on-screen keyboards for shoulder-surfing protection) are an explicit exception.
Voice input counts as an input modality. Don't filter keystrokes in a way that breaks voice typing.
Mobile-first design is about layout adaptation; it should not also remove input paths.

How Jeikin handles this

The scanner flags user-agent sniffing patterns (navigator.userAgent, isMobile-like utilities) that gate event handlers. The dashboard records each finding and asks for confirmation that no input modality is removed. This is a manual judgement call captured per component.