Don’t Require Dragging: WCAG 2.2’s Single-Pointer Rule for Sliders, Carousels, and Reorderable Lists

Quick answer: WCAG 2.2’s SC 2.5.7 Dragging Movements (Level AA) requires that any functionality operated by a dragging movement can also be operated with a single tap or click — no dragging required — unless dragging is essential to the task. The W3C’s own named examples are a price-style range slider (click anywhere on the track instead of dragging the thumb) and a draggable content carousel (forward/back buttons instead of swiping items into view). Both are near-universal e-commerce patterns, and both commonly ship with no non-drag alternative at all.

This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.2 Level AA requires and how to meet it, not whether a specific site carries legal risk.

SC 2.5.7 Dragging Movements (Level AA), in the W3C’s own words

The Understanding doc states the criterion directly:

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

The doc breaks a drag interaction into four discrete steps: tap to establish a start point, press and hold, reposition, then release. Its stated intent is that “not all users can accurately press and hold that contact while also repositioning the pointer” — people using a trackball, head pointer, eye-gaze system, or speech-controlled mouse emulator, along with anyone who can’t perform that sequence with precision. The fix isn’t “make dragging easier” — it’s “provide an equivalent that doesn’t require dragging at all.”

Two exceptions:

1. Essential — removing the drag requirement would fundamentally change the functionality, using WCAG’s general definition of “essential.” The doc doesn’t give a dedicated e-commerce example for this one — a freehand-drawing or signature-capture tool, where the dragged path itself is the point, is the kind of case it’s meant to cover.
2. User-agent-determined — native browser/OS behavior. The doc is explicit that this criterion “does not apply to scrolling and dragging gestures enabled by the user agent” — ordinary page scrolling or a touchscreen’s native “drag to refresh” are the browser’s responsibility, not the content’s, unless a site suppresses native scrolling and implements its own drag-driven scroll mechanism, at which point “the scrolling/dragging gesture is interpreted and processed by the content itself,” and the criterion applies again.

One thing worth flagging: this criterion is evaluated independently from keyboard accessibility (SC 2.1.1/2.1.3). Arrow-key support for a slider doesn’t automatically satisfy SC 2.5.7 — the doc is explicit that “achieving keyboard equivalence for a dragging operation does not automatically meet this success criterion, unless that equivalent keyboard operation also provides controls that can be clicked or tapped with a pointer.” A slider that’s keyboard-operable but still requires dragging for a mouse or touchscreen user still fails this SC.

Price-range sliders: the W3C’s own named example

The Understanding doc’s Figure 1 is a horizontal range slider, described with a fix that maps directly onto a faceted-search price filter:

While a range slider is operated by dragging the slider thumb, an alternative pointer method to change the value is to click/tap anywhere on the slider track to move the thumb to that position.

The Examples section restates the same fix as its own listed technique:

A range slider control widget, where the value can be set by dragging the visual indicator (thumb) showing the current value, allows tapping or clicking on any point of the slider track to change the value and set the thumb to that position.

Most price-filter sliders already respond to a click on the track by moving the nearest thumb — default behavior for the native <input type="range"> element and most slider libraries built on it. The failure mode shows up in custom-built sliders (a styled <div> track with a draggable handle, wired up with pointer-move listeners) where a developer implemented drag-to-set but never wired up click-to-set, because manual QA with a mouse naturally exercises dragging and rarely tries a bare click. The doc’s own belt-and-suspenders option is a plain numeric text input next to the slider — “an input beside a slider could allow any user to enter a precise value…” — which it separately notes is device-agnostic since “text entry can take place through voice, pointer, or keyboard.”

A minimal fix pattern for a custom-built price-range track:

const track = document.getElementById("price-track");
const thumb = document.getElementById("price-thumb");

// Existing drag handling (pointerdown/pointermove/pointerup on the thumb) stays as-is.
// Add a click handler on the track itself for the single-pointer alternative:
track.addEventListener("click", (event) => {
  // Ignore clicks that originated on the thumb -- that's the drag path, not this one.
  if (event.target === thumb) return;

  const rect = track.getBoundingClientRect();
  const ratio = (event.clientX - rect.left) / rect.width;
  setSliderValue(clampToStep(ratio * (max - min) + min));
});

