Screen reader testing for ecommerce: a practical guide

Automated accessibility scanners catch 30-40% of WCAG violations. The other 60-70% require manual testing with real assistive technology. For ecommerce stores, that means running a screen reader through your checkout flow and listening for what breaks.

This guide covers which screen readers to use, which flows to test and exactly what to listen for. It is written for developers and QA engineers who have not done this before but need to do it properly. Pair this with keyboard navigation testing for complete manual coverage.

Which screen readers to use

Screen reader behavior varies significantly by browser and operating system. You need to test the combinations your users actually use, not just the one that is convenient for you.

NVDA with Chrome on Windows

NVDA (NonVisual Desktop Access) is free, open source and the most widely used screen reader globally. The WebAIM Screen Reader Survey (2024) found that NVDA is used by 40.4% of screen reader users. Pair it with Chrome, which is the most common browser among screen reader users for web tasks.

Download NVDA from nvaccess.org. Install it, open Chrome and start NVDA. Press Insert+N to open the NVDA menu if needed. The key commands you need: Arrow keys to read line by line, Tab to move between interactive elements, H to jump between headings, F to jump between form fields, B to jump between buttons.

JAWS with Chrome or Edge on Windows

JAWS (Job Access With Speech) is the most common screen reader in enterprise and corporate environments. It is paid software ($95-$1,500 per year depending on license). The 40-minute free demo mode is sufficient for testing. Use it with Chrome or Edge.

JAWS has slightly different behavior from NVDA in some edge cases, particularly around ARIA live regions and dynamic content. If your store has a meaningful enterprise or B2B component, test with JAWS.

VoiceOver with Safari on macOS

VoiceOver is built into every Mac. Press Command+F5 to turn it on. Use it with Safari, not Chrome. VoiceOver on macOS behaves very differently in Chrome versus Safari, and most Mac screen reader users use Safari.

Key commands: VO (Control+Option) plus Arrow keys to navigate, VO+Space to activate, VO+Command+H to jump headings, VO+Command+J to jump form fields. The Web Rotor (VO+U) gives you a menu of page elements organized by type.

VoiceOver with Safari on iOS

Enable in Settings, Accessibility, VoiceOver. Swipe right to move forward through elements, swipe left to move back, double-tap to activate. A single tap reads the element under your finger without activating it.

Mobile checkout is where many ecommerce stores have the worst accessibility. Test this separately from desktop. Common failures on mobile include touch target sizes below 44x44 pixels, popups that trap focus and forms that do not trigger the correct keyboard type (numeric keyboard for credit card fields, for example). Our mobile ecommerce accessibility guide covers these patterns in detail.

TalkBack with Chrome on Android

TalkBack is Google's screen reader for Android. Enable in Settings, Accessibility, TalkBack. Navigation is similar to VoiceOver on iOS. TalkBack is the right choice for testing your Android mobile experience.

For most ecommerce stores, prioritize NVDA+Chrome (largest user base), VoiceOver+Safari macOS (important for Apple-heavy demographics) and VoiceOver+Safari iOS (mobile checkout). Add JAWS if you have B2B customers.

Setting up for testing

Before you start, turn off your monitor or close your eyes. Seriously. The point of screen reader testing is to understand the experience without visual reference. If you can see the screen, you will unconsciously use visual context to compensate for audio gaps, which masks real problems.

Set speech rate to something you can actually follow. Experienced screen reader users run at speeds that sound like gibberish to newcomers. Start slow. The default NVDA rate is fine for testing.

Clear your browser cookies and test as a guest user. Then repeat as a logged-in user. The experiences often differ significantly.

The testing protocol: flows to test

Flow 1: Product discovery and browsing

Start on the homepage. Navigate with Tab to reach the main navigation. Ask yourself: does the screen reader announce what section you are in? Is there a skip navigation link that lets you jump past the header to the main content?

Navigate to a category page using the H key to jump between headings. Can you tell where the product grid starts? Are product cards announced with useful information (product name, price, whether it is in stock)? Or does the screen reader read "link, link, link" with no context?

Test the product filter. If your store has a faceted filter sidebar, tab into it. Can you check and uncheck filter options with the keyboard? When you apply a filter, does the screen reader announce that the product list has updated? This requires a properly implemented ARIA live region. Without it, filter changes are silent.

Flow 2: Product page

Navigate to a product detail page. Check heading structure first using H to jump headings. The product name should be an H1. Sections like description, reviews and related products should use H2 or H3 in logical order.

Test variant selection. If the product has size or color options, are these announced as what they are? A radio group with proper labels reads as "Size, Small, radio button, 1 of 4" which is clear. A set of divs styled as buttons reads as nothing, or as arbitrary text.

Find the Add to Cart button. Tab to it. Does the screen reader announce "Add to Cart, button"? Or does it read the button's text correctly but not announce it as a button? Or, worst case, does it announce nothing?

Activate Add to Cart. What happens? Does the screen reader announce that the item was added? This is a critical live region. Without it, users have no feedback that their action succeeded. They may add the same item five times trying to get confirmation.

Flow 3: Cart

Navigate to the cart page. Is the cart contents table or list read in a logical order? For each item, does the screen reader announce: product name, quantity, price? Or does it announce them in a scrambled order, or skip some entirely?

