Return and Exchange Request Forms: Getting File Uploads and Item Selection Right

Quietramp · Sep 20, 2026

Return and Exchange Request Forms: Getting File Uploads and Item Selection Right

A “Start a Return” flow is one of the most-used forms on an e-commerce site after checkout itself, and it usually bundles three separate custom controls into one page: checkboxes for picking which item(s) from an order to send back, a reason field, and — for damaged or defective claims — a photo upload. Each of the three has its own accessibility failure mode, and the upload field in particular hides a trap that looks correct visually and breaks completely for screen reader users.

Quick answer: item-selection checkboxes need an accessible name specific to the product, not a generic “Select item” repeated for every row (SC 4.1.2 Name, Role, Value). Format and size instructions on the photo upload (“JPG or PNG, max 5MB”) need to be programmatically tied to the input, not just placed visually nearby (SC 3.3.2 Labels or Instructions). And the custom-styled “Choose File” button that almost every store uses instead of the native, hard-to-style file input has to hide the real input with the right CSS property, or it silently stops being operable by assistive technology.

This is educational content about technical accessibility standards, not legal advice. Meeting WCAG 2.1 AA does not guarantee legal compliance with the ADA or any other law, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.

Picking which items to return

Return forms for multi-item orders almost always render one row per line item, each with its own checkbox. The mechanism is the same one covered in our comparison-table guide: a checkbox with no accessible name, or the same name repeated across every row, tells a screen reader user “checkbox” or “Select item” three times with no way to tell which product each one belongs to.

<!-- Fails: identical, unidentifiable checkboxes -->
<input type="checkbox" id="item-1"><label for="item-1">Select item</label>

<!-- Passes: name includes the actual product -->
<input type="checkbox" id="item-1">
<label for="item-1">Return: Wool Crew Sweater, size M, navy</label>

If the row includes a product thumbnail, the checkbox’s own label text (not the image alt text) should carry the identifying detail — a screen reader user tabbing through checkboxes hears the label, not a separately-announced image.

The reason field

A dropdown for “Reason for return” (wrong size, changed my mind, damaged, doesn’t match description) is one of the more form-standard pieces of this page — a native <select> handles keyboard support and screen reader semantics for free, and if the design calls for a custom-styled listbox instead, our custom dropdown guide covers the full WAI-ARIA combobox/listbox mechanics needed to replace it without losing that support. Nothing about a return-reason field is distinct enough from that pattern to repeat here.

The photo-upload field: where the real problems live

Damaged- or defective-item claims usually ask for a photo, and this is the one component on the page genuinely uncovered by anything else on this site — and the one most likely to look fine in a design review while failing completely for a screen reader user.

The hiding technique that breaks it

Native <input type="file"> buttons are famously hard to style consistently across browsers, so almost every store hides the real input and styles its <label> to look like a button instead — click the label, it activates the file picker. MDN’s own reference documents this exact pattern, and is explicit about how the input has to be hidden: “the recommended approach uses opacity… opacity is used to hide the file input instead of visibility: hidden or display: none, because assistive technology interprets the latter two styles to mean the file input isn’t interactive.”

That’s a genuinely easy trap: a developer who reaches for display: none — the obvious, default choice for hiding an element you don’t want seen — gets a visually identical result to using opacity: 0. Sighted QA passes without incident. But a screen reader (or switch-access, or voice-control) user now can’t interact with the file input at all, because assistive technology treats a display: none element as removed from the interaction tree, not just visually hidden.

<!-- Breaks assistive tech access, even though it looks identical -->
<input type="file" id="claim-photo" style="display: none;">
<label for="claim-photo" class="btn-style">Choose Photo</label>

<!-- Works: still visually hidden, still interactive -->
<input type="file" id="claim-photo" style="opacity: 0; position: absolute; width: 1px; height: 1px;">
<label for="claim-photo" class="btn-style">Choose Photo</label>

Format and size limits no one can hear

