Your Drag-Only Sortable List Fails WCAG 2.2: What 2.5.7 Actually Requires

Drag the card to the right column. Slide the thumb to set your price. Reorder the list by grabbing a row. Every one of those interactions has a user who cannot do it: someone with a tremor, someone using a head pointer, someone on a phone with one hand free. WCAG 2.2 gave that user a criterion number, 2.5.7, and it sits at Level AA, which means it is part of the conformance target most contracts and decrees name.

The rule in one paragraph

Success Criterion 2.5.7, Dragging Movements, says 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. A dragging movement is press, hold, move, release, where only the start and end points matter. The W3C understanding document names the patterns directly: a price-range slider where clicking the track should move the thumb, and a draggable carousel where forward and back buttons should replace the swipe. Both are standard storefront furniture, and both commonly ship with no non-drag alternative at all.

Two exceptions, and neither is as wide as teams hope. Dragging is essential only when removing it would fundamentally change the function, and freehand drawing is about the only honest example. User-agent-determined covers native scrolling and the browser's own gestures, not a custom drag-to-scroll carousel a developer built to replace native scrolling. If your code interprets the drag, the criterion applies to you.

The patterns that fail on storefronts

Sortable lists are the most common failure, and they hide in admin tools as often as on the storefront: reorder product images, reorder menu items, reorder homepage sections. The fix is a pair of Move up and Move down buttons on each row, or a Move to menu. The dnd-kit library ships this as a built-in keyboard sensor, Space or Enter to pick up, arrow keys to move, Space to drop, Escape to cancel, and that pattern is worth copying even if you never touch the library.

Price sliders fail differently. A slider that responds to arrow keys meets 2.1.1 Keyboard, but the understanding document is explicit that keyboard equivalence does not automatically meet 2.5.7. A pointer user who cannot drag still cannot set a price. The fix is a tap on the track that jumps the thumb, plus and minus buttons, or a number field next to the slider where the shopper types the value. Kanban boards need the same treatment: select the card, then choose the target column from a menu.

The test that takes five minutes

Put the mouse down and use only clicks and taps. Try to reorder a list, set a price range, and move a card between columns. If any of those needs a press-and-hold, the page fails 2.5.7. Then check the alternative buttons themselves against 2.5.8: a 16-pixel Move up arrow squeezed against Move down replaces one failure with another, because the alternative has to be at least 24 by 24 CSS pixels or properly spaced. For the target-size side of the same audit, see the skip link test, which takes thirty seconds and catches half of keyboard failures, and the form error pattern that screen readers actually hear.

Frequently asked questions

Does keyboard support satisfy 2.5.7 on its own?

No. The W3C understanding document says achieving keyboard equivalence for a dragging operation does not automatically meet this criterion, unless the keyboard equivalent also provides controls that can be clicked or tapped with a pointer. A slider that works with arrow keys but still needs a drag for mouse and touch users fails.

Is dragging ever essential, so the exception applies?

Almost never on a storefront. Essential means removing the drag would fundamentally change the function, and freehand drawing is the usual example. Reordering a list, moving a card, or setting a price range all have obvious non-drag equivalents, so the exception does not save them.

What counts as a single-pointer alternative?

Any control that completes the same action with discrete clicks or taps: Move up and Move down buttons, a Move to menu, tapping the slider track, plus and minus buttons, or a number field. The alternative has to do the whole job, not part of it.

Do the alternative buttons have their own size rule?

Yes. They are pointer targets, so 2.5.8 applies: at least 24 by 24 CSS pixels, or enough spacing that a 24-pixel circle centered on the target touches no other target. A tiny 16-pixel arrow next to another tiny arrow fails 2.5.8.