Drag and drop needs a non-drag equivalent

What it is

A non-drag alternative lets people achieve the same reorder, move, classify, or transfer result without maintaining a press, moving, and precisely dropping. Drag can be efficient but cannot be the sole route: within a single continuous gesture it demands sustained press, controlled trajectory, and precise release all at once, and any single failure in that chain forces the whole action to be redone — a heavier motor and precision demand than almost any other common interaction primitive.

Why it happens

Drag is hard to replace gracefully because it fuses three separable steps into one uninterruptible action: naming the source, specifying the destination, and committing the change. A non-drag alternative pulls that chain apart: an independent click or selection fixes the source and lets the user pause to review it, a menu item, button, shortcut, cut-and-paste, or a dedicated "move to" dialog specifies the destination, and confirmation commits separately. Once separated, each step can be paused, inspected, or backed out at any point — no sustained motion and no precise spatial targeting is required, since selecting a menu item with a keyboard needs no few-pixel-wide drop zone. A second, equally important byproduct: a command path can state "from where, to where, becoming what" in words, while a drag's destination and outcome are usually inferable only by looking — a hover highlight has almost nothing for a screen reader to translate.

Where it stops holding

An alternative need not reproduce every intermediate animation or motion of the drag; it only has to reach the same final state under the same constraints (say, no duplicate name within the same parent). But the reverse does not hold either — "more steps" is never a reason to omit the alternative. If an operation is reachable only through drag, keyboard users and people relying on switch devices are not merely less efficient, they are shut out of the feature entirely. Batch moves and multi-selected, cross-hierarchy reordering are cases where a command path (select several, then run one "move to") usually beats repeated individual drags outright — here the alternative is not a fallback but the better primary route.

Applying it

• For every operation reachable by drag, provide a visible "select–move-to–confirm" command path or an equivalent keyboard shortcut — not just a buried entry in a settings screen.
• Have the alternate path clearly state on screen what is currently selected, which destinations are available, and what the outcome will be after confirmation, so no object moves without the user seeing it coming.
• Design the command path as the primary route for batch and multi-selection scenarios, rather than assuming users will repeat a single drag once per object.
• How to check: complete an end-to-end reorder or move task using only the keyboard (or a switch device), with no mouse or touch at all, and verify the resulting state exactly matches what the drag path would have produced.

Related

• Same group: C1.08.1 Drag and drop has three phases: pickup, transport, and drop · C1.08.2 Drag-start thresholds prevent a click from becoming a drag · C1.08.3 Valid drop targets must be explicit during drag · C1.08.4 Auto-scroll when dragging to an edge · C1.08.5 Drag and drop can be cancelled and returned to origin
• Nearby: J1 Motor and interaction accessibility · C1.07 Single and double click
• Search terms: accessible drag and drop · keyboard alternative · move to