Accessibility regression testing for headless storefronts
Headless storefronts break accessibility in ways themed stores do not, because every deploy can rewrite the DOM. Regression testing in CI, automated checks on every pull request plus scheduled full-page scans, catches WCAG breaks before they ship instead of after a demand letter arrives.
Why headless breaks accessibility faster
On a Shopify theme, the platform owns much of the markup and guards many accessibility basics. On a headless build, your team owns everything: the component library, the routing, the focus management, the live regions. That freedom is the point of headless, and it means a single refactor can silently remove landmarks, break heading order, or drop keyboard support across dozens of pages at once.
The breakage is rarely dramatic. A designer swaps a button component and the new one lacks a disabled state announcement. A performance pass lazy-loads images and the alt text pipeline breaks. A new variant picker looks identical but is no longer operable by keyboard. Each deploy is a small roll of the dice, and without regression testing, you find out from users or lawyers.
What belongs in CI
Every pull request should run automated accessibility checks against the changed routes. Tools like axe-core integrate into Playwright or Cypress suites and catch the mechanical failures: missing labels, insufficient contrast, broken heading hierarchy, missing landmarks. These checks are fast, deterministic, and cheap. They will not catch everything, but they catch the regressions that embarrass you.
Scope the checks to the routes the PR touches, plus a fixed set of critical paths: homepage, product page, cart, and checkout entry. A full-site scan on every commit is too slow; a targeted scan plus a nightly full scan is the right balance. The nightly scan is your safety net for the interactions between changes that no single PR test sees.
What automation cannot catch
Automated checks catch roughly a third to half of real WCAG failures. They do not catch focus order that is technically valid but confusing, live regions that announce at the wrong time, or keyboard traps in custom components. For those, you need periodic manual testing: a keyboard-only pass through the purchase path every sprint, and a screen reader pass before major releases.
The highest-value manual test is the one nobody wants to schedule: completing a purchase with only a keyboard, on the actual production build, after every significant frontend release. It takes twenty minutes and finds the failures that automated tools structurally cannot see.
Baselines and budgets
Regression testing needs a baseline to regress from. Run a full scan of production, triage the findings into must-fix and known-acceptable, and record the counts. CI then fails the build when violations increase beyond the baseline, not when any violation exists. A zero-violation gate sounds noble and gets disabled within a month; a no-new-violations gate survives contact with real development.
Pair the gate with an accessibility budget, the same way teams budget performance. A per-route violation budget, reviewed when exceeded, turns accessibility from a vague aspiration into a number the team manages. The budget should tighten over time as the backlog of known issues shrinks.
Who watches the watcher
CI checks rot. Selectors change, routes get renamed, and the accessibility suite quietly starts testing pages that no longer exist while the new checkout flow goes unexamined. Assign ownership of the test suite itself, and review its coverage quarterly against the actual sitemap. A regression suite that does not cover the current storefront is theater.
Headless gives you complete control over the storefront. Regression testing is how you keep that control from becoming liability. Ship fast, but make the pipeline prove every deploy is at least as accessible as the one before it.