Continuous accessibility monitoring vs. one-time audits: what each actually delivers.

The market has converged on two distinct accessibility services: the one-time audit (a multi-week engagement that produces a remediated site at one point in time) and continuous monitoring (an ongoing service that watches the production site for regressions). Vendors sometimes describe one as a replacement for the other; neither actually is. The accessibility posture that holds up over time combines them, and the boundary between what each one does is worth understanding before you buy.

Accessibility services tend to fall into two categories. The first is the audit: an engagement that runs typically 2-6 weeks, examines the site against WCAG 2.2 AA criteria, and produces a remediated codebase plus documentation. (See the complete WordPress accessibility audit for how that works end to end.) The second is monitoring: an ongoing service that watches the live site, flags regressions, and (depending on the vendor) either alerts you or remediates them.

The two are often pitched as alternatives. “Why pay for a one-time audit when you can have continuous monitoring?” goes one sales pitch. “Why pay an ongoing subscription when one solid audit covers you?” goes the other. Both pitches are wrong. The services do different things, and a site that depends on accessibility (regulated industries, anything with meaningful compliance exposure, anything with an actual disabled user base) typically needs both.

What the audit actually delivers.

A one-time audit is a snapshot of the site’s accessibility status at one point in time, with the bugs found during that snapshot fixed. The output is:

• A remediated codebase. The structural, semantic, ARIA, focus-management, and visual issues found during the audit are fixed in the theme.
• A compliance summary documenting the state of the site after remediation.
• An auditable record for legal or regulatory review.
• Confidence that as of the audit completion date, the site meets WCAG 2.2 AA on the templates and components tested.

What it does not deliver:

• Coverage of templates or components added after the audit completes.
• Detection of regressions caused by content changes, plugin updates, or theme tweaks made after the audit.
• Catching new WCAG criteria or browser-behavior changes that emerge after the audit.

The audit’s value compounds for a finite window, typically 6-12 months, after which the site has accumulated enough change that an updated audit is warranted.

What continuous monitoring actually delivers.

A continuous-monitoring service (using tools like axe Monitor or Siteimprove) runs in your CI/CD pipeline and against the production site on a recurring schedule. It detects:

• New scanner-detectable issues introduced by content or theme changes.
• Regressions to previously-fixed issues.
• New pages or templates that haven’t been tested.
• Performance degradation against accessibility-adjacent metrics (focus visibility, contrast on dynamically-styled content).

Some services also include:

• Monthly remediation of flagged issues (the vendor’s developer fixes the flagged bugs).
• A documented log of all detected issues and their resolution (the “affirmative defense” record that holds up against an ADA demand letter).

What monitoring doesn’t deliver:

• The depth of manual screen-reader testing that a real audit includes. Monitoring runs scanners; scanners miss the categories of issue covered in what automated WCAG scans catch — and the categories they fundamentally can’t.
• The remediation of complex structural issues that need a developer to think through. Monitoring catches surface bugs; deep architectural issues need human judgment.
• The initial baseline. Monitoring assumes a site that’s mostly compliant; it’s not useful as the starting point on a site that’s never been audited.

The Overlay Trap: What monitoring is NOT.

It is critical to distinguish continuous monitoring from accessibility “overlays” (third-party JavaScript widgets that claim to use AI to dynamically fix a site on the fly). Monitoring is a reporting tool that tells your developers what underlying code to fix. Overlays are front-end band-aids. Overlays actively interfere with native screen readers, do not fix the root source code, and are universally condemned by the accessibility community. Relying on an overlay is not monitoring; it is a liability.

Why most sites need both.

The combination works because each service covers what the other can’t:

• Audit establishes the baseline. The site is brought to a known-good state, with documented coverage.
• Monitoring maintains the baseline. As changes accumulate, regressions get caught and fixed before they ship to many users.
• Periodic re-audit catches what monitoring misses. Every 12-18 months, a fresh audit catches the structural issues that crept in despite monitoring, and re-validates against current WCAG criteria.

This is the realistic ongoing posture for any site that takes accessibility seriously: initial audit, continuous monitoring, periodic re-audit. None of the three alone covers what all three together do.

The audit-only failure mode.

A site that gets audited once and then leaves accessibility alone for years sees a predictable decay:

• New content gets added without alt-text discipline.
• New components ship without the patterns the audit established.
• Plugin updates change generated markup in ways that introduce regressions.
• New WCAG criteria emerge; the audit’s coverage was against an older version.

Eighteen months after the audit, the compliance summary is still on file but the site is no longer compliant. The “we got audited” defense doesn’t hold up if the audit is two years old and the site has changed substantially.

The monitoring-only failure mode.

A site that subscribes to a monitoring service without ever doing a real audit fails differently:

• The monitoring catches surface issues but misses the structural ones that need real testing.
• The baseline never gets established. Issues from before the monitoring started don’t get caught (the scanner sees the current state; it doesn’t know the structural issues were there from launch).
• The team gets a false sense of security from the green dashboard. The dashboard says “no issues found” because the issues the site has are the ones scanners can’t see.
• A real accessibility complaint reveals what the monitoring missed. The “we have monitoring” defense is meaningfully weaker than “we executed a documented audit + maintain monitoring.”

What to actually buy.

For most sites, the practical sequence:

1. Start with a one-time audit. Establish the baseline. Remediate the surface area. Document the work.
2. Add continuous monitoring after the audit completes. The monitoring is meaningful starting from a good baseline; on a never-audited site, it surfaces too much to act on.
3. Plan for a periodic re-audit. Every 12-18 months for most sites; every 6-12 months for high-traffic regulated sites where the legal exposure justifies the more frequent cadence.
4. Build a regression-prevention culture between audits. Document accessibility requirements for new components, train designers and developers, include accessibility checks in deploy procedures.

The audit + monitoring combination, on a site with engaged stewardship, sustains accessibility as a property of the platform. The audit alone is insufficient; the monitoring alone is insufficient; the combination, maintained, is what actually keeps the site accessible to the users who need it.

See accessibility that holds up for what this looks like as a service.