WCAG 2.5.6: Concurrent Input Mechanisms

What This Rule Means

\n

WCAG 2.5.6 — Concurrent Input Mechanisms is a Level AAA success criterion under WCAG 2.2. Its core requirement is straightforward: web content must not restrict or interfere with the user's ability to use multiple input mechanisms simultaneously or interchangeably. In practical terms, this means a web page or application cannot programmatically detect which input device the user is currently employing and then lock them into that single modality, denying them access to other available input methods.

\n

Modern devices support a rich variety of input mechanisms: physical keyboards, mice and trackpads, touchscreens, styluses, switch controls, voice input, eye-tracking, and more. Many users rely on more than one of these at the same time — for example, a laptop user with a touchscreen might switch fluidly between the touchpad and the finger-touch interface. A power user might navigate a form by keyboard while using a mouse to scroll. A person with a motor impairment might use a combination of a head pointer and a switch device. The criterion protects all of these workflows.

\n

A failure occurs when a website uses JavaScript to detect the type of input being used and then removes or disables functionality for other input types. For example, if a site detects a touch event and subsequently removes keyboard focus indicators or disables keyboard navigation, that is a direct violation. Similarly, blocking pointer input after detecting keyboard use, or using platform APIs to artificially constrain input to a single modality, all constitute failures.

\n

A pass occurs when users can engage with any and all available input mechanisms at any time during their interaction. The content should respond correctly to whichever input mechanism the user chooses to employ at any given moment without requiring a page reload, a mode switch, or any additional user action to re-enable an input type.

\n

The criterion contains one official exception defined in WCAG: the restriction is permitted where it is essential — meaning where a specific input modality is intrinsically required. A classic example is a handwriting recognition application where touch or stylus input is the very point of the functionality. Another example might be a digital signature capture field that requires a specific pointer input. Even in these cases, the exception should be interpreted narrowly and the author should provide alternative means of completing the task wherever possible.

\n

It is important to note that this criterion does not require authors to add support for input mechanisms the device does not possess. It governs restrictions placed on mechanisms the device and platform already support. If a device has no touchscreen, there is nothing to restrict.

\n\n

Why It Matters

\n

The freedom to use concurrent or interchangeable input mechanisms is not a convenience feature — it is a critical accessibility requirement that directly affects several distinct groups of users.

\n

Users with motor impairments frequently rely on assistive technology that combines multiple input mechanisms. A person with limited hand mobility might use a sip-and-puff switch device alongside an on-screen keyboard. Someone with a tremor might begin navigating a page by keyboard but switch to a mouse or touch interface when a keyboard shortcut fails. If a website detects one input type and disables others, these users may be completely locked out of content or functionality.

\n

Users with cognitive or learning disabilities often benefit from the ability to choose the input method that feels most comfortable or natural for a given task. Forcing a single modality removes that choice and can introduce unnecessary cognitive load, particularly when a user is not proficient with the device's primary input method.

\n

Older adults, who may have age-related motor challenges, are increasingly using devices that support both touch and keyboard input. The ability to switch between these mechanisms as fine-motor control fluctuates throughout the day is important for sustained independent use of the web.

\n

Power users and multi-modal device users — such as Surface Pro or iPad Pro users — regularly use a keyboard, stylus, and touch interface on the same device in the same session. A website that detects touch input and removes keyboard shortcuts, or vice versa, degrades the experience of an enormous user base that may not identify as having a disability.

\n

Consider this real-world scenario: A Turkish bank's online portal detects that a customer is using a touchscreen tablet and switches into a "mobile mode" that disables keyboard navigation. A customer with a motor disability who uses the tablet with a Bluetooth keyboard is now unable to tab through form fields, navigate menus by arrow key, or use keyboard shortcuts. They cannot complete their banking tasks independently. This is not only an accessibility failure but also a potential legal exposure under Turkish accessibility regulations.

\n

From a usability and SEO perspective, respecting concurrent input mechanisms correlates with better Core Web Vitals scores, lower bounce rates, and higher user satisfaction across diverse device categories — all signals that search engines reward.

\n\n

Related Axe-core Rules

\n

WCAG 2.5.6 requires manual testing — there is no automated axe-core rule that can reliably detect all violations of this criterion. The reason is fundamental: automated tools can inspect the static DOM and CSS, and they can detect certain JavaScript patterns, but they cannot fully observe the runtime behavior of event listeners as they respond to different input modalities during an actual user session. The decision to restrict an input mechanism is often encoded in application logic that only executes in response to specific events, making static analysis insufficient.

\n

\n
• No dedicated automated axe-core rule exists for 2.5.6. Axe-core does not ship a rule that specifically checks for concurrent input mechanism restrictions, because the violation manifests as dynamic JavaScript behavior rather than a structural HTML or ARIA issue. A page can pass all automated axe checks and still violate 2.5.6 if its event handlers programmatically remove or disable input modalities at runtime.
\n
• Pointer events and touch event detection: While axe-core cannot catch the restriction itself, manual auditors should look for JavaScript that listens to touchstart or pointerdown events and then modifies the DOM, removes focus management, or sets flags that alter keyboard behavior. Similarly, keydown listeners that trigger CSS class changes hiding touch targets are red flags to inspect manually.
\n
• Why automation falls short: Automated scanners analyze the document at a point in time. Input mechanism restrictions are conditional — they activate only after a specific input event fires. A scanner running before user interaction cannot see that a touchstart handler will later call document.querySelectorAll('[tabindex]').forEach(el => el.setAttribute('tabindex', '-1')) and effectively destroy keyboard navigation. Only a human tester who exercises both input modalities in sequence can discover this failure.
\n

