For site owners, product managers and QA
Sites don't stay fixed. Monitoring that tells you which release broke it.
Re-scans that compare against your baseline, alert on regressions rather than on everything, and name the change that introduced the barrier — not just the barrier.
01 — The problem
Most monitoring stops working the day your team stops reading it.
Three failure modes, all of them common, none of them about the scanning engine.
Volume mistaken for thoroughness
One low-contrast rule in a stylesheet becomes four hundred findings across four hundred blog posts. That is one CSS line, not four hundred emergencies — but counted as four hundred it makes a report look exhaustive and an inbox look impossible.
False positives your team has to triage
This is documented by the customers themselves, not by us: the University of Iowa publishes articles explaining common false positives in its monitoring reports and how to tell whether action is needed, and the University of Warwick has published the specific false positives it identified on its own templates. Every one of those is staff time spent on a finding that was never real.
A rising line that hides a falling floor
An estate-wide score can climb from 70 to 85 while checkout quietly becomes unusable with a screen reader, because checkout is a handful of pages inside an average of hundreds. Averages move on volume. Barriers happen on specific journeys.
A typical weekly digest — noise
- 1.4.3Low contrast — 412 occurrences
- 1.1.1Missing alt text — 88 occurrences
- 2.4.4Link text unclear — 240 occurrences
- …and 47 more categories
- ≡Identical to last week's digest
Week four: the rule that files this to a folder nobody opens.
What we send instead — signal
- NEWMenu button lost its expanded state — Theme 2.4
- 4.1.2Critical · nav .menu-toggle · needs developer
The other 46 open issues have not changed and are waiting in the report. Nothing new happened to them, so nothing was sent about them.
02 — Delta
Pick a release. See what it changed.
This is the whole idea, so here it is working rather than described. Four deploys on one site over five weeks.
Select a deployment
18 June — baseline established
49 open
- First full scan. 49 findings recorded, 6 critical. Nothing to compare against yet — this is the measured starting point everything after is judged from.
2 July — Sprint 41
−4 closed+0 new45 unchanged
- Form labels added across the account area
- 45 findings unchanged — reported in full, notified about zero times
16 July — Theme 2.4 · alert fired
+2 new−0 closed45 unchanged
- Critical. The navigation menu button no longer reports whether it is expanded, so a screen reader user cannot tell if the menu opened.
- Serious. Focus outline removed from primary buttons by the new stylesheet.
24 July — hotfix verified
−2 closed+0 new45 unchanged
- Expanded state restored on the menu button — confirmed by re-scan, 8 days open
- Focus outline restored — confirmed by re-scan, 8 days open
A baseline is worth recording before any remediation starts. Without it, "we improved" has no denominator.
03 — Built for continuous delivery
Where the alerts go, and who gets which one.
Tier availability is marked on each item, because finding out later is worse than knowing now.
- From free
Scheduled re-scans
Automated re-scans on a schedule, with frequency set by tier — daily on the entry plan, twice-daily on Scale, continuous on Infrastructure. Each run is compared against your baseline rather than treated as a new investigation.
- From free
Regression alerts, critical only
A notification fires when something that used to pass stops passing — with the URL, the element selector, the WCAG criterion, the severity, and whether the fix needs a developer. Unchanged findings stay in the report and generate nothing.
- From free
Tickets to your tracker
Developer-side regressions export to Jira, GitHub, Trello or Asana with the selector and remediation note in the body, so triage is an estimate rather than an investigation.
- Infrastructure
Scan triggered by your pipeline
Fire a scan from CI/CD the moment you deploy, and fail the build on a new critical finding. Being straight with you: the CLI, custom API and webhooks sit on the Infrastructure tier today. If pipeline-triggered scanning is why you are on this page, say so — the roadmap for it is driven by how many teams ask.
- Paid tiers
Timestamped audit history
Every scan is dated and kept, including the runs where things got worse. If a claim ever arrives, the file already contains a record of continuous, documented effort rather than a reconstruction made afterwards.
- Jira
- GitHub
- Trello
- Asana
04 — The honest promise
What automated monitoring can and cannot do.
It will catch
- An
altattribute that disappeared in a template change - A form control that lost its programmatic label
- A contrast ratio that dropped below threshold after a palette tweak
- Invalid or removed ARIA introduced by a plugin update
It will not tell you
- Whether the new
alttext actually describes the image - Whether a screen reader user can finish your redesigned checkout
- Whether the focus order still makes sense to a person following it
- Whether an error message explains how to recover
The reason we are this careful about wording
In January 2025 the US Federal Trade Commission brought a complaint against a vendor in our own category over claims that its tool could make any website WCAG compliant; the final order, approved in April 2025, required a $1 million payment (FTC case 2223156 (opens in a new tab)). The FTC's complaint said the product failed to make basic components accessible — navigation menus, form fields, image descriptions. Separately, UsableNet counted 119 defendants sued in May 2025 alone while already running a third-party accessibility widget (UsableNet 2025 Midyear Report (opens in a new tab)). We sell a widget too. That is exactly why nothing on this page says monitoring makes you compliant, and why every finding is labelled as widget-addressable or developer-only.
Automated testing reliably detects 30–50% of WCAG 2.2 AA success criteria. Monitoring is how you hold that automatable share steady between human audits — it is not a substitute for them. What our monitoring adds is a trigger: when a scan detects that a major flow has been rebuilt, it flags that a human re-audit is due, rather than letting a green dashboard imply nothing changed.
05 — FAQ
Questions, answered honestly.
How often should we scan?
Match it to how often the site changes, not to how worried you are. A shop or web app that ships weekly benefits from a scan on every release. A marketing site that publishes a few posts a month does not get more value from daily scanning — it gets more email. If you are unsure, start with the schedule your plan includes and increase it only when a regression slips through.
Will scanning load our servers or distort our analytics?
Our scanner requests pages the way a crawler does, on a schedule you control, so load is a function of how many pages and how often. If server impact is a concern on a large site, tell us before you set the schedule and we will size it with you. On analytics: any crawler can show up in your reporting unless it is excluded, so ask us for the exact identifiers our scanner sends and filter on those — we would rather give you something you can verify in your own reports than a reassurance you have to take on trust.
What exactly arrives when a critical regression is found?
An email with the page URL, the element selector, the WCAG success criterion, the severity, whether the fix needs a developer, and remediation guidance — framework-specific where we know your stack. Enough to open the file and start, without opening the dashboard first. We give you the selector rather than a line number, because we scan rendered pages and cannot see your source tree.
What about third-party widgets we do not control?
Chat tools, payment iframes and embedded media change without asking you, and they are a genuine and common source of regressions. Findings that originate in third-party content are identified as such in the report, so you can raise it with that supplier in writing rather than spending a sprint looking for it in your own code. What your obligations are for third-party content depends on your jurisdiction and your contracts — that part is a question for your counsel, not for us.
Does monitoring keep us compliant?
No. Monitoring keeps you informed, which is a different and more useful thing. It detects regressions in the machine-testable part of WCAG, records what happened and when, and tells you when a human audit is due. It does not make your site conformant, it does not provide legal immunity, and a clean monitoring dashboard is not a conformance claim. What it produces is evidence of documented, continuing effort — which is worth having, and is not the same as immunity.
Catch the break before your visitors do.
Set up monitoring in under two minutes. No card, no trial timer, no sales call in the way.
Baseline today, and every scan after it is measured from something real.