Returns and refund page accessibility for ecommerce

Most ecommerce accessibility work focuses on the purchase path: product pages, cart and checkout. Returns flows are almost always skipped. That creates a concentration of unaudited violations in a part of your store that handles high volumes of post-sale interactions, many of them from customers who are already frustrated.

Under the ADA and the European Accessibility Act, accessibility requirements apply to the full range of digital services offered to customers, not just the pages that drive revenue. A screen reader user who cannot initiate a return or access a refund status page has the same legal standing as one who cannot complete a purchase.

Returns flows also tend to involve more complex interactions than a typical checkout: order lookup, reason selection, photo upload, label generation and status polling. Each of these is a potential failure point. This guide covers where returns flows fail, what WCAG criteria apply and how to test with assistive technology.

Why returns flows are high-risk for accessibility

Returns and refund pages share several characteristics that make them particularly prone to accessibility failures.

First, they are built late. Returns functionality is typically added to a store after launch, often using a third-party app rather than custom development. Third-party apps receive less accessibility scrutiny than core store pages. The app renders a form in an iframe or a hosted subdomain, and no one on the development team audits it.

Second, they are complex forms. A return request form may include order number lookup, reason dropdowns, item quantity selectors, condition descriptions, photo upload and submission confirmation. Each of these elements has specific WCAG requirements. Getting all of them right requires deliberate implementation.

Third, they are rarely tested. QA for returns flows typically checks the happy path. Accessibility testing requires going further: triggering every error state, navigating with keyboard only, verifying screen reader announcements at each step.

Finally, the population of customers initiating returns skews toward people who have had a problem with an order. A product that arrived damaged, a size that did not fit, an item that was not as described. Customers in these situations are already under friction. An inaccessible returns flow on top of a product problem is a customer service failure and a legal exposure simultaneously.

Return request forms: labels, structure and input purpose

The return request form is the highest-risk component in the returns flow. It concentrates the same WCAG failure patterns found in checkout forms, but with less attention from developers and auditors.

The most common failure is missing or disconnected labels. Every input, select, textarea and file upload in the form must have a programmatically associated label. A visual label that is not connected to its input via a for / id pairing, or via aria-labelledby, fails WCAG 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value). Screen readers announce unlabeled inputs as "edit text" or "combo box" with no indication of what the field is for.

Our accessible forms guide covers all three label association methods. For return forms specifically, watch for:

• Order number fields that use placeholder text ("Enter your order number") instead of a proper label. Placeholders disappear as the user types and are not reliably announced by all screen readers.
• Return reason dropdowns rendered as custom select components without the correct ARIA roles. A visual dropdown that is not a native select element needs role="combobox" or role="listbox" with appropriate keyboard interaction patterns.
• Quantity steppers for selecting how many items to return. A custom stepper built from two buttons and a number display needs aria-label on each button and an aria-live region or aria-valuenow on the quantity display so screen readers announce changes.
• Condition description textareas without character count indicators that are accessible. If you limit the return reason to 500 characters and show a live counter, the counter must be an aria-live region.

WCAG 1.3.5 (Identify Input Purpose) also applies where forms collect personal information. An order lookup form that asks for an email address must include autocomplete="email". A name field must include the appropriate autocomplete token. This benefits users with cognitive disabilities and motor impairments who rely on autofill.

Error handling in return request forms

WCAG 3.3.1 (Error Identification) requires that input errors are identified in text and that the item in error is described to the user. WCAG 3.3.3 (Error Suggestion) requires that if the error can be described, a suggestion for correction is provided.

Returns forms fail both of these frequently. Common failure patterns include:

• Errors indicated only by a red border on the input, with no text description of the error. This fails both 3.3.1 and WCAG 1.4.1 (Use of Color).
• A generic "Please complete all required fields" message shown at the top of the form without identifying which fields have errors or linking back to them programmatically.
• Error messages placed adjacent to the input in the DOM but not associated with it via aria-describedby. The message is visible but not announced by screen readers when the field receives focus.
• Client-side validation that fires on blur with an error message, but does not move focus to the error or use a live region to announce it. A user navigating by keyboard tabs past the field, triggers validation and has no indication that an error appeared behind them.

The correct pattern is to associate each error message with its input using aria-describedby, so screen readers announce the error text when the input receives focus. When a user submits a form with multiple errors, focus should move to the first error or to a summary at the top of the form that lists all errors with anchor links to each field.

File upload for return photo evidence

Many returns flows ask customers to upload photos of damaged or incorrect items. File upload components are one of the most commonly inaccessible form elements in ecommerce.

A native <input type="file"> is keyboard accessible and screen reader compatible by default, but most stores replace it with a custom drag-and-drop component for visual design reasons. These custom components frequently fail:

• WCAG 2.1.1 (Keyboard): the drop zone is not reachable or activatable by keyboard. Users cannot Tab to it and press Enter to open the file picker.
• WCAG 4.1.2 (Name, Role, Value): the drop zone has no accessible name, no role that communicates its purpose and no state announcement for when a file has been selected.
• WCAG 1.4.3 (Contrast): instructional text inside the drop zone ("Drag and drop your photos here") often uses low-contrast styling.

