An accessibility audit for online stores: the checks that matter first

Most online stores that commission an accessibility review get back a long spreadsheet from an automated tool, a score, and very little sense of what to fix first. The volume is misleading. A catalog with 20,000 product pages built from six templates may produce tens of thousands of flagged items that trace back to a few dozen root causes, while the barrier that actually stops a blind shopper from paying never appears in the scan at all.

This guide sets out a working order for an ecommerce accessibility audit: what to check first, who should check it, how to record it so developers can act, and how to stop the same defects coming back in the next release. It sits inside our broader guide to accessible retail and the rules that now apply to storefronts and stores, which covers the legal frameworks in more depth. Here the focus is method.

The technical benchmark referenced throughout is the Web Content Accessibility Guidelines (WCAG) published by the World Wide Web Consortium. WCAG 2.2 became a W3C Recommendation in October 2023; many legal frameworks and settlement agreements still reference WCAG 2.0 or 2.1 at level AA, and 2.2 AA is a superset of 2.1 AA for nearly all practical purposes, so auditing against 2.2 AA covers both.

What automated scanners catch and what they miss

Automated tools such as axe-core (which also powers the accessibility section of Google Lighthouse), WAVE from WebAIM, Pa11y and Microsoft Accessibility Insights parse the rendered page and test it against rules that a machine can evaluate. They are fast, free or cheap, and repeatable, which makes them the right first pass and the right regression guard. They are not an audit on their own.

The limits are well documented. When the UK Government Digital Service built a test page with deliberately introduced barriers in 2017, it reported that the best performing automated tool found roughly 40 percent of them, and some tools found far fewer. Deque, which maintains axe-core, has reported that automated tests accounted for a little over half of issues by volume in its own audit data. The gap between those figures reflects what is being counted, but both point the same way: a large share of real barriers need human judgment.

The pattern WebAIM keeps finding

WebAIM’s annual “Million” report scans the home pages of the top one million websites. Its recent editions have found detectable WCAG failures on roughly 95 percent of those home pages, with an average of around 50 detectable errors per page in the 2025 edition, according to WebAIM. The leading categories barely move from year to year: low contrast text, missing alternative text, missing form labels, empty links, empty buttons and a missing page language. These figures change annually and should be checked against the latest WebAIM publication before being quoted.

Retail sites tend to reproduce these failures at scale. A product tile with an icon-only “add to wishlist” button and no accessible name repeats on every listing page, so the scanner count balloons while the fix is one component change.

What a scan can and cannot judge

Check	Automated scan	Needs a human	Typical retail example
Image has alt attribute	Yes	Whether the alt text is meaningful	Every gallery image reads “product image”
Text contrast ratio	Yes, for plain text on flat backgrounds	Text over photos, gradients, hover states	White price on a lifestyle banner
Form field has a label	Yes	Whether the label and error text make sense	Postcode field labelled only by placeholder
Keyboard operability	Partly (tabindex misuse, missing roles)	Whether a whole task can be completed	Size selector built from clickable divs
Focus order and visibility	Rarely	Yes	Focus jumps behind a sticky header on scroll
Status messages announced	No	Yes, with a screen reader	“Added to cart” toast never announced
Captions accuracy	Detects a track exists, at best	Yes	Auto-captions mangle product names
Time limits	No	Yes	Checkout session expires with no warning

The practical conclusion is to run the scanner early, cluster its output by component rather than by page, and then spend the expensive human hours on the journeys where scanners are blind.

Keyboard-only paths through search, filter and checkout

If an auditor has one day, it should go here. Keyboard access is the foundation that screen reader, switch device and voice control users all depend on, and a single failure on the purchase path is a hard stop rather than an inconvenience. WCAG criteria 2.1.1 (Keyboard) and 2.1.2 (No Keyboard Trap) are both level A, the most basic tier.

The test is simple to describe and tedious to do: unplug the mouse, put the trackpad away, and try to buy something using Tab, Shift+Tab, Enter, Space, the arrow keys and Escape. Record every point where focus disappears, lands somewhere unexpected, or cannot move on.

The journey to walk, in order

1. Skip link and global navigation, including the mega-menu and any country or currency switcher.
2. Site search: typing a query, moving through autocomplete suggestions with the arrow keys, and submitting.
3. Listing page: applying and removing filters, changing the sort order, and paging or loading more results.
4. Product page: gallery, variant selectors (size, color), quantity, add to cart, and any size guide modal.
5. Mini cart or cart drawer: opening, editing quantity, removing an item, and closing it again.
6. Checkout: guest versus account choice, address entry and lookup, shipping method, payment fields, promo code and order review.
7. Post-purchase: confirmation page, account creation offer, and order tracking.

