WCAG 2.5.1 — Pointer Gestures

What this requires

All functionality using multipoint or path-based gestures must also be operable with a single pointer without a path-based gesture, unless the multipoint or path-based gesture is essential. "Multipoint" means more than one finger; "path-based" means a swipe, drag, or stroke where the path itself carries meaning. There must be a single-tap or single-click alternative.

How AI coding tools fail this

When asked to "add swipe gestures to the gallery" or "pinch to zoom the map", AI tools wire up the gesture handlers and consider the input complete. Users on assistive pointing devices (head tracker, switch input, single-finger touch) can't perform the gesture and have no alternate path.

The second pattern: carousels with swipe-only navigation. The component listens for touchmove and pointermove deltas but ships no buttons for previous/next. The visual affordance — the chevrons — sometimes exists; the controls behind them often don't.

The third: drag-to-sort lists with no keyboard or click-based alternative. The user can rearrange with a mouse drag and nothing else.

Failing examples

A carousel that only responds to swipe:

<div onTouchStart={...} onTouchEnd={swipeToNext}>
  {currentSlide}
</div>

A drag-to-sort list with no alternative:

<DraggableList items={items} onReorder={save} />

Passing examples

Carousel with explicit buttons and ARIA wiring:

<div role="region" aria-label="Gallery" aria-roledescription="carousel">
  <button onClick={prev} aria-label="Previous slide">
    <ChevronLeft aria-hidden="true" />
  </button>
  <div onTouchStart={...} onTouchEnd={swipeToNext}>
    {currentSlide}
  </div>
  <button onClick={next} aria-label="Next slide">
    <ChevronRight aria-hidden="true" />
  </button>
</div>

Drag-to-sort with a keyboard alternative — dnd-kit, react-aria, and react-beautiful-dnd all provide keyboard handlers:

<DraggableList
  items={items}
  onReorder={save}
  keyboardShortcuts={{
    moveUp: "ArrowUp",
    moveDown: "ArrowDown",
    pickUp: "Space",
    drop: "Space",
  }}
/>

Edge cases

Essential gestures. A piano-keyboard app, a drawing canvas, a pinch-zoom map where the pinch is the point — these may meet the criterion only through the gesture. The exemption is narrow.
onClick already covers single-pointer alternatives. The failure is usually omitting the click handler, not the gesture itself.
Touch and pointer events are not interchangeable with keyboard. See 2.1.1 for the keyboard requirement.
Swipe-to-dismiss patterns (a toast that swipes away) need a close button alongside the gesture.
Long-press is a path-based gesture (the path being "stay still") — it falls under this criterion. Provide a single-tap alternative.

How Jeikin handles this

This is a manual review item. The scanner flags components with gesture handlers (onTouchMove, onPointerMove, drag setups) and asks the reviewer to confirm a single-pointer alternative exists. The dashboard tracks the alternative path per gesture.

References

W3C — Understanding 2.5.1 Pointer Gestures (opens in new tab)