Accessible Upload Interfaces #

Upload interfaces fail accessibility in predictable ways. The dropzone is a div that only responds to a mouse dragging files from a desktop window, so keyboard users, screen-reader users, switch users and most phone users cannot add files at all. Progress is a coloured bar with no text, updated sixty times a second, which a screen reader either ignores or reads aloud until the user gives up. Errors appear as a red border and an icon, and disappear on the next render. Each of these excludes people who need to upload a CV, a medical document or a photo of an ID card — tasks that are rarely optional.

The fixes are not exotic. A native <input type="file"> is already keyboard-accessible, labelled and supported by every assistive technology; a dropzone should be an enhancement around it, not a replacement for it. Progress needs a text equivalent and a deliberate announcement strategy. Errors need text that names the file, the problem and the fix, placed where it will be found and announced once. This topic belongs to frontend UX, chunking and progress tracking and applies to everything built in upload queue concurrency control and realtime upload progress events.

Three guides go further: building an accessible file dropzone, announcing upload progress to screen readers and writing accessible upload error messages.

Prerequisites #

• An upload flow that works end to end with a plain file input — build that first, then enhance.
• A screen reader to test with: VoiceOver on macOS and iOS, NVDA on Windows, TalkBack on Android.
• WCAG 2.2 AA as the target, which is what most accessibility laws and procurement rules reference.
• Keyboard-only testing habits: unplug the mouse for a full upload, including errors and retries.

How it works #

An accessible upload interface is built in layers, and each layer must degrade to the one below it. The base is a native file input with a visible label. Everything a mouse user can do by dragging, a keyboard user can do by pressing Enter or Space on the input’s button, and a phone user can do through the operating system’s file picker, camera or photo library — none of which your code has to implement.

The drop area is a region around the input that also accepts dropped files. It does not replace the input, does not need a role="button" of its own, and never traps focus. The file list is plain HTML — a list of items, each with the file’s name, its size and its status as text — so it reads correctly in every screen reader without ARIA. Progress bars can use the native <progress> element, which exposes its value to assistive technologies.

Announcements are the one place ARIA is essential. Screen reader users cannot see a bar move, so meaningful changes — upload started, halfway, finished, failed — are sent to a polite live region. The art is restraint: announce milestones, not every percent, and combine updates for many files into one message.

Step-by-step implementation #

1. Start with a labelled input #

<div class="uploader">
  <label for="files" class="uploader__label">Add photos (JPEG, PNG or HEIC, up to 50 MB each)</label>
  <input id="files" name="files" type="file" multiple
         accept="image/jpeg,image/png,image/heic"
         aria-describedby="files-hint">
  <p id="files-hint" class="uploader__hint">You can also drag files onto this area.</p>
  <ul id="file-list" class="file-list" aria-label="Files to upload"></ul>
  <div id="upload-status" class="visually-hidden" role="status" aria-live="polite" aria-atomic="true"></div>
</div>

The label names the purpose and the constraints before the user picks anything, which prevents most errors. accept narrows the picker but is not validation — users can still choose “All files”, and drops ignore it entirely.

2. Enhance with drop, without replacing the input #

Attach dragover and drop handlers to the .uploader container, style it when a drag is over it, and pass dropped files through the same function the input’s change handler uses. Keep the input visible and styled as a button (“Choose files”); visually hiding it inside a clickable div is where most dropzones lose keyboard access. Building an accessible file dropzone covers the details, including the dragleave flicker problem from fixing dragleave flicker on drop zones.

const zone = document.querySelector<HTMLElement>(".uploader")!;
const input = document.querySelector<HTMLInputElement>("#files")!;

input.addEventListener("change", () => { addFiles([...(input.files ?? [])]); input.value = ""; });
zone.addEventListener("dragover", (e) => { e.preventDefault(); zone.classList.add("is-over"); });
zone.addEventListener("dragleave", (e) => { if (!zone.contains(e.relatedTarget as Node)) zone.classList.remove("is-over"); });
zone.addEventListener("drop", (e) => {
  e.preventDefault(); zone.classList.remove("is-over");
  addFiles([...(e.dataTransfer?.files ?? [])]);
});

