Dragging interaction has no pointer alternative

What is this issue?

An element with draggable="true", or an equivalent pointer-event-driven drag implementation, is the only way to perform some action (reordering a list, moving an item between two areas, adjusting a value), and no alternative exists that completes the same action through a single tap, a single click, or a keyboard interaction. WCAG defines a dragging movement as any interaction requiring the user to press down, move the pointer while holding it down, and release at a target location, and 2.5.7 requires that dragging never be the only way to trigger the resulting action.

The rule doesn’t forbid drag-and-drop itself; it requires a second path to the same outcome that doesn’t depend on sustained, precise pointer control.

Why does this matter?

A drag gesture demands continuous, precise motor control for its entire duration: pressing down accurately on the source element, holding that press while moving to the exact target, and releasing at precisely the right spot; any slip anywhere in that sequence usually cancels or misfires the action. For someone with a tremor, limited fine motor control, or a condition that makes sustained pressure difficult, that’s not a minor friction point; it’s a task they may never be able to complete no matter how many times they try.

This is new to WCAG 2.2 specifically because drag-and-drop reordering has become common in modern interfaces (task boards, photo galleries, playlist builders), often replacing a numbered “move up/move down” pattern that was keyboard-operable by default. Each replacement quietly removes an alternative that used to exist for free.

Who is affected?

• Motor impairments: a tremor, limited fine motor control, or a condition affecting sustained grip strength can make holding a precise click-and-hold-and-move gesture accurately for the whole drag duration difficult or impossible, especially over longer drag distances.
• Low vision users: dragging requires visually tracking a moving element in relation to a target drop zone in real time, which is significantly harder with reduced vision or while using screen magnification that only shows part of the screen at once.

Users of switch controls, eye-tracking software, and voice control software are also affected, since none of those input methods can reliably perform a sustained press-hold-move-release sequence the way a standard mouse or touchscreen gesture assumes.

What users experience

Robert has a tremor that makes precise, sustained mouse movements difficult. He’s reordering his task list on a project management tool where the only way to move a task is to drag its card between columns. He tries three times to drag “Finish quarterly report” from “To Do” to “In Progress,” but his hand shakes mid-drag each time and the card snaps back to its original position, registering as a cancelled drag rather than a completed move. After the third failed attempt, he gives up reordering the list and just works through tasks in whatever order they happen to be in, even though it isn’t the order he actually needs to prioritize them.

How do I fix it?

Add at least one alternative way to perform the same action that requires only a single tap, click, or keyboard interaction, most commonly a pair of “move up” and “move down” buttons for reordering, or a “select, then choose a destination” two-step flow for moving items between areas. This works because it replaces the sustained precision a drag gesture demands with a sequence of discrete, single-activation steps, each of which succeeds or fails independently instead of requiring one unbroken motion.

Keep the drag interaction in place for users who prefer and can perform it: the fix is additive, not a replacement. Make sure the alternative controls are reachable through normal keyboard navigation and visible without requiring a hover state, since a control that only appears on mouse hover reintroduces the same reachability problem for keyboard users that this rule exists to prevent.

Code Examples

<ul id="task-list">
  <li draggable="true">Finish quarterly report</li>
  <li draggable="true">Review design mockups</li>
  <li draggable="true">Schedule team retro</li>
</ul>

<ul id="task-list">
  <li draggable="true">
    <span>Finish quarterly report</span>
    <div class="reorder-controls">
      <button type="button" aria-label="Move Finish quarterly report up">↑</button>
      <button type="button" aria-label="Move Finish quarterly report down">↓</button>
    </div>
  </li>
  <li draggable="true">
    <span>Review design mockups</span>
    <div class="reorder-controls">
      <button type="button" aria-label="Move Review design mockups up">↑</button>
      <button type="button" aria-label="Move Review design mockups down">↓</button>
    </div>
  </li>
</ul>

The draggable="true" attribute and its drag handlers stay untouched, and anyone who can perform the drag gesture keeps using it exactly as before. The move-up/move-down buttons give everyone else a fully keyboard- and single-tap-operable way to reach the same outcome, one step at a time, with each press an independent, forgiving action instead of one continuous, cancellable gesture.