Test the quantity controls. Most stores use plus and minus buttons. Are these labeled? "Button, plus" is not useful. "Increase quantity of Blue T-Shirt, button" is. Without a label, users cannot distinguish which item's quantity they are changing in a multi-item cart.

Test Remove Item. Does activating remove announce that the item was removed and that the cart has been updated? Or does the page silently update without any announcement?

Find the Proceed to Checkout button. Tab to it. Activate it.

Flow 4: Checkout

Checkout is the highest-priority flow. This is where accessibility failures directly prevent purchases from completing.

Press F (in NVDA) to jump through form fields. Listen to what each field announces. A properly labeled field announces the label first, then the field type: "Email address, edit." An unlabeled field announces only "edit" or the placeholder text. Placeholder text disappears when you start typing, so it cannot serve as a label. Any field that relies on placeholder text as its label is a violation.

Fill in the email field. Tab to the next field. Does focus move logically from field to field? Or does focus jump unexpectedly, skip fields or get trapped?

Test error states. Submit the checkout form without filling in required fields. Does the screen reader announce which fields have errors? Are error messages programmatically associated with their fields? A red border and red text next to a field is purely visual. Without an aria-describedby linking the error message to the field, screen reader users receive no error information.

Test the payment section. Credit card inputs from third-party payment processors (Stripe, Braintree, Adyen) are common failure points because they use iframes. The iframe must have a meaningful title attribute. Without it, the screen reader announces "frame" with no context when focus enters the payment section.

Complete the checkout if possible. Does the confirmation page announce success clearly?

Flow 5: Account creation and login

Test account creation form for label associations and error handling. Test the login form. Test password recovery. These are lower priority than checkout but still common in demand letters.

What common failures sound like

Knowing what to listen for is the hardest part for first-time testers. Here are specific failure patterns and what they sound like:

• Missing form label. You tab to a field and hear "edit" or "edit, blank" with no description of what the field is for. Or you hear the placeholder text ("Enter your email") which disappears when you start typing.
• Icon-only button. You tab to a button and hear "button" with no other text. Or you hear the icon file name: "search-icon-32.png, button." This happens when buttons have only icon content and no aria-label.
• Missing cart update announcement. You activate Add to Cart and hear nothing. The page may have visually updated the cart count in the header, but without a live region, the screen reader does not announce it.
• Filter result update not announced. You check a filter option and silence. The product grid updated visually but the screen reader received no notification. The user does not know if their action worked.
• Modal focus not trapped. A size guide popup opens. You press Tab expecting to navigate within the popup. Instead, focus moves behind the popup to the page underneath. The popup is visually present but you are navigating invisible content behind it.
• Inaccessible dropdown. A custom dropdown for selecting size or color does not respond to arrow keys. Pressing Space or Enter on it does nothing. It only works on mouse click.
• Image missing alt text. A product image announces the file name: "IMG-4291-LIFESTYLE-CROP.jpg, image." A well-implemented image announces: "Blue cotton T-shirt worn on model, outdoor setting."
• Checkout error not announced. You submit the form with an empty required field. The page adds a red border to the field and text that reads "This field is required." The screen reader announces nothing because focus did not move to the error message and there is no live region announcing validation errors.

What to document

For each failure, record: the screen reader and browser combination, the page and flow step where the failure occurred, what was announced versus what should have been announced and the relevant HTML element (inspect the DOM to find it). This documentation is what your developers need to fix the issue and what you need to demonstrate compliance efforts if challenged.

What automated tools miss that you will catch

The violations that screen reader testing catches and automated tools miss include: focus order that is technically valid but confusing in practice, live regions that exist in the markup but are not triggered on dynamic updates, keyboard traps in modals and dropdowns, payment iframe titles that are present but meaningless ("iframe" is technically valid but useless) and error handling that passes HTML validation but provides no accessible feedback.

These are the violations that cause real usability failures. They are also the ones most likely to appear in ADA demand letters, because plaintiff attorneys typically test sites with screen readers before filing.

How often to test

Run a full screen reader test of all critical flows quarterly at minimum. Run it after any major theme update, checkout change or new third-party app installation. Automated monitoring between manual tests catches regressions that would otherwise go undetected until a user reports a problem, or until a demand letter arrives.

The goal is not a perfect score on one test. The goal is a process that catches new violations before they reach users or lawyers.

Frequently asked questions

Which screen reader should I use to test my ecommerce store?

Prioritize NVDA with Chrome on Windows (used by 40.4% of screen reader users), VoiceOver with Safari on macOS and VoiceOver with Safari on iOS for mobile checkout. Add JAWS if you have B2B customers. Always pair screen readers with their recommended browsers for accurate results.

What percentage of WCAG violations do automated tools miss?

Automated accessibility scanners catch only 30-40% of WCAG violations. The remaining 60-70% require manual testing with real assistive technology. Focus order issues, live region failures, keyboard traps and meaningless iframe titles are common violations that only screen reader testing reveals.

How often should I run screen reader tests?

Run a full screen reader test of all critical flows quarterly at minimum. Run additional tests after any major theme update, checkout change or new third-party app installation. Automated monitoring between manual tests catches regressions that would otherwise go undetected.

What does a missing form label sound like on a screen reader?

When you Tab to an unlabeled input field, the screen reader announces only "edit" or "edit, blank" with no description of what the field is for. A properly labeled field announces the label followed by the field type, such as "Email address, edit."