2.5.1 Pointer Gestures
- Level A
- Operable
- Since WCAG 2.1
Summary
Complex gestures exclude a lot of people. Pinching needs two coordinated fingers; a swipe or drawn gesture needs a steady, continuous movement along a route. Users with tremors, limited dexterity, or missing digits, and anyone operating a device with a head pointer, mouth stick, eye-gaze system, or a single stylus, can often manage a tap but not a pinch or a traced path. This criterion, introduced in WCAG 2.1 at Level A, requires that anything operated by a multipoint gesture (two or more contact points, such as pinch or two-finger rotate) or a path-based gesture (one where the journey matters, not just the start and end points) can also be operated with a single pointer performing no path-based gesture.
The auditor's mental model has three steps. First, inventory every gesture the content itself implements: pinch to zoom, two-finger rotate, swipes, drawn shapes. Second, classify each one: multipoint, path-based, or neither (a tap, double tap, or long press involves no route and no second finger, so it is not caught by this criterion and can itself serve as the alternative). Third, for every caught gesture, hunt for a single-pointer alternative in the content: zoom buttons for a pinch, next and previous controls for a swipe, a rotate button for a two-finger twist. Only an essential gesture (one whose path is the point, such as freehand drawing) escapes the requirement.
Official wording
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.
EN 301 549 mapping
- Web pages
- Clause 9.2.5.1
- Software and native apps
- Clause 11.2.5.1 (via Table 11.8)
Clause 9.2.5.1 applies this criterion to web pages unchanged. For software, clause 11.2.5.1 carries the requirement through a word-substitution table (Table 11.8) that restates it for application user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Test with a mouse and single clicks only, then confirm on a real touch device, because desktop emulation hides multitouch behaviour. For every piece of gesture-driven functionality, ask whether a sequence of single taps or clicks achieves the same result. Embedded maps and image viewers are the classic case: author-implemented pinch to zoom needs visible plus and minus buttons (or stepped double-tap zoom); browser-level pinch zoom of the whole page is user agent behaviour and out of scope.
Carousels deserve honest handling. A plain swipe between slides feels simple, but W3C's guidance treats direction-dependent swipes as path-based: the gesture only works because the pointer travels a route in a particular direction, so endpoints alone do not describe it. A swipe-only carousel therefore fails unless visible next and previous controls (or dot navigation that responds to single taps) do the same job. The same logic applies to swipe-to-dismiss banners and swipe-based tab strips.
Also check custom gesture recognisers in JavaScript: drawn-symbol shortcuts ("draw a Z to undo"), pull-down gestures implemented by the page rather than the browser, and canvas widgets that interpret pointer trails. Watch pointer event handlers in devtools if you are unsure whether the page or the browser owns a gesture. Remember the alternative must itself be single-pointer: keyboard shortcuts alone do not satisfy this criterion.
iOS
The European standard carries this criterion into native software through a word-substitution table that restates it for application user interfaces, so app screens are graded to the same requirement as web pages.
Work through each screen performing only single taps, double taps, and long presses. The high-frequency iOS failure spots are pinch to zoom in map views and photo or document viewers without on-screen zoom buttons or stepped double-tap zoom, and two-finger gestures in drawing, annotation, and photo-editing apps (two-finger rotate to rotate a crop, two-finger tap to undo) without equivalent buttons. Use Accessibility Inspector or the Xcode view debugger to confirm whether an alternative control exists but is hidden or off-screen, which does not count as an available alternative if a single-pointer user cannot reach it.
Do not credit AssistiveTouch or other OS-level accessibility features as the alternative: WCAG places the obligation on the content, and the app itself must offer the single-pointer route. Standard platform behaviours help in places (a UITableView swipe action usually has an Edit-mode or long-press equivalent), but verify the equivalent actually exists on each screen rather than assuming it.
Android
The same word-substitution rule in the European standard applies, so Android apps are graded identically. The failure spots mirror iOS: pinch to zoom in maps, image viewers, and PDF views without zoom buttons, and multi-finger gestures in creative or editing tools without button equivalents.
Android adds a system-gesture collision problem. Gesture navigation reserves edge swipes for back, and TalkBack remaps most touch gestures entirely, so in-app swipes near screen edges can become unreliable or unreachable. This is a practical reason the single-pointer alternative matters: with TalkBack running or gesture navigation enabled, the swipe may simply never fire. Test gesture-driven features with gesture navigation on, and again with TalkBack running, and check that button alternatives exist and remain operable in both states. Layout Inspector or "Show layout bounds" in developer options helps confirm whether an alternative control is genuinely present on the screen. As on iOS, platform accessibility services do not substitute for the app providing its own alternative.
Pass and fail examples
Passes:
- An embedded map with pinch to zoom that also offers plus and minus buttons: every zoom level is reachable with single taps.
- A photo viewer where double tap zooms in steps and a long press opens a zoom menu: double tap and long press are neither multipoint nor path-based, so they are valid alternatives to the pinch.
- A carousel that supports swiping but also shows tappable next and previous arrows and slide dots.
- A photo editor with two-finger rotate that also provides rotate-left and rotate-right buttons.
- A freehand drawing canvas in a sketching app: the drawn path is the functionality itself, so the gesture is essential.
Fails:
- A map that can only be zoomed by pinching, with no buttons and no stepped double-tap zoom.
- A carousel operable only by swiping: the swipe depends on the direction of travel, which W3C guidance treats as path-based, and no single-pointer alternative exists.
- An image gallery where two-finger rotate is the only way to rotate a picture.
- An app-implemented swipe-to-reveal action on list rows with no long-press menu, edit mode, or visible buttons offering the same actions.
- A "draw a shape to unlock" custom gesture with no tappable alternative, where the drawn shape is a shortcut rather than the purpose of the feature.
Not a fail under this criterion:
- A straight drag of a list item from one position to another: dragging is graded under 2.5.7 Dragging Movements, because only the start and end points matter, not the route.
- A control that activates the moment the finger touches down, with no way to abort: that is a pointer cancellation finding under 2.5.2.
- Swipe-scrolling a page or list: scrolling is user agent or platform behaviour, out of scope here.
- A gesture-driven feature that cannot be reached by keyboard: file that under SC 2.1.1 Keyboard; this criterion is about pointer alternatives, not keyboard access.
Commonly confused with
- Dragging Movements, SC 2.5.7. The cleanest split: dragging cares about endpoints, path-based gestures care about the route. A straight drag to reorder a list is 2.5.7; a drawn shape or direction-dependent swipe is 2.5.1. The two overlap on many components (sliders, reorder handles, map surfaces), and a single interaction can raise both questions, so classify by what the gesture actually depends on before filing.
- Pointer Cancellation, SC 2.5.2. 2.5.1 asks whether a complex gesture has a simple alternative; 2.5.2 asks whether an accidental pointer press can be aborted or undone. "It fired when I brushed the screen" is a 2.5.2 finding even on a plain button that 2.5.1 never touches.
- Keyboard, SC 2.1.1. Keyboard support does not satisfy either pointer criterion: the alternative to a gesture must itself be operable with a single pointer. A map with arrow-key panning and keyboard zoom but no on-screen buttons still fails 2.5.1, and a missing keyboard route is a separate 2.1.1 finding.
- Motion Actuation, SC 2.5.4. Shake to undo and tilt to scroll are device-motion inputs, not pointer gestures. They need alternatives too, but the finding files under 2.5.4, not here.
How AUDITSU tests this
AUDITSU's audit walkthrough covers pointer gestures screen by screen. For each screen you review, the walkthrough asks you to list the gesture-driven functionality (pinches, rotations, swipes, drawn gestures), classify each gesture, and then attempt the same outcome using only single taps, double taps, and long presses on controls the screen itself provides. Each question records a pass, fail, or not applicable result per screen with your evidence attached, so a swipe-only carousel or button-less pinch zoom lands in the report tied to the exact screen where you found it.
For native app audits, the walkthrough applies the same questions because the European standard restates this criterion for application user interfaces; where TalkBack or VoiceOver is running for other checks, the walkthrough prompts you to confirm the single-pointer alternatives remain operable. Essential-gesture claims (signature fields, drawing canvases) are recorded with a justification so the exception is auditable rather than assumed.
For the full guided workflow, see the audit platform.