WCAG 2.5.7 — Dragging Movements
Drag a card to a column, drag a slider thumb, drag a file into an upload zone. For users without fine motor control, drag isn't an interaction — it's a barrier. Each draggable thing needs a non-drag path.
What this requires
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. The criterion targets sortable lists, drag-and-drop file upload, draggable sliders, and similar interactions.
How AI coding tools fail this
When asked to add drag-and-drop sorting, AI tools wire up the drag handlers and consider the interaction complete. There's no "move up" / "move down" button alternative; users who can't drag have no path to reorder.
The second pattern: drag-and-drop file upload zones with no file input button. The hint says "drop files here"; users who can't drag files are stuck.
The third: range sliders implemented as draggable divs rather than
<input type="range">. Native range inputs are operable with arrow
keys; custom draggable divs often aren't.
Edge cases
- Native range inputs satisfy the criterion automatically — they respond to arrow keys.
- Drag-handle visibility doesn't satisfy the criterion alone; the non-drag alternative has to actually exist.
- Drawing apps and signature pads are essential-drag use cases.
- Sliders for colour pickers and similar should expose number inputs alongside the drag handle.
- Map panning is essential drag, but zoom and direction controls must also exist as buttons.
How Jeikin handles this
The scanner flags components with drag handlers
(onDragStart, onPointerMove followed by onPointerUp) and asks
the reviewer to confirm a non-drag alternative exists. The dashboard
records the alternative path. For native <input type="range">,
the criterion is treated as satisfied automatically.