\n\n

How to Test

\n

\n
1. Automated baseline scan: Run axe DevTools or Lighthouse on the page to establish a baseline and catch any co-occurring issues. While neither tool has a dedicated 2.5.6 rule, axe DevTools' best-practices checks may flag keyboard traps or focus management issues that are symptomatic of input restriction. Note any failures for remediation alongside the manual checks below.
\n
2. Inspect JavaScript source and event listeners: Open Chrome DevTools, navigate to the Elements panel, and use the Event Listeners pane to inspect whether touchstart, pointerdown, pointermove, or MSPointerDown listeners are attached to the document or body. In the Console, search the page's JavaScript source for patterns like ontouchstart in window, navigator.maxTouchPoints, or 'pointer' in navigator combined with DOM modifications. These are common techniques used to detect input modality and gate functionality.
\n
3. Multi-modality interaction test (keyboard + touch): On a device that supports both touch and keyboard input (e.g., a Surface, an iPad with keyboard, or a touchscreen laptop), begin navigating the page exclusively by keyboard (Tab, Shift+Tab, Enter, Space, arrow keys). Note which interactive elements are reachable and functional. Then, without reloading the page, switch to touch navigation — tap links, buttons, and form controls. Verify that all functionality available via keyboard remains accessible via touch and vice versa. Document any element that becomes unreachable or non-functional after switching.
\n
4. Screen reader combined input test: Using NVDA with Firefox, navigate the page by keyboard to activate screen reader mode. Then use the touchscreen (if available) to attempt to interact with the same elements. Confirm the screen reader and the page respond correctly to both inputs. Repeat with VoiceOver on Safari on an iPad, using both the touch gestures and a paired Bluetooth keyboard. With JAWS on Chrome, verify that switching between keyboard and mouse does not break focus management or cause interactive elements to become inoperable.
\n
5. Code review for modality-locking patterns: Manually review any JavaScript libraries or frameworks used on the page for built-in modality detection. Some UI libraries, particularly older mobile-first frameworks, include code that disables mouse or keyboard events on touch-detected devices. Check the library documentation and source for such behavior and verify it has been overridden or disabled.
\n
6. Re-test after dynamic interactions: Perform actions that trigger significant DOM changes — opening modals, navigating single-page app routes, submitting forms — and re-run the multi-modality test after each transition. Restrictions are sometimes introduced only in specific application states.
\n

\n\n

How to Fix

\n

Detecting touch to disable keyboard navigation — Incorrect

\n

<!-- JavaScript detects touch and removes all tabindex values,\n     breaking keyboard navigation for users who switch input modes -->\n<script>\n  window.addEventListener('touchstart', function() {\n    document.querySelectorAll('a, button, input, [tabindex]').forEach(function(el) {\n      el.setAttribute('tabindex', '-1');\n    });\n  }, { once: true });\n</script>

\n

Detecting touch to disable keyboard navigation — Correct

\n

<!-- Do not restrict keyboard accessibility based on touch detection.\n     Allow both input modalities to function concurrently.\n     If you need to manage focus styles for aesthetics, use the\n     :focus-visible CSS pseudo-class instead of removing tabindex. -->\n<style>\n  /* Show focus rings only for keyboard navigation, not mouse clicks,\n     without removing keyboard access entirely */\n  :focus:not(:focus-visible) {\n    outline: none;\n  }\n  :focus-visible {\n    outline: 3px solid #005fcc;\n    outline-offset: 2px;\n  }\n</style>\n<!-- No JavaScript modality detection needed -->

\n\n

Pointer event used to suppress keyboard events — Incorrect

\n

<!-- A custom slider that, upon receiving pointer input, stops\n     responding to keyboard arrow keys, locking the user into\n     pointer-only interaction -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var pointerUsed = false;\n  slider.addEventListener('pointerdown', function() {\n    pointerUsed = true;\n  });\n  slider.addEventListener('keydown', function(e) {\n    if (pointerUsed) return; // keyboard disabled after pointer interaction\n    if (e.key === 'ArrowRight') { /* increment */ }\n    if (e.key === 'ArrowLeft') { /* decrement */ }\n  });\n</script>

\n

Pointer event used to suppress keyboard events — Correct

\n

<!-- Both pointer and keyboard interactions are handled independently.\n     No flag is set that prevents one modality from working after\n     the other has been used. -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var value = 50;\n\n  function updateSlider(newValue) {\n    value = Math.max(0, Math.min(100, newValue));\n    slider.setAttribute('aria-valuenow', value);\n  }\n\n  // Pointer handler — always active\n  slider.addEventListener('pointermove', function(e) {\n    if (e.buttons === 1) {\n      // calculate new value from pointer position\n    }\n  });\n\n  // Keyboard handler — always active, not disabled by pointer use\n  slider.addEventListener('keydown', function(e) {\n    if (e.key === 'ArrowRight') updateSlider(value + 1);\n    if (e.key === 'ArrowLeft') updateSlider(value - 1);\n  });\n</script>

\n\n

Mobile framework auto-disabling mouse events — Incorrect

(Content truncated due to token limit — please retry this article.)