2.5.1 Pointer Gestures

WCAG 2.2 · 2.5.1 A Operable

What it requires

Any functionality that uses a multipoint gesture (two or more fingers, such as pinch-to-zoom or a two-finger rotate) or a path-based gesture (where the path you trace matters, such as a swipe, a drag along a slider, or drawing a shape) must also be operable with a single pointer without a path-based gesture — a single tap, click, double-tap, long press, or press-and-release.

The criterion does not forbid complex gestures; it requires that an equivalent simple alternative exists. The exception is when the gesture is essential — for example, a signature field or a free-hand drawing tool where the path itself is the point.

  • People with motor or dexterity disabilities who cannot accurately perform pinch, rotate, or precise swipe gestures.
  • People using a head pointer, mouth stick, eye-tracker, or single switch, which emulate one pointer and cannot produce multi-finger input.
  • People with tremor who can tap but cannot trace a controlled path.
  • Anyone using an alternative input device (e.g. a mouse on a touch UI) that has no equivalent for a touch-only gesture.

How to detect it

Concrete checks for Pointer Gestures
Check What to look for
Manual / functional Inventory every swipe, pinch, rotate, drag, and multi-finger interaction (carousels, sliders, maps, image zoom). Confirm each can be done with a single tap or click instead.
Single-pointer test Operate the whole UI with one finger or a mouse only — no path, no second finger. Anything that becomes unreachable fails.
Keyboard / AT Not a keyboard criterion, but switch and pointer-emulation users are the target; verify equivalents work for single-pointer assistive tech.
Automated tools Tools like axe cannot reliably detect this — gestures are behavioural. It almost always needs manual review.

How to fix it

  1. List every interaction that relies on a multipoint or path-based gesture.
  2. For each, add a single-pointer alternative: tap targets, Prev/Next buttons for swipe carousels, +/− buttons for pinch-zoom, or clickable steps for a drag slider.
  3. Make the alternative a real control (a focusable <button>), not a decorative element, so it is operable by name and role.
  4. Only skip the alternative where the gesture is genuinely essential (e.g. a signature pad).
  5. Retest with one pointer only to confirm nothing is gesture-locked.

Example — a swipe-only carousel given equivalent single-tap controls:

<div class="carousel" data-swipe>
  <!-- swipe still works, but is no longer the only way -->
  <button type="button" aria-label="Previous slide"></button>
  <button type="button" aria-label="Next slide"></button>
</div>

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule that can confirm WCAG 2.5.1. Multipoint and path-based gestures depend on what an interaction actually requires, so this criterion needs manual review using the console check and steps below.

Run this in the browser console

console — find gesture-driven elements 
// Read-only: surfaces likely path/multipoint gesture targets for manual review.
const suspects = [...document.querySelectorAll(
  '[ontouchmove],[onpointermove],[ongesturechange],[draggable="true"],' +
  '[class*="swipe" i],[class*="slider" i],[class*="carousel" i],[class*="pinch" i],[class*="rotate" i],[class*="drag" i],[role="slider"]'
)];
console.log('Possible gesture targets:', suspects.length);
console.table(suspects.map(el => ({ tag: el.tagName, cls: el.className, role: el.getAttribute('role') })));
suspects.forEach(el => el.style.outline = '2px solid magenta');

What to check manually: For each highlighted control, confirm any swipe, pinch, rotate or drag can also be operated with a single-point action (a tap or click on a visible button). No script can tell whether a path-based gesture is genuinely the only way to perform the function.