Accessibility testing tools for ecommerce: 12 tools compared

The accessibility testing tool landscape is crowded. Free browser extensions, open-source CLI tools, enterprise SaaS platforms and AI-powered scanners all claim to find WCAG violations. Each has different coverage, different false positive rates, different ecommerce support and different pricing.

For ecommerce stores specifically, tool selection is more complex than for static websites. Online stores have dynamic content (AJAX cart updates, filter results, product variant changes), flows that require authentication (account pages, order history), multi-step interactions (add to cart, proceed to checkout, enter payment) and content that changes based on state (empty cart vs full cart, logged in vs guest). Many tools cannot reach or test these states at all.

This guide compares 12 tools, explains what each can and cannot detect, includes pricing and recommends a testing strategy specifically for ecommerce stores.

How much of WCAG can automated tools actually detect?

This is the most important number to understand before evaluating any accessibility testing tool. Multiple independent studies from Deque Systems, WebAIM and the UK Government Digital Service consistently find that automated tools detect 30-40% of WCAG 2.1 AA violations. The remaining 60-70% require human judgment.

Why so low? Many WCAG failures cannot be detected by analyzing code alone:

• Alt text quality. A product image with alt="product" has alt text. Whether it describes the product requires a human. See our product image alt text guide for what good alt text looks like.
• Heading hierarchy in context. Tools check that headings exist and follow order. Whether the heading structure matches the content's logical outline requires understanding the content.
• Focus order. Whether tab order matches visual layout and user expectations requires actually navigating the page.
• Keyboard traps. Detecting that a user cannot escape a modal or dropdown requires keyboard testing. Our keyboard navigation guide covers this.
• Screen reader experience. Whether ARIA labels communicate the right information requires listening to the output.
• Color contrast on images/gradients. Text over product images needs contextual analysis tools cannot fully perform. See our color contrast guide.

A clean automated scan means you caught the automatically detectable 30-40%. It does not mean you pass WCAG 2.1 AA.

Tool comparison table: 12 tools at a glance

axe-core: the most widely used accessibility engine

axe-core is an open-source accessibility testing engine developed by Deque Systems. It powers Deque's commercial axe DevTools, the Playwright accessibility API, the Chrome and Firefox axe extensions and hundreds of third-party integrations. It is the most widely deployed accessibility testing engine in the industry.

Why axe-core dominates ecommerce testing:

• Very low false positive rate. axe-core only flags issues it is confident are genuine failures. In CI/CD pipelines, false positives cause alert fatigue and get ignored. axe-core avoids this.
• Multiple integration paths. Browser extension, JavaScript library (inject into any page), Playwright plugin, Cypress plugin, Jest matchers, CLI wrappers. Use it however your team works.
• Active development. Regular updates adding new rules and improving detection accuracy.
• Ecommerce flow testing. When combined with Playwright, axe-core can test any page state: empty cart, full cart, checkout step 2, logged-in account page. Script the interaction, then run axe.run() on the resulting DOM.

Limitations: The free version covers a subset of WCAG rules. Like all automated tools, it reports on the DOM state at the moment of testing. Dynamic changes (AJAX updates, modal opens) require re-running in each state.

Google Lighthouse accessibility audit

Lighthouse is built into Chrome DevTools and available as a CLI. Its accessibility audit uses a subset of axe-core rules and produces a 0-100 score.

The score is widely cited but often misunderstood. A score of 90/100 does not mean 90% accessible. The score reflects the weighted pass/fail of the automated checks Lighthouse runs. A store with one missing form label (high-weight rule) might score 72, while a store with 20 minor failures might score 88.

Practical value: Lighthouse is a quick, built-in baseline check that requires no setup. Run it as a first pass. Do not use it as your only check or cite its score as compliance evidence. It scans one page at a static point in time and cannot test cart, checkout or any state requiring interaction.

WAVE Web Accessibility Evaluation Tool

