Why Users Must Be Able to Use Multiple Input Methods

Users may rely on more than one way to interact with web content. Depending on their abilities, environment, or task, they may switch between a keyboard, mouse, touchscreen, stylus, or assistive technologies such as speech input.

WCAG 2.5.6 ensures that web content does not lock users into a single input modality when others are available on the platform.

What Are Input Modalities

Input modalities are the different ways users can interact with content, such as:

• Keyboard input
• Pointer input (mouse, touch, stylus, trackpad)
• Assistive technologies that emulate keyboard or pointer input (for example, speech input or switch devices)

Users may use one modality, multiple modalities at the same time, or switch between them during a session.

WCAG Success Criterion

2.5.6 Concurrent Input Mechanisms (Level AAA)

Web content does not restrict the 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

This is a Level AAA success criterion and is not required for Level A or AA conformance.

Intent of the Success Criterion

This success criterion intends to ensure that users can use and switch between input modalities at any time while interacting with content.

Content must not assume that:

• The first input modality used is the only one the user will use, or
• Users will continue using the same input modality for the entire session

If multiple input modalities are available on the platform, users must be free to use them without losing access or functionality.

What It Means to Restrict Input Modalities

Content restricts input modalities when it prevents users from switching input methods or ignores certain inputs once another has been detected.

Common examples include:

• Disabling keyboard input after mouse interaction
• Cancelling pointer events once keyboard focus is established
• Ignoring input from a newly connected device
• Requiring a page reload to switch input methods

If a user can perform an action with one modality but not another, and no valid exception applies, the content fails WCAG 2.5.6.

How This Criterion Is Commonly Broken

In practice, failures are rarely intentional. They usually occur in custom components that manage their own input handling.

Common causes include:

• Event handling that listens only to mousedown but not keydown
• Widgets that reset or remove focus after pointer interaction
• Games or canvas-based apps bound to a single input event type
• Logic that disables one modality after detecting another

These patterns unintentionally lock users into one input modality.

Valid Exceptions

Essential

Restricting input modalities is allowed when it is essential to the activity.

Example:

• A typing tutor that measures keyboard speed must restrict interaction to keyboard input

Security

Restrictions are allowed only when strictly necessary to protect content security.

Example:

• Limiting certain forms of automated input in an authentication flow, provided that assistive technologies are not blocked

Security restrictions must be narrowly applied and must not prevent legitimate assistive technology use.

Respecting User Settings

Restrictions are allowed when they respect explicit user preferences.

Example:

• Honouring an operating system setting that disables touch input

Relationship to Other WCAG Criteria

This criterion complements, but is not satisfied by, the following:

• 2.1.1 Keyboard — ensures keyboard access exists
• 2.5.1 Pointer Gestures — ensures simple pointer alternatives
• 2.5.4 Motion Actuation — ensures motion input is optional

Passing these does not guarantee conformance with 2.5.6.
Content must still support concurrent and switchable input modalities.

Common Failures of SC 2.5.6

Locking interaction to a single modality
Keyboard input stops working after mouse use.

Ignoring newly connected devices
A keyboard, mouse, or touch display added mid-session does not work.

Focus loss when switching modalities
Switching from pointer to keyboard breaks navigation or state.

Restart required to change input
Users must reload the page to use a different modality.

Common Misinterpretations

• Assuming keyboard support alone is sufficient
• Treating the first detected input modality as the user preference
• Blocking “simulated” input without considering assistive technologies
• Resetting focus on pointer interaction without restoring keyboard access

Examples That Pass

• A user opens a menu with a mouse and navigates items using the arrow keys.
• A touch-enabled laptop supports keyboard, trackpad, and touch input simultaneously.
• A user switches from speech input to mouse interaction without interruption.
• A secondary input device connected mid-session works immediately.

Developer Checklist

• Can the same component be operated with keyboard and pointer input?
• Does switching input modalities mid-interaction preserve focus and state?
• Do newly connected input devices work without a reload?
• Are any input restrictions truly essential or security-driven?
• Do assistive technologies continue to function across modality changes?

Benefits

This success criterion benefits:

• Users with motor impairments who alternate input methods
• Assistive technology users who rely on multiple modalities
• Users experiencing fatigue or pain
• Users working across different devices or environments

Allowing concurrent input modalities prevents unnecessary loss of access when conditions change.

Wrapping Up

WCAG 2.5.6 ensures that users are not locked into a single way of interacting with content. Where multiple input modalities are available on a platform, content must allow users to use and switch between them freely, unless a narrow and valid exception applies.

Most failures occur accidentally in custom components. Designing input handling that remains flexible, modality-agnostic, and focus-safe is key to meeting this criterion.