Home WCAG

WCAG 2.5.7 Dragging Movements

Any drag-to-do interaction must have a single-pointer, non-drag alternative. New in WCAG 2.2 at Level AA. Reorderable lists, file uploads, and pan/zoom are the most common offenders.

Normative spec
https://www.w3.org/TR/WCAG22/#dragging-movements
Last verified
Byline
Editorial team

What this criterion requires

Success Criterion 2.5.7 Dragging Movements is a Level AA criterion added in WCAG 2.2 (October 2023). It requires that any function that can be operated by dragging is also operable by a single pointer gesture without dragging — unless dragging is essential or the user agent supplies the function.

The single-pointer alternative does not have to be on the same control or in the same place; an equivalent button elsewhere is fine.

Why it matters

A surprisingly large share of users cannot perform a sustained drag. The reasons are varied: tremor, low pointer accuracy, switch devices, voice control, head-tracking, eye-tracking, single-finger operation on a tablet, or simply a stiff trackpad. WCAG 2.2’s Understanding document estimates that about 9% of pointer-using adults have measurable difficulty with sustained drag.

Exceptions

Two narrow exceptions apply:

  1. Essential. The drag is intrinsic to the function — drawing on a canvas, signing on a signature pad, panning a topographic map.
  2. User-agent control. The drag is supplied by the platform itself (window-resize handles in a desktop browser, native file upload <input type="file"> drop targets that the OS provides).

What a passing implementation looks like

For a sortable list, the user can:

  1. Activate any item with a single click or tap.
  2. See keyboard alternatives (Alt+Up / Alt+Down) or visible buttons (“Move up” / “Move down”).
  3. Hear order changes announced via a live region with aria-live="polite".

For a file uploader, the user has both:

  1. The drop zone (drag-and-drop), and
  2. A standard <input type="file"> button activated by a single click.

The drag interaction is a progressive enhancement; the click interaction is the floor.

Authoring patterns

A drag-and-drop sortable list with full keyboard parity:

<ul role="list" id="todo">
  <li>
    <span>Buy groceries</span>
    <button type="button" aria-label="Move up">↑</button>
    <button type="button" aria-label="Move down">↓</button>
  </li>
  <!-- ... -->
</ul>
<div role="status" aria-live="polite" id="reorder-live"></div>

The arrow buttons activate on Enter or Space and trigger the same DOM mutation as the drag-drop handler. The <div role="status"> announces the new position (“Item moved to position 2 of 5”) within about 200 ms.

For touch-first reorder UIs, a “Move…” mode pattern works well: tap the item once to enter move mode, then use a separate drop-target list of slots, exited with a Cancel button. The Apple Music app uses this pattern; it has been documented as roughly 95% as efficient as drag for non-power users.

Common pitfalls

  • Drag-only file upload. A drop zone without a corresponding <input type="file"> fails the criterion outright.
  • Slider-only volume. A drag-only volume slider should also have step buttons (- / +).
  • pointermove-only kanban board. Provide keyboard arrow-key reorder + visible per-card “Move” menu.
  • Pinch-zoom map without zoom buttons. Add + and − buttons with the same effect as pinch.
  • Slide-to-confirm without tap-to-confirm. A “swipe to confirm” control is a drag; provide a button.

Verification

Automated tools cannot reliably detect a missing drag alternative because they cannot tell that a control is drag-operable. Human review is required:

  1. Identify every drag interaction on the page (pan, swipe, reorder, slide-to-confirm, drop).
  2. For each, list the keyboard or click-only alternative.
  3. If the alternative does not exist, the criterion fails.

Cross-engine support

This criterion is platform-agnostic — engines render whatever markup the author chooses. The relevant primitives — Pointer Events (w3.org/TR/pointerevents3, CR 2024), pointerdown/pointerup/pointermove — reached interop in 2019 and pass at about 99% across Chromium (Blink), WebKit, and Gecko per the Interop dashboard.

Further reading