Accessibility regression testing for online stores

A regression is a problem that was absent — or fixed — and appears again after a change. For accessibility, regressions are common because most barriers live in shared components.

Two places to catch regressions

Where	Strength	Blind spot
CI (before deploy)	Fast feedback to developers	Staging data, no third-party apps, no real checkout
Production monitoring	Real store, real apps, real checkout	Detects after release

Most stores need both. Third-party apps, tag managers and payment providers change production without any deployment on your side — only production monitoring sees that.

Making results comparable

• Stable fingerprints: identify an issue by rule, page type and a normalised selector (remove auto-generated ids and list indexes). The same issue on a different product is the same template issue.
• Baselines: store the first result and compare every new scan with the latest one.
• Resolved vs. not tested: only mark an issue resolved when the page type was actually re-tested.

Test the journey, not just pages

A static page scan will not notice that the add-to-cart button stopped responding to the Enter key, or that the cart drawer no longer receives focus. A journey test drives the browser like a keyboard user: Tab to the button, press Enter, check what happens.

Suggested cadence

• Purchase journey: daily
• Key templates (home, category, product, cart, account, search): weekly
• Full manual audit: yearly or after a redesign