Automated scans between audits are a monitoring practice that helps teams catch obvious accessibility regressions as code ships. Scans do not determine WCAG conformance, and they only flag approximately 25% of issues. But when a site changes frequently, running scans between full audits gives you a signal that something broke before a user reports it. The audit remains the source of truth for conformance. Scans fill the space in between.
| Activity | Role in an Accessibility Program |
|---|---|
| Accessibility Audit | A (manual) evaluation that identifies issues against WCAG 2.1 AA or 2.2 AA and produces a report used for remediation and conformance claims. |
| Automated Scan | An automated check that flags a portion of accessibility issues (about 25%) on a schedule or when triggered by a code change. |
| Cadence | Full audit at defined intervals or after major releases. Scans between audits, often weekly or per deploy. |
| Output | Audit produces a report with severity and remediation guidance. Scans produce alerts and code-level pointers for a narrower set of issues. |
What Scans Actually Catch
Automated scans are good at a specific set of items. Missing alt attributes, empty buttons, form controls without labels, low-contrast text where the values are declared in CSS, missing document language, and duplicate IDs. These are code-level items where a rule can be written and applied consistently.
Scans cannot evaluate whether alt text is meaningful, whether heading order reflects the content structure, whether focus order matches visual order, or whether a custom component behaves correctly for a screen reader user. Those are judgment calls. Judgment calls belong to an auditor.
Why Run Scans Between Audits?
Sites change. A marketing team ships a new landing page. A developer swaps a component library. A CMS update pushes a template revision. Any of these can introduce new accessibility issues on pages that were clean at the last audit.
Running scans on a set cadence, weekly, per deploy, or against a curated list of key templates, gives the team an early signal. If the scan count spikes after a release, someone can look at the affected pages and address the issue before it compounds. That is the value: catching the obvious stuff early so the next audit is not littered with regressions.
What Scans Are Not
Scans are not audits. They do not evaluate WCAG conformance. They do not identify the majority of issues that a (manual) audit would. A clean scan report does not mean a site is accessible, and a scan score of 100 is not the goal.
Teams that rely on scans as the primary accessibility check tend to accumulate issues that go undetected until a full audit or a user complaint surfaces them. The scan is a smoke detector. It tells you something obvious is on fire. It does not tell you the building is safe.
How to Set a Cadence That Works
The right scan cadence depends on how often the site changes. A brochure site with quarterly updates does not need daily scans. A high-traffic ecommerce site with weekly template changes benefits from scans on every deploy. Tie the scan schedule to release velocity.
Full audits sit on top of the scan cadence. Most teams conduct a full audit annually or after a significant redesign, and use scans in the intervening months to monitor for regressions. When a scan flags something, the fix is usually quick because the change is fresh in the developer’s mind.
Where AI Fits In
Automated scans have been around for years, and their limits are well documented. What has changed recently is how AI can support the workflow around scans and audits. Accessible.org Labs is actively researching how AI can make evaluation and remediation more efficient, helping teams triage scan output faster and apply audit findings with better context. That is real AI applied to a workflow, not a claim that AI has automated conformance.
Frequently Asked Questions
Should we replace our audit with more frequent scans?
No. Scans and audits do different work. Scans monitor for a narrow set of issues between full evaluations. A (manual) audit is the only way to determine WCAG conformance. Increasing scan frequency does not close the gap on the 75% of issues scans cannot detect.
How often should we scan?
Match the cadence to your release velocity. Weekly scans work for most sites. Scans on every deploy work for teams shipping daily. What matters is that the scan runs frequently enough to catch regressions while they are still small.
What should we do when a scan flags an issue?
Review the flagged item, confirm it is a real issue and not a false positive, and address it in the next sprint. If the same category of issue keeps appearing, that points to a pattern in the codebase worth fixing at the component level rather than page by page.
Do scans satisfy legal requirements?
No regulation is satisfied by a scan alone. ADA compliance, EAA compliance, and Section 508 all reference the underlying accessibility standard, and conformance to that standard cannot be verified by an automated tool.
Scans keep the code honest between audits. The audit keeps the program honest overall. Both matter, and neither substitutes for the other.
Contact Accessible.org to discuss an audit and monitoring cadence that fits your release schedule. Contact Accessible.org.
