Accessibility monitoring and an audit answer different questions, so the decision is usually about order rather than picking a winner. An audit tells you where you stand right now, in depth, including the failures no tool can see: whether your custom dropdown works from the keyboard, whether a validation error actually reaches a screen reader. Monitoring tells you when that answer stops being true. It runs on a schedule, covers far more pages than a person can read, and catches the regression someone shipped on Tuesday afternoon. If nobody has ever assessed your site properly, start with the audit. Monitoring an unassessed site gives you a tidy chart of the issues automation can detect and silence about everything else. If you have had an audit, monitoring is what stops it going stale between reviews. For anyone in scope of the EAA, the ongoing half is not optional: Article 13(3) requires service providers to have procedures in place so the service remains in conformity, not just arrives there once.
What is the difference between accessibility monitoring and an audit?
An audit is a point-in-time assessment done by people. Someone works through a sample of your pages against the WCAG success criteria, with a keyboard and a screen reader, and writes up what fails, where, and why it matters. Monitoring is an automated check that repeats on a schedule across many more pages and reports what changed since the last run.
The W3C treats them as the same activity at different frequencies. WCAG-EM 2.0, the W3C's evaluation methodology, describes re-running an evaluation "periodically to monitor progress", reusing part of the earlier sample so the results stay comparable (W3C). Monitoring is an audit you repeat cheaply. That framing is useful because it makes the trade-off obvious: repeating something cheaply means dropping the expensive part, and the expensive part is the human.
| One-time audit | Continuous monitoring | |
|---|---|---|
| Who does the work | A person, with assistive technology | A scanner, on a schedule |
| Depth vs breadth | Deep, on a small sample | Shallow, across many pages |
| Question it answers | Where do we stand against WCAG? | What changed since last week? |
| Typical cadence | Annually, or before a release or procurement | Per deploy, nightly or weekly |
| What you hand to a reviewer | Findings with expert judgement and severity | A trend line, a diff, a dated scan history |
Which one should you buy first?
Audit first, unless you already know your baseline.
The reason is that monitoring measures change against a starting point, and if the starting point was never established, the chart is measuring nothing useful. A site that has 300 detectable violations on day one and 300 on day ninety looks stable. It is stable at bad. Meanwhile the criteria a scanner cannot evaluate at all, like whether your error messages are understandable or whether a drag interaction has a pointer alternative, stay invisible for the entire ninety days.
One exception is worth naming. If your site is small, changes rarely, and you cannot fund both, a scheduled scan plus a serious manual pass on your two most important journeys beats a one-off audit followed by nothing. An audit's value decays. WebAIM's 2026 analysis of a million home pages found 95.9% had detectable WCAG failures, averaging 56.1 errors per page, up 10.1% from the 51 per page recorded in 2025 (WebAIM). The web is getting less accessible year over year, mostly through added complexity, and your site is not exempt from that drift.
What can monitoring actually catch?
The frequent, mechanical failures, which is a larger share of your real defect count than the phrase "only automated" suggests.
Deque's analysis of more than 2,000 audits, covering roughly 13,000 pages and nearly 300,000 issues, put automated coverage at about 57% of issues by volume (Deque). Counted by success criteria rather than defect volume, the honest figure lands nearer 30%. Both numbers are true and they measure different things, which is why we quote the range of roughly 30 to 57% rather than the flattering end of it.
The reason volume coverage is so much higher is that the common failures are the machine-checkable ones. Missing alternative text, low contrast, an input with no associated label, an empty link, a missing document language. A scanner will tell you button.icon-close has no accessible name at 09:14 on the morning it ships, and that is exactly the kind of finding you want caught by a robot rather than by a customer.
Monitoring also does one thing an audit structurally cannot: it watches content you did not write. WCAG's own conformance guidance is direct about this, in the context of third-party content: "Be sure to monitor any content that can change without approval from the web page author, as a page which once conformed may suddenly fail to conform" (W3C). If marketing can publish a hero image through a CMS, or a review widget injects markup at runtime, your conformance is a moving target by design.
What does an audit catch that monitoring never will?
Judgement. The W3C puts it plainly in its guidance on choosing tools: evaluation tools "can not determine accessibility, they can only assist in doing so", and "human judgement is required" (W3C WAI).
Concretely, a scanner can confirm an image has an alt attribute. It cannot tell you the alt text says "image1234.png". It will not tell you your modal returns focus to the top of the document instead of the button that opened it, or that the whole checkout collapses at 200% zoom on a phone. We publish a longer breakdown in what a real accessibility audit includes. The short version is that the criteria requiring a human are the ones your users actually notice.
Regulators have formalised this split, which is the most persuasive thing I know to show a finance director. Under the public sector Web Accessibility Directive, Commission Implementing Decision (EU) 2018/1524 sets two monitoring depths: a simplified method of mostly automated tests across a broad sample, and an in-depth method putting a person through whole journeys with assistive technology. The bodies who check accessibility at national scale do both. They do not pick one.
Does the law expect ongoing monitoring, or is one audit enough?
One audit is not enough, and the texts say so in more than one place.
The EAA puts the obligation on service providers directly. Article 13(3) of Directive (EU) 2019/882 requires that "procedures are in place so that the provision of services remains in conformity with the applicable accessibility requirements", and adds that changes to the service, to the requirements, or to the harmonised standards a service was declared against must be taken into account (EUR-Lex). That is a process requirement, not a document requirement. A PDF from last March does not satisfy it.
WCAG points the same way through the shape of a conformance claim. The example claim in the W3C's conformance guidance is dated: "On 20 September 2009, all web pages at http://www.example.com conform to Web Content Accessibility Guidelines 2.0..." (W3C). A claim is anchored to a date and a set of pages, which means it starts expiring the moment you deploy.
This is also why an accessibility statement is easier to keep honest with something running continuously behind it. A statement documents your effort and your known limitations, not a guarantee, and it ages badly when the last real evidence behind it is nine months old. If you report against EN 301 549, Annex C gives you the per-clause structure for met, partially met or not met, and a scan history gives you the dates to defend each line.
How often should you scan, and how deep?
Match the cadence to how often the thing changes, not to a vendor's pricing tier.
A practical split that works for most product teams:
- Every deploy, on the pages that deploy touched, so a regression never reaches a customer.
- Weekly, across the crawlable site plus your authenticated journeys: signup, checkout, password reset, the main task in your app. Homepage-only scans miss where barriers live, as we covered in why homepage scans miss your real risk.
- Annually, or after a significant redesign, a human audit against the standard you are held to.
WCAG-EM's rule on sampling applies to the automated runs as much as the human ones: include every view that belongs to a complete process. A clean cart page means nothing if step four of checkout traps keyboard focus, because under WCAG a process only conforms if every page in it conforms.
How do you combine both without paying twice for the same work?
Let the scanner own the repeatable part and buy human time only for what needs a human.
In practice the audit scope excludes what the scanner already covers well. If continuous scanning handles contrast, labels, alt text and ARIA validity across 400 pages, the auditor should not re-check those by hand on 12. Point them at keyboard operability, focus management, screen reader semantics on your custom components, and the journeys that carry revenue. The audit gets cheaper and sharper at once, because you are buying judgement rather than coverage.
One opinion, stated plainly: a monitoring dashboard that has never been calibrated against a human review is a comfort object. It goes green, everyone relaxes, and the criteria it was never able to evaluate stay broken. We built our scanner to say what it cannot decide, and to leave those clauses open rather than quietly pass them, because a report that admits its own gaps is the only kind worth putting in front of a regulator. Automation finds issues. Full conformance still needs a person.
Run it in the other direction once, too. Take your last audit's findings, turn the machine-checkable ones into monitored rules, and you will know within a week whether the fixes held. Most teams find at least one that did not survive the next sprint.
Frequently asked questions
Is accessibility monitoring a replacement for an audit?
No. Monitoring detects roughly 30 to 57% of issues depending on how you count, and the criteria it cannot evaluate, such as meaningful alt text, focus order and screen reader semantics on custom components, are the ones users hit hardest. Monitoring keeps an audit's result from going stale. It does not produce that result.
How often should we run an accessibility audit?
Annually is the common baseline for a site under active development, plus an audit after any significant redesign or before a procurement or conformance report. If your site barely changes, a longer gap is defensible as long as something automated is watching between reviews.
Does the EAA require continuous accessibility monitoring?
The EAA does not prescribe a tool or a frequency. Article 13(3) of Directive (EU) 2019/882 requires service providers to have procedures in place so the service remains in conformity, including when the service or the standards change. Regular checking is the normal way to meet that, and a dated scan history is the easiest evidence to produce.
Can a scan report be used as compliance evidence?
It supports a claim, it does not make one. A scan gives you dated, per-page results you can map to the clauses of EN 301 549 or the WCAG criteria your statement references. Findings that need human confirmation should be recorded as exactly that, rather than folded into a percentage implying more certainty than the method supports.
Start with your baseline
If you do not know where your site stands today, the fastest way to find out is to scan a real journey rather than the homepage. Run a free scan on the page you would least like a regulator to open, then work the result against the WCAG checklist to see which items still need a person. That takes an afternoon and tells you whether your next spend should be the audit or the monitoring.
Pavel Charkasau, founder, wcagc.com. Last updated 13 September 2026.
Sources
- Directive (EU) 2019/882 (European Accessibility Act), EUR-Lex — Article 13(3): service providers shall ensure "that procedures are in place so that the provision of services remains in conformity with the applicable accessibility requirements", taking account of changes to the service, the requirements and the harmonised standards. Accessed 13 September 2026.
- Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 2.0, W3C — re-running an evaluation "periodically to monitor progress" and reusing part of the preceding sample for comparability; Methodology Requirement 3.3, "Include all samples that are part of a complete process in the selected sample set." Accessed 13 September 2026.
- Understanding Conformance, WCAG 2.2, W3C — the dated example conformance claim; Conformance Requirement 3 on complete processes; on third party content, "Be sure to monitor any content that can change without approval from the web page author, as a page which once conformed may suddenly fail to conform." Accessed 13 September 2026.
- Selecting Web Accessibility Evaluation Tools, W3C WAI — "Tools cannot check all accessibility aspects automatically. Human judgement is required"; tools "can not determine accessibility, they can only assist in doing so." Accessed 13 September 2026.
- Automated testing study identifies 57% of digital accessibility issues, Deque — March 2021; more than 2,000 audits across roughly 13,000 pages and nearly 300,000 issues; about 57% of issues covered by automated testing when measured by volume. Accessed 13 September 2026.
- The WebAIM Million: the 2026 report, WebAIM — February 2026; detectable WCAG 2 failures on 95.9% of home pages; 56.1 errors per page on average, a 10.1% increase on the 51 errors per page found in the 2025 analysis. Accessed 13 September 2026.
- Commission Implementing Decision (EU) 2018/1524, EUR-Lex — the monitoring methodology under Directive (EU) 2016/2102: a simplified method of mostly automated tests across a broad sample, and an in-depth method covering whole user journeys with assistive technology. Accessed 13 September 2026.