Ecommerce Website Accessibility Audit: What to Test Across Product Pages, Cart and Checkout

An ecommerce website accessibility audit differs from a general website audit in one specific way: the thing you are testing is not a page, it is a transaction.

A marketing site fails accessibility when someone cannot read an article. A store fails when someone cannot buy. That difference changes what you test, the order you test it in, and how you rank what you find.

This guide covers what to test at each stage of the purchase path. It applies to any platform. Where a problem is specific to how Shopify themes or apps are built, that is noted, because Shopify stores share a set of failure patterns that are worth knowing about.

Why Ecommerce Accessibility Testing Is Different

Ecommerce accessibility testing has to account for three things that most website audits do not.

The failure points are concentrated in the last few steps

Browsing is usually the accessible part. Product grids are mostly links and images, and those tend to be reasonable even on poorly built sites. The barriers cluster where interaction starts: variant selectors, quantity steppers, cart drawers, discount fields, address forms, payment.

That matters commercially. A blocked customer on a blog post leaves quietly. A blocked customer in checkout has already decided to buy and cannot complete it, which is why checkout barriers are both the most expensive to you and the most damaging in a complaint.

Most of the page is generated, not written

A product page is a template rendered several hundred times with different data. That cuts both ways. One bad snippet becomes three hundred violations, and one fix resolves all of them. It also means testing every URL is pointless. You test templates and journeys.

Third-party code sits on top of everything

Reviews, popups, chat, filters, loyalty, currency switchers. Each injects its own markup into pages you did not write. On a typical store the apps introduce a meaningful share of what an audit finds, and you remain responsible for how the storefront behaves even when the code came from somewhere else.

Product Listing Pages, Filters and Sorting

This is where a shopper decides whether your store is usable at all. Two tests matter most here.

Link names that stand alone

Screen reader users frequently navigate by pulling up a list of every link on the page, out of context. On a badly built collection page that list reads:

Every product looks identical. The fix is not complicated, but it is easy to get wrong in a way that looks fine visually:

Filters that announce their own results

The common failure: a shopper ticks "Size M", the grid silently refreshes, and nothing tells them anything happened. Sighted users see the change. Everyone else waits.

How to test it: turn on a screen reader, apply a filter, and listen. If you hear nothing between ticking the box and the page settling, that is a failure of WCAG 4.1.3 Status Messages.

Also check: filter groups wrapped in fieldset with a legend, so the question being answered is clear; applied filters individually removable by keyboard; and price range sliders that offer a non-dragging alternative, since WCAG 2.2 requires one.

Product Pages: Variants, Images and Errors

The product page is where most ecommerce accessibility audits find their highest-severity issues. For a deeper, hands-on look at this stage, see our guide to Shopify product page accessibility.

Variant selectors

Colour swatches are the single most common serious failure on product pages. A row of coloured circles with no text conveys nothing to a screen reader user, and nothing to a colourblind shopper trying to distinguish two similar shades.

How to test it: tab to the swatches. Can you reach them at all? Can you change selection with arrow keys? Does each announce a colour name rather than "button"?

Radio inputs give you arrow key navigation, grouping and selected state without writing any JavaScript. The visible label can be hidden from sighted users with CSS if the design calls for swatches alone, but it must remain in the accessibility tree.

Also check what happens when a variant is unavailable. "Out of stock" shown only by greying out a swatch fails WCAG 1.4.1, because colour is carrying the information on its own.

Product images

Alt text on product images is the most-cited violation in ecommerce and the easiest to fix badly. Filenames are useless. So is repeating the product title, which the screen reader has just read from the heading.

The useful test is not "does alt text exist" but "could someone choose between two similar products using only what they hear". Gallery thumbnails need distinct descriptions for the same reason; four images all reading "product photo" tell a shopper nothing about which angle they are looking at.

Errors on the product page

Try adding to cart without choosing a size. Most stores show a message in red near the button. Two questions: is it announced, and does focus move to it? If the answer to both is no, a screen reader user hears silence after pressing a button and has no way to know why nothing happened.

Cart, Discount Fields and Validation

The cart is where the most-missed failure lives, and it is worth testing carefully.

The cart drawer

Slide-out carts are close to universal now, and a large proportion of them are broken in the same way: the drawer opens visually, but keyboard focus stays on the page behind it. The shopper presses Tab and moves through hidden content they cannot see, never reaching the checkout button inside the drawer.

How to test it in thirty seconds:

1. Add something to the cart using the keyboard.
2. When the drawer opens, press Tab once.
3. Did focus land inside the drawer, or somewhere behind it?
4. Press Escape. Does the drawer close?
5. After it closes, where is focus? It should be back on the cart button.

Any "no" is a WCAG 2.1.2 or 2.4.3 failure, and it blocks the purchase outright. We have written up the code for fixing cart drawer focus in detail, including the focus trap.

Quantity and remove controls

Three items in the cart, three buttons that all announce as "Remove". Which one is about to be activated? The shopper has no way to know.

