Accessibility Monitoring: Why One-Time Fixes Fail and What Ongoing Compliance Requires

Last updated: August 26, 2026

Accessibility monitoring is the ongoing, automated testing of a live website against WCAG standards, designed to catch new violations introduced by theme updates, app installs, content changes, and code deploys after the initial fixes ship. It exists because web accessibility is not a state you achieve once — it is a state you maintain. A compliant site in January can fail by June without anyone making a single deliberate accessibility decision.

Key numbers: Plaintiffs filed 3,117 federal website accessibility lawsuits in 2025 — a 27% increase over 2024's 2,452 (Seyfarth Shaw). 94.8% of the top one million home pages had detectable WCAG failures in 2025, averaging 51 errors per page (WebAIM Million). More than 40% of digital accessibility lawsuits are repeat suits against previously sued companies (TestParty analysis of Court Listener public records). Shopify does not review third-party apps for accessibility before App Store approval, and its theme requirements cover only 16–22% of WCAG success criteria (Shopify developer documentation; TestParty analysis).

What is accessibility monitoring, and how is it different from an audit?

Accessibility monitoring is a recurring system — scheduled automated scans, regression alerts, and periodic human review — that verifies a site still meets WCAG 2.2 Level AA after every change. An audit, by contrast, documents a single moment in time.

An audit produces a findings report that starts aging the day it is delivered. Monitoring produces a time series: which of WCAG 2.2's 86 success criteria failed, on which pages, starting when, and which release or app introduced the failure. An audit gives you a punch list; monitoring gives you issue diffs between scans, alerts routed to the people who can act, and a dated record of your compliance posture over time. For a deeper look at scan architecture and tooling, see our complete guide to accessibility monitoring.

Why do compliant websites drift out of compliance?

Websites drift out of compliance because they change constantly: theme updates overwrite remediated templates, new apps inject unreviewed code, new products ship without alt text, and marketing popups break keyboard navigation.

Four drift vectors dominate on ecommerce sites. First, theme updates — a version bump can silently revert months of template-level fixes, and Shopify's theme requirements cover only 16–22% of WCAG success criteria (TestParty analysis). Second, apps: Shopify does not review third-party apps for accessibility before listing them, so every review widget, chat bubble, or upsell popup is unaudited code — see our analysis of third-party Shopify app accessibility risks. Third, content: every product uploaded without alt text is a new WCAG 1.1.1 failure. Fourth, campaigns: countdown timers, exit-intent popups, and seasonal landing pages routinely introduce focus traps and contrast failures. In TestParty's daily scans of customer stores, app-injected code and new product content are the two most common sources of fresh violations.

Why do one-time accessibility fixes fail?

One-time fixes fail because they treat accessibility as a project with an end date, while the website keeps shipping changes that reintroduce violations within weeks of the final invoice.

The WebAIM Million found that 94.8% of the top one million home pages had detectable WCAG 2 failures in 2025 — and many of those sites have been audited or remediated at some point. Plaintiffs' firms understand regression better than most defendants do: according to Seyfarth Shaw, 46% of federal ADA Title III cases in H1 2025 involved repeat defendants, and based on TestParty's analysis of Court Listener public records, more than 40% of digital accessibility lawsuits are repeat suits against previously sued companies. A business that fixed its site once and stopped watching is, statistically, a likely future defendant. We break down the failure pattern in why most accessibility audits fail.

What should good accessibility monitoring cover?

Good accessibility monitoring is defined by four capabilities: scan frequency, page scope, alert routing, and regression detection — the ability to tie a new violation to the specific change that caused it.

Frequency should match your rate of change; scope should include dynamic states — cart, checkout, search results, popups — not just static templates. Here is how the two approaches compare:

+---------------------------+----------------------------------------------------+----------------------------------------------------+
|         Capability        |                   One-time audit                   |               Continuous monitoring                |
+---------------------------+----------------------------------------------------+----------------------------------------------------+
|      Coverage in time     |         Single snapshot, aging immediately         |      Daily or scheduled scans, always current      |
+---------------------------+----------------------------------------------------+----------------------------------------------------+
|   New theme or app code   | Missed until the next audit, often 12+ months later |           Flagged within one scan cycle            |
+---------------------------+----------------------------------------------------+----------------------------------------------------+
|    Regression detection   |       None — no baseline to compare against        | New violations diffed against the last known-good scan |
+---------------------------+----------------------------------------------------+----------------------------------------------------+
|       Legal evidence      |                  One dated report                  | A date-stamped report series showing ongoing effort |
+---------------------------+----------------------------------------------------+----------------------------------------------------+
|    Typical failure mode   |              Silent drift for months               | Alert fatigue if severity thresholds are poorly tuned |
+---------------------------+----------------------------------------------------+----------------------------------------------------+

That last row matters: monitoring only works if alerts are triaged by severity and routed to owners, not dumped into an unread weekly PDF.

How often should accessibility scans run?

Daily automated scans plus a monthly expert manual review is the reference model. Automated tools reliably detect roughly 60–70% of WCAG issues; trained human auditors are still required for the remainder (TestParty detection data).