Where retail sites usually break

The most common blockers are custom controls built from generic elements. A color swatch implemented as a styled div with a click handler cannot receive focus, so a keyboard user simply cannot choose a variant. Drawers and modals that open without moving focus into them, or that let focus wander into the page behind, are a close second.

Payment fields deserve special attention. Many stores embed card fields from a payment provider in iframes, and focus handling across iframe boundaries is a frequent source of traps. The fix may sit with the provider rather than the store, which is one reason the audit should name the component owner on every finding.

Contrast, focus states and the design system fixes

Contrast failures are the single most common detectable error on the web, according to WebAIM’s data, and they are also among the cheapest to fix if they are fixed in the right place. WCAG 1.4.3 (Contrast Minimum, level AA) sets a ratio of at least 4.5:1 for normal text and 3:1 for large text. WCAG 1.4.11 (Non-text Contrast, level AA) sets 3:1 for the visual boundaries of interface components and for meaningful graphics, which covers input borders, checkbox outlines and the selected state of a size button.

Fix tokens, not pages

Retail brands often have a palette chosen for the look of a campaign: pale grey body copy, light brand-colored buttons, and sale prices in a soft red. When the audit finds contrast failures, the efficient response is to change the design tokens or CSS variables in the component library, so the correction cascades across every template. Page-by-page fixes drift back within a few releases.

Text placed over photography is the exception that tools miss. A hero banner with white text over a product image may pass on one crop and fail on another as the image changes by campaign. Teams commonly solve this with a solid or semi-opaque backing panel behind the text rather than relying on image selection.

Focus indicators and sticky elements

WCAG 2.4.7 (Focus Visible, level AA) requires that keyboard focus is visible. Many stores remove the browser’s default outline for aesthetic reasons and never replace it. WCAG 2.2 added 2.4.11 (Focus Not Obscured, Minimum, level AA), which matters for retail because sticky headers, cookie banners, chat widgets and “free shipping” bars routinely cover the focused element as a user tabs down the page.

WCAG 2.2 also added 2.5.8 (Target Size, Minimum, level AA), a minimum of 24 by 24 CSS pixels for pointer targets with listed exceptions. Tiny quantity steppers, close icons on drawers and dense swatch grids are the usual offenders on mobile.

Forms, error messages and time limits

Checkout is a form, and forms are where accessibility defects turn directly into abandoned orders. The audit should test every field in the address, payment and account flows with a screen reader, not just inspect the markup. NVDA with Firefox or Chrome on Windows and VoiceOver with Safari on macOS and iOS are the common pairings; JAWS remains widely used in workplaces; TalkBack covers Android.

Labels and instructions

Every field needs a programmatic label (WCAG 1.3.1 and 3.3.2). Placeholder text that disappears on typing is not a label. Format requirements such as “phone number without spaces” should be stated before the user types, not revealed only on failure. Address lookup widgets that populate several fields at once should announce what happened.

Errors that can be found and fixed

WCAG 3.3.1 (Error Identification, level A) requires that errors are identified and described in text, and 3.3.3 (Error Suggestion, level AA) asks for a correction suggestion where one is known. In practice, auditors check four things: that an error summary appears and receives focus or is announced, that each field error is tied to its field programmatically, that color is not the only signal, and that the user’s other entries are preserved.

WCAG 2.2 added 3.3.7 (Redundant Entry, level A), which targets a familiar checkout irritation: asking for the same information twice in one process. Offering “billing address same as shipping” is the standard remedy. Criterion 3.3.8 (Accessible Authentication, Minimum, level AA) affects login and account creation; it discourages cognitive tests such as transcribing distorted characters unless an alternative is offered, and it means password managers and paste must not be blocked.

Session time limits

Many checkouts and cart reservations expire. WCAG 2.2.1 (Timing Adjustable, level A) requires that users can turn off, adjust or extend a time limit, with specific allowances such as a warning and at least 20 seconds to extend, subject to listed exceptions for real-time events. Limited inventory holds during a product drop are a genuine business constraint, so the audit should record the current behavior and the options rather than assume a single answer fits every store.

Product images, alt text and video captions

Product media is where accessibility and conversion overlap most visibly. A screen reader user cannot see the difference between the navy and the black version of a jacket, and an image that reads only “IMG_4471.jpg” gives them nothing to decide with. Good alt text is also good product data, which is why this work overlaps with product page SEO that drives organic conversions and benefits from the same attribute discipline.

Writing alt text at catalog scale

