A site that passed an audit in March can fail by September without anybody doing anything wrong. A new component ships, a marketing page goes up, a plugin updates, a designer removes a focus ring because it clashed. None of it is careless. It is just that nothing in the process was watching.
That drift is measurable at population scale. WebAIM's annual survey of a million home pages found detected failures on 95.9% of them, at an average of 56 per page, and that average was up 10% on the year before. The web is not slowly getting cleaner. It is accumulating, which is what regression looks like when you zoom out far enough to see it.
Keeping accessibility is cheaper than regaining it, and it comes down to four habits.
Put a Check in the Pipeline
An automated check on every pull request catches the mechanical failures before they merge. It will not find everything, and that is fine. What it finds is the class of regression that would otherwise accumulate silently, which is exactly the problem you are trying to prevent.
Start with a floor, not a ceiling
Turn it on with the rules you currently pass, so the build stays green on day one. Then add rules as you fix them. A check that goes red immediately gets switched off by day three, and it takes the habit with it. Once the check is limited to rules you already pass, set it to fail the build rather than warn, because a warning nobody has to act on is a warning nobody acts on.
How to wire it up, including which of axe's best-practice rules are worth adding deliberately, is in accessibility testing in CI.
Give the Team a Definition of Done
Most accessibility regressions come from people who would have done it right if they had known what right was. A short list attached to the work is more effective than training that happened last quarter.
- Developers get the developer checklist, which fits in a pull request template.
- Content editors get the content editor checklist, which is entirely CMS work.
- QA gets the test pass, run on the journey rather than the page.
- Designers get the design checklist, which runs inside the design tool before anything is built.
Name an Owner
Not a committee. One person who is asked about it, who sees the CI failures, and who decides whether a regression blocks a release.
This is the habit teams most often skip, and it is the one that decides whether the other three survive contact with a busy quarter. Accessibility that is everybody's job is nobody's.
Re-test on a Schedule
Automated checks fully settle 10 of the 356 WCAG techniques and failures we graded, which is 2.8%. Everything else drifts out of view unless somebody looks.
There is a national regulator's dataset that shows exactly which parts drift. The UK's Government Digital Service monitored 1,203 public sector websites over two years and named its four most common findings. Insufficient colour contrast, missing visible focus, keyboard operation problems, and content that does not reflow to the size of the device.
Only the first of those four is fully automatable. Focus visibility has one automated rule and it lists a human among its implementations. Focus order has no rule at all, and neither does reflow. So three of the four things a regulator actually found when it looked properly are three things a standard pipeline will not report, which is the whole argument for a manual cadence on top of CI.
| When | What | Who |
|---|---|---|
| Every pull request | Automated check on changed pages | CI |
| Every release | Keyboard pass on the main journey | QA |
| Every quarter | Manual review of anything new or rebuilt | Internal or external |
| Every year, or after a redesign | Full audit against all 55 rules | External |
Those intervals are our recommendation rather than anybody's standard, and the last row has a rule behind it. A redesign resets the clock regardless of where you are in the cycle, because a conformance claim is attached to specific pages on a specific date, and new templates are new pages. Every responsive variation counts separately too, so a rebuild that changes the mobile layout has changed something the old claim was about.
Continuous Monitoring and a Periodic Audit Answer Different Questions
Those two habits, the check in the pipeline and the manual cadence, get pitched against each other as though you were choosing one. They are not the same kind of thing. A continuous automated check is a tripwire, and a manual audit is a verdict, and the fastest way to see the difference is to ask each of them the questions an owner actually has.
| What you want to know | An automated check, running continuously | A manual audit, run periodically |
|---|---|---|
| Did something break since yesterday? | Yes, on the rules it runs, within a build or a crawl. | No. It describes the pages it covered on the day it was done. |
| How much of WCAG does it reach? | The machine-checkable part only. Our own grading puts that at 10 of the 356 techniques we graded. | All 55 rules at Level A and AA, including the ones no tool touches. |
| Does this page meet Level AA? | No. A clean run means its rules found nothing, which is not the same as a criterion being met. | Yes, rule by rule, for the pages tested on the date tested. |
| Can a screen reader user finish the checkout? | No tool answers this. | Yes, where a real screen reader user walked the journey. |
| Can it support a conformance claim? | No. A claim needs a date, a page scope and a level, and a continuous check supplies none of the three. | It supplies the evidence for one, for the pages in its scope. |
Read down the two columns and the roles sort themselves out. The check belongs in your pipeline, costs a build step, and earns its place by catching mechanical regressions in the gap between audits, which is exactly the drift this page is about. The audit is what produces an answer somebody outside your team can act on, because it carries a date, a named scope and a result against each rule. Neither one covers for the other, and a year of green builds is not evidence of anything a regulator asked for.
One thing we do not sell is the middle of that picture. There is no monitoring subscription here, no dashboard, no stored card and nothing that renews. The annual review is a full audit you book once a year on purpose, which is a booking rather than a subscription, and the check in your pipeline is yours to own and yours to switch off. That pairing is what we would do in your position, and it is a recommendation rather than a product.
The Things That Break It Most
- A new third-party component. A chat widget, a booking embed, a consent banner. Each one is somebody else's markup on your page and your duty to your customers. There is a mechanism in the standard for content you genuinely cannot control, called a Statement of Partial Conformance, and it does not let you off. It gives you a way to describe the situation honestly. See third-party scripts.
- A design refresh that keeps the templates. Colours change, contrast goes with them, and nobody re-measures the pairs.
- A marketing page built outside the design system. Usually assembled in a hurry, usually with headings chosen for their size.
- A plugin update. Especially on a CMS, where an update can quietly replace markup you had already fixed.
- Staff turnover. The person who understood why the focus styles were like that has left, and the comment explaining it never got written.
Keep the Statement Current
If you publish an accessibility statement, it makes a claim with a date on it. An out-of-date statement is a documented admission that you stopped paying attention.
Regulators do look. In that same monitoring exercise, 85% of the 1,203 sites had published a statement, and many of those were out of date and had not been reviewed in the previous twelve months. Which tells you two things. Publishing one is easy and common. Keeping it true is neither, and the gap between the two is visible to anybody who checks.
Review it whenever you re-test, and change the date only when you have actually looked.