2.5.1 Pointer Gestures

What this rule means

WCAG 2.5.1 requires that any functionality relying on multipoint gestures (such as two-finger pinch-to-zoom) or path-based gestures (such as swiping or drawing a shape) must also be operable through a single-pointer action without requiring a specific path. A simple click, tap, or long press must be available as an alternative.

This criterion does not forbid the use of complex gestures. It simply mandates that a single-pointer alternative exists. For example, a map that supports pinch-to-zoom must also provide on-screen zoom buttons. A carousel that responds to swipe gestures must also include previous/next arrow buttons.

Why it matters

Users with motor impairments may operate a pointer through a head-tracking device, eye-tracking system, or a single-switch scanning device — none of which can perform multipoint or path-based gestures. Users with limb differences, tremors, or limited dexterity may only be able to produce a simple tap or click.

Even users without disabilities benefit from single-pointer alternatives. A user holding a phone in one hand on public transit cannot easily perform a two-finger gesture. Providing alternatives ensures functionality is available regardless of input capabilities.

Related axe-core rules

There are no automated axe-core rules for this criterion. Verifying pointer gesture alternatives requires manual testing to confirm that single-pointer actions can achieve the same outcomes as multipoint or path-based gestures.

How to test

1. Identify all interactive features that respond to swipe, pinch, rotate, or multi-finger gestures.
2. For each gesture-driven feature, attempt to operate it using only single taps or clicks.
3. Verify that on-screen controls (buttons, sliders, +/- controls) exist as alternatives.
4. Test with assistive technology pointer emulators that can only produce single-point actions.
5. On touch devices, confirm that a single finger can achieve all outcomes without requiring a specific movement path.

How to fix

Provide on-screen control alternatives for every multipoint or path-based gesture. Below are common patterns.

Map zoom — bad practice

<!-- Only pinch-to-zoom, no single-pointer alternative -->
<div id="map"
  ontouchstart="handlePinchStart(event)"
  ontouchmove="handlePinchMove(event)">
</div>

Map zoom — good practice

<div id="map">
  <!-- Pinch-to-zoom still works for those who can use it -->
</div>
<div class="map-controls">
  <button onclick="zoomIn()" aria-label="Zoom in">+</button>
  <button onclick="zoomOut()" aria-label="Zoom out">−</button>
</div>

Carousel swipe — providing button alternatives

// Touch swipe handler still available
carousel.addEventListener('pointerdown', startSwipe);
carousel.addEventListener('pointermove', trackSwipe);
carousel.addEventListener('pointerup', endSwipe);

// Single-pointer alternatives via buttons
prevBtn.addEventListener('click', () => carousel.goToPrev());
nextBtn.addEventListener('click', () => carousel.goToNext());

Common mistakes

• Relying solely on swipe gestures for carousel or slider navigation without providing arrow buttons.
• Implementing pinch-to-zoom on custom map or image components without zoom in/out buttons.
• Using multi-finger gestures (three-finger tap, two-finger rotate) as the only way to trigger an action.
• Providing path-based gesture shortcuts (draw an L shape to go back) without a simpler alternative like a back button.
• Assuming all users can perform swipe-to-delete or swipe-to-reveal actions on list items without an alternative menu.