WebAIM's latest analysis of the top one million home pages makes uncomfortable reading. In February 2026, 95.9% of sites had detectable WCAG failures. That's worse than the previous year's 94.8%.
Let that sink in. Despite increased awareness, legal pressure, and better tooling, the web is getting less accessible, not more.
The pattern emerging from repeat ADA litigation in the US tells us why. Organisations fix problems once, get sued again two years later, and discover a fresh batch of failures. Accessibility isn't something you complete. It's something you maintain.
The one-off fix fallacy
Here's a scenario that plays out constantly: A company receives a legal demand or fails an audit. They hire someone to remediate their site. Three months later, the marketing team publishes new landing pages. The development team ships a redesigned checkout flow. Neither team runs accessibility checks.
Within six months, the site has regressed to roughly where it started.
This happens because accessibility gets treated as a project with a start and end date. But websites aren't static documents. They're living systems that change weekly, sometimes daily. Every new component, every content update, every third-party widget is an opportunity to introduce barriers.
What the repeat lawsuits tell us
In the US, plaintiffs' lawyers have noticed something useful: companies that settled accessibility claims make good targets for follow-up litigation. Not because the lawyers are opportunistic (though some are), but because the underlying issues genuinely recur.
A business fixes their image alt text in 2024. By 2026, they've added 500 new product images, half of which have empty or meaningless alt attributes. They fixed their form labels, but the new contact form a contractor built doesn't have any. The pattern repeats across every WCAG criterion.
The litigation data reveals that accessibility failures cluster around the same issues year after year:
- Missing or inadequate alt text (WCAG 1.1.1)
- Insufficient colour contrast (WCAG 1.4.3)
- Missing form labels (WCAG 1.3.1, 4.1.2)
- Empty links and buttons (WCAG 2.4.4, 4.1.2)
- Missing document language (WCAG 3.1.1)
These aren't obscure technical requirements. They're the basics, and they keep breaking because nobody's checking.
What ongoing accessibility actually looks like
Treating accessibility as an ongoing practice means building it into your existing workflows rather than bolting it on afterwards.
During development
Accessibility checks should run in your CI/CD pipeline. When a developer submits code that creates a button without an accessible name, the build should flag it before it reaches production. Automated tools catch roughly 30-40% of WCAG issues—the predictable, pattern-based ones. That's not everything, but it stops the most common regressions.
During content creation
Your CMS should make accessibility the path of least resistance. If uploading an image requires alt text before saving, people write alt text. If it's optional, they skip it. The same applies to heading structure, link text, and video captions. Make the accessible choice the default choice.
During QA
Manual testing catches what automation misses. Can someone navigate your new feature using only a keyboard? Does the tab order make sense? Do screen reader announcements convey the right information? These checks take minutes per feature when done during development. They take days when done as a remediation project months later.
On a schedule
Even with checks at every stage, things slip through. Run a full automated scan monthly. Review the results. Fix regressions before they accumulate. Conduct manual audits quarterly or after major releases.
The cost comparison
Remediation projects are expensive. Agencies quote thousands of pounds to audit and fix an existing site. Legal costs if things go wrong run much higher.
Ongoing checks cost far less. A developer spending 30 minutes per sprint on accessibility testing. A content editor adding two minutes per image for proper alt text. An automated scan running in the background.
The maths favours prevention.
For UK developers and agencies
While the lawsuit data comes from the US, the technical reality applies everywhere. UK sites must meet accessibility requirements under the Equality Act 2010. Public sector sites have explicit WCAG 2.1 AA obligations. The European Accessibility Act now affects products and services across the EU.
More importantly, your users need accessible sites regardless of legal requirements. The 95.9% failure rate means nearly every site is excluding people unnecessarily.
Making it stick
The organisations that maintain accessibility over time share common traits:
- Accessibility has an owner. Someone's job includes checking that standards don't slip.
- Testing is automated where possible. Machines catch the repetitive stuff.
- Training is ongoing. New team members learn the basics. Existing team members get refreshers.
- Metrics are tracked. You can't improve what you don't measure.
The WebAIM numbers will keep getting worse until more organisations treat accessibility as maintenance rather than a project. The repeat litigation will continue until businesses realise that fixing something once doesn't mean it stays fixed.
WCAGCheck scans your website for WCAG compliance issues and tells you exactly what to fix. Try it free at wcagcheck.co.uk