WAVE is a browser extension and web service from WebAIM. It overlays visual annotations directly on the page: red flags for errors, yellow flags for warnings, green icons for passed checks and structural indicators for headings, landmarks and ARIA.

Best use case: visual, in-context review. When you see a red error flag next to a product image or a missing form label in the checkout, the connection between code and UI is immediate. This makes WAVE excellent for training developers and for QA reviews.

WAVE has a higher rate of warnings (items needing human review) than axe-core. The browser extension works on any page including authenticated pages and localhost, which is valuable for testing checkout pages behind login.

Pa11y: open-source CLI for batch testing

Pa11y is an open-source command-line tool that uses axe-core or HTML_CS (HTML CodeSniffer) as its engine. It is designed for batch testing and CI/CD integration.

Ecommerce value: Pa11y can batch-test URLs from a config file and supports Puppeteer actions to script page interactions. You can test the cart page after adding a product, or test checkout after entering a shipping address. Its JSON output integrates cleanly with CI/CD pipelines.

Pa11y requires Node.js and command-line comfort. It is a developer tool, not suitable for non-technical team members.

Deque axe DevTools (commercial)

Deque's commercial product extends axe-core with additional rules, needs-review items (likely problems requiring human confirmation), best-practice checks beyond WCAG minimums and guided manual testing workflows.

The guided tests are particularly relevant for ecommerce. They walk through manual keyboard testing procedures, focus management checks, screen reader testing checklists and other manual checks that catch the 60-70% automated tools miss.

Pricing: approximately $200-400 per user per year. Enterprise plans add organization-wide issue tracking and integrations.

Evinced: AI-powered accessibility testing

Evinced uses AI and machine learning to detect accessibility issues that rule-based tools miss. It claims to detect up to 3x more issues than traditional automated tools with fewer false positives. The platform includes SDKs for Selenium, Playwright and Cypress, plus a browser extension.

Ecommerce relevance: Evinced's flow testing can analyze multi-step interactions and detect issues in dynamic content changes. Their site scanner crawls JavaScript-heavy SPAs and can handle the client-side rendering common in headless commerce setups.

Limitation: Enterprise pricing. Evinced raised $93M in funding and targets large organizations. Mid-market ecommerce stores may find the cost prohibitive compared to axe-core + manual testing.

Siteimprove: enterprise monitoring platform

Siteimprove crawls your entire site on a schedule, tracks issues over time, shows improvement trends and integrates with CMS workflows. It covers accessibility alongside SEO, content quality and analytics.

For ecommerce, its strengths are scheduled monitoring (catching regressions when new products or pages go live), historical tracking and organizational reporting. Most useful for larger organizations with dedicated accessibility programs.

Siteimprove cannot test authenticated pages, checkout flows or dynamic interactions without additional configuration. Pricing starts at several thousand dollars per year.

ARC Toolkit: free Chrome extension

ARC Toolkit is a free Chrome extension from The Paciello Group (now TPGi). It provides detailed accessibility testing results organized by WCAG criteria, with visual highlighting of issues on the page.

ARC Toolkit stands out for its detailed structural analysis: it clearly shows heading hierarchy, landmark regions, ARIA roles and tab order. For ecommerce stores reviewing their ARIA implementation or heading structure, ARC Toolkit provides more structural detail than WAVE or axe.

No CI/CD integration. Manual testing only. But free, high-quality and useful as a second-opinion tool alongside axe.

IBM Equal Access Accessibility Checker

IBM's open-source accessibility checker includes a browser extension and a Node.js module for CI/CD integration. It uses IBM's own rule engine, which catches some issues that axe-core misses (and vice versa). Using both gives broader coverage.

The browser extension provides detailed explanations for each issue with links to IBM's documentation and WCAG techniques. The Node.js module integrates with Playwright and Puppeteer for automated testing.

Completely free under Apache 2.0 license. Less widely adopted than axe-core but a strong complement.

Playwright accessibility API

