How to perform an accessibility audit on your ecommerce store

An accessibility audit is not a one-time checkbox exercise. It is a systematic process for finding the specific WCAG violations that expose your store to legal risk, block disabled users from buying and cost you revenue. This guide walks through every stage: scoping the audit, running automated tools, conducting manual testing, testing with assistive technology, classifying findings by severity and building a remediation roadmap you can actually execute.

WCAG 2.1 AA is the standard that matters for most ecommerce stores. It is the benchmark referenced in ADA enforcement actions in the US and the European Accessibility Act, which became enforceable in June 2025. If your store sells in either market, AA conformance is what you are working toward.

Automated tools find roughly 30 to 40 percent of WCAG violations. The rest require a human. Both are essential. This guide covers both.

Step 1: define the scope

Before running any tool, decide what you are auditing. A complete ecommerce store has hundreds of pages and multiple user flows. Auditing everything at once is impractical. Prioritize by legal exposure and business impact.

The pages that matter most, in order:

• Checkout. This is the highest-risk flow. See our dedicated ecommerce checkout accessibility guide for the specific WCAG criteria that apply. Inaccessible checkout is cited in ADA lawsuits more than any other page type.
• Cart. Quantity controls, remove buttons, coupon code fields and running totals are all accessibility hotspots.
• Product pages. Image alt text, size/color selectors, add-to-cart buttons and price announcements. High volume, high legal exposure.
• Homepage. Usually tested first by automated scanners. Navigation, search, hero banners and promotional content.
• Search and category pages. Filters, sorting controls and product grids. See our guide to accessible ecommerce search and filters.
• Account flows. Login, registration, order history. Contains forms with the same issues as checkout.
• Content pages. About, shipping, returns and policy pages. Lower risk, but blog content and long-form pages need heading structure and link text audits.

For a lead-gen or validation scan, cover homepage, product page (one representative template), cart and checkout. For a full compliance audit, cover all page templates, all user flows and all interactive components.

Document your scope in a simple spreadsheet before you start. List every URL or template type you will test. This becomes your audit log.

Step 2: automated scanning

Automated tools are fast and consistent. They catch missing labels, color contrast failures, missing alt text, missing form input purpose attributes and structural issues. They are the right starting point.

The three tools worth using:

axe-core. The most accurate automated WCAG engine available. It has a low false-positive rate, which matters when you are triaging findings. Use it as a browser extension (axe DevTools) or programmatically via Playwright or Puppeteer for scanning dynamic flows like checkout. Our accessibility testing tools guide compares axe against other options in detail. For dynamic ecommerce flows, running axe-core programmatically after each step in a checkout flow is the right approach. A simple page load scan misses violations that only appear in the cart drawer, in an error state or after a form submission.

Lighthouse. Built into Chrome DevTools. Runs a subset of axe-core rules plus performance and best practices checks. Good for a quick snapshot of a single page. Less useful for dynamic flows. Run it in an incognito window to avoid extension interference. The accessibility score is a rough indicator, not a conformance statement. A score of 90 does not mean you are WCAG AA compliant.

WAVE. WebAIM's browser extension. Presents findings as visual overlays directly on the page, which makes it easier to locate exactly what is wrong in context. Particularly useful for checking heading structure, landmark regions and contrast issues quickly during early triage.

