Web Accessibility Compliance: Beyond the WCAG 2.2 Audit

Web Accessibility Compliance: Beyond the WCAG 2.2 Audit 

Website accessibility lawsuits reached 3,117 federal filings in 2025, according to Seyfarth Shaw’s annual ADA Title III review – up 27% on 2024, and 36% of all Title III filings. 

A firm scaling toward a growth phase, an acquisition, or a public tender is precisely the profile that gets noticed: more traffic, more pages, more public commitments about inclusion, more surface area. 

If your accessibility strategy is a PDF audit sitting in a shared drive, you have bought a photograph of a river.

Getting the site itself right is design work, not a bolt-on. 

It is the discipline a serious web design agency builds into the structure of a site rather than inspecting for afterwards – and the difference between those two approaches is the whole of this article.

How Enterprise Web Accessibility Compliance Is Actually Achieved

Web accessibility compliance is achieved not by passing a one-off WCAG 2.2 audit but by embedding conformance into the design system, QA process, release gates and procurement so it holds through every redesign and release. An audit tells you where you stand today. An operating model determines where you stand after the next fifty deployments.

• WCAG 2.2 became a W3C Recommendation on 12 December 2024, and W3C states that content conforming to 2.2 also conforms to 2.0 and 2.1.
• WebAIM’s 2026 analysis of the top one million home pages found 95.9% carried detected WCAG failures – evidence that conformance-as-event does not hold.
• The durable fix is architectural: accessible components produce accessible pages, so the design system is where compliance is won or lost.

Web accessibility compliance is achieved not through one-off audits but by embedding WCAG 2.2 conformance into design systems, QA, release gates and procurement as a continuous operating model.

What You Need in Place Before You Start

An operating model needs foundations that most guides skip. Without these, you are auditing forever.

• You need a single owner with authority over releases – not a committee, and not “everyone.” 
• You need a component library or design system that pages are actually built from, so a fix applies once and propagates everywhere. 
• You need automated testing wired into your build, because manual audits cannot keep pace with WebAIM’s finding that home page complexity has risen to an average of 1,437 elements per page in 2026, up 22.5% in a single year. 
• And you need someone to have explicitly decided that overlay widgets are not your strategy.

That last point matters more than firms expect. Accessibility.com’s 2025 lawsuit reporting found 37% of sued websites used overlays – the automated “accessibility toolbar” widgets sold as instant compliance. 

They are named in litigation, not exempt from it. If a vendor has promised you a line of JavaScript that solves WCAG, the honest entry condition for this entire process is deleting it.

Stage 1 – Establish the Baseline You Can Actually Trust

The first stage is a real audit, and its job is to tell you the truth about the current state, not to produce a pass. 

Run automated tooling across representative templates, then have a human test keyboard navigation, screen-reader behaviour, and focus order – because automation catches roughly a third of issues and confidently misses the rest.

You know this stage is done right when your findings map to specific components, not specific pages. 

WebAIM’s 2026 data shows 96% of all detected errors fall into just six categories: low-contrast text, missing alt text, missing form labels, empty links, empty buttons, and missing document language. 

Low-contrast text alone appeared on 83.9% of home pages, with alt text missing on 53.1% and form labels missing on 51%. These are not exotic edge cases. They are the same six failures repeating across a component library.

The failure mode here is auditing pages instead of patterns. A 40-page report listing the same contrast failure 40 times is a report of one broken button style, transcribed 40 times. Fix the button once, and the report shrinks to nothing.

“Ninety-six per cent of accessibility failures are six problems affecting forty different page addresses. Firms that audit pages spend the budget forty times. Firms that audit components spend it once, then never see those six failures again – because the fix lives in the design system, not the page.”

Stage 2 – Fix at the Design System, Not the Page

The second stage remediates the components, and this is where accessibility stops being compliance work and becomes design work. 