The fix is either to use the native input (styled to match your design) or to implement the custom component with correct ARIA: role="button" on the drop zone, an accessible name via aria-label, keyboard activation via Enter and Space, and a live region that announces when a file has been accepted or rejected.

After a file is selected, the filename must be announced to screen readers. A common pattern is to show the filename visually but not update any accessible element. The correct approach is to either display the filename in a live region or move focus to a confirmation element that announces the filename.

Order lookup accessibility

Many stores require customers to look up their order before initiating a return. This lookup typically involves entering an order number and an email address, then submitting to retrieve the order.

The lookup form itself must meet the same label and error handling requirements as any other form. The order results returned by the lookup are where additional failures occur.

If the lookup returns a list of orders with actionable items (a "Return" button for each), those buttons must have accessible names that distinguish them. A series of buttons all labeled "Return" fails WCAG 2.4.6 (Headings and Labels) and 4.1.2. Use aria-label to include the order identifier: aria-label="Return order #10045".

If the lookup returns no results, the "no results" message must be in a live region or receive focus so screen reader users are informed without having to navigate through the DOM to find it.

Dynamic loading states during the order lookup (a spinner while the results load) need ARIA. A spinner that appears and disappears without any announcement leaves screen reader users uncertain whether the form submission was received. Use aria-live="polite" to announce "Loading your orders" when the request starts and either move focus to the results or announce their availability when the results load.

Return status tracking

Return status pages show the current state of a return: submitted, received by warehouse, refund processing, refund issued. These pages often use visual timeline components or progress indicators that fail accessibility requirements.

A visual progress bar or stepper that shows return status must communicate its state to screen readers. A series of styled circles with no accessible text fails WCAG 1.3.1. Each step in the timeline should have text that describes the step and its current state: "Return received. Completed." versus "Refund issued. Pending."

If return status updates in real time (polling the server for status changes), any update that changes the displayed status must be announced. Use aria-live="polite" on the status region so that changes are announced without interrupting the user's current focus.

Email notifications for return status updates sit outside the web accessibility scope, but the links in those emails must lead back to accessible status pages. A link to a tracking page that only works for sighted users who can read a visual map is a failure of the full return experience.

RMA portal navigation

Merchants with higher return volumes often implement a dedicated RMA (Return Merchandise Authorization) portal, either custom-built or through a third-party returns platform. These portals are often multi-step flows with their own navigation, account states and document management.

RMA portal navigation must be fully keyboard accessible. See our keyboard navigation guide for the full set of requirements. For RMA portals specifically:

• Multi-step flows must manage focus correctly between steps. When a user advances from "Select items" to "Choose reason," focus must move to a logical starting point on the new step, not remain on the now-hidden "Next" button.
• Navigation between return items (if the portal handles multiple open returns) must be keyboard accessible and not rely on hover-only interactions.
• Any modal dialogs used to confirm actions (confirming a return, canceling an RMA) must follow the ARIA dialog pattern: focus must be trapped inside the dialog while it is open, the dialog must have an accessible name, and closing the dialog must return focus to the trigger element.
• Document actions (download shipping label, view return confirmation) must be keyboard accessible. Icon-only buttons need accessible names via aria-label.

Return shipping label generation and download

Generating and downloading a return shipping label is a critical step in the returns flow. Failures here block the customer from completing the return entirely.

The label generation button or link must have a clear, accessible name. A button labeled "Get label" is acceptable. A button with only a printer icon and no text needs an aria-label of "Download return shipping label" or similar.

When the label is generated, the success state must be announced. If a "Your label is ready" message appears dynamically in the DOM without focus management or a live region, screen reader users will not know the label is available without manually exploring the page.

PDF labels opened in a new tab or window must have the new-window behavior communicated in advance. WCAG 2.4.4 (Link Purpose) requires that the purpose of a link can be determined. A link that opens a PDF in a new window without warning fails this. Add "(opens in a new tab, PDF)" to the accessible name, either visibly or via visually-hidden text.

If the label download is a file download rather than a new tab, confirm the download initiation with an accessible announcement. Users with screen readers cannot see a browser's download notification.

Refund confirmation screens

The refund confirmation screen is the final step of the returns flow. It confirms the return has been received or the refund has been issued. These screens are typically simple but still generate accessibility failures.

WCAG 4.1.3 (Status Messages) requires that status messages be programmatically determinable through role or property so they can be announced without receiving focus. A confirmation message that appears on a new page is accessible by default if the page has a meaningful title element and a logical heading. A confirmation message that appears dynamically on the same page (after AJAX submission) needs a live region or focus management.

Refund amount, timeline and method must be conveyed in text, not only through visual layout. A table showing the refund breakdown must have proper table headers using th elements with scope attributes, not styled div elements that only visually resemble a table.

Check color contrast on confirmation screens. Green success states and grey informational text frequently fail the 4.5:1 ratio for normal text.

Third-party returns apps: Loop, Returnly and Happy Returns