And when the subtotal changes after an update, that change needs announcing through a live region, the same pattern as filter results.

Discount code fields

A small field that causes a disproportionate amount of trouble. Test all three outcomes:

Form validation generally

The pattern that works, and that surprisingly few stores implement: on a failed submission, move focus to the first field with an error, make sure the error text is programmatically associated with that field, and describe how to fix it rather than just stating it is wrong.

"Invalid email" tells someone nothing. "Email must include an @ symbol, for example name@example.com" tells them what to do.

Checkout: Keyboard and Screen Reader Testing

Before testing, establish what you can actually change. On hosted checkouts you often cannot edit the checkout page itself. Shopify locks it on every plan below Shopify Plus, and some other platforms are similar.

That is less limiting than it sounds, because in practice the barriers are rarely on the checkout page. They are in the cart drawer, the express payment buttons and the apps that sit in front of it. Customers get stuck before they arrive.

The keyboard run

Put the mouse away. Genuinely away, not just unused. Then complete a full purchase:

1. Tab through email, name, address, shipping method, payment.
2. Select the shipping option with Arrow keys, not Tab.
3. Watch the focus indicator constantly. Is it always visible? Does a sticky header ever cover the focused field?
4. Deliberately enter an invalid email and continue. Is the error announced? Does focus move to it?
5. Complete the order with Enter.

On Safari for Mac, turn on full keyboard access first, in Settings under Advanced. Otherwise you will record failures that are actually browser settings.

Express checkout buttons

Shop Pay, PayPal, Apple Pay and Google Pay buttons are usually images or brand logos, and frequently have no accessible name. A shopper tabbing through hears "button, button, button" with no way to tell them apart. Each needs a name, and the group benefits from a label explaining what these buttons are.

The screen reader run

Keyboard testing proves a control can be reached. Screen reader testing proves it makes sense when announced. These are different failures, and you need both.

Test with both if you can. They disagree more often than people expect, and a pattern that works in one can be silent in the other. Declaring conformance after testing a single screen reader is a shortcut worth avoiding.

Third-Party Apps, Popups and Review Widgets

Test each app individually, because they fail in different ways and because you need to know which one to blame.

A practical method: disable your apps one at a time in a staging environment and re-run a short keyboard pass. It is slower than scanning, but it tells you precisely which app introduced which problem, which is the information you need in order to decide between configuring it, replacing it, or removing it.

For a fuller treatment of which categories cause the most trouble, see our guide to Shopify apps and accessibility. The patterns hold on other platforms too, since most of these apps ship the same widget everywhere.

Automated Scans Versus Manual Testing

Both belong in an ecommerce WCAG audit. The mistake is treating one as a substitute for the other.

Roughly a third of WCAG success criteria are machine testable. That figure gets quoted a lot and the exact number varies by who is counting, but the direction is not in dispute: a clean automated scan does not mean an accessible store. It means the machine-detectable problems are fixed.

A scanner will happily report zero errors on a product page whose colour swatches cannot be reached with a keyboard, because every element on that page is technically valid.

What an Ecommerce Accessibility Audit Report Should Contain

The report is what you are actually buying when you commission an ecommerce website accessibility audit, so if you are comparing web accessibility audit services for ecommerce sites, this is the part to ask about before you pay. The report is the deliverable, and the difference between a good one and a scanner export is enormous.

That last point is worth dwelling on. One bad snippet rendering across 300 products is a single finding with a count of 300, not 300 findings. Reports padded out to look thorough are harder to act on, not easier.

The report should also be ordered. A list of ninety issues with no priority leaves the reader to guess, and they will usually guess wrong, fixing cosmetic items before the keyboard trap in the cart. Severity should reflect what blocks a purchase.

Ask to see a sample before committing. Any firm doing this properly will have one. Ours is described in full on our audit methodology page, including what the method does not cover, which is a section most vendors leave out.

Ecommerce Website Accessibility Checklist

An ecommerce website accessibility checklist condensed from everything above, in the order a shopper encounters it.

When to Bring in Professional Help

Plenty of this you can do yourself, and you should. Running the keyboard pass on your own store is genuinely worth an afternoon regardless of what you decide afterwards.

It is worth getting help when:

• You have found problems but cannot fix them. Focus management, ARIA and dynamic announcements are where self-directed work usually stalls.
• You need documentation. If you have received a complaint, or you are answering a procurement questionnaire, informal notes are not enough. You need findings mapped to criteria, dated, with evidence of remediation.
• You want to know what you missed. Self-testing tends to find the issues you thought to look for. An outside pass finds the rest.
• The checkout is affected. This is the one area where the cost of getting it wrong is immediate and measurable.

What it should not cost you is a subscription. Overlay widgets that promise instant compliance do not change the underlying code, which means the barriers described in this article remain for anyone whose assistive technology the overlay fails to intercept. More on why overlays fall short.

Frequently Asked Questions