Reviewed November 5, 2026

Dragging Movements Need a Second Way In: WCAG 2.5.7 on Storefronts

WCAG 2.2 criterion 2.5.7, Dragging Movements, at Level AA requires that any action done by dragging, such as sliding a before and after image comparison or dragging a product carousel, can also be done with a single pointer action like a tap or click, unless dragging is essential. Most storefront sliders ship without that alternative.

A customer with a tremor, a switch device, or a broken trackpad meets your before and after slider and cannot operate it. The product photo comparison, the feature you added to sell harder, just became the wall they cannot get past. WCAG 2.5.7 was written about exactly this pattern.

The criterion is new in WCAG 2.2 and stores mostly have not caught up, because drag interactions look fine in a design review and fail only in the hands of the people they exclude.

What counts as dragging on a storefront

Dragging means holding and moving a pointer: the comparison slider handle, the drag to rotate a 360 product view, drag sorting in a bundle builder, a price range slider with two handles, swiping carousels on desktop where buttons were never added. Each one needs a single pointer alternative that achieves the same result.

The exceptions are narrow and defined: where dragging is essential to the function, or where the movement is inherent to the control type, like a native slider the platform provides. A marketing carousel is never essential. The photos can be reached another way, so they must be.

The fixes are cheaper than the audit finding

Comparison sliders take a range input under the handle surprisingly well: the same control, operable by click, tap, arrow keys, and steppers, with the drag kept as an enhancement. Carousels need previous and next buttons that actually exist in the DOM and are reachable, not arrow glyphs painted on with CSS.

Price range sliders are the repeat offender in faceted navigation. Two draggable handles and no typed input means a whole class of shoppers cannot set a budget. Add min and max number fields beside the slider. It is an afternoon of work and it is also better UX for every shopper in a hurry.

Testing without special equipment

Unplug your mouse discipline for ten minutes: try each drag feature with single clicks only, then with a keyboard alone. If a feature cannot be completed both ways, it fails 2.5.7 or its keyboard cousins. Screen reader checks come second here. This criterion is about pointer alternatives, and the failure is visible to anyone willing to stop dragging.

Log the failures by component, not by page. The same comparison slider lives on forty product pages, and fixing the component fixes the template everywhere, which is the only way remediation math ever works in a store's favor.

Frequently asked questions

What is WCAG 2.5.7 in plain terms?

It is the WCAG 2.2 Level AA rule that anything a user does by dragging must also be doable with a simple tap or click, unless dragging is essential to the task. Sliders, drag carousels, and drag sorting on storefronts are the common cases.

Do swipe carousels on mobile fail this criterion?

A swipeable carousel with working previous and next buttons, or dots that jump to a slide, provides the single pointer alternative and can pass. A carousel that only moves by swiping, with no tappable control, does not.

Are price range sliders a problem?

Often, yes. If the only way to set a price range is dragging two handles, users who cannot drag are locked out. Adding minimum and maximum input fields next to the slider is the standard fix.

Does 2.5.7 replace keyboard accessibility requirements?

No. Keyboard operability comes from other criteria such as 2.1.1. Criterion 2.5.7 covers pointer users who cannot drag. A compliant control generally needs both: clickable alternatives and full keyboard support.