WCAG 2.5.7 — Dragging Movements

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.

Passing examples

Sortable list with per-row "move up" / "move down" buttons in addition to drag handles:

<ul>
  {items.map((item, i) => (
    <li key={item.id}>
      {item.label}
      <button
        onClick={() => moveUp(i)}
        disabled={i === 0}
        aria-label={`Move ${item.label} up`}
      >
        ↑
      </button>
      <button
        onClick={() => moveDown(i)}
        disabled={i === items.length - 1}
        aria-label={`Move ${item.label} down`}
      >
        ↓
      </button>
      <DragHandle aria-label={`Drag ${item.label} to reorder`} />
    </li>
  ))}
</ul>

Drop zone with a paired click-to-browse file input:

<>
  <DropZone onDrop={uploadFiles}>
    <p>Drop files here, or</p>
    <label className="cursor-pointer text-link underline">
      browse to choose files
      <input
        type="file"
        multiple
        className="sr-only"
        onChange={(e) => uploadFiles(Array.from(e.target.files ?? []))}
      />
    </label>
  </DropZone>
</>

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.

References

W3C — Understanding 2.5.7 Dragging Movements (opens in new tab)