How do you test a Shopify store with a screen reader?

Use a free screen reader, turn off your monitor or look away, and try to complete a purchase using only what you hear. Automated scans catch roughly a third of accessibility failures; the rest, unlabeled buttons, silent cart updates, keyboard traps, only show up when a human listens to the store. One focused hour with NVDA or VoiceOver finds more real barriers than a month of dashboard scores.

Pick your tools

On Windows, NVDA is free and is the most common screen reader in accessibility testing. On Mac, VoiceOver is built in and toggled with Command plus F5. Pair the screen reader with the browser your customers actually use, usually Chrome with NVDA or Safari with VoiceOver. Testing with an unusual combination can produce failures your customers never encounter and miss the ones they do.

You do not need to become fluent. Learn five commands: read next item, read previous item, activate the current item, jump to the next heading, and list all form fields. That small set covers nearly the entire purchase path. The goal is not expert operation; it is experiencing the store the way a customer who cannot see it does.

Walk the purchase path, not the homepage

Start on a product page, not the homepage. Add the product to the cart, open the cart, and check out. Demand letters cite purchase-path barriers far more than homepage issues, because the purchase path is where a blocked customer loses money. Listen for the moments that matter: does the screen reader announce that the item was added, or does the cart update silently? Can you find the quantity controls, or are they icon-only buttons with no labels? Does the checkout announce errors when a field is wrong, or do you have to hunt for red text you cannot see?

Test the dynamic parts twice. Shopify themes and apps update the page without reloading: variant pickers that change the price, slide-out carts, shipping calculators, discount code fields. Each dynamic update is a chance for the store to go silent. If the price changes on screen but the screen reader says nothing, a blind customer just made a decision with wrong information.

What to write down

Record failures as customer tasks, not code defects. "The Add to Bag button on product pages has no accessible name" becomes "a screen reader user cannot identify the add-to-cart button." Task framing keeps the report readable for non-developers and maps directly to legal risk, which is framed in terms of what customers cannot do.

For each failure, note the page, the component, and what you expected to hear. Screenshots help developers, but a short audio clip or a transcript of what the screen reader said is better, because it shows the failure exactly as the customer experiences it. Keep the notes dated. If a demand letter arrives later, dated evidence that you tested and fixed issues is worth far more than a claim that you care about accessibility.

Common Shopify findings

Icon-only buttons are the most frequent find: search, account, cart, wishlist, and menu icons that announce as "button" with no name. Next are app-injected components, review widgets, upsell popups, chat bubbles, that were never tested with assistive technology and often trap keyboard focus or announce nothing at all. Third are form problems at checkout and in contact forms: fields without labels, error messages that appear visually but are never announced, and required-field markers that only exist as red asterisks.

Fix in that order too. Named buttons and labeled forms are usually small theme edits. App components may require pressuring the vendor or replacing the app, which takes longer, so start those conversations early. And retest after every fix with the same screen reader and the same task list, because repairs frequently introduce new failures nearby.

What screen reader testing does not replace

It does not replace automated scanning, which is better at catching markup-level issues across hundreds of pages quickly. It does not replace keyboard-only testing, which finds focus and trap problems faster than listening does. And it does not replace testing with disabled users, who will find things your one-hour session never will. Screen reader testing is one layer in a program: automated scans for breadth, keyboard and screen reader testing for depth, and real user feedback for truth.