Related caution: the Understanding doc notes this criterion can overlap with SC 2.5.1 Pointer Gestures — both can fail at once “if the slider requires the user to exactly follow its track, or otherwise the user’s grip on the slider thumb is ‘lost.’”

Draggable carousels: also named directly by the W3C

Figure 2 in the Understanding doc is captioned, verbatim, “example of a typical draggable content carousel” — the swipe-to-browse product or promo carousel used on most e-commerce homepages and category pages. The Examples section gives the exact fix, described as an e-commerce pattern:

A news site has a horizontal carousel with different news teasers that can be dragged to move items into view. It also offers forward and backward buttons on the left and right of the carousel, to move the carousel to the previous and next item with a simple click/tap. These buttons can be visible (for instance, as large arrow icons) or visually hidden (but still operable with a pointer).

If a carousel’s only interaction is swipe/drag — common on mobile-first implementations that skip visible arrow buttons to save space — it fails SC 2.5.7 outright, independent of whatever auto-rotation behavior it has. That’s distinct from our accessible carousels and sliders article, which covers auto-rotation pause controls (SC 2.2.2) and accessible names for prev/next buttons (SC 4.1.2) — a carousel can have perfectly labeled, keyboard-operable arrows and still fail 2.5.7 if those buttons don’t exist on the touch/mouse version and dragging is the only way to advance. The fix is additive, not a redesign: keep the swipe gesture, and add visible (or accessibly-hidden-but-pointer-operable) forward/back buttons alongside it.

Drag-to-reorder: wishlists, saved carts, and cart line items

Some storefronts let shoppers manually reorder wishlist items or saved-cart line items by dragging. Technique G219 (one of the criterion’s own sufficient techniques) gives the single-pointer alternative directly:

A list of items can be re-ordered by picking up an item and dragging it upwards or downwards… After a single pointer activation, the list items display up and down arrows which allow a step-wise re-ordering of the list via single pointer inputs (taps or clicks at the up or down arrow).

In practice: a tap on a list item (or a dedicated “reorder” control) reveals up/down buttons that perform the same reordering one step at a time, no sustained press-drag-release needed. Failure F108 is the Working Group’s named failure for this exact gap — drag-to-reorder with no single-pointer alternative.

Three things this criterion doesn’t require

• Removing drag interactions entirely. It asks for an alternative alongside dragging, not a replacement — shoppers who prefer to drag or swipe can keep doing so.
• A keyboard-only fix. Arrow-key support satisfies keyboard-accessibility criteria (2.1.1/2.1.3) but is evaluated separately — SC 2.5.7 wants a pointer alternative (click/tap), not just a non-pointer one.
• Rebuilding native scroll or “pull to refresh.” Those are excluded as user-agent behavior, unless a site suppresses native scrolling and implements its own.

FAQ

Does a native <input type="range"> slider automatically satisfy SC 2.5.7? In most browsers, yes — clicking the track moves the thumb by default. Custom-built slider components (a styled <div> track with JavaScript drag handling) are where this usually needs to be added deliberately, since they don’t inherit that native behavior.

Do carousel navigation dots count as the single-pointer alternative to dragging? Yes, if each dot is independently clickable/tappable and moves the carousel to that slide. A carousel with dots that are purely a visual progress indicator (not interactive) doesn’t count.

Is this the same requirement as SC 2.5.1 Pointer Gestures? No, though they can both apply to the same component. SC 2.5.1 covers path-based or multi-point gestures (like a two-finger pinch); SC 2.5.7 covers dragging movements (grab, move, release), regardless of path.

An automated scan won’t catch most of this

A scanner can tell you a range slider has an accessible name and a valid ARIA role. It can’t tell you whether clicking the track actually moves the thumb, whether a carousel has any navigation short of a swipe gesture, or whether a wishlist’s drag-to-reorder feature has a button-based fallback anywhere in its markup — all of that requires actually operating the component with a mouse click (not a drag) and watching what happens, not just parsing the DOM. That gap is why Quietramp pairs an automated scan with a manual review pass that actually operates interactive components the way a scanner can’t. See a sample report or check pricing — $890 for a one-time audit, $99/month for ongoing re-checks after fixes ship.

---

This is educational content about technical accessibility practice, not legal advice. Meeting WCAG 2.2 does not guarantee legal compliance with the ADA or any other law. Consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.