3. Render each file as text #

Each list item shows the name, the size in human units, and a status string. The <progress> element carries the numeric value and is labelled by the file name, so a screen reader moving through the list hears “holiday.jpg, progress bar, 45 percent”.

function renderItem(item: { id: string; file: File; status: string; percent: number; error?: string }) {
  const li = document.getElementById(`f-${item.id}`) ?? Object.assign(document.createElement("li"), { id: `f-${item.id}` });
  li.innerHTML = "";
  const name = Object.assign(document.createElement("span"), { id: `n-${item.id}`, className: "file__name", textContent: item.file.name });
  const size = Object.assign(document.createElement("span"), { className: "file__size", textContent: formatBytes(item.file.size) });
  const bar = Object.assign(document.createElement("progress"), { max: 100, value: item.percent });
  bar.setAttribute("aria-labelledby", name.id);
  const status = Object.assign(document.createElement("span"), { className: "file__status", textContent: statusText(item) });
  li.append(name, size, bar, status);
  if (item.error) li.append(Object.assign(document.createElement("p"), { className: "file__error", textContent: item.error }));
  return li;
}

In real code, update the existing nodes rather than rebuilding them, so focus on a row’s buttons is not lost — the rendering guide shows how.

4. Announce milestones politely #

Write short messages to the role="status" region: when a batch starts, at 25/50/75 percent of the batch, when it completes, and when a file fails. Rate-limit to one announcement every few seconds and merge messages for many files (“3 of 12 photos uploaded”). Announcing upload progress to screen readers has a small announcer with throttling and deduplication.

5. Write errors people can act on #

“Upload failed” helps nobody. “holiday.heic is 72 MB — the limit is 50 MB. Try exporting a smaller version.” names the file, the problem and a fix. Show it next to the file, keep it until the user acts, include it in a summary at the top of the list when several files fail, and announce it once. Writing accessible upload error messages has a catalogue of messages for common failures.

Configuration reference #

Two WCAG 2.2 additions matter especially. Success criterion 2.5.7 (Dragging Movements) requires that anything done by dragging can also be done with a single pointer without dragging — which a visible “Choose files” button satisfies. Criterion 2.5.8 (Target Size, minimum) requires pointer targets of at least 24 by 24 CSS pixels, which rules out the tiny “×” remove buttons many file lists use. Contrast requirements apply to the drop area’s border and to progress bars: the filled portion must be distinguishable from the track at 3:1.

Edge cases and gotchas #

Hidden inputs lose focus styles. Inputs hidden with display: none cannot be focused; ones hidden with opacity: 0 over a styled label are focusable but show no focus ring. Style the input’s own button with ::file-selector-button, or keep the input in the layout and add a visible :focus-visible outline to the label.

Screen readers read the file input’s default text. “No file chosen” is read after every selection. Showing the selected files in your own list and resetting input.value after reading files keeps the input’s text neutral.

Mobile screen readers and drag. VoiceOver and TalkBack users cannot drag files from another app into a web page in most cases. The file input’s picker is their only path; make sure it is obvious and large.

Live regions added dynamically. A live region inserted into the DOM at the same time as its first message is often not announced. Render the empty region with the page and only change its text later.

Time limits. Upload URLs expire and sessions time out. A user navigating slowly with assistive technology may hit an expiry before starting. Request URLs when the upload starts, not when files are selected, and recover automatically as in recovering from expired presigned URLs mid-upload.

Focus management during and after uploads #

Moving focus is disruptive; do it only when the element the user was on disappears or when the user must act. Progress updates, other rows finishing and background retries must never steal focus. When a row’s control changes (Pause becomes Resume), render the new button in the same place and move focus to it so the user can press it again. When a row is removed, move focus to the next row’s first control, or back to the input if the list is empty. When a batch finishes with failures, moving focus to a heading such as “2 files couldn’t be uploaded” is reasonable — the user must act — but only once, at the end.

Making uploads understandable, not just operable #

