WCAG 2.5.1: Pointer Gestures

Who this helps

Complex gestures assume two things: fine motor control and multiple contact points. Plenty of people have neither. Someone with a tremor caused by Parkinson’s disease or cerebral palsy may be unable to trace a steady path across a screen. Someone with the use of one finger, a partial hand, or a prosthesis cannot perform a two-finger pinch at all.

The fix is always the same shape: expose the functionality through ordinary, visible controls that need only a tap or click. Those controls also tend to satisfy 2.1.1 Keyboard for free, because a real button is keyboard-operable too.

Multipoint vs. path-based gestures

The criterion covers two specific families of gesture, and the distinction matters when you audit a page:

• →Multipoint gestures use two or more contact points at once: pinch-to-zoom, two-finger rotation, a three-finger tap, a split-tap. If the gesture cannot be performed with one finger, it is multipoint.
• →Path-based gestures depend on the direction or path of movement, not just where the pointer starts and ends: swiping left to reveal a delete action, flicking through carousel slides, drawing a “Z” to trigger a shortcut, or sliding along a rating widget where the traced path is what the code evaluates.

What is not covered: plain drag-and-drop where only the start and end points matter (that is 2.5.7 Dragging Movements, Level AA), single taps and double taps, long presses, and gestures the browser or operating system handles for you, such as two-finger scrolling of the whole page.

The only escape hatch is the essential exception: when the path itself is the point of the feature. A signature capture field exists precisely to record your freehand path, so no tap-based alternative could be equivalent. Very few features genuinely qualify — if buttons could achieve the same outcome, the gesture is not essential.

Pass and fail examples

Code examples

Carousel: swipe as enhancement, buttons as baseline

The failing version wires up touch events and nothing else. The passing version keeps the swipe but drives the same function from real buttons.

<!-- ✗ Fails: swiping is the only way to change slides -->
<div id="carousel">
  <ul class="slides">…</ul>
</div>
<script>
  const el = document.getElementById("carousel");
  let startX = 0;
  el.addEventListener("touchstart", (e) => (startX = e.touches[0].clientX));
  el.addEventListener("touchend", (e) => {
    const dx = e.changedTouches[0].clientX - startX;
    if (dx < -50) nextSlide();
    if (dx > 50) prevSlide();
  });
</script>

<!-- ✓ Passes: visible buttons operate the same function with one tap -->
<div id="carousel">
  <button type="button" onclick="prevSlide()">Previous slide</button>
  <ul class="slides">…</ul>
  <button type="button" onclick="nextSlide()">Next slide</button>
  <!-- swipe listeners can stay as a convenience -->
</div>

Custom pinch-zoom with single-pointer controls (React)

If your component interprets multi-touch to zoom, add zoom buttons that change the same state. One state, two input methods.

function ZoomableImage({ src, alt }) {
  const [scale, setScale] = useState(1)

  const zoomIn = () => setScale((s) => Math.min(s + 0.25, 4))
  const zoomOut = () => setScale((s) => Math.max(s - 0.25, 1))

  return (
    <div>
      {/* ✓ Single-pointer alternative to the pinch gesture */}
      <div role="group" aria-label="Zoom controls">
        <button type="button" onClick={zoomOut}>Zoom out</button>
        <button type="button" onClick={zoomIn}>Zoom in</button>
      </div>

      {/* Pinch handling updates the same scale state */}
      <div onTouchMove={handlePinch /* optional enhancement */}>
        <img src={src} alt={alt} style={{ transform: "scale(" + scale + ")" }} />
      </div>
    </div>
  )
}

Swipe-to-reveal actions with an always-available menu

List items that reveal actions on swipe should expose the same actions through a tappable control on each row.

<!-- ✓ Every swipe action is also a plain button -->
<li class="message-row">
  <span class="subject">Quarterly report</span>
  <button type="button" aria-haspopup="menu" aria-expanded="false"
          onclick="toggleRowMenu(this)">
    Actions for “Quarterly report”
  </button>
  <div role="menu" hidden>
    <button role="menuitem" type="button" onclick="archiveMessage()">Archive</button>
    <button role="menuitem" type="button" onclick="deleteMessage()">Delete</button>
  </div>
</li>

Common failures

• ✗Carousels, image galleries, or story viewers that advance only on swipe, with no previous/next buttons.
• ✗Custom pinch-to-zoom on images, charts, or maps with no zoom in/out buttons or equivalent single-tap control.
• ✗Swipe-to-delete or swipe-to-archive list rows with no visible button or menu offering the same actions.
• ✗Gesture shortcuts — drawing a letter or shape to trigger a command — with no discoverable button or menu equivalent.
• ✗Pull-to-refresh as the only way to reload content in a web app, with no refresh button.
• ✗Custom sliders or scrubbers whose value can only be set by tracing along the track, with no tap-to-set, stepper buttons, or text input.
• ✗Providing an alternative that itself requires a path-based gesture — e.g. replacing a two-finger rotate with a one-finger circular drag still fails; the alternative must be tap/click based.

How to test for 2.5.1

1. 1

   Inventory every gesture the page implements

   On a touch device (or emulator), work through the page and note every interaction that responds to swiping, pinching, rotating, multi-finger taps, or drawn shapes. Check JavaScript for touchstart/touchmove, pointermove, and gesture libraries (Hammer.js, use-gesture) to catch handlers you might miss by hand.

2. 2

   Attempt each function with a single tap or click

   For every gesture found, try to achieve the same outcome using only single taps or clicks on visible controls. Advance the carousel, zoom the map, reveal the row actions. If any function has no tap/click route, it fails.

3. 3

   Verify the alternative is not itself path-based

   The alternative must work without tracing a path. A control you must drag along a track is not a valid alternative — look for tap-to-activate buttons, steppers, or inputs.

4. 4

   Test with a mouse on desktop

   A quick proxy: if the feature cannot be operated with ordinary mouse clicks (no click-drag paths, no wheel-only interactions), single-pointer users on touch devices are probably locked out too.

5. 5

   Evaluate any claimed 'essential' exceptions

   For each gesture with no alternative, ask whether the path itself is the purpose (signature, freehand drawing). If buttons could achieve the same end result, the exception does not apply. Automated scanners cannot detect 2.5.1 failures — this is a manual test.

Work through the full WCAG 2.2 checklist to cover the neighbouring input-modality criteria at the same time — gestures, cancellation, and motion usually travel together.

Frequently asked questions