WCAG 2.5.6 Concurrent Input Mechanisms: Supporting Different Ways to Interact

What 2.5.6 Concurrent Input Mechanisms means

WCAG 2.5.6, called “Concurrent Input Mechanisms”, covers the idea that interactive functions should work with different ways of interacting. That includes keyboard, mouse or pointer, touch, voice or switch input. The goal is to avoid designs that only work with a single physical action or a single device.

Why this matters

People use different hardware and software to interact with the web. A person might use speech software at the same time as a keyboard. Another person might rely on a switch plus a touch device. If a control only accepts one type of input the user may not be able to complete a task. Supporting concurrent input improves access for mobility, vision and cognitive needs.

Common interaction problems this criterion addresses

• Widgets that require multi-finger gestures with no single-pointer or keyboard alternative.
• Controls activated only by touch events while keyboard activation is disabled.
• Custom controls built with mouse events only, lacking keyboard events or ARIA roles.
• Interfaces that block assistive devices when another input method is present.

High-level requirements for authors

Follow these practical rules when you build interactive features.

• Provide at least one non-gesture way to perform every function that otherwise requires a gesture.
• Keep keyboard access available whenever pointer or touch input is accepted.
• Do not require simultaneous use of two physical inputs unless a real-world input of that type is essential.
• Use semantic HTML and ARIA to expose roles, names and states to assistive tech.

Specific checks and patterns

1. Use native controls where possible

Native elements like <button> and <input> come with built-in keyboard and pointer support. Use them before creating a custom control. If you must create a custom control, make it behave like the native one.

2. Expose keyboard activation

Ensure custom controls respond to Enter and Space in a predictable way. Provide a visible focus indicator. Example pattern:

<div role="button" tabindex="0" aria-pressed="false"
     onclick="toggle()" onkeydown="if(event.key==='Enter'||event.key===' ') toggle()">
  Toggle
</div>

Do not rely on pointer-only events such as pointerdown or touchstart without an equivalent key handler.

3. Avoid gesture-only operations

If a function requires a swipe or pinch, provide a clearly labelled alternative like a visible button. Do not require multiple fingers when a single-pointer alternative would work.

4. Keep inputs independent

Do not block keyboard input while listening for pointer or voice input. If an input is modal, make that clear and ensure all supported input methods work inside that modal.

5. Use WAI-ARIA to expose semantics, not to replace native behaviour

Use roles, states and properties so assistive tech sees what your control does. For example, use role=“button” and aria-pressed when creating a toggle. But also implement keyboard and pointer handlers.

Testing checklist

Test each interactive component with this basic matrix.

• Keyboard only: Tab, Shift+Tab, Enter, Space, arrow keys where relevant.
• Mouse or trackpad only: click, double-click, hover effects.
• Touch only: tap, swipe, pinch if supported.
• Voice control: try common voice commands or a browser voice extension.
• Switch control: test with simple scanning if available.
• Screen reader with keyboard: NVDA, VoiceOver or JAWS plus keyboard navigation.

Common failures and fixes

• Failure: Control only responds to touch events. Fix: Add keyboard handlers and use role and tabindex.
• Failure: Gesture required for critical function. Fix: Offer a labeled button or icon that performs the same action.
• Failure: Keyboard focus is lost after pointer interaction. Fix: Manage focus programmatically so it remains on an actionable element.
• Failure: Assistive tech cannot discover the control. Fix: Add semantic markup or ARIA so the control is exposed to the accessibility tree.

Real-world refactor: a touch-only image carousel

Problem: a carousel required swipe to advance. Users who rely on keyboard or assistive tech could not move slides.

Refactor steps

1. Keep the carousel container focusable and set aria-live where appropriate for announcements.
2. Add prev and next buttons using <button>, with descriptive aria-label attributes.
3. Retain swipe handling for touch, but make swipe only an enhancement. Ensure buttons trigger the same functions.
4. Ensure keyboard users can tab to buttons and use Enter or Space to change slides. Manage focus so keyboard users know slide changed.

Developer tips and code patterns

• Prefer pointer events with keyboard fallbacks. Example: handle click and keydown rather than only touchstart.
• Use CSS touch-action to avoid interfering with native scrolling if you need custom gestures.
• Provide clear labels. Use aria-label or visible text so voice control can identify actions.
• Keep event handlers small and shared so the same function is used for pointer and keyboard activation.

When simultaneous physical actions are allowed

Some real-world controls require combined physical actions. For example, a music keyboard needs two simultaneous keys. Only require simultaneous actions when the action maps to a real-world physical device or when there is no feasible alternative. When you do require them, document the requirement and provide an alternative mechanism when possible.

Wrap-up checklist for release

• Every interactive function works with at least one non-gesture input.
• Keyboard access is preserved when pointer, touch or voice features are active.
• Custom controls expose role, name and state to assistive tech.
• Documentation explains any unavoidable simultaneous-input requirements and why they are necessary.

Further learning

Consult the official WCAG and WAI-ARIA documents for normative text and examples. Follow platform guidance for voice and switch control on iOS, Android and desktop environments when you implement support for those inputs.