Accessibility is also about comprehension. People with cognitive disabilities, people using a second language and people under stress — uploading documents for a benefits claim, a visa, a medical appointment — all benefit from the same things: plain words, one decision at a time, and nothing that disappears before it can be read.

State constraints in everyday terms before the user acts. “Photos or scans, up to 50 MB each, up to 10 files” is clearer than “Accepted: image/*, application/pdf; max 52428800 bytes”. If you need specific documents, name them: “Upload the front and back of your ID card as two files”. Show examples where it helps, such as a thumbnail of an acceptable scan next to the input.

Avoid time pressure. Do not auto-submit a form the moment uploads finish, and do not clear selected files after an error; let the user review the list and decide when to continue. Keep success visible: a row that says “Uploaded” with a tick and the file name gives reassurance that a toast notification disappearing after three seconds cannot. When an upload completes something important — a submitted application, a shared file — confirm it on the page in text, not only with an icon.

Use consistent vocabulary. If the button says “Add files”, the empty state should not say “Drop documents to attach” and the error “Upload rejected”. Pick one verb for the action and one noun for the objects and use them everywhere, including in announcements, so screen reader users hear the same words they see.

Touch, zoom and motion #

On phones, the file input opens the system sheet with camera, photo library and files. That sheet is accessible by default, so a large, clearly labelled button that opens it is the best mobile upload interface there is. If you offer “Take photo” separately, use capture on a second input, as described in capturing photos with the capture attribute, and label both buttons with what they do rather than with icons alone.

Users who zoom to 200 % or 400 % need the file list to reflow into a single column. Long file names should wrap (overflow-wrap: anywhere) rather than being truncated with an ellipsis, because the end of a name — …final-v3.pdf versus …final-v4.pdf — is often the part that matters. If truncation is unavoidable, keep the extension visible and expose the full name as text in the row, not only in a tooltip.

Respect prefers-reduced-motion. Animated striped progress bars, bouncing icons on the drop area and confetti on completion can cause discomfort for people with vestibular disorders. Keep motion subtle by default and turn it off when the user asks: a static bar that fills is as informative as an animated one. Never convey status by animation alone — a spinner means nothing to someone who cannot see it and too much to someone who is distracted by it.

Colour must not be the only signal either. A red row for failures and a green row for success are fine as reinforcement, but each status also needs a word and, ideally, an icon with a text alternative. Check that the colours you use meet contrast against the page background in both light and dark themes.

Testing with real assistive technology #

Automated checkers find missing labels and contrast failures but not whether an upload is usable. Run a scripted manual test on each release: with only a keyboard, add three files, remove one, pause and resume another, trigger a size error and fix it. Repeat with VoiceOver on iOS using the photo library, and with NVDA and Firefox on Windows. Listen for three things: that every control has a meaningful name, that progress is announced at a tolerable rate, and that errors are announced once and can be found again. Record short screen-reader videos of the flow; they make regressions obvious in review.

Build the test into your definition of done rather than an annual audit. Upload interfaces change often — a new file type, a new limit, a redesigned list — and each change can break announcements or focus in ways no linter notices. A ten-minute keyboard and screen-reader pass on every change to the upload flow costs far less than retrofitting fixes after complaints, and it keeps the team familiar with how the interface actually sounds.

Include people with disabilities in usability testing when you can. Five sessions with screen-reader, keyboard and magnification users routinely surface problems that sighted developers testing with a screen reader miss — for example, that a milestone announcement interrupts the user while they are reading the next field, or that “Remove” buttons without the file name are ambiguous in a list of twenty.

Verification #

• Complete an upload using only Tab, Shift+Tab, Enter and Space, including a retry.
• With VoiceOver or NVDA on, confirm you hear the label and constraints before choosing, one announcement when uploading starts, a few milestones and one on completion.
• Zoom to 400 % and confirm the file list reflows without horizontal scrolling (WCAG 1.4.10).
• Check drop area border and progress fill contrast at 3:1 or better.
• Confirm every row button is at least 24 × 24 CSS pixels.

Frequently Asked Questions