Reordering needs a non-drag path

What it is

Drag-to-reorder binds “change the order” to one continuous pointing path. Anyone short on pointer precision, unable to hold, keyboard-only, or using switch scanning cannot walk that path. A non-drag alternative reaches the same final order with discrete acts—move up / down, choose a slot, type an index—without first knowing how to drag. Accessibility already states that alternative paths must be equivalent in capability. Here that lands on content lists: reorder as a content operation cannot exist only as a drag. Pickup feedback and edge scrolling, however polished, do not replace this path.

Why it happens

Drag demands four things at once: see the slot, keep holding, travel the path, release in the right place. Break any ring and the whole act fails. A discrete alternative splits the same goal into “select this item” and “put it at this index,” each step retryable, none dependent on instantaneous path feedback. If the alternative appears only in a menu you find after learning to drag, the discovery cost is equivalent to absence. If it can move only one slot per step, an eighty-item list turns the alternative into a penalty and people quit reordering instead of switching to buttons. Equivalence means the same set of final orders, not the same time per step; if the time gap makes the task unfinishable, equivalence exists only in the copy.

Studying it

One reorder task, three UIs: drag only; drag plus one-slot move; drag plus “move to position / move to top.” Include keyboard-only and touch participants.

Independent variables: whether the alternative is discoverable, how far one step can jump, whether the reachable final orders match drag. Dependent variables: keyboard-only completion, step count, abandonment, moves that leave the legal range.

Do not recruit mouse users and “also try the keyboard”—that measures transfer, not whether the alternative is self-sufficient. Path length for switch scanning (how many controls to scan to move one slot) is its own metric. Lab buttons drawn as large as the instruction sheet will overestimate field discovery.

Where it stops holding

User-ordered playlists, board columns, and custom nav need the alternative. Algorithmic sorts (by date, by name) are not drag tasks; they do not need move-up controls. Read-only permission should hide both paths. On a very short list, one-slot moves are already equivalent and discoverable; “jump to n” is optional. If server order is authoritative across devices, a local alternative move must persist, or keyboard users change nothing that lasts.

Applying it

• Put move up / down on each reorderable row; put “move to top / bottom / position” in the item menu.
• Those controls must be visible or keyboard-focusable before any drag starts, not a reward for dragging successfully.
• Position is the item’s index in the list. After a move, leave focus on the item so further adjustments are cheap.
• Verify: pointer disconnected, keyboard-only, move the third item first; then “move to position” to place an item tenth. Final order matches what drag could reach, and focus does not vanish mid-way.

Related

• Within the group: H8.03.1 Pickup and drop need unmistakable feedback · H8.03.2 Long lists must auto-scroll while dragging
• Adjacent: J3.07 Drag-and-drop Alternatives · C3.18 Long-Press Drag to Reorder · C3.24 Accessible Alternatives to Gestures
• Search terms: reorder alternative · move up down · keyboard sortable