A design system is the set of reusable building blocks – buttons, form fields, navigation, cards – from which every page is assembled. Fix accessibility in the component, and every current and future page inherits the fix.

You know this stage is done right when a new page built by a marketing team is accessible by default, because it can only be assembled from accessible parts. 

That is the entire commercial argument for doing this architecturally: it moves the cost from ongoing to one-off. 

The alternative – page-by-page remediation – means paying for the same fixes forever, because the broken component keeps generating broken pages faster than you can audit them.

The failure mode is remediating live pages while leaving the source components untouched. The pages pass. The next page built from the same library fails. 

This is exactly how the litigation practice in the opening reintroduced every cleared failure within one release cycle.

Stage 3 – Wire Accessibility Into QA

The third stage makes accessibility a standard test, not a special project. 

Automated accessibility checks belong in the same pipeline as your other quality gates, running on every build, so a regression is caught the moment it is introduced rather than at the next annual audit.

You know this stage is done right when an accessibility failure breaks the build, just as a broken link or a failing unit test does. 

WCAG 2.2 success criteria are written as testable statements specifically to support this – W3C designed them to function in design specs, purchasing, regulation and contracts, not just in retrospective review.

The failure mode is treating accessibility testing as a manual quarterly event in an environment that ships weekly. 

The maths does not work. With pages averaging 1,437 elements and rising, no human review cadence keeps pace with a modern release schedule.

Stage 4 – Put Accessibility on the Release Gate

The fourth stage gives the standard teeth: nothing ships that fails. A release gate is a checkpoint that the code must pass before going live. 

Adding accessibility to that gate is the single mechanism that converts good intentions into an operating model, because it is the point where “we care about accessibility” becomes “this cannot deploy.”

This stage is achieved when a designer or developer has been stopped from shipping and has fixed the issue so they can proceed. 

Until that has happened at least once, you have a policy, not a gate.

The failure mode is a gate with an override that everyone uses. A checkpoint that can be waived under deadline pressure is not a checkpoint. 

This is the stage where the operating model is genuinely tested, and where most firms quietly fail – the gate exists on paper, and the exception becomes the rule.

Stage 5 – The Judgement Layer: Where Rules Run Out

The fifth stage is the one no tool automates, and it is where real experience separates working compliance from cosmetic compliance. 

WCAG 2.2 added new AA-level criteria – Focus Not Obscured, Dragging Movements, Target Size, Consistent Help, Redundant Entry, and Accessible Authentication – several of which resist pure automation because they depend on context and intent.

Target Size is the clearest example. An automated tool confirms that a tap target meets the minimum dimension. 

It cannot tell you whether two compliant targets sit close enough together that a user with a motor impairment triggers the wrong one under real conditions. 

That is a judgment call about actual human use, made by someone who has watched real people fail at real interfaces.

In 17 years of brand and web work, the pattern I see most often is firms passing the automatable criteria and failing the human ones. This form technically has labels, but is incomprehensible under a screen reader. This focus order is valid but nonsensical.

The Step Everyone Does Too Late: Procurement

Here is the sequence correction that separates a working result from a cosmetic one. Firms treat accessibility as something you check at the end – after the site is built, before it launches. 

By then, the expensive decisions are already made. Accessibility belongs at the start, in procurement.

The prevailing view is defensible on its face: you cannot test a site that does not exist yet, so accessibility feels like a launch-stage QA concern. 

Intelligent teams hold this position because it matches how they handle most quality checks. It is still the wrong order.

When a firm commissions a website, an agency, or a CMS platform without accessibility built into the contract and acceptance criteria, it inherits whatever it is given and then pays to retrofit later. 

W3C explicitly advises using the most current version of WCAG to maximise the future applicability of accessibility efforts – a procurement instruction, not a testing one. 

The decision that determines whether your site is accessible is made when you sign the contract, months before a single page is tested. 

A firm that specifies “WCAG 2.2 AA conformance, verified at acceptance, maintained via release gates” in its brief has solved at the start what most firms pay to fix at the end.