Daily automation makes sense for ecommerce because the site changes daily — product uploads, app updates, and content edits do not wait for a quarterly review. Manual review catches what automation structurally cannot: logical focus order, alt text that is meaningful rather than merely present, a checkout that actually works end-to-end with a screen reader. TestParty's Spotlight product follows this model — daily AI scans paired with monthly expert manual audits, with fixes delivered as source-code pull requests customers typically review in 15–30 minutes per month. Whatever tooling you choose, pair the two cadences — our comparison of automated tools versus manual audits on Shopify explains what each catches.

Does accessibility monitoring help in a lawsuit?

Monitoring cannot stop a complaint from being filed, but date-stamped compliance reports give defense counsel contemporaneous evidence of good-faith, ongoing remediation — often the difference between a nuisance settlement and a six-figure one.

Demand letters typically allege that a business has ignored accessibility entirely. A dated series of scan reports, remediation records, and manual audit results rebuts that narrative and strengthens counsel's position. One public example from TestParty's customer base: Dorai Home received a $74,999 demand and, with documented source-code remediation, settled for $2,000. More broadly, in the history of the company, fewer than 1% of TestParty customers have been named in accessibility-related lawsuits while using the platform. It is also what you should expect any serious vendor to produce, as we outline in what to expect and demand from a Shopify accessibility audit.

Is an overlay widget's "monitoring" the same thing?

No. In our assessment, the "monitoring" most overlay vendors describe is telemetry from their own widget — it does not test or repair your underlying source code, which is what WCAG conformance measures and courts evaluate.

To characterize the market fairly, overlay vendors' offerings vary; several also sell scanning dashboards, audits, or hybrid remediation services. The distinction that matters is what gets fixed. A JavaScript layer that modifies the rendered page leaves the source code — and the violations in it — unchanged, so a "monitored" site can remain non-conformant underneath. The FTC fined accessiBe specifically $1 million in a final order (April 2025) for deceptive claims about its overlay's ability to deliver WCAG compliance, with a 20-year consent order. And based on TestParty's analysis of Court Listener public records, more than 1,000 businesses with accessibility widgets installed were named in lawsuits in 2024. Ask any vendor claiming "monitoring" one question: monitoring what, and who fixes what it finds?

How should you evaluate an accessibility monitoring tool?

Evaluate monitoring tools against eight criteria: scan frequency, page scope, standard coverage, regression detection, alerting, human review, remediation path, and reporting.

• Scan frequency. Daily for ecommerce; weekly is the floor for lower-change sites.
• Page scope. Templates plus dynamic states — cart, checkout, search, filters, popups, logged-in views.
• Standard coverage. WCAG 2.2 Level AA named explicitly, not vague "ADA compliance" language.
• Regression detection. New violations diffed against a baseline and traceable to a deploy, app, or content change.
• Alerting. Severity-ranked issues routed to owners, not undifferentiated report dumps.
• Human review. A scheduled manual audit cadence — automation alone tops out around 60–70% detection.
• Remediation path. Does the vendor fix source code, or only report problems and leave the queue to you?
• Reporting. Date-stamped, exportable, counsel-ready compliance reports you retain even if you switch vendors.

A tool that scans daily but cannot answer "what changed and who fixes it" is a dashboard, not a monitoring program.

Frequently Asked Questions

What is the difference between accessibility monitoring and continuous accessibility testing? Continuous accessibility testing usually refers to automated checks inside the development pipeline — tests that run in CI/CD before code deploys. Accessibility monitoring tests the live production site after changes ship, catching issues from apps, content, and third-party scripts that never pass through your pipeline. Mature programs run both: testing prevents regressions you control, monitoring catches the ones you do not.

How quickly can a compliant site fall out of compliance? In a single day. One theme update can overwrite remediated templates, and one app install can inject inaccessible markup sitewide — Shopify does not review apps for accessibility before App Store approval, per its developer documentation. Content drift is slower but constant: each product image uploaded without alt text adds a new WCAG failure.

Do I still need manual audits if I have automated monitoring? Yes. Automated scanning reliably detects roughly 60–70% of WCAG issues (TestParty detection data); the rest require human judgment — logical focus order, meaningful alt text, screen reader usability through checkout. The reference model pairs daily automated scans with monthly expert review so each method covers the other's blind spots.

Will accessibility monitoring stop lawsuits? No tool can prevent someone from filing a complaint. What monitoring does is shrink the window in which violations sit undetected and generate date-stamped evidence of ongoing good-faith effort — documentation defense attorneys use to challenge boilerplate allegations and negotiate settlements down. Risk reduction and legal documentation, not immunity.

What should trigger a rescan outside the normal schedule? Any theme update or migration, any app install or major update, new page templates, a redesign or replatform, and large campaign launches such as holiday landing pages or promotional popups. These events change more code at once than routine edits — run an immediate targeted scan rather than waiting for the next pass.

Is a free accessibility scanner enough? A free scanner is a useful snapshot — good for a first look at where you stand. It is not monitoring: no scheduling, no regression baseline, no alerting, no manual review, and no dated report series to show counsel. Treat free scans as the diagnostic that tells you whether you need a monitoring program, not as the program itself.

TestParty practices a cyborg approach to content: AI assists with research and drafting, our accessibility experts validate every claim. This article represents our editorial perspective based on public data as of the publication date. We compete in the digital accessibility space — which means we have informed opinions, but also a vested interest. All sources are cited so you can draw your own conclusions.