Explore behaviors before defining the interface.
Quick guide for designers
When to use
Use when a task requires attaching files. Distinguish choosing a file from uploading it to the system.
What to design
Show allowed formats, size, and count, the file list, progress, success, errors, removal, and retry.
How it behaves
Selection opens the system file picker. Dragging is an alternative; upload may be immediate or require an explicit action.
What to document in Figma
Define upload initiation, limits, duplicate files, cancellation, removal, and what is preserved after failures.
How to review
Check states in the design. In the implementation, verify selection, upload, and recovery with keyboards, touch, and screen readers.
Before interaction
- Can people tell which documents are needed, whether the field is required, and which limits apply before opening the picker?
- Does the drop zone also provide a control to select files without
dragging?
Selection and upload
- Does the list identify each file by name and size? Does the interface distinguish selected, waiting, uploading, uploaded, and failed?
- Is it defined whether adding files accumulates the selection or replaces it? How are duplicates handled?
- When the system picker is canceled, do previous files and data remain available?
Errors and recovery
- Does the error identify the file, problem, and correction? Does an isolated rejection preserve other valid files?
- Are canceling a transfer, removing a selection, and deleting an uploaded file distinguished? Is the effect of each action documented?
- After removing a file, does focus move to an available control? Are long names still identifiable on small screens and with magnification?
Interaction Methods
Mouse and touch
Activating Select files opens the native picker. Drag and drop, when available, runs the same checks as selection.
Clicking or tapping Remove removes the file from the list; Cancel upload stops its transfer; Retry repeats the failed upload when these actions are available.
Keyboard
Tab and Shift + Tab traverse the field and file controls. Enter or Space on Select files opens the native picker; choosing and canceling within it follow the platform.
After choosing a file, Tab reaches Upload when submission is explicit. Enter or Space activates Upload, Remove, Cancel upload, or Retry on the focused button.
Screen readers
When navigating the field and files with a screen reader, people identify the label, restrictions, and each file’s name and state. Activating Select files opens the platform picker.
With a mobile screen reader, swiping traverses controls in the standard navigation mode and double tapping activates the focused control. Uploading or removing gives corresponding feedback.
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 File upload
Educational scenarios for reviewing behavior. Adapt them to context and execute them in the implementation; the presence of this text does not mean tests were performed.
Keyboard navigation
- WHEN I use
Tabto reach Select files - I SEE visible focus and can open the picker using the platform command without
draggingfiles - THEN, when I choose a file, I SEE its name and state in the list and can reach removal and retry controls when available
Screen reader on desktop
- WHEN I navigate the field and list with a desktop screen reader
- I HEAR the label, restrictions, and identification of each file and its actions
- THEN, when I upload or remove a file, I HEAR or perceive the outcome without losing focus to an unavailable element
Screen reader on mobile devices
- WHEN I explore the field and files with TalkBack or VoiceOver on mobile
- I HEAR names and states and can open the picker with the platform gesture
- THEN, when I activate a file action, I HEAR or perceive its update and keep navigating available controls
Additional scenarios — editorial extension
Add without dragging
- GIVEN the file field
- WHEN I select a file through the keyboard-accessible control
- THEN it appears identified in the list and its state distinguishes selection from upload.
Reject one file
- GIVEN valid files and one exceeding the stated limit
- WHEN I add the set
- THEN the error identifies the rejected file and valid files follow the documented preservation rule.
Retry and removal
- GIVEN a failed upload
- WHEN I activate Retry
- THEN only the corresponding upload is retried; when an item is removed, focus remains on an available control.
Review with a mobile screen reader
- GIVEN a file list
- WHEN I navigate with a mobile screen reader
- THEN I identify each name, state, and action and can select files with platform gestures.
Points to consider
The accept attribute helps filter the picker but does not replace server-side file validation. Size, count, and contents also require implementation checks.
Do not promise resumable upload or file preservation after reload without actual support. Document recovery limits.
USWDS File input is a reference for file selection; the asynchronous upload flow described here is an editorial adaptation requiring its own implementation.
Implementation notes and behavior decisions
Remove, Cancel upload, and Retry are distinct controls when those actions exist.
Tab and Shift + Tab traverse the field and each file control. Picker activation follows the native control and platform commands.
The gesture of dragging cannot be the only way to add files. Focus order follows the displayed list.
Associate the label, restrictions, and errors with the field. Identify the file in repeated action names, such as Remove receipt.pdf.
Communicate upload start, completion, and failure without moving focus for every update. A progress indicator must identify its operation.
References
Additional references for components of type File upload.
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.
Technical references and examples consulted for this editorial adaptation. Each source retains its scope; consulting an example does not prove accessibility of another implementation.