Pointer Gestures
Anything a multipoint or path-based gesture does has to be reachable with a single pointer that does not depend on the path, unless the gesture is genuinely essential. Multipoint means two pointers at once, such as a pinch, a two-finger swipe, or a split tap where one finger rests and another taps. Path-based means the route matters, which covers flicking, tracing a shape, and any control expecting you to follow a line. Signing your name is the standard's example of essential, because a signature is the path. The alternative can be a tap, a click, a double tap, a long press or a click and hold, so it does not have to be a button. It cannot be a drag, since that would fail 2.5.7 instead. And most sliders are not in this rule at all, because almost every slider keeps your grip when you drift off the track, which makes it a dragging movement under 2.5.7.
Why it matters
The obvious reason is dexterity. A pinch assumes two fingers that cooperate, a flick assumes a straight fast line, and a head pointer, an eye-gaze system, a prosthetic hand or one working thumb delivers neither reliably. The less obvious reason is stronger. On a touchscreen with a platform screen reader running, your gesture usually never arrives at all. The screen reader consumes path-based gestures before the page sees them, so a horizontal swipe over your carousel moves the screen reader's cursor instead of moving the carousel. Pass-through gestures exist and depend on the hardware, the operating system, its settings and the browser, which is another way of saying they cannot be relied on. So the single-tap alternative is not a courtesy for people who find swiping hard. Without it, a screen reader user on a phone cannot reach the function at all.
Who this rule protects
This affects people with limited dexterity or tremors, people using a head pointer, eye-gaze system, prosthetic or speech-controlled mouse emulator, people working one-handed, screen-reader users on touchscreens whose own software eats the gesture before the page sees it, and people with cognitive or learning disabilities who can fall back on a plain tap where a custom gesture makes no sense to them.
How to check it yourself
- List every gesture the interface answers to, including carousel swipes, pinch zoom on images and maps, two-finger rotation, and swipe actions on list rows.
- Search the code for touchstart and touchend handlers. That finds the gestures nobody documented.
- Try each one with single taps only, the way a head-pointer user has to. A tap, a double tap, a long press or a click and hold all count as the alternative.
- For swipe-to-reveal rows, the test is not whether a button is visible. It is whether every option the swipe reaches is also reachable after opening the row with a single tap.
- Check the alternative is not itself a drag. Replacing a pinch with a drag moves the failure to 2.5.7 rather than fixing it.
Failures we see most often
- An image gallery that advances only on a swipe, with no controls of any kind.
- A map that zooms only on a pinch, with no plus and minus buttons.
- Swipe-to-reveal row actions where swiping left offers Archive and swiping right offers Delete, and opening the row with a tap offers neither.
- A shortcut that fires when the user draws a shape, such as tracing a Z to undo, with no other route to the same action.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Blind and screen reader userspeople who cannot see the screen
- Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
- Voice controlpeople who operate the page by speaking to it
- Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it
How to fix it
- Pair every gesture with a control that does the same job in one tap. The controls can sit over or beside the component, and they can even be visually hidden as long as a pointer can still operate them, which keeps a photo gallery clean.
- For a slider that does enforce its track, make the track itself clickable. Tapping a point on the track sets the value, and that one change satisfies this rule.
- Build sliders on the native range input underneath your styling. Custom controls built on native ones stay operable with the screen reader's own gestures, and controls rebuilt from divs do not.
- Treat every gesture as a shortcut for the people who like it, never as the only route to a result.
Step-by-step fix guides (3)
Passes vs. fails
Passes
Previous and Next buttons sit beside the gallery, swiping still works for anyone who wants it, and a screen reader user can reach both.
Fails
Product photos change only when somebody swipes, so a head-pointer user is looking at the first photo and will keep looking at it.
In audits and lawsuits
No automated rule exists for this criterion, and the fastest first pass over an unfamiliar codebase is a search for touchstart and touchend handlers, which W3C names as the way to find gestures nobody remembers building. Two boundaries save arguments. Gestures the browser or the operating system provides are outside the rule, so the back-swipe and the notification pull-down are not yours to fix. And keyboard support does not satisfy this rule, however good it is, because the people it protects are often on a touchscreen with no keyboard within reach. This is not a phone-only rule either. It scopes to any pointer, so a swipe-driven carousel on a laptop trackpad sits inside it too.