Dragging can make reordering appear direct, but it is not a complete input contract. Provide a way to select an item and move it without holding a pointer down, and make the same operation available from the keyboard. Up and Down buttons, a move-to-position selector, or choose-item-then-target mode can express the action. The underlying mutation should accept a stable item ID and destination, not a DOM index that shifts when filtering or concurrent edits occur. Announce the new position and keep focus on the moved item or its control. A server-side version check is needed if multiple reviewers can reorder the same queue.
Reorder Controls Without Dragging
Working case
A reviewer moves case 47 above case 62 in the priority queue. Pointer drag works on a large monitor, but a user with limited dexterity cannot hold and move the pointer accurately. Add Move up and Move down buttons, and offer a click-then-target path when many positions exist. A keyboard user can operate those controls and hears 'Case 47, position 3 of 12' after the move. If another reviewer changed the queue while this action was in flight, the server rejects the stale ordering version and returns the current order for repair.
Implementation boundary
function moveCase(order, caseId, destinationIndex) {
const remaining = order.filter(id => id !== caseId);
remaining.splice(destinationIndex, 0, caseId);
return remaining;
}
console.log(moveCase([47, 62, 93], 47, 1).join(","));
// Output: 62,47,93The array transformation is a client-side ordering step; validate the destination range, item membership, and queue version at the server before persisting. Both drag and button paths should call the same mutation function. Keep button labels contextual, such as 'Move case 47 up', and disable only impossible moves at list boundaries while preserving clear position feedback. After success, place focus predictably; after a conflict, restore or reconcile the current order and explain the change. A single-pointer alternative must not require dragging even if a keyboard route also exists.
Cost and boundaries
Filtering and inserting in an array of n IDs is O(n) time and O(n) additional memory for the new order. Persisting the entire order can be expensive for a long queue; a rank key or neighbor-based command may reduce payload but adds conflict and compaction concerns. Extra controls occupy space, yet they remove a hard input barrier. Measure completion time with keyboard, touch, and pointer, not only drag speed. Frequent reorder announcements should stay concise so assistive technology does not repeat the whole queue.
Failure trace
The UI stores only source and destination DOM indexes. A filter removes a row between drag start and drop, so the wrong case moves. Use stable IDs and a queue version. Another implementation supplies keyboard controls but no single-pointer alternative to dragging; a touch user who cannot drag still has no way to choose a destination. Provide explicit buttons or a selection mode reachable by one or more taps, and verify the same server mutation receives the intended item ID.
Verification
- Every drag action has a keyboard and non-drag pointer route.
- A filtered list cannot cause the wrong item to move.
- Focus and position feedback follow the moved case.
Practice drill
Reorder a 12-case list with keyboard only, then with taps that never hold a pointer down. Move the first and last items and inspect disabled boundary controls. Filter the list mid-operation and verify the selected stable ID still identifies the right case. Apply a concurrent reorder from a second session before saving; the first client must show a conflict and updated positions. Keep focus on case 47's control after a successful move and announce its new position once.
Decision note
Treat drag as one optional gesture over an ID-based reorder command that also has keyboard and non-drag pointer controls.
Common Mistakes
- Persisting DOM indexes instead of stable item IDs.
- Offering keyboard support but no non-drag pointer path.
- Moving focus to the document body after reordering.
Connected lessons
Complex Accessible Interactions; Data Table Versus Interactive Grid; Combobox Suggestions and Active Option; Async Status Announcements and Focus; Accessible Names and Native Controls; Conditional Writes and Lost-Update Prevention; Accessible forms: connect labels, errors, and focus.
Apply and check
Build Project: accessible operations workspace and review Web Development: streams and interaction decisions quiz.
