Pointer Gestures

In brief

Pinching with two fingers, swiping along a path or tracing a shape are hard or impossible for many people. Someone with a tremor, someone who uses a head pointer or a stylus, or someone who has one hand free may not be able to perform them. If a function can only be done with such a gesture, it is closed to them.

This criterion requires that all functionality that uses multipoint or path-based gestures can be operated with a single pointer without a path-based gesture, unless the gesture is essential. In practice: if you offer a pinch or a swipe, also offer a button or a tap.

What does it cover?

• Multipoint gestures: Gestures that need more than one point of contact, such as a two-finger pinch or a split tap. They need a single-pointer alternative.
• Path-based gestures: Gestures where the path of the movement matters, such as a swipe in a specific direction, a flick or tracing a shape. They also need a simple alternative.
• Not path-based: A simple drag, where only the start and end points matter, is covered by 2.5.7 instead. A slider whose thumb is released when the pointer leaves the track can count as path-based.
• The alternative: A button, a tap or a menu that does the same thing (G215), for example plus and minus buttons beside a pinch-to-zoom map, or a single tap on a slider track (G216).
• Essential gestures: A gesture is exempt if it is essential, meaning that removing it would fundamentally change the function, such as entering a signature.
• Not covered: Gestures that belong to the operating system, the browser or assistive technology, such as system swipes, browser back flicks and screen reader navigation. Pinch-to-zoom that the page implements itself is covered.
• Out of scope: Dragging is 2.5.7. Keyboard access alone is not enough, and is covered by 2.1.1.

Who does it affect?

People with tremors, limited dexterity or motor disabilities who cannot make precise multi-finger or path-based gestures. People who use a head pointer, a mouth stick, a stylus, a trackball or an eye-gaze system. People who use a device one-handed or on a fixed mount.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Simple pointer operation is part of "operable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 2.5.1 by reference and turns it into separate clauses for each kind of ICT.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 2.5.1 is the same in WCAG 2.1 and 2.2.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Pinch-to-zoom with buttons

When the page implements zoom with a pinch gesture, add buttons for people who cannot pinch.

map.addEventListener("touchmove", handlePinchZoom); // pinch only

<div id="map">…</div>
<button type="button" id="zoom-in" aria-label="Zoom in">+</button>
<button type="button" id="zoom-out" aria-label="Zoom out">−</button>
<script>
zoomIn.addEventListener("click", () => map.zoomBy(1));
zoomOut.addEventListener("click", () => map.zoomBy(-1));
</script>

2. A carousel operated by swiping

A swipe is a path-based gesture. Offer previous and next buttons.

<div class="carousel" data-swipe="true">…</div>

<div class="carousel">
  <button type="button" aria-label="Previous slide">‹</button>
  <div class="slides">…</div>
  <button type="button" aria-label="Next slide">›</button>
</div>

3. Swipe to delete

Provide a visible control for the same action.

row.addEventListener("swipeleft", () => deleteItem(row));

<li>
  Invoice 0042
  <button type="button" aria-label="Delete invoice 0042">Delete</button>
</li>

4. A slider that works with a single tap

Let users set the value by tapping the track, or add a number field (G216).

<div class="slider" data-needs-drag="true"></div>

<label for="vol">Volume</label>
<input id="vol" type="range" min="0" max="100">
<input type="number" min="0" max="100" aria-label="Volume value">

5. A gesture that is a shortcut only

A gesture can stay, as long as the same function is available by single-pointer controls.

canvas.addEventListener("pointermove", detectCircleGesture); // the only way to refresh

<button type="button" id="refresh">Refresh</button>
<!-- The circle gesture remains as an optional shortcut -->

6. A signature field: the essential exception

Drawing a signature is inherently path-based, so it is exempt. Offer another way where possible, for example typing a name.

<canvas id="signature"></canvas>

<canvas id="signature" aria-label="Draw your signature"></canvas>
<label for="typed">Or type your full name</label>
<input id="typed">

Code examples for mobile

On mobile these gestures are very common: pinch, multi-finger swipes, swipe actions. For each, offer a button or a menu item, and expose the alternative to screen readers as a custom action.

iOS (SwiftUI)

import SwiftUI

struct InvoiceRow: View {
    let title: String
    var onDelete: () -> Void

    var body: some View {
        HStack {
            Text(title)
            Spacer()
            // A simple, visible alternative to the swipe action
            Button("Delete", role: .destructive, action: onDelete)
        }
        .swipeActions(edge: .trailing) {
            Button("Delete", role: .destructive, action: onDelete)
        }
        // VoiceOver users also get the action in the actions rotor
        .accessibilityAction(named: "Delete", onDelete)
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.Row
import androidx.compose.material3.Text
import androidx.compose.material3.TextButton
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.CustomAccessibilityAction
import androidx.compose.ui.semantics.customActions
import androidx.compose.ui.semantics.semantics

@Composable
fun InvoiceRow(title: String, onDelete: () -> Unit) {
    // The swipe-to-dismiss gesture can stay, but add a visible control as well
    Row(
        modifier = Modifier.semantics {
            customActions = listOf(CustomAccessibilityAction("Delete") { onDelete(); true })
        }
    ) {
        Text(title)
        TextButton(onClick = onDelete) { Text("Delete") }
    }
}

How to test

• List the gestures: Find every pinch, multi-finger tap, swipe, flick, rotation and shape in the product.
• Look for the alternative: For each one, is there a way to do the same thing with a single tap or click on a visible control?
• Try it with one finger: Use a single finger, a stylus or a mouse click. Can you finish every task?
• Check zoom and maps: Does a zoomable image or map have zoom buttons?
• Check swipe actions: Does a swipe-to-delete, swipe-to-archive or carousel swipe have a button or menu equivalent?
• Check the exceptions: Is a remaining gesture really essential, such as signing?
• Check mobile: Do VoiceOver and TalkBack users get the alternative actions?
• Use a checker as a starting point: Automated tools cannot detect gestures. A person must go through the interactions.

Common mistakes

• Pinch as the only way to zoom: Add plus and minus buttons (F105).
• Swipe as the only way to move through content: Add visible next and previous controls.
• Hidden swipe actions: A destructive action available only by swiping left.
• Two-finger gestures for core features: Many users have only one finger or pointer available.
• A slider that needs a precise drag: Allow a tap on the track or a text field.
• Keyboard support treated as enough: It is a separate criterion; pointer users still need a simple alternative.
• Calling every gesture essential: Only a gesture where removal changes the function is essential.
• Forgetting gestures you added on top of the system ones: Custom pinch and swipe handlers are covered.

Sources

• Understanding SC 2.5.1: Pointer Gestures (W3C), opens in a new tab
• G215: Providing controls to achieve the same result as path-based or multipoint gestures (W3C), opens in a new tab
• F105: Failure of Success Criterion 2.5.1 due to providing functionality via a path-based gesture without simple pointer alternative (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.