Level A

Multipoint and path-based gestures (pinch-zoom, two-finger rotate, swipe, draw-a-shape) cannot be produced by head pointers, mouth sticks, eye-gaze systems, or single switches -- shipping them without a single-pointer alternative locks those users out of the feature entirely.

2.5.1 Pointer Gestures

In Plain Language

2.5.1 Pointer Gestures (Level A, new in WCAG 2.1) says any functionality that uses a multipoint gesture (two or more simultaneous contacts, like pinch-zoom or two-finger rotate) or a path-based gesture (one where the shape of the path matters, like a swipe direction or drawing a letter) must also be operable with a single pointer that does not trace a path -- a tap, click, double-tap, long-press, or straight drag[1]. The only exception is when the gesture is essential to the activity itself, such as signature capture.

The mechanism this protects against: head pointers, mouth sticks, eye-gaze systems, and single switches emit one pointer event at a time and cannot synthesise a second simultaneous contact or a precise path. Ship a pinch-only zoom or a swipe-only carousel and those users lose the feature outright.

Why It Matters

  • Multipoint gestures require two simultaneous contacts. Pinch-zoom, two-finger rotate, and split-tap all depend on the device reporting two touches at once. Head pointers, mouth sticks, and eye-gaze systems emit a single pointer stream -- there is no second finger to add.
  • Path-based gestures require precise movement along a route. A swipe is distinguished from a tap-and-drag by the shape and direction of the path. Users with tremor, limited range of motion, or switch input cannot reliably trace a straight line, let alone a drawn shape, so the recogniser rejects the input.
  • Dragging where only the endpoints matter is still allowed as an alternative. 2.5.1 explicitly permits single-pointer dragging (start point, end point) as a single-pointer method -- it is the path requirement that makes a swipe inaccessible, not the movement itself. 2.5.7 Dragging Movements (Level AA, new in WCAG 2.2) is the companion rule that covers the remaining drag case.
  • Situational limits hit the same failure mode. A user holding a phone one-handed, wearing gloves, or working on a trackpad without multi-touch loses multipoint gestures for the same mechanical reason an eye-gaze user does -- the hardware will not produce a second simultaneous contact.

Examples

Do: Provide button controls alongside gesture-based zoom

[ Map view ]

✔ Pinch-to-zoom is available, but + and - buttons provide the same functionality with a single click.

<!-- Map supports pinch-to-zoom AND button controls -->
<div class="map-container">
  <div id="map">...</div>
  <div class="controls">
    <button aria-label="Zoom in" onclick="zoomIn()">+</button>
    <button aria-label="Zoom out" onclick="zoomOut()">-</button>
  </div>
</div>
Don't: Only pinch-to-zoom with no single-pointer alternative

[ Map view ]

Pinch to zoom

✘ Users who cannot pinch have no way to zoom the map. No button or single-click alternative is provided.

Do: Provide arrow buttons alongside swipe-based carousel
Slide 2 of 5

✔ Swiping works, but previous/next buttons let single-pointer users navigate the same content.

<!-- Carousel supports swipe AND button navigation -->
<div class="carousel">
  <button aria-label="Previous slide">&lt;</button>
  <div class="slide">Slide 2 of 5</div>
  <button aria-label="Next slide">&gt;</button>
</div>
Don't: Swipe-only carousel with no buttons
Slide 2 of 5

Swipe left or right

✘ Users who cannot swipe have no way to navigate between slides.

How to Fix It

  1. Inventory every multipoint and path-based gesture in the interface. Look for pinch-zoom, two-finger rotate, split-tap, swipe (left/right/up/down), draw-a-shape unlock, and any custom recogniser that checks the shape of a drag path. A drag where only the start and end points matter (move a tile from A to B) is not path-based and is not captured by 2.5.1 -- it is covered by 2.5.7 Dragging Movements at Level AA.
  2. Add a single-pointer control for each one. Pinch-zoom gets + and - buttons. Swipe carousels get previous/next buttons. Custom sliders get a numeric input or stepper buttons. Draw-a-shape unlock gets a PIN or password fallback. The alternative must achieve the same result, not a degraded version.
  3. Use real <button> elements. The alternatives are reachable by keyboard for free, which also satisfies 2.1.1 Keyboard. A <div onclick> fails both criteria at once.
  4. Scope the "essential" exception tightly. The exception in 2.5.1 applies only when the gesture is fundamental to the activity -- signature capture, freehand drawing in an art tool, a piano keyboard that needs chord input[1]. A map zoom, a carousel, or a volume slider is never essential, because the same output is reachable with a button or a numeric field.
  5. Test with multi-touch disabled. In desktop browser devtools, emulate a single-pointer device, or test on a trackpad with multi-touch off. Every feature that was reachable with pinch, swipe, or path gesture must still be reachable with taps, clicks, and straight drags alone.

References

  1. [1] W3C (2023). Understanding Success Criterion 2.5.1: Pointer Gestures. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures.html ↩ ↩