Screen reader testing for e-commerce: a practical guide
Automated accessibility scanners are reliable for a specific class of issues: missing alt text, absent form labels, incorrect ARIA roles, color contrast failures. These are structural problems that tools can detect from the DOM alone. But a meaningful portion of the failures that screen reader users actually encounter do not show up in automated scans at all.
Focus management problems -- where focus goes when a cart drawer opens, where it returns when a modal closes, whether a filter panel's state is announced -- require a running browser with real user interaction to observe. Reading order that looks correct in the DOM but is scrambled by CSS positioning only becomes apparent when you hear it read aloud. Error messages that appear visually but are never announced to assistive technology are invisible to any static analysis tool.
Research consistently puts automated tools at detecting roughly 30 to 57 percent of WCAG issues. The rest require manual testing. For e-commerce sites, where purchase flows involve modals, drawers, dynamic updates, and multi-step forms, the manual portion matters more than on most other site types.
This guide covers how to do basic screen reader testing on e-commerce sites, what to look for in each major flow, and what failures are most likely to be invisible to automated scans.
Which screen reader to use
Three screen readers cover the vast majority of assistive-technology users:
- NVDA (Windows, free) -- used by roughly 40% of screen reader users globally, per the WebAIM Screen Reader Survey. Pairs with Firefox. Download at nvaccess.org.
- JAWS (Windows, commercial) -- the dominant choice in enterprise and corporate environments. If your audience includes business purchasers, JAWS behavior matters. A 40-minute trial mode is available without a license.
- VoiceOver (macOS and iOS, built-in) -- enabled in System Settings under Accessibility. On Mac, pairs with Safari. Activate with Command + F5 or the Touch ID shortcut if configured.
For most e-commerce testing, NVDA with Firefox is the practical starting point: it is free, straightforward to install, and representative of a large portion of real users. If you discover issues there, verify them in VoiceOver before prioritizing a fix -- cross-screen-reader inconsistency is common, and some behaviors are browser or screen reader quirks, not site bugs.
TalkBack (Android) and VoiceOver on iOS matter for mobile. Mobile-specific issues are a separate testing track and beyond the scope of this guide.
Core navigation commands
Screen readers operate in two modes. Browse mode (sometimes called reading or virtual mode) lets the user move through page content with arrow keys. Forms mode (or application mode) activates when focus enters an interactive control; arrow keys operate the control rather than moving through content. NVDA and JAWS switch between these modes automatically; knowing that the switch is happening explains behaviors that otherwise feel like bugs.
| Key | What it does |
|---|---|
Tab |
Move to the next focusable element (links, buttons, inputs) |
Shift+Tab |
Move to the previous focusable element |
H |
Jump to next heading |
1 through 6 |
Jump to next heading of that level (1=h1, 2=h2, etc.) |
B |
Jump to next button |
F |
Jump to next form field |
K |
Jump to next link |
G |
Jump to next graphic |
T |
Jump to next table |
Ins+F7 |
Show list of all links on the page |
Ins+F6 |
Show list of all headings on the page |
Ins+F5 |
Show list of all form fields on the page |
Enter |
Activate a link or button |
Space |
Activate a button, check a checkbox, open a select |
Arrow keys |
Read adjacent content (browse mode) or operate a control (forms mode) |
Ins+Space |
Toggle between browse and forms mode |
Ins+Q |
Quit NVDA |
For VoiceOver on Mac, the modifier key is Control+Option (abbreviated VO). VO+Right and VO+Left move through content; VO+Space activates a control; VO+U opens the rotor (a list of headings, links, form controls, and other landmarks).
Control to stop speech. You can slow the speech rate in NVDA Settings under Speech. Starting at 70-80% of the default rate makes it easier to follow during initial testing.
What to test on e-commerce sites
Rather than testing every page, focus on the flows that matter most for users and that carry the highest litigation risk: homepage navigation, product discovery, the product detail page, cart, and checkout. Testing these five areas will surface the majority of meaningful barriers.
1. Homepage and navigation
Skip link: The first Tab press should activate a "Skip to main content" link. Press Enter on it and verify focus moves past the header directly to the main content area. If no skip link appears, or if it appears but Enter does nothing, that is a WCAG 2.4.1 failure.
Main navigation: Tab through the header. For each top-level navigation item with a dropdown: press Enter or Space to open it and verify the dropdown opens. Then verify you can Tab into the dropdown items, activate one, and reach the destination page. If the dropdown only opens on hover and there is no keyboard equivalent, it is unreachable.
Heading structure: Press H to jump through headings. The page should start with a single H1 (usually the brand name or a hero headline), followed by logical H2/H3 sections. Promotional content, featured categories, and editorial sections that appear as headings visually should have actual heading markup. If jumping H-H-H reads a collection of promotional slogans that are not announced as headings, the visual hierarchy is not reflected in the markup.
Search: Tab to the search field. Type a query and submit it. Verify the results page announces how many results were found (usually a live region update or a clearly labeled results heading). Navigate the results list using heading or link shortcuts.
2. Product listing pages
Product cards: Tab through the product grid. For each card, note what is announced: ideally the product name, price, and any status (sale, sold out, new). A card that reads only "link" or announces an image filename as the name is an image-alt or link-name failure.
Filters and sorting: Activate a filter panel or sort control. Verify the panel state is announced (announced as expanded or collapsed). After applying a filter, verify the results update is announced -- typically via a live region that says "12 products" or similar. If applying a filter silently reloads the product grid with no announcement, users navigating by screen reader have no way to know the page changed.
Pagination: At the bottom of a results list, verify the current page is indicated in the pagination control (aria-current="page") and that the next/previous links have descriptive labels ("Page 2", not just "2").
3. Product detail pages
The product detail page has the highest density of interactive controls and the most common failures.
Product images: Tab to the main product image. It should be announced with a meaningful description ("Navy blue wool coat, front view"), not the filename ("img_product_5891.jpg") and not silence (a presentational image incorrectly bearing an unlabeled link).
Image gallery: If a thumbnail gallery is present, Tab through the thumbnails. Each should have a unique, descriptive label ("Coat shown from the back" or at minimum "Image 2 of 5"). Activating a thumbnail should move the main image and ideally announce which image is now showing via a live region.
Color and size selectors: These are among the most common failure points. Tab to the color or size selector. For each option, verify its name is announced (not just "button" or "radio button"). For the selected option, verify its selected state is announced ("Royal Blue, selected" or "Small, checked"). Custom button-based selectors that do not communicate selected state, or that announce the same unlabeled name for every option, make it impossible to choose a variant.
Quantity input: Tab to the quantity field. Verify it has an associated label ("Quantity") rather than relying on visible placeholder text that disappears when you type.
Add to cart button: Verify the button has a descriptive label. "Add to cart" is fine. Just "Add" or an icon button with no label is not.
Cart update notification: After activating Add to Cart, listen for an announcement that the item was added. Sites that update a cart count icon silently -- no announcement, no focus movement, no live region -- leave screen reader users unsure whether the action succeeded. They may activate the button multiple times.
4. Cart
Cart drawer (if used): When the cart drawer opens, focus should move into it. Tab through the drawer contents. When you close the drawer (Escape or a close button), focus should return to the element that triggered it. A drawer that opens without moving focus, or closes and drops focus to the top of the page, is a focus management failure.
Cart page: On a full cart page, verify each line item reads product name, variant (size, color), quantity, and price. Quantity controls (stepper buttons or input) should have labels. Remove buttons should identify what they remove ("Remove Navy Wool Coat" not just "Remove" -- if there are multiple items, "Remove" is ambiguous).
5. Checkout
Checkout is the highest-stakes area. A user who cannot complete checkout cannot buy.
Form labels: Tab through each checkout field. Verify every field has an announced label: "First name", "Email address", "Street address". Fields labeled only with visible placeholder text lose their label the moment you type. Fields that appear visually labeled by adjacent text ("Card number" in a column header) but have no programmatic label association are a WCAG 1.3.1 and 4.1.2 failure.
Validation errors: Submit the form with intentionally missing or incorrect values. Verify that errors are announced automatically, not just displayed visually. The typical correct pattern: the page scrolls to a summary error ("There are 3 errors") announced via a live region, with individual field errors linked by aria-describedby so that tabbing to the field reads both its label and its error message. A common failure: red asterisks appear next to invalid fields and the border turns red, but no announcement is made and the user has no idea which fields failed.
Autocomplete: On the shipping address form, verify that fields have appropriate autocomplete attributes (autocomplete="given-name", autocomplete="postal-code", etc.). This enables browser autofill via keyboard, which dramatically reduces the input burden for users with motor disabilities.
Multi-step checkout: If checkout spans multiple steps, verify that the current step is indicated and announced when you advance ("Step 2 of 3: Shipping"). Focus should move to the top of the new step content, not stay on the "Continue" button that is no longer visible.
Order confirmation: After completing a test order (if feasible), verify the confirmation page announces the order summary clearly. "Order confirmed, order number 12345" as the page heading is sufficient. A confirmation that reads only a graphic banner or marketing content without the order details is a usability failure.
Failures that automated tools reliably miss
The following categories of failure almost never appear in automated scan results. They require screen reader testing to discover.
Focus management after dynamic events. When a modal opens, a drawer slides in, or a toast notification appears, where does focus go? Automated tools see the modal in the DOM; they cannot observe where focus was before the event or whether the open/close sequence was handled correctly. Manual testing is the only way to verify this.
Announced state of custom controls. A custom toggle switch built from a div might have aria-checked="true" in its initial state. But does aria-checked update to "false" when activated? Automated tools check whether the ARIA attribute is present; they do not simulate interaction. Only manual testing confirms state changes are announced.
Reading order in CSS-positioned layouts. Two-column layouts that place a sidebar before the main content in the DOM but visually to the right of it cause screen reader users to encounter sidebar navigation before the page's primary content. The DOM order is what the screen reader reads; visual order is irrelevant. A tool that checks for valid ARIA and present labels will not catch a wrong-order DOM.
Timeout announcements. Checkout sessions often expire after inactivity. If a timeout warning appears on screen with no announcement, a screen reader user navigating slowly through a long form will not notice it. They complete checkout, submit, and find their session expired with no explanation. This is a WCAG 2.2.1 failure and common in checkout flows.
Live region content quality. A cart update might be announced ("Item added") but the content might be so brief it is missed in the flow of other announcements. Or a product filter might update a live region that says "filtered" without saying how many results remain. Tools can confirm a live region exists; only listening to it confirms whether the message is useful.
CAPTCHA and third-party challenges. CAPTCHA widgets at checkout or account creation are notoriously inaccessible. Automated tools flag that a CAPTCHA exists and may flag missing labels, but the actual interaction -- can a screen reader user solve it? -- requires manual testing against the live widget.
Setting up a testing environment
For Windows testing with NVDA:
- Download NVDA from nvaccess.org (free, no account required). Install it.
- Open Firefox (not Chrome; NVDA has better compatibility with Firefox for most controls).
- Start NVDA from the Start menu or your desktop shortcut. You will hear "NVDA started."
- Navigate to your site. Press Control to stop initial speech.
- Use the keys in the table above. When you want to activate a link or button, Tab to it and press Enter.
- When done, press Ins+Q to quit NVDA.
For Mac testing with VoiceOver:
- Open System Settings, go to Accessibility, and turn on VoiceOver. Or press Command+F5.
- Open Safari.
- Navigate to your site. VoiceOver begins reading immediately.
- Use Control+Option+Right/Left to move through content; Control+Option+Space to activate controls. Control+Option+U opens the rotor for quick navigation by headings, links, or form controls.
- Press Command+F5 again to turn VoiceOver off when done.
How manual testing relates to automated scanning
Automated scanning and manual screen reader testing are complementary, not interchangeable. Automated tools are fast, consistent, and repeatable -- they run on every page at every deploy without human effort. They are reliable for structural failures that do not depend on interaction: missing alt text, absent labels, invalid ARIA usage, contrast ratios. Running automated scans as a baseline catches a large portion of issues before any manual work is done.
Manual screen reader testing covers the interaction layer that automated tools cannot reach. It is slower and more expensive to run, so it makes sense to run it on the flows that matter most rather than on every page. For most e-commerce sites, that means the product detail page, cart, and checkout at minimum.
A reasonable testing cadence for a small to mid-size store: automated scanning on a continuous basis (weekly or after deploys), manual screen reader testing for the checkout flow any time the checkout template changes, and a full manual pass on new feature types (a new cart drawer, a new filter panel design, a new multi-step checkout).
The goal of either form of testing is the same: identify barriers before users encounter them, fix them in the correct place in the code (not with an overlay widget that patches the DOM after the fact), and confirm the fix works by re-testing the fixed interaction.
BarrierScan runs automated axe-core scans across your site and generates a prioritized finding report. We cover the structural failures that automated tools reliably detect. For the interaction-layer issues described in this guide, we document what automated testing found and recommend manual testing scope for the highest-risk flows.