Dragging Movements
WCAG 2.2 Success Criterion 2.5.7, Level AA. Anything operated by dragging must also be operable with a single pointer, without dragging.
What it requires
A dragging movement means the pointer engages an element on the press (down event) and the element, or a representation of its position, follows the pointer until release (up event) (Source: W3C, Understanding SC 2.5.7 ) . A single pointer is an input that targets one point at a time, such as a mouse, one finger, or a stylus. The required alternative is a way to reach the same result with a plain tap or click, not a press-and-hold-and-move.
Who it helps
- People who cannot perform a precise sustained drag because of tremor, limited dexterity, or fine-motor difficulty.
- People using adapted input devices: trackball, head pointer, eye-gaze system, or a speech-driven mouse emulator, where holding while moving is cumbersome and error-prone.
This is separate from keyboard access. A touchscreen user may have no keyboard at all, so the alternative must work with a single pointer, not only with the Tab key.
How to meet it
Provide a single-pointer alternative for every drag interaction. The sufficient technique is G219: ensuring an alternative is available for dragging movements (Source: W3C Technique G219 ) . W3C’s own examples:
- Map: drag to pan, and also provide up, down, left, and right buttons.
- Slider: drag the thumb, and also let the user click or tap anywhere on the track to move it.
- Kanban or sortable list: drag a card, and also offer select-then-move via buttons or a menu.
- Color wheel: drag the marker, and also click or tap to set the value.
- Carousel: swipe or drag, and also provide previous and next buttons.
<!-- Drag-and-drop kept, plus a single-pointer alternative -->
<li class="card" draggable="true">
Design the landing page
<button type="button" aria-label="Move: Design the landing page">
Move…
</button>
</li> Exceptions
- Essential. Dragging is essential when removing it would fundamentally change the function and the result cannot be achieved another conforming way — for example, free-form drawing or painting, or capturing a handwritten signature, where the path itself is the content.
- User-agent determined and not author-modified. Native browser scrolling and native drag behaviors are out of scope. But if your content suppresses the browser’s own scrolling and re-implements drag or scroll handling, that custom behavior is in scope.
Common failure: F108, providing no single-pointer method that avoids a dragging movement (Source: W3C Failure F108 ) .
How to test it
- List every interaction operated by dragging: sliders, maps, drag-and-drop lists, color pickers, marquee selection, carousels.
- For each, confirm the same result is achievable with a single pointer and no dragging (a tap or click on a button, track, or menu item).
- If a drag-only function has no single-pointer equivalent and dragging is not essential or user-agent controlled, it fails.
Common questions
Does this criterion ban drag-and-drop?
No. You can keep drag-and-drop. You just have to also offer a way to do the same thing with a single pointer and no dragging, such as buttons or a menu.
Does it apply to native scrolling?
No. Behavior the browser provides and you have not modified is exempt. But if you suppress native scrolling and implement your own drag-to-scroll, it is back in scope.
How is this different from Pointer Gestures (2.5.1)?
Dragging Movements is about grabbing and moving an element; direction does not matter. Pointer Gestures (2.5.1, from WCAG 2.1) is about path-based or multipoint gestures where the path or direction does matter.