Select your language
Select other languages

Automatic translation

Loading translator…

Magoomake your components work correctlyBack to homepage

Drag'n'Drop

Allows moving and rearranging elements, with alternatives to dragging and dropping.

For working examples and design patterns for this component, see the references tab (opens the references on this page).

COMPONENT GUIDE

Explore behaviors before defining the interface.

Quick guide for designers

Always consider the context of the application, even when the guidance follows a standard pattern. Interaction design documents intent. Behavior must be verified in the implementation.

When to use

Use to move or reorder items, offering alternatives to dragging.

What to draw

Show the selected item, allowed destinations, and new position, plus a way to cancel.

How it behaves

In the described pattern, Enter selects and arrows reposition; Escape cancels. Movement can be canceled without losing data.

What to document in Figma

Annotate commands, non-drag alternatives, and how the new position or a disallowed destination’s reason is communicated.

How to review

Check whether the purpose and states are clear on small and large screens and with zoom. Verify documented behavior in the implementation, including keyboard and screen reader use where applicable.

Full guidance

Interaction Design

Questions to ask when designing interactive components of type Drag'n'Drop.

Important:
Depending on the context in which you build your components, there may be further questions, and some listed here may not be necessary. Assess each case individually.

Designing for "no interaction"

  1. Before interacting, can you visually tell that the component is actionable?
  2. Before interacting, can you visually tell that the component supports dragging and dropping?

Designing for mouse use (any pointing device)

  1. Is there visual feedback when hovering over the actionable component?
  2. Is there visual feedback when clicking the actionable component?
  3. When dragging an actionable component, can you identify where it came from and where it is going?
  4. When dropping the previously selected component, can you visually identify the position change?

Designing for gesture use

  1. Is there visual feedback when activating the component?
  2. Is there visual feedback when pressing and holding the component?
  3. Is there visual feedback when releasing the component?
  4. When dragging an actionable component, can you identify where it came from and where it is going?
  5. When dropping the previously selected component, can you visually identify the position change?

Designing for keyboard use (any non-pointing device)

  1. Is there visual feedback when focusing the component?
  2. When navigating between components, can you perceive the focus change?
  3. When focusing an item in a list, can you tell that its position can be changed?
  4. When changing a list item's position, can you visually identify the change?

Designing for screen reader use

  1. When focusing the group of components, can you identify what the group is?
  2. Are there clear instructions on how to interact with the component?
  3. When focusing a component, can you identify it as draggable?
  4. When focusing a component, are interaction instructions provided?
  5. After interacting with the component, is there audible feedback on what happened?

Interaction methods

Possible interaction methods for components of type Drag'n'Drop.

Important:
Only the main methods are listed here. Custom components require further study.

Mouse interaction (any pointing device)

  • On hover, the component should provide visual feedback confirming that interaction is possible.
  • On a mouse click, the component should provide visual feedback confirming the click.
  • When clicking and holding the mouse button, the component should provide visual feedback confirming it is ready to be dragged.
  • On releasing the mouse button, the component should move to the destination.
  • It should be possible to cancel the movement without losing stored data.

Keyboard interaction (any non-pointing device)

  • When focused with the keyboard, the component should provide visual feedback with a visible focus indicator.
  • It should be possible to navigate to the next or previous item using the TAB or SHIFT+TAB keys respectively.
  • It should be possible to select components with the ENTER.
  • It should be possible to cancel component selection with the ESC.
  • After activation with the ENTERkey, it should be possible to use the arrow keys Up ArrowandDown ArrowandRight ArrowandLeft Arrow to reposition the component.
  • After repositioning, you can navigate again using the TAB or SHIFT+TAB.

Keyboard (or gesture) interaction + screen reader

  • When focusing the component group, you can hear what the group is.
  • When focusing a component in the group, you can hear which component is draggable.
  • When focusing the component, you can hear clear instructions on repositioning it.
  • After repositioning the component, you can hear its new position.
  • If a position is not permitted, you should hear the reason.
  • If repositioning requires a system action, such as restarting, that requirement must be communicated and it must be possible to cancel the repositioning.

Gherkin

BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).

Scenario: Given that I am on a page containing Drag'n'Drop

Keyboard navigation

  1. WHEN I use the Tab key to move focus to a draggable item
  2. The focus I SEE is strongly indicated visually
  3. THEN, when I use the Enter to select the item
  4. I SEE that the selected item is ready to be repositioned
  5. THEN, when I use the arrow keys to move the item
  6. I SEE the item's position updated
  7. AND, when I use the Esckey, I SEE selection or movement canceled without data loss

Desktop screen reader

  1. When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and use the Tab key to move focus to a draggable item
    • I HEAR the focused item's name.
    • I HEAR that the item can be repositioned.
    • I HEAR clear instructions on starting, moving, confirming, or canceling the interaction.
  2. THEN, when I reposition the item with the keyboard
  3. I HEAR the item's new position or a message stating that the chosen position is not permitted.

Mobile screen reader

  1. WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to focus a draggable item, the following happens:
    • I HEAR the focused item's name.
    • I HEAR that the item can be repositioned.
    • I HEAR clear instructions on interacting with the component using available gestures.
  2. THEN, when I reposition the item
  3. I HEAR the item's new position or a message stating that the chosen position is not permitted.

Considerations

Considerations for components of type Drag'n'Drop.

  • Drag'n'Drop components are complex to keep consistent across interaction methods. Use them only when necessary.

References

Additional references for components of type Drag'n'Drop.

Important:
Most references are on the course platform alongside the lessons cited in this material.

Disclaimer:
The links listed here are a curated collection of references where you can find implemented components, rather than recommendations. There is no unified implementation format and no guarantee that these links follow every design pattern. Direct questions to the teams responsible for the linked materials. Before copying a model, remember that all materials are constantly updated and that patterns, particularly proprietary ones, may change.

Design patterns

Design System

Original content by Marcelo Sales, initially used in the AccessBoost course (external link - opens in a new window). These interactions represent standard industry patterns, but may be customized in specific cases, provided there are sufficient instructions for people to understand the behavioral change.