Lesson 22 of 30

Drag-and-Drop Interaction Design

Q: You're building a drag-to-reorder list, like a Kanban board's cards. Walk me through the visual states you'd design for the drag itself, and then tell me how you'd handle it for a user who can't use a mouse.

A strong answer covers: Name the grabbed state (shadow, lift, reduced opacity) as the signal that an item is now under the user's control; Name the drop-zone indicator as showing landing position before release, distinct from the dragged item just following the cursor; Name the placeholder holding vacated space so the list doesn't reflow unpredictably during the drag; State honestly that pointer-based drag excludes keyboard-only and many screen-reader users, and that the real fix is a separate first-class interaction (arrow-key reordering or move up/down buttons), not just ARIA labeling.

A drag-and-drop reorder needs to feel controllable at every instant, not just correct once it's over — three visual states carry that feeling, and an honest accessibility gap sits underneath all of it that visual polish alone can't close.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A drag-and-drop list's underlying reorder logic works correctly, but users describe the interaction as feeling "broken" or "accidental." There's no shadow, scaling, or opacity change when an item is picked up. What's the likely cause?

Missing grabbed-state visual feedback — without a shadow, lift, or opacity change, there's no signal the item is now under the user's controlThe reorder logic must actually be buggy, since correct logic always produces a interaction that feels correctThe drop-zone indicator's color doesn't have enough contrast against the background

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Drag-and-Drop Interaction Design

What interviewers actually ask about this, and what a strong answer has to cover.

You're building a drag-to-reorder list, like a Kanban board's cards. Walk me through the visual states you'd design for the drag itself, and then tell me how you'd handle it for a user who can't use a mouse.

A strong answer covers

Name the grabbed state (shadow, lift, reduced opacity) as the signal that an item is now under the user's control
Name the drop-zone indicator as showing landing position before release, distinct from the dragged item just following the cursor
Name the placeholder holding vacated space so the list doesn't reflow unpredictably during the drag
State honestly that pointer-based drag excludes keyboard-only and many screen-reader users, and that the real fix is a separate first-class interaction (arrow-key reordering or move up/down buttons), not just ARIA labeling

Likely follow-ups

Does adding aria-grabbed and aria-dropeffect to the draggable items solve the accessibility gap? Why or why not?
What's a concrete, discoverable alternative interaction you'd design for a keyboard-only user to reorder this same list?

Practice these with the AI interviewer →

The plain-language idea

A drag interaction lives or dies on feedback during the drag, not just on whether the final reorder is correct. Three visual states do that work:

Grabbed — the moment an item is picked up, it needs to visually separate from the rest of the list: a shadow, a slight scale-up, reduced opacity. This is what tells the user "this is now under your control," distinct from the static list around it.
A drop-zone indicator — while dragging, something needs to show exactly where the item will land if released right now, before the user commits. Without it, dropping is a guess.
A placeholder holding the vacated space — the gap the dragged item left behind should stay visible and stable while dragging continues, so the rest of the list doesn't jump unpredictably underneath the cursor.

See it in a real thing: the states a drag needs, and the gap underneath them

.dragging {
  box-shadow: var(--shadow-lg);
  transform: scale(1.02);
  opacity: 0.9;
  cursor: grabbing;
}

.drop-indicator {
  height: 2px;
  background: var(--track-accent);
}

Grabbed, drop zone, placeholder, droppedStep 1 of 4

Idle — a plain, orderable list of three items.

Here's the honest part: native HTML5 drag-and-drop, and most custom pointer-based implementations built on mousedown/touchstart, are mouse- and touch-only by construction. A keyboard-only user, or a screen-reader user navigating without a mouse, cannot pick an item up and drop it using Tab and Enter alone — there's no clean "keyboard version" of a spatial pointer gesture. aria-grabbed and aria-dropeffect existed as an attempt at this and were deprecated from the ARIA spec precisely because labeling a drag target doesn't give a keyboard user any way to actually perform the drag.

What people usually miss

Watch out

Missing grabbed-state feedback makes a correct reorder feel broken. Even flawless underlying logic feels accidental or uncontrollable if there's no shadow, lift, or opacity change the instant an item is picked up.
Without a placeholder holding the vacated space, the list reflows unpredictably mid-drag — items shifting positions while the user is still deciding where to drop makes the whole interaction feel jumpy and hard to trust.
A drop-zone indicator is a distinct signal from the dragged item following the cursor. The cursor position shows where the item currently is; the indicator shows where it will land — conflating the two leaves the user guessing right up to the moment of release.
The accessibility gap here is real, not theoretical, and it's one of the few places "just add ARIA" genuinely doesn't fix the underlying problem, because the interaction itself is spatial and pointer-based in a way keyboard input can't replicate directly.
Touch drag needs its own accommodation, distinct from mouse drag — a small hit target or an instantly-triggered drag can conflict with normal scrolling on a touchscreen; a brief long-press to disambiguate "starting a drag" from "starting a scroll" is a common, necessary fix.

Why this matters in interviews

A "here's a Kanban board, walk me through the drag interaction" prompt is testing two separate things at once — whether a candidate can name the visual states that make dragging feel controllable, and whether they'll volunteer the accessibility gap unprompted rather than needing to be asked "but what about keyboard users?"