WCAG 2.5.1 Pointer Gestures

What it asks

Touch screens brought in gestures: pinch to zoom, swipe to move between slides, two-finger rotate, draw a shape to unlock. They are quick for people who can make them. Many people cannot. A pinch needs two fingers moving at once. A swipe needs a steady motion in one direction. Someone using one finger, a stylus, a head pointer or a mouth stick may be able to tap exactly where they want and nothing more.

The rule covers two kinds of gesture. Multipoint gestures use more than one point of contact: a pinch, a two-finger scroll, a three-finger tap. Path-based gestures depend on the route the pointer takes, not just where it starts and ends: a swipe, a flick, tracing a pattern. For any function that uses either, the same function must be available with a single pointer and no path, such as a tap, a double tap, a click or a long press.

The one exception is a gesture that is essential. Drawing a signature is the usual example: the path is the point. The W3C notes that most gestures are not essential, because the result could be reached another way. Pinch to zoom is not essential when plus and minus buttons would do.

It does not require that gestures be removed. It asks for an alternative beside them. And it does not cover gestures the browser or operating system provides, only ones the page itself handles. It is close to 2.5.7 Dragging Movements, which covers dragging, where only the start and end points matter.

Its official name is success criterion 2.5.1 Pointer Gestures, at Level A. It was added in WCAG 2.2, under guideline 2.5 Input Modalities and the principle Operable. The W3C’s normative text says, in part:

“All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.”

From WCAG 2.2, W3C. Full explanation: Understanding 2.5.1 Pointer Gestures.

Who it helps

People with motor disabilities that affect fine control, who can tap but cannot pinch, swipe or trace a shape. People using a single finger, a stylus, a head pointer, a mouth stick or a prosthesis. People using devices and assistive technology that only produce single taps and clicks.

What passes and what fails

These pass

• A carousel that swipes between slides and also has "Previous" and "Next" buttons.
• A map that zooms with a pinch and also with plus and minus buttons.
• An image viewer that rotates with a two-finger gesture and also has a "Rotate" button.
• A list where swiping an item reveals "Delete", and a long press or an overflow menu on the item offers the same.
• A signature pad that only accepts a drawn signature, because the path is essential to it.

These fail

• A swipe-only carousel with no buttons to move between slides.
• A map that can only be zoomed by pinching.
• A pattern that must be traced to unlock, with no typed alternative and no essential reason.
• A swipe-to-dismiss notification with no close button.
• A chart that can only be panned by dragging across it with two fingers.

How to test it by hand

1. On a touch device, or with the browser’s touch emulation, list every function that responds to a pinch, swipe, rotate, flick or traced pattern.
2. For each one, try to reach the same result with a single tap, double tap, click or long press, and nothing else.
3. Check that the alternative gives the same result. "Next" and "Previous" buttons must reach every slide a swipe would.
4. Make sure the alternative is visible or easy to find, not hidden in a way that only a gesture reveals.
5. For any function with no alternative, ask whether the gesture is genuinely essential. Most are not.

What automated testing can decide

What a machine can decide

Automated testing can find the parts of a page that handle touch or pointer gestures and present them as the places to check. That gives a reviewer a list rather than a blank page, and on a page with none of them, evidence that the criterion does not apply.

What it cannot

Knowing that an element handles touch does not say which gesture it handles, or whether a button beside it does the same job. Whether an alternative exists, whether it reaches every result the gesture can, and whether the gesture is essential all need someone to try the page. A tool cannot prove that no alternative exists.

How Dreven handles it

Dreven finds the parts of your pages that respond to multi-touch or path-based gestures and shows you each one, with the element, the page and a picture of it. A reviewer decides whether a single-pointer alternative exists and whether the gesture is essential.

On a page with none, the report records that the criterion did not apply and why.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 2.5.7 Dragging Movements (Level AA). Dragging, where only the start and end points matter, needs a single-pointer alternative too.
• 2.5.2 Pointer Cancellation (Level A). Single-pointer actions should complete on release, so a slip can be cancelled.
• 2.1.1 Keyboard (Level A). Everything must also work from a keyboard, which is a separate requirement.
• 2.5.8 Target Size (Minimum) (Level AA). The buttons offered as an alternative need to be large enough to press.

Questions people ask

All WCAG 2.2 criteria, in plain words