File Upload

A file input with drag-and-drop support, file list management, progress reporting, and accessible validation feedback.

Demo

Use the upload control below to select one or more files. You can click the labeled button to open the native file browser, or drag files onto the drop zone. After selecting files, observe how the file list is updated and how status messages are communicated. Try removing a file from the list and notice how the change is announced. If validation errors occur — such as an unsupported file type — observe how the error is surfaced.

What to Observe

• The file input is triggered by a visible, labeled button so keyboard users can open the file browser without a mouse.
• When files are added or removed, the updated file list is announced to screen reader users through a live region or focus management.
• Each file in the list has an associated remove button with an accessible name that includes the filename (for example, "Remove report.pdf").
• Upload progress is communicated to assistive technology, not conveyed through visual animation alone.
• Validation errors — such as file type or size restrictions — are announced and linked to the relevant control.

Anatomy

[Anatomy image placeholder — will be added when assets are available]

1. Label — A visible <label> that names the file input and describes what files are expected.
2. File input — The native <input type="file"> that triggers the browser's file picker; may be visually hidden but must remain accessible.
3. Drop zone — A designated area that accepts dragged files; must also support keyboard activation as a fallback.
4. File list — A list of selected files, each showing the filename and a remove action.
5. Remove button — A per-file button that deletes the file from the selection; must have an accessible name identifying which file it removes.
6. Status / error region — A live region that announces upload progress, success confirmations, and validation errors.

Accessibility Behavior

• The file input or its visible trigger button must have a descriptive label that names the control and indicates any file type or size restrictions.
• The drag-and-drop drop zone must not be the only way to select files — a keyboard-operable button must also be available.
• Changes to the file list (additions and removals) must be communicated to assistive technology, either through a live region or by moving focus appropriately.
• Remove buttons must have accessible names that identify which specific file they will delete, not generic labels like "Remove" or "X".
• Upload progress and completion status must be conveyed programmatically, not only through a progress bar or spinner.
• Validation errors must be linked to the control and announced without requiring the user to search for them.

Common Mistakes

• Making drag-and-drop the only interaction method, with no keyboard-accessible alternative for selecting files.
• Using identically labeled "Remove" buttons for every file in the list, making it impossible for screen reader users to distinguish which file each button affects.
• Hiding the native file input with display: none and replacing it with a styled element that has no accessible label or keyboard trigger.
• Displaying upload progress only as a visual progress bar with no corresponding text or ARIA live update.
• Showing validation errors in a location far from the input without programmatically linking them, so users must hunt for the error message.

Why This Matters

File upload is a critical interaction in document management systems, profile setup, support workflows, and many other task flows. When the drag-and-drop zone is the only supported method, users who navigate by keyboard — including many users with motor disabilities — are completely blocked. Poor labeling of remove buttons turns a simple task into a guessing game for screen reader users. And silent upload progress leaves users uncertain whether anything is happening at all. These failures are particularly costly because file upload often sits at a high-stakes point in a workflow, such as submitting an application or attaching evidence to a case.

Accessibility Validation

This component is validated against internal accessibility criteria aligned with WCAG standards, using our internally developed system, Resonance Specs.

To learn more, please contact us.

Code

Reference Implementation

• Back to Home
• GitHub Code