Sneak peek: Accessibility Regression Testing
Catch accessibility issues where they start – components
Modern frontends are built with components but accessibility tests still happen at the page level, far removed from where developers work. This drowns you in duplicate issues because components are reusable across pages.
Today, we’re sharing a sneak peek of Accessibility Regression Testing which catches issues at the component level before they snowball into larger problems. It combines industry standards Storybook and axe with Chromatic’s purpose-built regression workflow.
Every time you push code, Chromatic automatically detects violations in your components to make compliance a natural part of the git workflow. We believe this can reduce the cost of accessibility fixes by 100x. Join our early access program to try it out first.
- 🧩 Component-level scans target the root cause
- 🚦 Automated regression tests prevent repeat violations
- 📈 Realtime reports to track progress over time
Why page-level tests fall short
Traditional page-level tests fail to address accessibility at its source. For decades, the best practice was to navigate page-by-page and run accessibility scans along the way to ultimately compile an audit report. While this method may work for tiny websites, it’s both too noisy and too late for today’s apps.
When issues are found at the page level, the root cause is often buried deep inside a component. You have to weed through thousands of noisy violations to figure out which component caused the violation.
What’s more, page-level tests occur too late in the development cycle. Developers build components first and then assemble them into pages. One flawed component can spread issues throughout your app, making problems harder to identify and more time-consuming to fix. And if your team relies on separate auditors, be prepared to wait days or weeks to learn what’s wrong.
The consequence? Accessibility is relegated to an afterthought instead of being a key part of the software development process.
What actually matters for developers
We talked to teams at Shopify, Indeed, Square, and the broader Storybook community. It’s clear accessibility is now a core requirement for frontend developers. From our conversations, these needs stood out:
Catch issues at the source - components. One flawed component can spread accessibility issues throughout the app, but fixing that component also fixes every instance where it’s used.
Continue shipping without making things worse. Teams inherit accessibility debt that can't just be resolved overnight. They want to ship new features without adding more debt.
Reports in minutes not months. Traditional reporting methods generate a dump of all violations captured at a single point in time. This is manual and time consuming. Reports must provide quick & granular visibility into violations.
- 🐌 Voluntary Product Accessibility Templates (VPAT) take months and only target the page level.
- 📜 Scanners requires configuration and are single shot.
Include human experts when it’s most efficient. While automated tests can catch the majority of accessibility problems, they don’t catch everything. Complex context-sensitive issues still require human judgment. Combine automation with experts in a natural workflow.
Accessibility regression testing is ideal for developers
Axe has long been the industry standard for running automated accessibility tests on HTML-based interfaces. It acts as the first line of QA to catch blatant accessibility violations.
When you run axe, it gives you a list of all violations across every page under test. But it's unlikely you'll address all these issues immediately - teams often inherit more accessibility debt than can be resolved at once.
Accessibility regression testing is a technique that uses baselines to track the "last known good state" of a component. When you push code in a pull request, the component is rescannned to detect new and changed violations while omitting the noise from preexisting violations (debt).
Teams can continue shipping new features without worrying about introducing new issues. Preexisting debt is reported separately so that you can resolve it at your own pace.
How Chromatic works
Accessibility Regression Testing seamlessly complements Chromatic’s existing visual and functional tests. It uses axe and our proprietary regression algorithm to detect new violations down to the component-level in a pull request.
Our aim is to provide instant accessibility feedback at every phase of development from coding through to CI. Here’s how it works:
During development: Fast feedback in Storybook
As you build components in Storybook, run accessibility checks directly on your components using the a11y addon (powered by axe). Any violations are flagged in real time, with detailed error descriptions and guidance to help you resolve them quickly.
Violating elements are highlighted directly in Storybook’s canvas, so you can see exactly where the problem lies. There’s no need to leave your development environment or tab to the command line to debug—it all happens in flow.
In CI: Regression-proof with Chromatic
Storybook helps an individual developer spot check as they build, while Chromatic provides blanket coverage for the entire development team.
Chromatic tracks accessibility violations over time, establishing a baseline for each component. This separates preexisting issues from others and new issues that you accidentally introduced. Each team member is responsible for addressing accessibility violations brought on by their own changes.
When code is pushed, Chromatic automatically tests every component by comparing accessibility violations to the established baseline. If there are new or changed issues, Chromatic flags them for you to review. This ensures teams never backslide—even as the app evolves and more developers contribute.
Intuitive debugging for faster fixes
When violations are detected, Chromatic makes it easy to drill down into the details. Problematic DOM nodes are highlighted directly in your component snapshot, so you can pinpoint the exact source of the issue.
- Inspect violations with detailed descriptions and suggested fixes.
- Launch the published Storybook to debug live in your browser with devtools.
- Share links to specific violations with your team for faster collaboration.
Proactively prevent false positives
Accessibility tests examine DOM structure. The problem is that the DOM structure and selectors can change as you code which introduce false positives. For example, if you remove a wrapping element or tweak a styled component a preexisting issue can appear as “new” when it's not.
When compared to naive text-based diffs, Chromatic drastically reduces noise caused by DOM shifts without reducing the fidelity of regression testing. Our proprietary regression algorithm uses computer vision and DOM context to distinguish minor structural changes from bonafide violations.
Realtime reporting with impact analysis
Chromatic continuously reports on WCAG issues across components and pages in realtime. You get a birds-eye view which can help identify high-impact areas to focus on. For example, fixing a Button that's used on a hundred pages.
Think of Chromatic as an automated sidekick to a Voluntary Product Accessibility Template (VPAT): developers use our reports to quickly fix violations which in turn streamlines the manul VPAT process.
Must-have for European Accessibility Act and ADA
With the European Accessibility Act (EAA) coming into enforcement June 28, 2025, development teams are trying to figure out how to address years of deferred accessibility debt.
Under the European Accessibility Act, only new or updated features must meet the latest accessibility standards. As a developer, this means that if you push commits that alter code, this updated code is considered “new” and must comply. Whereas unchanged components are considered legacy and exempt until June 28, 2030. Read the specifics in our EAA for developers guide.
Accessibility Regression Testing leverages baselines with timestamps to help you identify which components are “new” versus unchanged legacy. This way you can tell what code must meet EAA standards. And perhaps more pragmatically, what code can remain on your accessibility backlog to fix later.
Build accessible frontends at your own pace
Chromatic doesn’t just help you find accessibility issues—it helps you integrate accessibility as a feedback loop in the frontend development process. We believe this is the most sustainable way of approaching long term compliance.
For teams working through a backlog of accessibility debt, Chromatic allows you to continue shipping with the confidence that you wont add more debt.
For teams that have cobbled together some testing, Chromatic is a complete solution that guards against regressions so when you become compliant you actually stay there.
Sign up for early access now
Accessibility Regression Testing is in active development now. Join our early access program (it’s free!) to be the first to try it out. You’ll get access to a private Slack with support directly from our technical team.