Drag and drop: when it helps and what alternative to offer

Drag and drop helps when people need to move, reorder, group or resize something they can see on screen, and when they expect to do it with that gesture. It gets costly over long distances, for fine adjustments and on phones. That’s why it shouldn’t be the only way in. WCAG 2.2, the W3C accessibility guidelines, asks that every action done by dragging also works with a simple click or tap, unless dragging is essential (WCAG 2.2, success criterion 2.5.7).

What the gesture is

Drag and drop is a kind of direct manipulation: you act on the object you’re looking at, and the result shows up right away. Ben Shneiderman coined the term in the early 1980s, when typing commands was the norm (Nielsen Norman Group, NN/g, on direct manipulation). Moving a file to another folder is the classic example. On the command line, the same task means remembering the command and the path to both folders.

Page Laubheimer at NN/g breaks the gesture into four steps:

the object is visible on screen;
you grab it, with a click or a long press;
without letting go, you carry it to the target;
you let go, and the object moves or triggers an action, like deleting a file dropped in the trash.

When it helps

The gain comes from watching it happen. The article on direct manipulation lists the upsides: the object stays in view, the effect shows up right away, mistakes are easy to undo and it’s quick to learn. People recognize what they can do instead of memorizing it.

According to NN/g, the gesture fits four tasks: grouping, reordering, moving and resizing. A task board with columns, like Trello, is the typical case. The target column is right there, so is the card, and the movement tells the story without any text.

Where it costs you

The same gesture has a physical cost. NN/g says it can be slow, imprecise and tiring, especially over long distances. The mouse hits the edge of the desk, the finger has to shift, and the object lands in the wrong spot. Then you start over.

Fitts’s law helps explain why. It says the time to reach a target goes up with distance and down with the target’s size (NN/g, Fitts’s law). Dropping something on an exact spot is the small target case.

Repetitive tasks suffer too. In NN/g’s direct manipulation example, a YouTube playlist with 113 videos let you drag a video or send it to the top or the bottom. To put a video somewhere in the middle, an option to move it to a numbered position would have been faster.

Phones have no hover, the state when a cursor rests on something, which usually signals that you can drag it. That’s why NN/g recommends the gesture on touchscreens only when research shows people expect it and when there’s no simpler alternative, like a menu. Gmail is the article’s example: on desktop, you drag a message to a folder; on mobile, you use a menu.

What accessibility asks for

Success criterion 2.5.7 in WCAG 2.2 is new in this version and sits at level AA. It asks that every function done by dragging can also be done with a single pointer, without dragging. A single pointer is a mouse, a finger or a stylus, one point at a time. It doesn’t cover cases where dragging is essential or gestures that belong to the browser, like scrolling the page.

The reason is on the page that explains the criterion. Some people can’t hold and move at the same time with any precision. Others use a head pointer, an eye tracker or voice commands that act like a mouse. For them, dragging is slow and error-prone.

The same page gives examples you can borrow:

a board with columns opens a menu when you tap a card, so you can pick the target column;
a sortable list shows up and down buttons next to the selected item;
a slider accepts a click anywhere on the track;
a draggable map also has buttons to move the view.

A text field counts as an alternative too, since you can fill it in with a keyboard, voice or touch.

How to design the gesture

The guidance from NN/g and from Apple’s Human Interface Guidelines fits together:

Show that it can be grabbed. Use a drag handle and the system’s standard cursor. NN/g warns that handle icons vary a lot and look like the three-dot menu or the three-line menu, so they aren’t enough on their own.
Show that it’s been grabbed. A shadow, an outline, a slight tilt or a translucent image of the object. Apple suggests showing that image once the object has moved about three points, the screen unit Apple uses.
Show what’s about to happen. In a list, the other items make room before you let go. NN/g suggests a short animation, around 100 milliseconds, that starts when the center of the object crosses the edge of its neighbor.
Help people hit the target. The drop zone can be a bit bigger than it looks, with a highlight once the object is inside it. Apple asks for highlights only on targets that accept that content.
Say when it didn’t work. If someone drops on an invalid spot, the object goes back where it came from.
Let people undo. Apple recommends letting people undo a drag and asking for confirmation when the action can’t be reversed.
On touch, give room and a signal. NN/g asks for at least 1 cm by 1 cm of free space to grab the object and a short delay to tell a tap, a scroll and a grab apart. A light vibration confirms the grab.

Where the sources disagree

Apple wants the gesture everywhere. Its guidelines say to support drag and drop “as much as possible”, because people know it and try it everywhere (Apple, Human Interface Guidelines). NN/g is more careful, at least on touchscreens. There, the gesture only goes in with evidence that people expect it and no simpler alternative (NN/g).

Here’s how I put the two together: dragging as a shortcut, and a menu as the path that always works. Apple’s own guidelines ask for other ways to do the action, like a menu command to move the item.

The second gap is the keyboard. NN/g handles accessibility through the keyboard: the handle gets focus with Tab, the spacebar grabs the object and the arrow keys move it. WCAG keeps the two apart. The page on criterion 2.5.7 says a keyboard path doesn’t meet the criterion on its own, because touchscreen users may not have a keyboard. The keyboard is covered by other criteria, 2.1.1 and 2.1.3.

Where I used this

Vexor installs AI assistants on WhatsApp, and the panel that comes with the assistant has a board of clients by interest level: new, interested, hot, booked, client or cold. Changing stage means dragging the card to another column. The stage changes right away, and the change is kept in the history, with the date.

That’s the ground where the gesture helps: a few columns, all in view, and a movement that tells the change by itself. The dated history covers part of what the sources ask for, which is making it clear what changed and when.

This board is also the W3C’s own example, so the rule applies to it. Changing stage has to work with a simple click or tap too, like a stage menu on the card. For the keyboard side, the post on semantic HTML shows what the browser already gives you.

The common mistake

The most frequent slip is making dragging the only way to act. In a demo, with a mouse and a big screen, it feels natural. It fails with a finger on a phone, in a long list and for anyone who can’t hold and move at once. Dragging can stay as a shortcut. The path that always works is a button or a menu that does the same thing in one click.