# Accessible Returns Portals: The Start Return Flow, Tested

Source: https://storefrontaccess.com/blog/2026-10-30-accessible-returns-portal-starting-return.html

Reviewed October 30, 2026


Starting a return means picking an order, picking items, and picking a reason, in a form with deadlines. Where return portals fail screen reader and keyboard users, and the fixes.

## The form's real difficulty

A return start is a multi step form with a deadline hanging over it: pick the order, pick the items, pick a reason, choose a refund or exchange path, confirm. For a keyboard or screen reader user, the difficulty is not the number of steps. It is whether each step announces what it needs, whether the order and item selections are identifiable, and whether an error at step three sends you back to step one with everything lost. Return portals are built as afterthoughts to a purchase flow that got all the design attention. It shows.

Test yours as a customer would, with an order you can return, keyboard only. Try to start a return for one item out of three, with a reason, and see where you get stuck. The stuck points are almost always the same three places: item selection, reason selection, and the confirmation screen. Fix those and the rest of the portal usually follows.

## Item and order selection

Order history pages are the first trap. Orders listed by number and date alone, with no product summary in text, force a screen reader user to open every order to find the one they want to return. Include the product names in the order row text, and give each row a link with a descriptive name, return items from order containing, rather than a row of identical return buttons. Identical button names are one of the most common accessibility defects in all of commerce, and order history is where they accumulate.

Item selection inside the return needs real checkboxes or radios with labels naming the product and variant, not clickable cards whose selected state is a colored border. Quantity controls need the same treatment: a number input with a label, or clearly labelled increment buttons, with the current quantity announced. A customer returning one of two identical items needs to know which one the form has registered. Count and name are the information. Everything else is decoration.

## Reasons, labels, and deadlines

Return reason lists are frequently built as custom dropdowns or tile grids with poor keyboard support. A native select, or a radio group for the common reasons, is almost always the more accessible choice, and it degrades gracefully on mobile. If the reason selection changes what happens next, an exchange offer for one reason, a prepaid label for another, announce that change and keep the deadline information visible throughout, not just on the page before the form.

The label choice is another decision point that needs plain text: who pays for return shipping, what the refund timing is, and whether the refund goes to the original payment or store credit. If those facts only exist in a policy page, link them at the point of choice with their names as link text. A customer who discovers the restocking fee after submitting the return has not been informed. They have been processed.

## Confirmation and the error path

Confirmation is where return portals most often fail silently. The customer submits, the page reloads or swaps to a confirmation, and nothing announces the result. The confirmation should state the items, the expected refund amount, and how the label will arrive, in text, and it should be reachable by keyboard focus or announced through a live region. Include the return reference number as text the customer can copy, and send the same information by email, because the portal session is not where a customer stores a reference.

Errors in a return form must not wipe the selections. A missing reason should produce an error tied to the reason control, in words, with the order and items still selected when the customer returns to fix it. Losing a four step selection to a single missed field is the kind of failure that turns a routine return into a support call, and support calls about returns are the cost center this portal was supposed to reduce. Test the error path as carefully as the success path. It is where the money leaks.

## Related reading

If this topic is useful, these earlier guides go deeper on connected questions: [Product Comparison Tables a Screen Reader Can Actually Use](https://storefrontaccess.com/blog/2026-10-29-accessible-product-comparison-tables-screen-reader.md), [Delivery Instructions at Checkout: A Small Field, A Big Barrier](https://storefrontaccess.com/blog/2026-10-29-accessible-delivery-instructions-checkout-fields.md), and [Making Store Pickup Options Clear for Screen Reader Users](https://storefrontaccess.com/blog/2026-10-28-accessible-store-pickup-options-screen-reader.md).

## Frequently asked questions

### How should order history support returns accessibly?

List product names in the order row text, and give each return action a descriptive name that includes the order and its contents, instead of repeated identical return buttons. A screen reader user should find the right order without opening every one.

### What is wrong with clickable cards for item selection?

Their selected state is often shown only by color or a border, which assistive technology cannot convey. Use real checkboxes or radios with labels naming the product and variant, and labelled quantity controls, so the selection is announced.

### How should return reasons be presented?

As a native select or a radio group for the common reasons, with any consequence of the chosen reason announced and refund and shipping facts stated at the point of choice, not only on a separate policy page.

### What must a return confirmation include?

The items, the expected refund amount, how the label arrives, and the return reference as copyable text, announced or focusable, and repeated by email. Errors must be tied to the control that caused them and must not wipe the rest of the form.