WCAG 1.1.1 (Non-text Content, level A) requires a text alternative that serves the equivalent purpose. For a primary product image, that usually means the product name plus the visual attributes a shopper would use: color, pattern, material appearance and the angle shown. Purely decorative images, such as background textures, should have empty alt text so screen readers skip them.

Large catalogs cannot hand-write alt text for every image, so the audit should check the template logic. A common robust pattern builds alt text from structured attributes (“Women’s waxed cotton jacket in olive, back view”) and lets merchandisers override it. Automated generators can help with volume, but their output needs sampling for accuracy; a wrong color in alt text is a misdescription, not a minor style issue.

Video, 360 views and user-generated media

Prerecorded video with audio needs captions under WCAG 1.2.2 (level A), and audio description under 1.2.5 (level AA) where important visual information is not conveyed in the soundtrack. Product demo videos often show the feature without saying it, which is exactly the case audio description addresses. Autoplaying video or carousels need a pause control (WCAG 2.2.2). Review photos uploaded by customers are harder to control; many stores accept that these will lack descriptive alt text and ensure the surrounding review text carries the information.

Filters, modals and infinite scroll patterns

Listing pages concentrate the interactive patterns that are hardest to make accessible, and they are also the pages that drive most product discovery. The audit should test them with both keyboard and screen reader, because the failures are behavioral rather than structural.

Faceted filters

Filters that apply instantly on each checkbox click reload or reorder results while the user is still choosing, often moving focus back to the top of the page. Screen reader users then lose their place in a long list of facets. Auditors check whether filter state is exposed (checked or unchecked), whether the result count change is announced as a status message under WCAG 4.1.3 (level AA), and whether there is a clear way to see and remove active filters.

Modals, drawers and quick view

Quick view windows, size guides, store pickers and cart drawers should follow the established dialog pattern documented in the W3C’s ARIA Authoring Practices Guide: focus moves into the dialog on open, stays within it while it is open, Escape closes it, and focus returns to the control that opened it. Each step is easy to break with a third-party script, so the audit records which vendor component is involved.

Infinite scroll and load more

Infinite scroll can make the footer, with its returns policy and contact details, practically unreachable for keyboard users, because new products keep loading as focus approaches it. A “load more” button, or classic pagination, gives users control and is easier to announce. If infinite scroll stays for commercial reasons, the audit should verify that newly loaded items are reachable and that the footer links are available elsewhere.

Recording findings so developers can act on them

An audit report that lists “1,842 issues” without grouping is rarely fixed. The deliverable that works is a backlog of tickets, each tied to a component, with enough detail to reproduce and retest. This is where the method in our guide to the parts of SEO for retailers that still matter is a useful parallel: technical findings get fixed when they are framed as template defects with a measurable outcome, not as page-level complaints.

What each finding should contain

• A short title naming the component and the barrier, such as “Size swatches not keyboard operable on product page”.
• The WCAG success criterion and level, so the ticket can be prioritized against the target standard.
• Steps to reproduce, including the browser and assistive technology used.
• Expected behavior and the observed behavior, in plain language.
• Scope: which templates and how many pages share the component.
• Owner: in-house team, theme vendor, app vendor or payment provider.
• Severity, using a fixed scale agreed before the audit starts.

A severity scale that maps to revenue

Severity	Definition	Retail example	Typical target
Blocker	A user cannot complete a core task	Keyboard trap in payment iframe	Next release or hotfix
Critical	Task possible only with significant workaround	Variant selector unlabeled for screen readers	Within one sprint
Serious	Barrier on a frequent but non-blocking path	Filter changes not announced	Within the quarter
Moderate	Friction or inconsistency	Low contrast on secondary links	Batched with design system update
Minor	Best-practice gap with limited impact	Redundant title attributes	Opportunistic

Severity should be judged by impact on the task, not by the WCAG level. A level AA contrast failure on the “Place order” button can matter more to the business than a level A issue on an archived blog page.

Who should do which part

Developers can run automated checks in their own pipeline. Designers can own contrast, focus and target size. Manual expert review and assistive technology testing are specialist work and are usually done by an internal accessibility lead or an external auditor. Sessions with disabled users, paid and recruited through specialist panels, surface usability problems that conformance testing misses and are worth scheduling once the blockers are fixed rather than before.

Retesting cadence and release gates

Retail sites change weekly. New campaign templates, promotional banners, third-party apps and checkout experiments all reintroduce defects, so a single audit decays quickly. The goal after the first audit is a system that catches regressions before customers do. Teams that already run conversion experiments, as described in our retail marketing guide for the era of AI search and social commerce, can attach accessibility checks to the same release process.