Playwright includes a built-in accessibility testing API powered by axe-core. For ecommerce stores already using Playwright for end-to-end testing, adding accessibility checks to existing test flows is the most efficient approach.

Example: your existing Playwright test navigates to a product page, adds to cart, proceeds to checkout and fills the shipping form. Add await checkA11y(page) at each step. You now have accessibility testing of your complete purchase flow with zero additional test infrastructure.

This is the strongest approach for ecommerce because it tests the actual user flows including states no standalone scanner can reach: checkout with items in cart, account pages behind login, error states after invalid form submission.

Tenon: API-first testing

Tenon provides an API that accepts HTML and returns accessibility issues. Post HTML from your build pipeline, get structured results back. Its certainty rating system (definite vs probable) reduces noise.

Best for component-level testing during development. Less suited for complete ecommerce flow testing but useful for design system and component library validation.

TestParty: ecommerce-specific accessibility

TestParty is the most notable ecommerce-focused accessibility testing platform. Backed by $4M in seed funding and used by 100+ brands, it specifically targets online store accessibility with ecommerce-aware scanning.

TestParty understands ecommerce page types (product pages, category pages, cart, checkout) and tests ecommerce-specific patterns like product variant selectors, price announcements, add-to-cart confirmations and filter interactions.

Limitation: Accessibility only. No PCI DSS, no privacy compliance, no AI Act transparency. If you need multi-pillar compliance, you need additional tools.

WCAG criteria coverage by tool

Not all tools test the same criteria. Here is which WCAG 2.1 AA criteria each tool type reliably detects:

Pricing comparison

Ecommerce-specific testing challenges

Ecommerce stores present challenges that static sites do not:

• Dynamic content. Product availability, cart contents, prices and promotions change via AJAX. A scan at one point may miss states users encounter. Filter interactions update product grids without page reload. See our accessible search and filters guide.
• Authenticated pages. Account pages, order history, saved payment methods and wishlists require login. Most scanners cannot authenticate.
• Cart state dependencies. Checkout cannot be tested without items in cart. Scanners hitting /checkout find a redirect or empty-cart page instead of the actual checkout form.
• Client-side rendering. React, Vue and headless commerce storefronts render content client-side. Scanners must execute JavaScript and wait for DOM stabilization. See our headless commerce accessibility guide.
• Third-party script interference. Chat widgets, review platforms, recommendation engines and accessibility overlays inject DOM elements that may not be accessible. Some tools cannot test elements injected by third-party scripts.
• Mobile-specific issues. Touch target sizes, gesture alternatives and responsive layout problems require device testing that desktop automation misses.
• Media content. Product videos with missing captions, auto-playing media and audio descriptions require manual review.

Platform-specific testing: Shopify, WooCommerce, Magento, BigCommerce

Shopify

Shopify stores have platform-specific testing considerations. Dawn and other Liquid themes are server-rendered, so standard URL scanning works. However, Shopify apps inject scripts and DOM elements that create accessibility violations the theme itself does not have. Test with apps enabled, not just the base theme.

Shopify checkout is hosted by Shopify and has limited customization. Test it separately. Checkout Extensibility blocks need individual accessibility testing. Use the axe DevTools extension directly on the checkout page.

WooCommerce

WooCommerce accessibility depends heavily on the active theme. Storefront has reasonable defaults. Third-party themes vary wildly. WooCommerce Blocks (the newer React-based components) have different accessibility characteristics than classic shortcodes.

WooCommerce AJAX cart updates and variable product selectors are common failure points. Test cart quantity changes, variant selection and the coupon code flow specifically.

Magento / Adobe Commerce

Magento uses Knockout.js for checkout, which creates testing complexity. The multi-step checkout renders different DOM states that require scripted interaction to reach. Luma theme has known accessibility gaps. Hyva and PWA Studio have different profiles entirely.

Layered navigation (faceted filters) and configurable product pages are Magento-specific flows that need targeted testing.

BigCommerce

