Some web interactions rely on gestures such as swiping in a specific direction or using multiple fingers at once. These interactions can exclude users who cannot perform precise movements or who rely on alternative input methods.
In short:
If an action requires a specific movement or more than one finger, there must also be a simpler way to do it.
WCAG Success Criterion
2.5.1 Pointer Gestures (Level A)
This success criterion requires that any functionality operated using multipoint gestures or path-based gestures must also be operable using a single pointer, without requiring a specific movement path.
The requirement applies unless the multipoint or path-based gesture is essential to the functionality itself.
This is a Level A success criterion and is required for basic WCAG conformance.
Important scope note:
This criterion applies only to author-provided content that interprets pointer actions. It does not apply to gestures required to operate the operating system, browser, or assistive technologies.
What “Pointer” Means in WCAG
In WCAG, a pointer is any input that controls a cursor or touch point, including:
- A mouse
- A finger on a touchscreen
- A stylus
- A head pointer
- An eye-gaze system
- A speech-controlled pointer emulator
What “Single Pointer” Means
A single pointer means using one of these inputs at a time, without requiring multiple fingers or coordinated movements (for example, swiping in a specific direction or using two fingers at once).
Intent of the Success Criterion
The intent of this criterion is to ensure that content can be operated by users with a wide range of motor abilities and input devices.
Some users:
- Cannot perform precise or coordinated movements
- Use input methods that do not support multipoint gestures
- Rely entirely on pointing devices and find simple pointer actions easier than keyboard commands
If functionality is available via pointer input, users must be able to operate it using simple, single-pointer actions.
Understanding Path-Based and Multipoint Gestures
Path-Based Gestures
A path-based gesture is one where how the pointer moves matters, not just where it starts and ends.
If the gesture:
- Must follow a specific direction, or
- Must pass through one or more intermediate points
Then it is path-based.
Examples include:
- Swiping left or right to trigger an action
- Sliders or carousels that only respond to directional movement
- Drawing a specific shape to perform a command
If deviating from the expected path causes the gesture to fail or change meaning, it is path-based.
Multipoint Gestures
Multipoint gestures require two or more pointers at the same time.
Examples include:
- Pinch-to-zoom
- Two-finger swipe
- Split tap
- Three-finger gestures
These gestures may be impossible for users who operate devices with a single finger, stick, or alternative pointer.
Dragging vs Path-Based Gestures
Dragging involves moving an object from a start point to an end point. The exact path does not define the command.
Dragging is not considered path-based as long as the path itself does not change the meaning of the action. Only the start and end points matter.
However, dragging still requires fine motor control. This is addressed separately in WCAG 2.5.7 Dragging Movements (Level AA).
Touchscreens vs Mouse Interaction
Components may behave differently depending on the input method.
For example, a slider:
- With a mouse: Vertical movement may still adjust the slider because the pointer remains captured.
- With touch: Vertical movement may be interpreted as page scrolling unless the user moves horizontally first.
In this case, touch interaction may unintentionally require a path-based gesture even if mouse interaction does not. For this reason, components should be tested on actual touch devices, not only with a mouse.
What This Criterion Requires
- If functionality relies on multipoint or path-based gestures, a single-pointer alternative must be provided
- Keyboard access alone is not sufficient
- The alternative must be discoverable and equally functional
Gestures may still be offered, but they must not be the only way to operate the content.
Common Failures of SC 2.5.1
❌ Swipe-only carousel
A carousel advances only when swiped left or right.
This fails SC 2.5.1 because the only way to advance content is a path-based gesture.
❌ Custom slider without buttons
A value can only be changed by dragging in a strict direction.
This fails SC 2.5.1 because no single-pointer alternative is available.
❌ Canvas-based controls with gesture-only interaction
Controls rely on drawing or swiping with no alternative UI.
This fails SC 2.5.1 because gesture input is required to operate the control.
How to Fix the Problem
Provide a single-pointer alternative such as:
- Tap or click
- Double-tap or double-click
- Long press
- Click-and-hold
- Visible buttons or controls that perform the same action
The alternative must be:
- Visible or easily discoverable
- Fully equivalent in functionality
- Operable with one pointer
Hidden gestures do not count as alternatives.
Exceptions
An exception is allowed when the gesture is essential to the functionality.
Examples:
- Handwritten signatures
- Free-form drawing or sketching
In these cases, the gesture itself is the purpose of the interaction.
How to Test for Single Pointer Operation
- Try using one finger only on a touchscreen
- Try using a mouse or trackpad without multitouch
- Attempt the interaction without swiping, pinching, or multi-finger input
- Confirm that every gesture-based action has a simple alternative
If you cannot complete the task without complex gestures, the criterion is not met.
Developer Checklist
- No functionality requires two or more simultaneous pointers
- No action depends on following a specific movement path to determine the command
- Gesture-based features have visible, single-pointer alternatives
- Touch interactions are tested on real touch devices
- Alternatives are discoverable and equally functionalBenefits
This success criterion benefits:
- Users with limited motor control
- Users relying on alternative pointing devices
- Users who cannot perform multipoint gestures
- Users with cognitive or learning disabilities who may not understand custom gestures
Wrapping Up
WCAG 2.5.1 ensures that pointer-based interactions remain accessible without requiring precision, coordination, or multiple fingers. While gestures can enhance usability for some users, they must never be the only way to operate functionality unless they are essential.
By providing clear, single-pointer alternatives, authors make content more inclusive, predictable, and usable for everyone.