Change type	Check	Who	Gate
Every code merge	Automated rules (axe-core or similar) in CI on key templates	Developers	Block merge on new serious violations
New component or app install	Keyboard and screen reader smoke test	QA or accessibility lead	Sign-off before launch
Campaign or seasonal template	Contrast, focus, alt text, carousel controls	Design and content	Checklist before go-live
Checkout or payment change	Full keyboard and screen reader purchase test	Accessibility lead	Release blocker if a blocker is found
Quarterly	Manual sample audit of top journeys	Internal or external auditor	Report to product owner
Annually	Full audit, ideally with user testing	External auditor	Update accessibility statement

Monitoring what the scan dashboard hides

Automated monitoring services that crawl the live site weekly are useful for trend lines, but a falling issue count is not proof of accessibility. Pair the dashboard with a short list of journey tests repeated each quarter, and track the number of open blockers and criticals as the headline metric rather than the total number of flagged items.

Third-party code and vendor contracts

A store can fix its own templates and still fail because of a review widget, a chat tool or a consent banner. Procurement teams increasingly ask vendors for an Accessibility Conformance Report based on the VPAT template, and some include remediation commitments in contracts. For stores selling into Europe, where the European Accessibility Act has applied to many e-commerce services since 28 June 2025 according to the European Commission, the vendor question becomes part of documentation; our explainer on the European Accessibility Act for online stores selling into the EU covers scope and exemptions.

For the wider picture of how website audits connect to physical stores, statements and remediation budgets, see the section on audits in our retail accessibility guide.

Important note on legal information

This article is general information about accessibility testing methods and is not legal advice. Whether and how accessibility laws apply to a particular store depends on its location, the markets it sells into, its size and the specific facts. In the United States, the Department of Justice has published web accessibility guidance under the ADA, and courts have taken differing views on how Title III applies to websites; in the EU, obligations derive from the European Accessibility Act as transposed into each member state’s law. Rules, standards and enforcement practice change, so current requirements should be verified with the official source, and a store with a specific question, a demand letter or a complaint should consult a qualified attorney. The technical criteria cited here come from the W3C’s WCAG 2.2 Recommendation.

FAQ on store accessibility audits

How long does an ecommerce accessibility audit take?

It depends on the number of distinct templates and journeys, not the number of pages. A store built on a standard theme with a handful of templates can often be audited manually in a few days, while a large retailer with custom checkout, apps and multiple locales may take several weeks. Automated scanning is a small fraction of the effort.

Is an automated accessibility score enough to show compliance?

No. Automated tools detect only the machine-testable portion of WCAG criteria. A perfect Lighthouse accessibility score can coexist with a checkout that cannot be completed by keyboard. Scores are useful as a regression signal, not as evidence that a site is accessible.

Which WCAG version should a retail audit test against?

Many audits now use WCAG 2.2 level AA, published by the W3C in October 2023, because it includes the 2.1 AA criteria and adds several that matter in retail, such as target size and redundant entry. The legal benchmark in a given jurisdiction may reference an earlier version, which should be confirmed with the relevant official source.

Do accessibility overlay widgets fix the problems an audit finds?

Overlays that add a toolbar or attempt automatic repairs do not change the underlying templates, and many accessibility practitioners and disability organizations have criticized them publicly. An audit should treat the site without the overlay as the system under test, because that is what most assistive technology users experience.

What should be tested first if budget is limited?

The purchase path with a keyboard and one screen reader: search, a listing page with filters, a product page with variants, the cart and checkout through to confirmation. Blockers on that path have the clearest impact on both users and revenue.

Who should own accessibility fixes on a Shopify or WooCommerce store?

Ownership follows the code. Theme templates belong to whoever maintains the theme, apps and plugins to their vendors, and payment fields often to the payment provider. Each finding should name its owner so it can be routed, and vendor issues may need to be raised through support channels or contracts.

How often should a store be re-audited?

A common pattern is automated checks on every release, a manual sample of key journeys each quarter, and a full audit annually or after a major redesign or replatforming. Checkout changes justify a focused retest whenever they ship.

Does an accessibility audit help SEO?

Indirectly. Meaningful alt text, a correct heading structure, descriptive link text and clean markup help both assistive technology and search engines interpret pages. Accessibility should be justified on its own terms, but the overlap means many fixes serve both goals.

Should disabled users be involved in testing?

Yes, where possible. Conformance testing checks the site against criteria; sessions with disabled shoppers show whether real tasks are practical. Recruiting through specialist research panels and paying participants fairly is standard practice, and sessions are most productive once known blockers are fixed.