Common Mistakes

Mistake: “Making the drag target bigger makes the gesture accessible enough.” A larger target helps with initial contact accuracy, but it doesn’t address the core problem: the gesture still requires sustained, continuous pointer control for its full duration. Someone who can’t hold a precise press-and-move motion is affected regardless of how large the drop zone is.

Mistake: “Touch devices already support drag via long-press, so mobile users are covered.” Touch-based dragging has the identical sustained-motor-control requirement as mouse dragging: a long-press-and-drag gesture is just as difficult for someone with a tremor or limited fine motor control on a touchscreen as it is with a mouse. Platform doesn’t change the underlying requirement for an alternative.

Mistake: “Reorder buttons only need to appear when the user hovers over the item, to keep the design clean.” A hover-only control is unreachable to keyboard users, who have no equivalent way to trigger a hover state through Tab navigation alone. The alternative controls need to be reachable through normal focus, not conditionally revealed by a pointer-only interaction.

Mistake: “This only applies to reordering lists.” Any interaction requiring a press-hold-move-release gesture is covered: dragging a card between kanban columns, dragging a slider handle, dragging a file onto an upload zone. The specific action being performed doesn’t matter; what matters is whether dragging is the only way to perform it.

How RedFlag Detects This

Custom automated: RedFlag’s own DOM detector, runs on every scan. RedFlag flags any [draggable="true"] element whose nearest ancestor with a sort-, drag-, or reorder-related class or id name (or its immediate parent, as a fallback) has no sibling button carrying an aria-label that contains the word “move,” “up,” or “down.”

False negative: a genuine drag-only interaction using a class-naming convention the detector doesn’t recognize (anything other than sort/drag/reorder-style names) passes undetected, since the check depends entirely on matching those specific naming patterns. False positive: a custom drag component using different terminology (for example, icon-only reorder buttons labelled “Reposition item” instead of containing “move,” “up,” or “down”) is flagged even though an alternative genuinely exists, since the detector only checks for those specific substrings. Manual step: for any flagged element, confirm by hand whether a genuinely usable, single-pointer or keyboard alternative exists nearby, regardless of whether its label happens to match the detector’s substring search.

Manual Testing

1. Open the page in Chrome or Firefox and identify every draggable element: reorderable lists, kanban-style boards, custom sliders.
2. For each one, try to complete the same action using only the keyboard: Tab to any visible alternative control and activate it with Enter or Space.
3. If no visible alternative exists, try completing the action with a single tap or click instead of a sustained drag.
4. Confirm the alternative actually produces the same outcome as the drag gesture, not a partial or different result.
5. If the only way to complete the action is a sustained press-hold-move-release gesture, the check fails.

Related WCAG Success Criteria

2.5.7 Dragging Movements: All functionality that uses a dragging movement for its operation must also be operable through a single pointer, without requiring dragging, unless dragging is essential. This rule is a direct check of whether that non-dragging alternative actually exists.

Related Issues

Interactive element is too small to tap accurately is another WCAG 2.2 addition in the same motor-accessibility family, both aimed at making pointer-based interactions forgiving of imprecise input rather than demanding exact control.

User must re-enter information already provided in the same process and Accessible authentication requires cognitive function test are the other new-in-2.2 criteria most likely to appear in the same audit as this one, since all three focus on removing unnecessary physical or cognitive burden from completing a task.

Navigation order is inconsistent across pages shares this rule’s broader WCAG 2.2 goal of predictable, low-friction interaction, even though the specific mechanism (navigation consistency versus drag alternatives) differs.

Focus indicator does not meet minimum size or contrast is worth checking on any reorder buttons you add as this rule’s fix, since a keyboard user needs a clearly visible focus indicator to use them confidently.

References

• W3C Understanding 2.5.7: Dragging Movements
• W3C WCAG 2.2: What’s New
• MDN: HTML Drag and Drop API