What it must accomplish
Collect files safely without hiding constraints or the status of each item.
Usage
Choose the control by behavior
- A task genuinely requires a file
- Accepted types and limits can be stated
- Progress and retry can be handled per file
- Structured fields would produce safer data
- The file cannot be stored or processed reliably
- Mobile capture or cloud selection is required but unsupported
Anatomy
Stable parts create a reliable contract
- 1Label and requirements
- 2Native file input or drop zone
- 3File list
- 4Per-file progress and status
- 5Remove and retry actions
Interaction and keyboard behavior
- The native picker is keyboard reachable
- Drop zones provide an equivalent button
- Remove and retry actions have specific names
Visual similarity does not guarantee behavioral equivalence. The component contract must preserve state, focus, semantics, and recovery across input methods.
Accessible behavior
- State accepted types and size before selection
- Announce progress without excessive updates
- Identify each file and its error
- Do not require drag and drop
Responsive considerations
Adapt the decision—not only the dimensions
Stack file metadata and actions at narrow widths, preserve long filename wrapping, and avoid horizontal progress layouts that clip.
Content considerations
Language is part of the component
- Use human-readable sizes and formats
- Explain security or privacy consequences
- State whether upload is complete or merely selected
Patterns that weaken the experience
Making the whole page an unlabeled drop zone
Combining all failures into one message
Removing failed files before users can inspect them
Comparison
What to study across systems
Enterprise systems emphasize multi-file queues and progress; public-service systems often favor simple native selection with explicit evidence requirements.
Open comparison