Drop Target

Usage

Overview

DropTarget wraps content with drag-and-drop semantics and consistent Interactable behavior—file uploads, reordering attachments, moving items between columns. Because drag alone excludes some input modes, always provide equivalent keyboard or button paths (Apple HIG + Carbon accessibility baseline).

When to use

File ingestion surfaces also offering browse buttons (dual path).
Internal tools where operators drag evidence between queues and validation is available client-side.

When not to use

Mobile-primary flows without tested gesture alternatives—prefer explicit pickers.
Precision tasks better served by searchable lists—drag increases error rates.

Variants

Rest, hover/active during drag, invalid drop, and success feedback should use tokens—never only color flashes.

Anatomy

Container with labeled instructions, optional iconography, children showing preview content, validation messaging region.

Content guidelines

Instructions specify accepted types, size caps, and cardinality; formatMessage.
Errors name the fix (“PDFs up to 25 MB”) not only “Invalid file”.

Behavior and states

Validate during drag when possible; on drop show progress for uploads via parent components.
Clear stale error state on new drag sessions.

Best practices

Do duplicate actions in visible buttons for keyboard and assistive tech users.
Do keep hit targets large enough for touch on hybrid dispatch tablets.
Don’t block paste or browse flows when drag fails—operators paste from email and CAD constantly.
Don’t run expensive synchronous validation on every pointer move without throttling.

Accessibility

Expose drop targets with clear names and instructions; keyboard alternatives must reach the same outcomes.
High-contrast mode should preserve boundary cues without relying on subtle tints alone.

File upload for full upload UX.
Interactable for unified interaction chrome.
Banner for validation summaries.

Collapsible / Accessibility

Drop Target / API and Development

On this page

Drop Target

Usage

Overview

When to use

File ingestion surfaces also offering browse buttons (dual path).
Internal tools where operators drag evidence between queues and validation is available client-side.

When not to use

Mobile-primary flows without tested gesture alternatives—prefer explicit pickers.
Precision tasks better served by searchable lists—drag increases error rates.

Variants

Rest, hover/active during drag, invalid drop, and success feedback should use tokens—never only color flashes.

Anatomy

Container with labeled instructions, optional iconography, children showing preview content, validation messaging region.

Content guidelines

Instructions specify accepted types, size caps, and cardinality; formatMessage.
Errors name the fix (“PDFs up to 25 MB”) not only “Invalid file”.

Behavior and states

Validate during drag when possible; on drop show progress for uploads via parent components.
Clear stale error state on new drag sessions.

Best practices

Do duplicate actions in visible buttons for keyboard and assistive tech users.
Do keep hit targets large enough for touch on hybrid dispatch tablets.
Don’t block paste or browse flows when drag fails—operators paste from email and CAD constantly.
Don’t run expensive synchronous validation on every pointer move without throttling.

Accessibility

Expose drop targets with clear names and instructions; keyboard alternatives must reach the same outcomes.
High-contrast mode should preserve boundary cues without relying on subtle tints alone.

File upload for full upload UX.
Interactable for unified interaction chrome.
Banner for validation summaries.

Collapsible / Accessibility

Drop Target / API and Development

On this page