Accessibility Regression Gate

Six weeks before a launch an audit returns 200 findings and the team's automated checks are green. Both facts are normal. Automated tooling reliably detects a minority of real barriers — contrast ratios, missing programmatic labels, invalid ARIA, duplicate ids — commonly put at around a third, and the rest are behaviours: focus after a route change, reading order, whether an error message is announced, whether a custom widget can be operated from a keyboard.

An accessibility regression gate is the practice of turning conformance from a project into a property of the pipeline. Two parts, and the second is what makes it real: an automated check on every pull request, and a manual keyboard-and-screen-reader pass on a named set of journeys before release. The architectural decision is not the tooling; it is naming the journeys — sign-up, sign-in, search, checkout, account recovery — rather than pretending to test 400 screens.

Why it matters

Accessibility fixed by audit regresses on the next feature, because nothing in the process prevents the regression: the audit is a snapshot, and the codebase moves weekly. Teams therefore pay for remediation repeatedly, and each round is more expensive than the last because the defects are spread across more code.

The economics changed with the law. The European Accessibility Act became enforceable on 28 June 2025 for consumer services including online shops and banking, with EN 301 549 as the harmonised standard referencing WCAG level AA, and WCAG 2.2 has been a W3C Recommendation since October 2023. Conformance is now a procurement question and a legal exposure, which means the cost of a regression is no longer measured in user goodwill.

Implementation patterns

• Automated rules in the pull-request pipeline, failing rather than warning. A warning accumulates and stops being read; a failing check with the specific element and the rule is the only outcome that changes behaviour.
• Component-level tests in the design system, where the same assertion protects every consumer. This is where automated checks pay best.
• Behavioural tests for the transitions no scanner sees: after a route change, assert focus is inside the new view; after submitting an invalid form, assert the error is associated with the field and announced; after opening a dialog, assert focus is trapped and returns on close.
• A named journey list with an owner, tested manually per release with a keyboard only and with a screen reader. Two hours, on 5 journeys, is the highest-value hour in the release.
• A baseline with a ratchet for legacy code. Existing violations are recorded and may not increase; new code must be clean. Without this the gate cannot be introduced into an old estate at all.
• Publish the conformance statement from the gate's output, so the document that regulators and customers ask for is generated rather than written from memory.

Industry example

The public evidence for the split between what tooling finds and what it misses is consistent: surveys of home pages by accessibility organisations have for years found automatically detectable failures on the overwhelming majority of sites, while remediation reports from practitioners attribute most user-blocking defects to behaviour and structure. Design-system-led programmes at large product companies fix roughly half the findings, the component-level half, and every published account of such a programme ends with the same observation — that page structure, focus management, content and error handling remained the application teams' work.

Failure scenarios

• A green build and a failing journey, which is the default state of any application whose gate is scanner-only.
• Warnings that nobody reads, the most common way a gate is technically present and practically absent.
• A gate introduced without a baseline in a legacy estate, which blocks every pull request on pre-existing violations and is switched off within a week.
• Component-library conformance defeated by overrides, where an application passes arbitrary styles or children and breaks contrast or semantics from outside.
• Manual passes that drift to whoever is free, so the screen-reader test is performed by someone who has never used one, and reports no issues.
• Journeys never updated, so the gate protects last year's checkout.

Trade-offs

Automated gates cost pipeline time and produce false positives that need a suppression mechanism with a review. Manual passes cost real hours per release and need a skill the team may not have, which usually means training two people or buying testing from users of assistive technology — the latter being both more accurate and more expensive.

The alternative is the annual audit, which is cheaper per year and finds problems after they ship, at the point where fixing them competes with the roadmap. The gate moves the same work earlier, where it is minutes rather than a project, and adds the property the audit cannot provide: it prevents the next regression.

When not to use it

An internal tool with a known user population who have no access needs does not need a release gate, and a prototype certainly does not. The other case for restraint is scope: if one application carries 90% of affected traffic, fix that application and its journeys first rather than building an estate-wide gate that delays any user benefit by six months. A gate is also the wrong response to a specific legal deadline with a large backlog — there the sequence is remediate the named journeys, then gate, because a gate does not fix what is already broken.

Interview question

Q: Your team's accessibility checks pass on every build and an external audit returns 200 findings. Explain how both can be true, and design the process you would put in place.

What a strong answer covers: the split between automatically detectable failures and behavioural ones, with the rough proportion; the two-part gate, with behavioural assertions for route changes, dialogs and form errors; naming a small set of journeys instead of claiming full coverage; the baseline-and-ratchet mechanism that makes adoption possible in legacy code; failing rather than warning; and the ownership question, because a gate with no owner for the manual pass decays within two releases.

Quick check

Quiz: Why can a design system not make an application conformant on its own? Because page structure, heading order, focus management across navigation, reading order, error flows and content remain the application's, and overrides can defeat the components.

Flashcard: What are the two halves of an accessibility regression gate? — Automated rules failing the build on every pull request, and a manual keyboard and screen-reader pass on a named set of journeys per release.