Most upload fields show a caption like “JPG, PNG, or HEIC, max 5MB” next to the button. SC 3.3.2 Labels or Instructions directly covers this: its Understanding doc states that instructions or labels “may also specify data formats for data entry fields, especially if they are out of the customary formats or if there are specific rules for correct input.” A visual caption sitting next to the input satisfies that requirement for a sighted user, but if it isn’t programmatically tied to the field, a screen reader user tabbing to the file input hears only “Choose Photo, button” — no format, no size limit — and only discovers the restriction after uploading the wrong thing and hitting an error.

The fix is Technique ARIA1 (aria-describedby), the same mechanism WCAG’s own worked example uses to associate instructions with a form field:

<label for="claim-photo" class="btn-style">Choose Photo</label>
<input type="file" id="claim-photo" accept="image/jpeg,image/png,image/heic"
       aria-describedby="claim-photo-hint">
<p id="claim-photo-hint">JPG, PNG, or HEIC. Max 5MB.</p>

The accept attribute is worth setting too, but on its own it isn’t a substitute for the text instruction — MDN’s own guidance notes accept “doesn’t validate the types of the selected files; it provides hints for browsers to guide users,” and it says nothing about the size limit at all.

Confirming the upload actually happened

Once a file is chosen, the visible UI typically swaps the button for a filename and a small “remove” control — a sighted user sees the change instantly. SC 4.1.3 Status Messages requires the same information reach a screen reader user without needing to move focus back to check: a status message is defined as content that provides “information to the user on the success or results of an action… or on the existence of errors” — which covers both a successful attach (“claim-photo.jpg attached”) and a rejected one (wrong format, over the size limit). Use role="status" for the success case and role="alert" for a rejected upload, the same split already covered in our gift card and promo code guide for error vs. routine feedback. If more than one photo can be attached, each file’s own “remove” control needs the filename in its accessible name — “Remove claim-photo.jpg,” not a bare “Remove” repeated for every file.

After submission

Once the request is submitted, the confirmation message itself needs the same role="status" treatment as any other post-submit confirmation. If the store’s return flow lets a shopper check back later for a status update (approved, label issued, refund processed), that’s the same asynchronous-status-update pattern covered in full in our order tracking guide — worth cross-linking rather than repeating the aria-live mechanics here.

What a scanner catches here, and what needs a person

axe-core’s label rule (tagged wcag412) reliably flags a file input with no associated label at all, the same as any other input. What it can’t catch: whether the format/size instructions are actually wired via aria-describedby or just sitting visually nearby with no programmatic link, and whether the display: none vs. opacity: 0 hiding choice was made correctly — both produce an identical DOM structure to a static scan, and the difference only shows up when assistive technology actually tries to interact with the element. It also can’t confirm an upload-success or upload-error status message actually fires, since that requires triggering the interaction and listening, not reading the page once. This is a component where a clean automated report says very little about whether it actually works.

FAQ

Does the accept attribute alone satisfy the format-instruction requirement? No. accept limits what the file picker shows or hints at, but per MDN it doesn’t validate file types and it doesn’t communicate a size limit at all. A programmatically associated text instruction (via aria-describedby or inside the label) is still needed to satisfy SC 3.3.2.

Why does the hiding method for a custom file-upload button matter so much? Because display: none and visibility: hidden remove an element from the accessibility tree entirely — assistive technology treats it as if it isn’t there, not just invisible. opacity: 0 keeps the element interactive while hiding it visually, which is the only one of the three that preserves keyboard and screen reader access to the real input.

Do I need a live region for a single-file upload, or only for multiple files? Either way. A single successful or failed upload is still a change in content that isn’t a change of context, which is exactly what SC 4.1.3 covers — the shopper needs to know it worked (or didn’t) without hunting for a visual cue.

Get your returns flow checked by a person, not just a parser

A clean automated scan on a returns form can confirm a label exists on the file input — it says nothing about whether that hidden input is still operable, whether the format instructions are actually announced, or whether an upload confirmation fires. Quietramp’s $890 audits include a manual pass through interactive components like this one, run by a person operating the flow with a keyboard and a screen reader. See a real sample report or check pricing — $99/month for ongoing re-checks after fixes ship.

Quietramp is an AI-operated agency with human oversight — this article was drafted by our Content/SEO writer role.

← Back to Notes