Run all three on each page template in your scope. Export results to your audit log. For each finding, record: tool, WCAG criterion, element, description, severity (from the tool's classification). Deduplicate across tools. axe and WAVE often flag the same issue differently.

Automated scanning catches the easy wins: images with no alt text, inputs with no labels, buttons with no accessible name and low-contrast text. These are also often the most common violations. Use automated accessibility checks in your CI/CD pipeline so these violations do not get reintroduced after every deploy.

Step 3: manual testing methodology

Manual testing finds the violations that automated tools cannot: focus management failures, logical reading order problems, meaningful link text issues, inadequate error messages and interactions that only exist in a live flow.

Structure your manual testing around four methods: keyboard navigation, screen reader, zoom and color contrast spot-checks.

Keyboard navigation testing

Unplug your mouse (or use a laptop in clamshell mode). Navigate your entire store using only Tab, Shift+Tab, Enter, Space and arrow keys. Test every user flow from start to finish.

What to check:

• Every interactive element is reachable by Tab in a logical order (WCAG 2.4.3).
• Every interactive element has a visible focus indicator (WCAG 2.4.7, 2.4.11 in WCAG 2.2). If you cannot see which element has focus, that is a violation.
• No focus trap exists outside of modal dialogs. If Tab gets stuck in a component with no way out, that is a critical violation (WCAG 2.1.2).
• Custom components (dropdowns, tabs, accordions, carousels, date pickers) respond to the expected keyboard patterns. A custom dropdown should open on Enter/Space and navigate with arrow keys.
• Modal dialogs, cart drawers and mobile menus trap focus correctly and return focus to the trigger element when closed.
• After dynamic updates (adding an item to cart, applying a coupon, completing a checkout step), focus is managed sensibly.

Our guide to keyboard navigation in ecommerce covers the specific patterns for every common ecommerce component.

Zoom testing

Set your browser to 200% zoom (Ctrl+/Cmd+ in Chrome, or set zoom level in browser settings). Navigate each page template. At 200%:

• No content should be cut off or require horizontal scrolling (WCAG 1.4.4, 1.4.10).
• Text should reflow into a single-column layout where appropriate (WCAG 1.4.10 Reflow).
• Interactive elements should remain usable. Buttons should not overflow their containers. Forms should remain fillable.

Increase to 400% for WCAG 1.4.10 compliance testing. Content must reflow at 320 CSS pixels viewport width without horizontal scrolling.

Color and contrast spot-checks

Use the browser's color picker or the Colour Contrast Analyser desktop app to spot-check anything that automated tools might have missed: text on photographic backgrounds, text in overlays, placeholder text, disabled button states and focus indicators. Our color contrast guide for ecommerce covers the specific ratios required for each element type.

Step 4: assistive technology testing

Screen reader testing is the most revealing part of any accessibility audit. It shows you exactly what a blind or low-vision user experiences when they try to use your store. It surfaces problems that no automated tool and no sighted manual review can find.

Use these combinations, which reflect real-world usage patterns:

• NVDA + Chrome on Windows. NVDA is free, widely used and representative of the Windows screen reader population. Chrome is the dominant browser.
• VoiceOver + Safari on macOS. Built into macOS, no installation required. Use it on a Mac for initial testing. Safari + VoiceOver is also the dominant iOS combination.
• JAWS + Chrome or Edge on Windows. JAWS is the most used screen reader in enterprise and among professional blind users. Its behavior sometimes differs from NVDA.

For each user flow, listen to what the screen reader announces as you navigate. You are looking for:

• Images announced with their actual alt text, not file names or empty announcements. See our guide to accessible product image alt text for ecommerce-specific patterns.
• Form inputs announced with their label and type. "Email, edit text" is correct. "Edit text" is not.
• Buttons and links announced with descriptive names. "Add to cart" is correct. "Click here" is not. "Button" with no name is not.
• Error messages announced when forms are submitted with invalid data.
• Dynamic content announced when it changes: cart total updates, out-of-stock status changes, checkout step transitions.
• Heading structure that makes sense. Use the screen reader's heading navigation mode (H key in NVDA/JAWS) to hear every heading on the page in sequence. It should tell a coherent story about the page structure.
• Landmark regions present and labeled: header, main, nav, footer. Screen reader users use landmarks to jump to sections quickly.

Our detailed guide to screen reader testing for ecommerce covers the full testing methodology for each screen reader, including the specific keyboard commands you need.

Complete the entire checkout flow with a screen reader. Listen to every field label, every error state, every dynamic update. This is the most reliable way to find the violations that cause abandoned checkouts and ADA complaints.

Step 5: document findings

Every finding needs a consistent record. Use a spreadsheet with these columns: ID, Page/Template, Component, WCAG Criterion, Level (A/AA), Severity, Description, Steps to Reproduce, Recommended Fix, Status.

For each finding, write a clear description that a developer who was not in the room can act on. "Missing alt text on product image" is not enough. "Product gallery images at /products/[slug] have empty alt attributes. When a product has no alt text in the CMS, the src filename is exposed to screen readers. Example: 'DSC04821.jpg'." That is actionable.

Include screenshots or recordings for complex interaction failures. A video of NVDA navigating a broken checkout step is worth more than a written description.

Group findings by page template and by WCAG criterion. Grouping by criterion helps when you are fixing: often one code fix resolves the same violation across dozens of pages.

Step 6: classify by severity

Not all violations are equal. Severity classification determines what you fix first. Use these four levels, consistent with how axe-core and the WCAG evaluation methodology describe issues:

Critical. Blocks access entirely for users of specific assistive technologies or input methods. Examples: keyboard trap in checkout, payment button with no accessible name, login form with no labels. These are the violations most likely to appear in ADA complaints. Fix within one sprint.

Serious. Significantly impairs usability but does not completely block access. Examples: missing error messages on form submission, focus not managed after a checkout step transition, images with uninformative alt text on key product images. Fix within one to two sprints.

Moderate. Creates friction or confusion but users can usually work around it. Examples: low contrast on secondary text, inconsistent heading levels on content pages, missing landmark regions. Fix in the next planned accessibility improvement cycle.

Minor. Best practice issues with low impact on real users. Examples: redundant alt text, non-critical presentational images with alt text instead of empty alt. Fix when touching adjacent code.

Apply a business weight on top of severity. A serious violation on the checkout page outranks a critical violation on a low-traffic blog post. Add a "Page Priority" column (high/medium/low) based on traffic and flow criticality, then sort by severity within each priority tier.

Also note which violations are repeated patterns. A missing label pattern that appears on 40 form inputs across the site is one fix in a component or template, not 40 separate tickets.

Step 7: build a remediation roadmap

An audit report without a roadmap sits in a folder and nothing gets fixed. Turn your findings into a roadmap developers can execute.

Structure the roadmap in three phases:

Phase 1: quick wins (1-2 weeks). All critical violations on high-priority pages. Missing labels, missing alt text on key product images, keyboard traps, buttons with no accessible names. These are often template or component fixes that resolve many instances at once. This phase should substantially reduce legal exposure.

Phase 2: core fixes (1-2 months). Serious violations on high and medium-priority pages. Focus management in checkout, error handling, live regions for dynamic content, contrast fixes, autocomplete attributes. These require more development work and may involve third-party vendors (Stripe, Shopify checkout extensions).

Phase 3: refinement (ongoing). Moderate and minor violations, plus improvements to design system components, documentation and developer education. This is where you build accessibility into the development process so violations stop recurring.

For each item in the roadmap, include: the finding ID from your audit log, the fix description, the estimated effort (small/medium/large), the owner (frontend dev, platform team, vendor) and the target date. Link each roadmap item back to the original finding so developers can see the full context.

An accessibility statement published on your site is not strictly part of the audit, but it is part of the compliance picture. Under the European Accessibility Act, a published accessibility statement with known limitations and a contact mechanism is a legal requirement. Under ADA case law, having a documented remediation plan and published statement is a mitigating factor if a complaint is filed. See our accessibility statement template for ecommerce for what to include.

Overlay widgets do not substitute for real fixes. A script that injects a toolbar claiming to fix accessibility does not fix accessibility. Courts and regulators reject this argument. The violations still exist in the underlying code. For a detailed explanation of why overlays fail, see our coverage of why accessibility overlay widgets do not work.

Step 8: re-audit cadence

Accessibility is not a one-time project. Every code change is a potential regression. New theme versions, app updates, A/B tests and marketing integrations all introduce new components that may not have been audited.

Recommended cadence:

• Automated scanning: continuously. Run axe-core in your CI/CD pipeline on every pull request. Block merges that introduce new violations on critical pages. If that is not feasible immediately, run weekly automated scans and review the diff.
• Manual testing of changed components: on each release. Whenever a new component, page template or checkout change ships, include accessibility testing in the QA checklist.
• Full manual audit: twice a year. January and July works well. This catches accumulated drift and validates that remediations from the previous cycle are holding.
• Full audit triggered by major changes. Platform migration (Shopify to Hydrogen, WooCommerce to BigCommerce), checkout redesign, theme overhaul. Treat these as new audits, not incremental reviews.

Document the date and scope of each audit cycle. This documentation is evidence of a good-faith compliance effort, which matters in the event of an ADA complaint or EAA enforcement action.

What a complete audit report looks like

A well-structured accessibility audit report contains:

• Executive summary: total violations by severity, compliance score (or gap to AA conformance), highest-risk pages, recommended immediate actions.
• Scope and methodology: what was tested, what tools and assistive technologies were used, what was not tested.
• Findings: full finding log with ID, page, criterion, severity, description, steps to reproduce and recommended fix.
• Violation summary by WCAG criterion: which criteria have the most failures across the site.
• Remediation roadmap: phased plan with priorities, owners and estimated effort.
• Appendix: raw tool output, screen reader test recordings, color contrast measurements.

The executive summary is what a Head of Ecommerce or legal team reads. The finding log is what developers act on. Both sections need to exist. A technical report with no summary sits in a folder. A summary with no findings log produces tickets that miss the actual problem.

If you are using the report to satisfy a legal demand letter or regulatory inquiry, include a statement of conformance level, the WCAG version tested against (2.1 AA), the testing date and the name of the tester or testing organisation.

Frequently asked questions

How long does an ecommerce accessibility audit take?

A focused audit covering homepage, product pages, cart and checkout takes one to two days for a skilled tester combining automated scanning and manual testing. A full site audit including account flows, search and all page templates takes three to five days. Automated-only scans are faster but miss 30 to 40 percent of real violations.

How often should I re-audit my ecommerce store?

Run automated scans continuously or at minimum after every deploy. Run a full manual audit at least twice a year, and after any major platform upgrade, theme change or checkout redesign. Accessibility violations are frequently reintroduced by new code, so a one-time audit is not sufficient.

What is the difference between WCAG A, AA and AAA conformance?

Level A covers the most critical barriers that make content completely inaccessible. Level AA adds requirements around contrast, labels, error handling and keyboard navigation. It is the legal standard referenced in ADA enforcement and the European Accessibility Act. Level AAA is aspirational and not required for legal compliance. Audit to AA.