We turned off the monitor. Not the screen reader, the monitor. Then we opened a real, live Shopify store and tried to buy a plain black T-shirt using nothing but a keyboard and our ears.
We have run dozens of accessibility audits. We know the success criteria by number. We can quote them without looking them up. But this time we were not scoring a report from a distance. We were the customer, and the customer just wanted to check out.
It took us eleven minutes to buy one T-shirt. It should have taken two. Here is exactly where it fell apart, in the order we hit it, and what it actually took to fix.
The Stat: 95.9% of the top one million home pages have detectable WCAG 2 failures, averaging 56 errors per page. (Source: WebAIM Million, 2026)
Step one: the cart, and the one moment that actually worked
Adding the T-shirt to the cart was fine. The screen reader announced the product name, the price, the size selector, and a clear "Add to cart" button. We heard a confirmation that the item had been added. No confusion, no guessing. If every step had been built like this one, the whole trip would have taken ninety seconds.
That is the frustrating part of this kind of testing. It is rarely that a store ignored accessibility entirely. It is that one screen gets careful attention and the next one, built by a different template or a different app, does not.
Step two: shipping info, where the form went silent
The shipping form was where things started going wrong. Several fields, including the address line and the postal code box, had no announced label at all. The screen reader read out "edit text" with nothing else, so we had to tab backward, forward, and guess from placeholder text that vanished the moment we started typing.
This is a direct, textbook violation of one of the oldest rules in the book. Under WCAG 3.3.2 Labels or Instructions, any field that asks a user for input has to actually tell that user what it wants, and it has to do it in a way assistive technology can pick up, not just as visual placeholder text sitting inside the box.
The fix, once we found it, took under an hour: proper <label> elements tied to each input with a for attribute, visible or visually hidden, read every time the field gets focus. No design changes. No new app. Just labels that were supposed to be there in the first place.
Step three: payment, where we got stuck and could not leave
Payment was the low point of the whole experiment. A card-details widget, loaded inside an embedded iframe from a third-party payment processor, grabbed keyboard focus and would not let go. Tab moved between the card number, expiry, and CVV fields, but Shift+Tab back out of the widget did nothing. Escape did nothing. We were stuck inside three fields with no way back to the rest of the page.
That is exactly the scenario WCAG 2.1.2 No Keyboard Trap exists to prevent: once focus lands inside a component, a keyboard-only user has to be able to move it back out again, every time, with no special trick required. We eventually escaped by refreshing the page and losing our progress, which is not a workaround anyone should have to discover mid-purchase.
Step four: confirm order, where we could not tell if we had actually bought anything
After resubmitting payment, we clicked "Place order." Visually, a confirmation banner appeared. Audibly, nothing happened. The screen reader had no idea the page had changed, because the confirmation message was not placed in a live region. We sat there for a genuinely uncomfortable few seconds wondering whether we had just bought a T-shirt or broken something.
The checklist below is the same one our team now uses on every Shopify checkout we test, in the order the failures tend to appear.
| Step | What we tested | Result | Root cause |
|---|---|---|---|
| Cart | Labels, add-to-cart confirmation | Passed | Native Shopify markup, properly labeled |
| Shipping info | Field labels on address, postal code | Failed | Placeholder text used instead of real labels |
| Payment | Keyboard exit from embedded card widget | Failed | Third-party iframe trapped focus |
| Confirm order | Announcement of order confirmation | Failed | Confirmation message not in a live region |
A few things you can check on your own store in the next ten minutes, no tools required:
- Tab through your shipping form with a screen reader and confirm every field announces a real label, not just a placeholder
- Tab into any embedded payment widget and confirm you can Tab or Shift+Tab back out without refreshing
- Submit a test order and listen for whether the confirmation is actually announced, not just displayed
- Check Shopify's own accessibility statement against what your specific theme and checkout apps actually do, since the platform's baseline and your store's build are not the same thing
Why this kind of testing keeps finding what scanners miss
None of these four failures would have necessarily shown up on an automated scan of the homepage. The missing labels, the keyboard trap, the silent confirmation - all of them only surface when a real person tries to complete a real task with a real screen reader, start to finish. That is why screen-reader testing catches what automated scanners miss, and it is why we no longer treat an automated report as the finish line for a client's checkout flow. It is the starting point.
If you want the full method we use, our full checklist for running a WCAG audit yourself walks through the setup, the tools, and the order of operations we followed here. And if you are curious what specific criteria tend to trip up form fields and focus order, WCAG 3.3.2 Labels or Instructions and WCAG 2.1.2 No Keyboard Trap are the two we point people to most often, because they are the two we hit again and again on real checkouts.
We bought the T-shirt, eventually. Most customers would have given up at the payment step and bought it somewhere else. If you want someone to sit down, turn off the monitor, and run this exact test on your own store, we would be glad to. You can get a free screen-reader-tested audit of your own checkout and find out exactly where your customers are getting stuck before they tell you with a refund request or a support ticket.