2.5.7 Dragging Movements

WCAG 2.2 · 2.5.7 AA Operable

What it requires

Any functionality that is operated by a dragging movement must also be operable by a single pointer without dragging — unless the dragging is essential, or the action is determined by the user agent and not modified by the author.

A dragging movement means pressing on a starting point, moving the pointer along a path, and releasing at a different end point — for example sliders, range inputs, colour pickers, kanban-style reorder lists, drag-to-dismiss cards, map panning, and signature pads. The criterion does not require keyboard access (that is covered by 2.1.1); it requires a non-dragging pointer path, such as tap or click targets, +/− buttons, or a press-and-pick interaction.

Dragging is difficult or impossible for many people, so a drag-only control locks them out entirely:

  • People with motor or dexterity disabilities, tremor, or limited fine motor control who cannot hold and move a pointer along a precise path.
  • People using a head pointer, mouth stick, eye-gaze, or single-switch input, where sustained dragging is unreliable or unsupported.
  • People using alternative pointing devices (trackball, joystick) or who find click-and-hold painful.

How to detect it

Ways to check 2.5.7 Dragging Movements
Check What to look for
Manual inventory List every control operated by dragging (sliders, reorder lists, map pans, swipe-to-dismiss, drawing). Each one needs a single-pointer alternative.
Single-pointer test Try to complete each action with only taps/clicks — no drag. If a slider has no +/− buttons or clickable track, it fails.
Essential exception Confirm the drag is truly essential (e.g. free-hand drawing) and not merely the author's preferred interaction before claiming the exception.
Automated tools Largely not detectable by axe or similar — they can't tell a drag-only control from one with an alternative. Treat as a manual check.

How to fix it

  1. Identify each drag-based control and decide whether dragging is genuinely essential. If not, an alternative is required.
  2. Add a single-pointer path: clickable increment/decrement buttons, a clickable track, "move up / move down" buttons for reorder lists, or pan buttons for maps.
  3. Keep drag and the alternative both available — you don't have to remove dragging, just stop relying on it.
  4. Use native elements where possible: <input type="range"> is operable by click and keyboard out of the box.
<!-- Reorder list: drag handle PLUS single-pointer buttons -->
<li>
  <span class="drag-handle" aria-hidden="true">⠿</span>
  Task name
  <button type="button" aria-label="Move up">↑</button>
  <button type="button" aria-label="Move down">↓</button>
</li>

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule that confirms 2.5.7. Whether a dragging movement has a single-pointer alternative cannot be detected by static analysis, so this criterion needs manual review using the console check and steps below.

Run this in the browser console

console-2-5-7.js 
// Read-only: surfaces likely drag-based controls for manual review.
const hits = [...document.querySelectorAll(
  '[draggable="true"], input[type="range"], [class*="slider"], [class*="drag"], [class*="resize"], [class*="sortable"]'
)];
console.table(hits.map(el => ({
  tag: el.tagName.toLowerCase(),
  id: el.id || '',
  cls: el.className || '',
  draggable: el.draggable
})));
hits.forEach(el => el.style.outline = '2px solid magenta');
console.log('Drag-suspect elements:', hits.length, hits);

What to check manually: For each highlighted control, confirm a single-pointer alternative exists (e.g. a tap, click, or arrow/value input that achieves the same result without dragging), and that the alternative is reachable and not itself a path-based gesture. No script can verify that the alternative truly produces an equivalent outcome.