How Often Should You Re-Audit Accessibility? Setting a Remediation Cadence
An accessibility audit is a snapshot. The day after it is delivered, the site starts changing: new products go up, a theme gets updated, a marketing app injects a popup, and each change can introduce new barriers. Companies that audit once and file the report discover this the expensive way, usually when a complaint arrives about a page that was fine during the last audit.
The question is not whether to re-audit but how often, and the answer depends on how fast the site changes. A static brochure site can go a year between full audits. An e-commerce store deploying theme changes weekly needs a much tighter loop. The cadence should match the velocity of change, not the calendar.
The three-tier model
Most organizations land on a three-tier rhythm. Automated scans run continuously or weekly, catching regressions like missing alt text on new product images, broken heading structure in new templates, or contrast failures in a redesigned banner. These scans are cheap and fast, but they catch only a fraction of real issues, roughly a quarter to a third of WCAG failures by most estimates.
Manual spot checks happen monthly or quarterly. A tester runs a keyboard-only pass over key flows, checkout, signup, search, and checks new components against a short checklist. This catches what scanners miss: focus order problems, unlabeled custom controls, and dynamic content that does not announce itself.
The full audit, manual testing plus assistive technology across the whole site, happens annually or after major changes: a replatform, a theme rebuild, or a significant new feature. This is the deep pass that produces the VPAT or the conformance statement, and it is the one that holds up if compliance is ever questioned.
Trigger-based audits beat calendar audits
The most effective programs add triggers on top of the calendar. Any theme update, new third-party app, checkout change, or template addition triggers a targeted accessibility check before it ships. This shifts the work left, catching issues in staging where they are cheap to fix instead of in production where they are liabilities.
Build the trigger into the deployment process. A pre-deploy checklist with five accessibility items, keyboard operability, labels, contrast, focus visibility, and screen reader announcements for dynamic content, takes a developer minutes and prevents the majority of regressions. The full audit then becomes a verification exercise rather than a rescue mission.
Measuring remediation, not just finding issues
An audit cadence is only half the system. The other half is remediation tracking: every finding gets an owner, a severity, and a deadline, and the metric that matters is time-to-fix, not issues-found. Dashboards that show open issues by severity and age keep accessibility visible between audits and prevent the familiar pattern where the same findings appear in three consecutive reports.
Prioritize by user impact and legal exposure. Barriers in checkout, account creation, and core navigation outrank issues on low-traffic content pages. Fix the paths that every user travels first, then work outward. This is also the prioritization a regulator or plaintiff's attorney would apply, so it aligns remediation with risk.
Documenting the program
Keep records of the cadence itself: when scans ran, what they found, what was fixed, and when the full audits happened. If accessibility practices are ever questioned, a documented, ongoing program is far stronger than a single audit report from two years ago. It shows the organization treats accessibility as operations, not as a one-time project.
The right cadence is the one you will actually sustain. A modest program executed consistently, weekly scans, quarterly spot checks, annual deep audit, outperforms an ambitious program that collapses after one cycle. Start with the rhythm your team can keep, and tighten it as the practice matures.