Level AA

Drag-to-reorder lists, kanban boards, and custom sliders routinely ship with no single-pointer fallback -- head pointers, eye trackers, switch devices, and voice control cannot issue a press-hold-move path.

2.5.7 Dragging Movements

In Plain Language

2.5.7 Dragging Movements (Level AA, new in WCAG 2.2) requires that all functionality operated by a dragging movement can also be achieved by a single pointer without dragging, unless dragging is essential or the drag behavior is determined by the user agent and not modified by the author[1].

A dragging movement is a press-hold-move-release path performed by a single pointer. The criterion does not ban drag interactions -- it requires a parallel path (click, tap, buttons, numeric input, context menu) that produces the same outcome without sustained pressure along a trajectory.

Why It Matters

  • A drag gesture couples two motor demands that can fail independently: maintaining pointer-down state and moving along a path. Users with tremor, limited grip strength, or spasticity lose the drag the moment either channel breaks -- a finger lifts, a button releases, a head pointer drifts -- and the operation resets.
  • Head pointers, eye-tracking systems, and single-switch scanning devices expose click and dwell events to the page but cannot synthesize a continuous drag path. For these input stacks, a drag-only control is not slow -- it is unreachable.
  • Touch users relying on AssistiveTouch or similar shells emit discrete taps, not pointerdown-with-motion sequences. Custom draggable="true" handlers that listen for dragstart never fire.
  • Voice-control stacks (Voice Control, Dragon, Voice Access) map utterances to click and tap commands against named or numbered targets. There is no reliable speech primitive for "hold this item and move it 140 pixels to the right."
  • 2.5.7 is distinct from 2.5.1 Pointer Gestures (Level A), which covers multipoint and path-based gestures like pinch-zoom and swipe[2]. 2.5.1 never applied to single-pointer drags, which is why 2.5.7 was added in WCAG 2.2 to close that gap[1].

Examples

Do: Provide move buttons alongside drag-to-reorder
  • Task A
  • Task B
  • Task C

✔ Users can reorder items with simple button clicks -- no dragging required.

<ul>
  <li>
    <button aria-label="Move Task A up" disabled>&uarr;</button>
    <button aria-label="Move Task A down">&darr;</button>
    Task A
  </li>
  <li>
    <button aria-label="Move Task B up">&uarr;</button>
    <button aria-label="Move Task B down">&darr;</button>
    Task B
  </li>
  <!-- Up/down buttons let users reorder without dragging -->
</ul>
Don't: Require dragging with no alternative
  • ☰ Task A
  • ☰ Task B
  • ☰ Task C

✘ The only way to reorder these items is by dragging. Users who cannot drag have no alternative.

<!-- BAD: drag-only reordering, no alternative -->
<ul>
  <li draggable="true">
    <span class="grip">&#x2630;</span> Task A
  </li>
  <li draggable="true">
    <span class="grip">&#x2630;</span> Task B
  </li>
  <!-- No buttons or keyboard controls to reorder -->
</ul>
Do: Offer click-to-place as an alternative to drag-and-drop

To Do

Design review

In Progress

Done

✔ Click a card to select it, then click a column to move it there -- no dragging needed.

<!-- Click-to-place alternative for drag-and-drop -->
<div class="card" tabindex="0" role="button"
     aria-label="Design review -- click to select,
                 then click a column to move">
  Design review
</div>
<!-- Step 1: click/tap the card to select it
     Step 2: click/tap the target column to place it -->
Don't: Use a custom slider that only responds to drag
Price range: $40

✘ This custom slider only works by dragging the thumb. There are no buttons, tap zones, or keyboard controls to adjust the value.

How to Fix It

  1. Map each drag interaction to a single-pointer twin. A drag-to-reorder list gets per-item up/down buttons. A kanban or drag-drop board gets a "Move to..." menu on each card with destination selection. A custom range slider gets prev/next (decrement/increment) buttons plus a numeric input that accepts direct entry. A drag-to-resize panel gets a size picker or preset buttons (Small / Medium / Large / Custom).
  2. Prefer native controls that already satisfy 2.5.7. <input type="range"> exposes keyboard arrow stepping, click-to-position, and programmatic value setting without any author-written drag handler. A native <select> replaces drag-to-choose widgets entirely. When the platform provides the mechanism, 2.5.7's user-agent exception applies and no extra work is needed[1].
  3. Do not conflate keyboard support with 2.5.7 compliance. Adding arrow-key movement to a drag-drop board satisfies 2.1.1 Keyboard, but 2.5.7 specifically requires a single pointer path -- tap, click, or activate -- because voice-control and switch users are driving pointer events, not keystrokes[3]. Ship both.
  4. Know what "essential" actually covers. The drag path itself must be the output -- a signature pad captures the trajectory, a freehand drawing tool records stroke shape, a map-drawing annotation tool records the polygon. Reordering, moving between columns, selecting a value on a scale, and resizing panels are not essential drags: the outcome is a final state, not a path, and a single-pointer alternative produces the same final state.
  5. Audit with pointer-only input. Unplug the mouse and drive the interface with tap-only input (a trackpad tap without click-drag, or a touch device with AssistiveTouch enabled). Every drag that cannot be completed is a 2.5.7 failure and needs a pointer alternative, not just a keyboard handler.

References

  1. [1] W3C (2023). Understanding Success Criterion 2.5.7: Dragging Movements. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html ↩ ↩ ↩
  2. [2] W3C (2023). Understanding Success Criterion 2.5.1: Pointer Gestures. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures.html ↩
  3. [3] W3C (2023). Understanding Success Criterion 2.1.1: Keyboard. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html ↩