WCAG 2.5.7 Dragging Movements: A Computable Contract for AI Design Agents
WCAG 2.5.7 is a computable contract: an AI design agent can mechanically find every drag-only control, but only a structured human-in-the-loop rubric can verify that its single-pointer alternative is genuinely usable.
That sentence is the whole argument of this post. Dragging Movements is a Level AA success criterion in WCAG 2.2, and it is unusually well suited to the way AI design agents work — because half of it is a pattern match, and the other half is a judgement call that no pattern match can settle. If you maintain a design system, ship component libraries, or build agents that audit interface code, this split is the thing worth internalising.
This review is based on W3C documentation; we did not run the tools hands-on.
What 2.5.7 actually says
The success criterion text is short. 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 stated goal is blunt: “Don’t rely on dragging for user actions.”
The Understanding document for Dragging Movements adds a scope note: the criterion applies to web content that interprets pointer actions, not to actions required to operate the user agent or assistive technology. That scope note excludes the operation of the user agent and assistive technology itself from the criterion.
The intent is stated plainly: “Some people cannot perform dragging movements in a precise manner.” The document names users of adapted devices — trackball, head pointer, eye-gaze, speech mouse emulator — for whom dragging is cumbersome.
The W3C definition of a dragging movement
Before an agent can detect anything, it needs the definition. W3C defines a dragging movement as: the pointer engages an element on the down-event, and the element (or a representation of its position) follows the pointer until an up-event.
Three clauses, three detection targets:
- Down-event engagement. A pointer goes down on an element.
- Follow. The element, or a representation of its position, tracks the pointer.
- Up-event release. The interaction terminates on pointer up.
That third clause — “or a representation of its position” — is what makes this criterion broader than the word “drag” suggests.
The four discrete actions inside a drag
The Understanding document decomposes a drag into four discrete actions: tap/click start, press-and-hold, reposition pointer, release.
This decomposition is the most useful thing in the document for anyone building an agent, because it converts a continuous gesture into four discrete checkpoints. A drag is not one action; it is four, and each one is a place where a user with an adapted device can lose the interaction. It also explains why “just use the keyboard” is not the answer — more on that below.
Seven drag patterns and their single-pointer alternatives
The Understanding document walks through seven patterns. Treat this as your detection catalogue.
| Control type | Drag interaction | W3C single-pointer alternative |
|---|---|---|
| Range slider | Drag the thumb along the track | Click/tap anywhere on the track to move the thumb there |
| Carousel | Drag to advance slides | Forward/backward buttons (may be visually hidden but must be pointer-operable) |
| Kanban board | Drag cards between columns | Select item with a single tap/click, then activate an arrow button to move it |
| Sortable list | Drag rows to reorder | Tap/click element, then use adjacent up/down controls |
| Map | Drag to pan | Up/down/left/right buttons |
| Colour wheel | Drag the indicator | Click another point on the wheel; also numeric text fields |
| Rectangle selection | Drag to draw a selection | Enable selection mode, click corner one, click corner two |
Two details are easy to miss. First, the carousel alternative can be visually hidden — the criterion cares about pointer-operability, not visibility. Second, the colour wheel example explicitly pairs the click-elsewhere behaviour with numeric text fields; text input can be an acceptable single-pointer alternative, and W3C notes that a text input beside a slider can be an acceptable single-pointer alternative.
For the slider case specifically, Technique G216 offers the fallback (G216 supports 2.5.1, not 2.5.7; see below): “A simple fallback for activation without a path-based gesture is to make the control slider track clickable,” plus arrow buttons for increment and decrement.
The two exceptions, and the suppression caveat
The criterion has two carve-outs.
Essential. If dragging is essential to the functionality, the requirement does not apply.
User-agent-provided. If the functionality is determined by the user agent and not modified by the author, it is out of scope. W3C names scrollbar dragging, touchscreen page scroll, and browser drag-to-refresh as examples that are not covered, because the browser provides them.
The caveat: content that suppresses the user agent’s scroll, or implements its own scrolling or drag behaviour, is covered. So the detection rule is not “is this a scroll interaction?” but “did the author take over the interaction?” If your component library ships a custom scroll container or a bespoke pan surface, the exception does not rescue it.
Keyboard equivalence is a separate criterion
Keyboard support is a separate criterion. SC 2.1.1 Keyboard and 2.1.3 Keyboard (No Exception) separately require keyboard operability. Keyboard equivalence does not satisfy 2.5.7 unless the keyboard path also offers click/tap controls.
The W3C reasoning is worth quoting in substance: dragging objects to a location, when the path to that location is not relevant, does not require path-dependent input — so dragging to a location can be done from the keyboard, and keyboard equivalence is required. But required is not the same as sufficient. A control can be perfectly keyboard-operable and still fail 2.5.7, because 2.5.7 is about single-pointer operation without dragging.
There is a second trap. Path-based gestures — swipe, flick — cannot serve as the single-pointer alternative. Using one would fail SC 2.5.1 Pointer Gestures. An agent that “fixes” a drag by adding a swipe handler has not fixed anything; it has moved the failure.
Where G216 sits — and where it does not
G216 is frequently cited in 2.5.7 conversations, and it is useful, but it belongs to 2.5.1 Pointer Gestures, not 2.5.7. Keep the two criteria distinct.
The practical consequence: G216 gives you a proven fallback pattern (clickable track, arrow buttons), but citing G216 is not the same as satisfying 2.5.7. The underlying pattern transfers; the conformance claim does not. Design-system documentation that files G216 under “2.5.7 techniques” is subtly wrong and will confuse anyone auditing against the actual criterion text.
Cancellation: what 2.5.2 adds to the picture
SC 2.5.2 Pointer Cancellation is a Level A criterion, and it governs the drag lifecycle. Down selects, move, up drops. The W3C example is precise: releasing outside the drop target reverts the action. The abort mechanism is to return the item to its original location before release.
The supporting techniques are G210 (drag-and-drop cancelable), G212 (native controls trigger on up-event), and the failure F101 (activating on down-event).
Why does this matter for 2.5.7? Because a drag that cannot be cancelled is worse than a drag that can. If you are adding a single-pointer alternative, the cancellation behaviour of the original drag is part of the specification you are matching — not an optional nicety.
Target size: the 24×24 rule and the slider note
SC 2.5.8 Target Size (Minimum) is Level AA and sets a 24 × 24 CSS px minimum, with exceptions for spacing, equivalent controls, inline targets, user-agent controls, and essential targets.
The spacing exception is defined geometrically: a 24-CSS-px-diameter circle centred on the undersized target’s bounding box must not intersect another target, or another undersized target’s circle. Sliders and gradient colour pickers count as one target (Note 1), which is directly relevant to how you measure a slider’s track versus its thumb.
The core contribution: machine-detectable vs human-verified
Now the split that makes 2.5.7 a good model for agent-assisted review.
Machine-detectable. In the approach described here, an agent can find drag-only controls: pointer event handlers that engage on down-event, position-tracking logic that follows the pointer, and release on up-event. It can enumerate the seven patterns above and flag which ones lack a non-drag path. It can check whether a custom scroll container suppresses user-agent scrolling. It can verify that a claimed alternative is not a path-based gesture. It can measure target boxes against the 24 × 24 CSS px rule and compute the spacing circle. All of this is structural, and structure is what agents are good at.
Human-verified. An agent cannot confirm that a clickable slider track is discoverable — that a user knows the track is clickable. It cannot confirm that a visually hidden carousel button is reachable and operable with the pointer. It cannot judge whether “essential” genuinely applies or is being used as an escape hatch. It cannot tell whether the keyboard path also offers click/tap controls in a way that satisfies 2.5.7 rather than merely 2.1.1. It cannot assess whether a text-input alternative is usable at the sizes and in the contexts where the control actually appears.
That is the contract. The agent produces a candidate list with structural evidence; a human with a rubric decides whether each alternative is genuinely usable. Neither half is sufficient, and the failure mode of pretending otherwise is a green dashboard over a broken experience.
A practical rubric for design-system maintainers
If you maintain a component library, the split translates into a two-column review per component.
Column A — agent output. Drag detected: yes/no. Down-event engagement: yes/no. Position representation: yes/no. Up-event release: yes/no. Non-drag alternative present: yes/no. Alternative uses a path-based gesture: yes/no. Author suppresses UA scroll: yes/no. Target box ≥ 24 × 24 CSS px, or spacing circle clear: yes/no.
Column B — human verdict. Is the alternative discoverable? Is it operable with a single pointer? Does the cancellation behaviour match? Is the “essential” claim defensible? Does the keyboard path also offer click/tap controls?
In our approach, Column A is automatable and belongs in CI. Column B is not, and pretending otherwise is how design systems accumulate false conformance claims. The WCAG 2.2 Recommendation is dated 12 December 2024, and errata exist — so pin your rubric to a version and track changes.
FAQ
Does keyboard support satisfy 2.5.7? No. SC 2.1.1 and 2.1.3 separately require keyboard operability, and keyboard equivalence does not satisfy 2.5.7 unless the keyboard path also offers click/tap controls. They are different criteria with different obligations.
Can I use a swipe gesture as the alternative? No. Path-based gestures such as swipe or flick cannot be the single-pointer alternative; that would fail SC 2.5.1 Pointer Gestures. The alternative must work with a single pointer without dragging.
Is a native scrollbar a 2.5.7 problem? Generally no. Scrollbar dragging, touchscreen page scroll, and browser drag-to-refresh are user-agent-provided and not covered. But if your content suppresses the user agent’s scroll or implements its own scrolling or drag, it is covered.
Does a slider count as one target or several for 2.5.8? One target. W3C Note 1 states that sliders and gradient colour pickers count as one target, which affects how you measure the track and thumb against the 24 × 24 CSS px minimum.
How this guide maps to the blog thesis
The argument here is that the most useful accessibility criteria have a computable core and an irreducibly human remainder. WCAG 2.5.7 is a clear example. Its definition is mechanical — down-event, follow, up-event. Its four actions are enumerable. Its seven patterns are catalogued. Its exceptions have testable boundaries. And yet the question that decides conformance — is this alternative genuinely usable? — is not a pattern match.
Build agents that do the first half well, and build rubrics that force the second half to happen on purpose.
How This Guide Was Built
The primary sources were the Understanding document for Dragging Movements, the Understanding document for Target Size (Minimum), the Understanding document for Pointer Cancellation, the Understanding document for Keyboard, the Understanding document for Pointer Gestures, Technique G216, Technique G210, Technique G212, and Failure F101, alongside the WCAG 2.2 Recommendation and its errata. Enforcement dates, automated detection rates, and browser-native drag behaviour are not covered here.