Passing Your Accessibility Audit Is Not the Finish Line

A passed audit tells you your site was accessible on the day someone tested it. It says nothing about the site two content updates later, after the new landing page went up, after the third-party embed changed its markup, after the “quick fix” from a contractor who didn’t know the pattern library.

That gap is bigger than most teams assume. Recent large-scale scans of the web’s top sites still find WCAG failures on the overwhelming majority of home pages — and the error count per page has been climbing year over year, not shrinking, even as more organizations run audits. Pages keep getting more complex faster than teams keep them accessible.

The uncomfortable truth: accessibility doesn’t stay fixed. It decays by default, the same way security posture or data quality decay by default, unless something is actively holding the line.

Why a Single Audit Can’t Hold

An audit is a snapshot. Everything that happens after the snapshot is untested by definition:

• New content — every blog post, PDF, product page, and form is a fresh surface with no guarantee anyone checked it
• Redesigns and component changes — a single updated button style or nav pattern can silently break keyboard navigation sitewide
• Third-party embeds — chat widgets, booking tools, and ad units are outside your codebase and outside your last audit’s scope
• Well-intentioned fixes — a developer patching one issue can introduce another, especially with ARIA attributes, which are easy to add and easy to misapply

None of this is a one-time failure. It’s normal organizational entropy applied to a standard that never stops moving.

What a Governance Cadence Looks Like Instead

The organizations that stay accessible don’t audit harder once — they build a rhythm:

• Automated monitoring, continuous. Lightweight scans catch regressions the moment they ship, not months later. This layer catches roughly half of all issues by volume — useful for speed, not sufficient alone.
• Manual expert review, scheduled. A real audit needs a human with a keyboard and a screen reader, on a fixed cadence (quarterly for high-traffic sites, at minimum annually for everyone else) — not only when someone complains.
• Change-triggered review. Any redesign, new component, or third-party integration gets a targeted accessibility pass before launch, not after.
• Named ownership. Someone specific owns accessibility posture per surface — not “the dev team” in the abstract. Diffuse ownership is how known issues sit unresolved for quarters.
• A living exceptions log. Not everything gets fixed immediately. That’s fine, as long as every known gap is written down with an owner and a target date — an untracked exception is a liability; a tracked one is a plan.

The Real Question to Ask

Not “did we pass our last audit,” but: if someone tested this site today, would it still pass? If nobody can answer that with confidence, the cadence — not the last audit — is the gap.

This is the same discipline behind any governed practice: the control that matters isn’t the one-time review, it’s the mechanism that keeps catching drift after the review is over.

Part of the Governed Growth Model framework.