Skip to main content
WCAGrules
Quick navigation

Glossary · Accessibility term

Pointer gesture

A pointer gesture is a touch or mouse action where the path your finger takes matters, or where more than one finger is on the screen at once. Swiping, tracing a shape, pinching to zoom, a two-finger rotate. Rule 2.5.1 asks at Level A that the same job can be done with a single pointer and no path, and W3C names six ways of doing it. A tap, a click, a double tap, a double click, a long press, or a click and hold. So the fix is usually smaller than people fear. One finger is not an escape either, because a single-finger swipe is a single pointer interaction and a path-based gesture at the same time. What the rule does not reach is the software around your content. Gestures the operating system, the browser or a screen reader needs are not yours to replace.

In practice

Two kinds are covered and telling them apart decides which rule you are looking at. Path-based, where the route matters, which is swiping, flicking, or tracing a shape. And multipoint, where two or more pointers are down together, which is pinch to zoom, a two-finger rotate, or a split tap where one finger rests while another taps. Speed can be part of it too, since a flick is only recognised above a certain pace, so a gesture can fail for somebody who moves slowly.

Dragging is the one that gets filed wrong. A drag picks something up and puts it down, and where only the start and end points matter it is not a path-based gesture, so 2.5.1 does not reach it. Most sliders work that way, because once you have grabbed the thumb you can drift off the track and keep hold of it. Test yours before you file it, because a slider that drops the thumb the moment your finger leaves the track has made the path matter and is back inside 2.5.1. The ordinary kind belongs to rule 2.5.7 instead, at Level AA. Filing a slider under 2.5.1 records a Level AA finding at Level A, and it also means the alternative you build cannot be another drag.

The answer nobody wants is that keyboard support does not settle it. W3C says so directly, because some people rely on a pointer entirely. Somebody using a head pointer would far rather click a labelled control than call up an on-screen keyboard to fake a shortcut. The exception is narrower than it sounds as well. Capturing a handwritten signature is inherently path-based. Acknowledging something, or confirming who you are, is not, so the flow around the signature usually has a conforming alternative even where the signature itself does not.

Why it matters

Somebody using a head pointer, an eye-gaze system or a speech-controlled mouse cannot perform a two-finger gesture at all. A carousel that only advances on a swipe is a carousel they cannot advance, and a map that only zooms on a pinch is a map they cannot read. The benefit W3C names that nobody expects is cognitive. A person who never learned your custom gesture is served by the same visible button as a person who physically cannot make it. That is a better argument for the button than the accessibility one. W3C publishes no test rule mapped to this criterion either, so nothing arrives on a dashboard and somebody has to go and try the gesture.

Which rule the slider belongs to

A carousel that only advances on a swipe fails 2.5.1, because a swipe is path-based. A slider you drag along a track almost never does, because dragging only cares where you started and where you let go. That one is 2.5.7 at Level AA, and its answer cannot be another drag.

Where this shows up on the site

Related terms

Knowing the word is the easy part.

Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.

Run the free scan

Go somewhere useful

Find tools, resources and your workspace.

29 destinations