“Accessibility is not a test you run before launch. It is a clause you write before you commission. The firms that get sued are rarely the ones that failed a test – they are the ones that never specified the standard, accepted whatever they were handed, and discovered the gap when the demand letter arrived.”

This is also where overlays fail as a strategy. 

A firm reaching for an overlay widget is trying to solve at the very end a problem that should have been specified at the very beginning. 

Accessibility.com’s 2025 reporting found overlays present on 37% of sued sites for exactly this reason: they are the cosmetic shortcut applied after the architectural decisions foreclosed the real fix.

Where This Stands Now

Accessibility is not a solved problem trending toward compliance – the data shows the opposite. WebAIM’s 2026 analysis found 95.9% of the top one million home pages carried detected WCAG failures, averaging 56.1 errors each. 

The failures are basic and repetitive: 96% fall into the same six categories, led by low-contrast text on 83.9% of pages. This is a systemic implementation failure, not a frontier of hard-edge cases.

Two forces are pulling in opposite directions. Pages are getting more complex – 1,437 elements on average in 2026, up 22.5% year on year – which makes manual compliance harder and strengthens the case for automated, architectural approaches. 

And litigation is intensifying: Seyfarth Shaw recorded 3,117 federal website accessibility filings in 2025, up 27%, with New York and Florida the busiest venues. Enforcement pressure is uneven geographically but rising overall.

The overlay market is under specific pressure. 

Beyond the 37% figure, Accessibility.com reported that even sites litigated in September 2025 included ones running third-party overlay tools – direct evidence that the quick-fix product does not confer the protection it advertises. 

For a professional services firm, the strategic read is straightforward: the market is failing at the basics, the courts are active, and the shortcuts are being tested and found wanting. 

The advantage goes to firms that build it in.

Two Objections a Sceptical MD Will Raise

“This sounds like an expensive way to do what an audit does.” 

It is the opposite. 

An audit is a recurring cost that scales with your page count; every redesign buys another audit, and every release between audits accrues risk. 

The operating model is a mostly one-off cost – fix the components once, wire the gate once – after which accessibility becomes a property of the system rather than a line item. 

The firm auditing pages pays the WebAIM six-category tax repeatedly. The firm-fixing component pays it once.

“We’re a professional services firm, not a target – the lawsuits are about retail.” 

The 3,117 filings in 2025 were not confined to e-commerce, and the profile that draws attention is precisely a visible, scaling firm making public commitments, which is what a growth-phase or pre-acquisition rebrand is. 

A firm publishing inclusion statements on an inaccessible careers page has manufactured its own contradiction, in writing, on a public URL.

The Verdict

Compliance is the floor. An audit tells you whether you are standing on it today; it tells you nothing about tomorrow, and the website is entirely made of tomorrows. 

That is why 95.9% of home pages still fail WCAG despite a decade of mature guidance and rising litigation – not because firms do not audit, but because they audit a moving thing once and file the result.

The firms that get this right stop buying photographs of the river. 

They fix accessibility in the design system so components carry it, wire it into QA so builds enforce it, put it on the release gate so nothing ships without it, and – the part almost everyone does too late – specify it in procurement so the standard is set before the first page exists. 

Conformance ceases to be an event and becomes a property of how the organisation ships.

For a firm rebranding ahead of a growth phase or acquisition, this is not a compliance chore to delegate downward. 

It is a design decision at the top of the build, and it is far cheaper to make once, early, than to retrofit under a demand letter.

The first action today: pull up your current website brief or your last agency contract and check whether “WCAG 2.2 AA, verified at acceptance” appears anywhere in it. 

If it does not, that is the gap – and it is the one that gets firms sued. 

If you want to know exactly where your current site stands and what it would take to build the standard in properly, request a website accessibility and design diagnostic – a structured review that identifies where your site is exposed and what to fix first.

Frequently Asked Questions