Your Order Tracking Page Is an Accessibility Blind Spot

Almost every accessibility audit we see stops at the same place: the moment the customer clicks “Place Order.”

That makes sense. Checkout is where the money is, so checkout is where the attention goes. But the customer’s relationship with your store does not end at checkout. It arguably starts there. After the order, there is a confirmation page, a confirmation email, an order status page, a tracking widget pulling data from a carrier, a “where is my order” lookup form, and eventually a return or exchange request.

That whole stretch is what retail people call the post-purchase experience. For accessibility, it is usually untouched territory. And it is the part of the journey a customer visits over and over, sometimes daily, while they wait for a package.

Here is what goes wrong, and how to check your own store.

Why post-purchase gets skipped

There is a practical reason this area stays broken: it is hard to look at.

To see your own order tracking page, you have to place a real order. Most accessibility checkers, whether automated tools or consultants doing a manual sweep, work from public URLs. An order status page sits behind an order number and an email address, or behind a customer login. Automated scanners never reach it. Neither does the average audit.

The second reason is that most of this stretch is not really yours. The confirmation page is generated by your platform. The tracking widget is a third-party app. The returns portal is another vendor entirely. The shipping status comes from the carrier’s API. Nobody on your team wrote this code, so nobody on your team thinks to test it.

Which means the failures survive for years.

The five things that break

1. Order status conveyed only by color and icon

The classic tracking display is a horizontal progress line: Ordered, Packed, Shipped, Out for Delivery, Delivered. Completed steps get a green filled circle with a checkmark. The current step gets a highlighted dot. Future steps are grey.

If that state lives only in the color and the shape of the dot, a screen reader user hears five words in a row with no indication of which one is current. A colorblind customer looking at the same widget cannot always tell green from grey at small sizes. The single most important piece of information on the page, where is my package right now, is the thing that is not available as text.

The fix is simple and free: the current status needs to exist as words. “Status: Shipped, 2 of 4 steps complete” as readable text near the tracker, not just implied by a filled circle. If the widget you use cannot do that, put the status in a plain sentence above the graphic yourself.

2. Live status updates that never get announced

Modern tracking pages poll for updates and swap the status in place. The page does not reload; the text just changes from “Preparing your order” to “Shipped.”

For a sighted customer that is a nice touch. For a screen reader user it is invisible. Content that changes silently in the middle of a page is content that does not exist, because the screen reader has already read past that point and has no reason to go back.

This is what live regions are for. A container marked as a polite live region tells assistive technology to announce changes inside it when the user is not busy. This is a one-attribute change that a developer can make in minutes, and it is worth asking your platform’s support team whether their tracking component supports it.

The same problem shows up on the “where is my order” lookup form. Someone types an order number, hits Enter, and the results appear below the form. Visually obvious. Announced to nobody.

3. Order confirmation pages that bury the confirmation

The confirmation page after checkout has one job: tell the customer the order went through. In practice it often opens with a marketing banner, a “you might also like” carousel, and a newsletter signup, with the actual order number somewhere in the middle.

Screen reader users navigate by headings. If the page’s first heading is “Recommended For You,” the confirmation is not what they land on. Worse, some platforms make the confirmation a visually styled block with no heading at all, so it does not appear in the heading list.

The confirmation needs to be the first meaningful heading on the page, and the order number needs to be selectable text, not baked into an image or a decorative graphic. This sounds obvious. Go look at yours.

4. Tracking numbers that are unreadable when spoken

A tracking number is a long string of digits and letters. Screen readers read long unbroken strings in unpredictable ways, sometimes as a single enormous number, sometimes character by character, depending on the software and the punctuation around it.

Customers frequently need to read that number aloud to a carrier’s phone system or copy it into another site. If the only way to get it is to listen to a screen reader guess at a 22-character string, that is a real barrier with a real workaround cost.

Two things help. First, provide a copy button with a proper label, so the customer can move the number without transcribing it, and announce that the copy succeeded. Second, make the number a real link to the carrier’s tracking page where possible, so most customers never need to handle the raw string at all.

5. Returns and exchange portals that fail at the first step

Return portals are almost always third-party, almost always embedded in an iframe, and almost always the least tested surface in the whole store.

The common failures cluster at the start. The lookup form asks for an order number and email with placeholder text instead of real labels, so a screen reader user hears “edit text, blank” twice and has no idea what goes where. Reason-for-return is a set of custom-styled radio buttons that cannot be reached with the keyboard. Photo upload for a damaged item is a styled button with no accessible name, which announces as just “button.” And the confirmation that the return was submitted appears in a toast that vanishes after four seconds without ever being announced.

A customer who cannot complete a return does not shrug and give up. They call, they email, they file a chargeback, or they leave a review. Every one of those costs more than fixing the form would have.

How to check yours in about twenty minutes

You do not need DevTools for this. You need a real order.

Place a test order on your own store. Use a real product and refund yourself afterward. You need the actual confirmation page and the actual tracking page, not a staging mockup.

On the confirmation page, press Tab from the top. Watch the focus indicator move. Can you see where you are at every step? Does the focus ever disappear behind a sticky header or into an invisible element? Can you reach every link and button without a mouse?

Now find the order number using only headings. Turn on your screen reader (VoiceOver on Mac with Command+F5, Narrator on Windows with Windows+Control+Enter) and pull up the heading list. Is the confirmation near the top, or is it buried under promotional content?

Go to the tracking page and read the status out loud. Not the graphic, the text. If you cannot state your order’s current status by reading words on the page, neither can a screen reader user.

Zoom the browser to 200 percent. Does the tracking timeline still work, or does it overflow horizontally and clip the last two steps? Progress trackers are notoriously fragile at high zoom because they are laid out as fixed-width horizontal rows.

Start a return without touching your mouse. Tab into the returns portal, select a reason, and get to the confirmation. This is where most stores fail, and it is the failure most likely to generate a support ticket.

Check the confirmation email too. Open it and look for images carrying text, a status graphic with no alt text, and link text that just says “click here.” Order emails are HTML documents and the same rules apply to them.

The business case, briefly

Post-purchase pages have unusually high repeat traffic. A customer who orders once may check tracking five times. If the status is unreadable, that is five frustrating visits and often a support contact, which for most stores costs more than the margin on the order.

There is a compliance angle as well. Under the ADA in the US and the European Accessibility Act in the EU, the obligation covers the service you provide, not just your landing pages. An e-commerce service includes the part where the customer finds out what happened to their order and how to send it back. A store with a flawless, audited checkout and an unusable returns portal has an accessible sales funnel and an inaccessible service, and that distinction has not protected anyone.

The good news is that this stretch of the journey is small. It is maybe five pages and one email. Compared to auditing an entire catalog, checking your post-purchase flow is a short afternoon, and it covers the pages your customers see most often while they are already anxious about where their money went.

Start with the tracking status text. If a customer cannot read their order status as words, nothing else on the page matters.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.