The majority of Shopify Plus stores using a dedicated returns platform are on Loop Returns, Returnly (now Shopify-owned) or Happy Returns. Each has accessibility issues that affect the stores using them.

Loop Returns. Loop renders its returns portal in a hosted subdomain or as an embedded experience. The hosted flow has improved in recent versions but continues to have issues with custom reason selection components that use non-native controls without full ARIA implementation. Focus management between steps in the multi-step flow is inconsistent. The photo upload component is a drag-and-drop implementation that fails keyboard accessibility unless the customer knows to activate it with Enter.

Returnly. Returnly's portal, now part of Shopify, has benefited from some accessibility remediation. However, its legacy hosted flow (still in use on many stores that have not migrated to Shopify's native returns) has persistent issues with error handling. Error messages on the order lookup form are not associated with inputs via aria-describedby and appear only as visual text near the field.

Happy Returns. Happy Returns focuses on in-person drop-off rather than mail returns. Its web-facing flow for initiating a return and finding a drop-off location has map components that are not accessible to screen readers. The drop-off location list view (an accessible alternative to the map) is present but hard to reach without keyboard navigation skills.

Your legal exposure is not reduced because a third party built the inaccessible flow. Under the ADA and EAA, the merchant is responsible for the accessibility of the customer journey. Require a VPAT (Voluntary Product Accessibility Template) from your returns app vendor, test the actual rendered flow with a screen reader and document the results. If the vendor cannot demonstrate WCAG 2.1 AA conformance, that is a contractual and compliance risk.

WCAG criteria that apply to returns flows

The full WCAG 2.1 AA checklist applies. The criteria that come up most often in returns flow audits are:

• 1.3.1 Info and Relationships: form labels, table headers, logical reading order.
• 1.3.5 Identify Input Purpose: autocomplete attributes on personal data fields in order lookup and contact forms.
• 1.4.1 Use of Color: error states that rely on red color alone, without text.
• 1.4.3 Contrast: instructional text in file upload zones, placeholder text, status badges.
• 1.4.11 Non-text Contrast: input borders, focus indicators, icon buttons.
• 2.1.1 Keyboard: all interactive elements reachable and operable by keyboard alone.
• 2.4.3 Focus Order: focus moves logically through multi-step flows.
• 2.4.4 Link Purpose: download links and new-tab links with meaningful names.
• 3.3.1 Error Identification: errors described in text and associated with the field.
• 3.3.3 Error Suggestion: corrective guidance in error messages.
• 4.1.2 Name, Role, Value: custom controls with correct ARIA roles, names and states.
• 4.1.3 Status Messages: confirmation states and dynamic updates announced to screen readers.

Testing the returns flow with screen readers and keyboard

Automated scanners catch a subset of violations: missing labels, contrast failures, missing form attributes. They do not catch focus management problems, live region issues or keyboard traps. Manual testing is required. Our screen reader testing guide covers setup and commands in detail.

For returns flows, test these specific scenarios:

• Keyboard-only test. Navigate to the returns page and complete the full returns flow using only Tab, Shift+Tab, Enter, Space and arrow keys. Initiate a return, select a reason, upload a photo, generate a label and reach the confirmation screen without using a mouse.
• Screen reader test. Repeat the full flow with NVDA on Windows (free, widely used by blind users) or VoiceOver on macOS. Listen to what is announced at each step. Note unlabeled controls, missing error announcements and confirmation states that do not get announced.
• Error state test. Submit the return request form with intentional errors. Enter an invalid order number. Skip required fields. Verify that errors are announced by the screen reader and that the error messages describe what went wrong.
• File upload test. Navigate to the photo upload component with keyboard only. Activate it with Enter. Select a file. Verify that the filename is announced after selection.
• Status tracking test. Navigate to the return status page. Verify that the status is communicated textually, not only visually. If the status updates dynamically, verify the update is announced.

Use your automated testing tools first to identify easy wins. Then cover the gaps with manual testing. Both steps are necessary for a credible WCAG 2.1 AA assessment of your returns flow.

Frequently asked questions

Are returns flows covered by ADA and EAA accessibility requirements?

Yes. The ADA and the European Accessibility Act both apply to the full range of ecommerce services, not just the purchase flow. A plaintiff or enforcement authority does not need to show that the inaccessible page blocked a purchase. Blocking a return, a refund or account self-service is treated as an equivalent barrier.

What WCAG criteria apply most often to returns forms?

The most commonly violated criteria are 1.3.1 (info and relationships, covering label association), 3.3.1 (error identification), 3.3.3 (error suggestion), 1.3.5 (identify input purpose), 4.1.2 (name, role, value for custom controls) and 4.1.3 (status messages for confirmation states). File upload components for photo evidence frequently fail 4.1.2 and 2.1.1.

Do third-party returns apps like Loop and Returnly create legal exposure for my store?

Yes. Under the ADA and EAA, the merchant is responsible for the accessibility of the entire customer journey, including flows powered by third-party vendors. If Loop or Returnly renders an inaccessible portal on your domain or a subdomain linked from your store, the exposure is yours. You should require VPAT documentation from any returns app vendor and test the actual flow with assistive technology.