BigCommerce Stencil themes and the Cornerstone base theme include basic accessibility. Optimized One-Page Checkout is BigCommerce-hosted. Script Manager injected scripts need testing as they can introduce violations.

Integrating accessibility testing into CI/CD for ecommerce

CI/CD integration catches regressions before production. The recommended three-layer approach:

• Layer 1: component tests in build. Test individual components (product card, form fields, navigation) in isolation using axe-core with Storybook, Jest or Playwright component testing. These run fast and catch component-level failures early.
• Layer 2: page tests on staging. After staging deploy, run axe-core via Playwright across representative pages: homepage, category page, product page, cart (with items), checkout (up to payment). Script the interactions needed to reach each state.
• Layer 3: production monitoring. Schedule weekly full-site scans on public pages. Use Pa11y batch mode or a commercial monitoring tool. Review results in sprint planning.

Set a failure threshold: critical and serious axe violations fail the build. Moderate and minor create warnings for triage. This prevents shipping new violations while not blocking every deploy on minor issues.

Recommended testing strategy for ecommerce stores

For a mid-market ecommerce store starting from scratch:

Steps 1-3 are free and give you an actionable baseline within a day. Steps 4-6 build ongoing protection against regressions. For a complete walkthrough of the process, see our guide on how to audit your store for accessibility. For the full compliance picture, combine this with our compliance audit checklist.

Frequently asked questions

What percentage of WCAG violations can automated tools detect?

Automated accessibility testing tools detect approximately 30-40% of WCAG 2.1 AA violations. The remaining 60-70% require manual testing with keyboards, screen readers and human judgment. No automated tool alone can confirm full WCAG compliance.

Which accessibility testing tool is best for ecommerce?

axe-core is the most widely adopted automated engine. For ecommerce specifically, you need a tool that can test dynamic flows. Playwright with axe-core or Evinced with flow testing are the strongest options. Combine automated scanning with manual keyboard and screen reader testing.

How much do accessibility testing tools cost?

Free options include axe-core, Lighthouse, WAVE extension, Pa11y, ARC Toolkit and IBM Equal Access. Commercial tools range from $200-400/user/year for axe DevTools Pro to $2,000-10,000+/year for enterprise platforms like Siteimprove and Evinced.

Can automated tools test ecommerce checkout for accessibility?

Standard scanners cannot reach checkout because it requires cart state and sometimes authentication. Tools that integrate with Playwright or Puppeteer (axe-core, Pa11y) can script these flows. Browser extensions like WAVE and axe DevTools can test checkout manually.

Is a Lighthouse accessibility score of 90+ enough for compliance?

No. Lighthouse uses a subset of axe-core rules and only scans one page at a static point. A score of 90/100 does not mean 90% accessible. It cannot test dynamic ecommerce flows. Use it as a starting indicator, not a compliance measure.

What is the difference between axe-core and axe DevTools?

axe-core is the free open-source engine. axe DevTools is Deque's commercial product that adds additional rules, guided manual testing workflows, needs-review items and organization-wide tracking. axe DevTools Pro costs $200-400/user/year.

How do you integrate accessibility testing into CI/CD?

Use axe-core with Playwright in your test suite. Test components in isolation during build, run page-level scans on staging after deploy and schedule production monitoring weekly. Set critical and serious violations to fail the build.

Which free tool is best for Shopify accessibility testing?

The axe DevTools browser extension (free tier) works on any page including Shopify checkout. For batch testing, Pa11y can scan your store URLs. WAVE provides the best visual, in-context issue identification.

Do accessibility testing tools work with headless commerce?

Headless commerce SPAs require JavaScript-capable tools. axe-core injected via Playwright handles client-side rendering. Static HTML scanners miss all dynamically rendered content. See our headless commerce accessibility guide.

How often should ecommerce stores run accessibility tests?

Run automated scans in CI/CD on every deploy. Schedule full-site production scans weekly. Conduct manual keyboard and screen reader testing quarterly or after major redesigns. Test third-party script updates as they happen.