Web Accessibility Compliance: What Applies, Where, and to Whom

Accessibility gets discussed as an ethical topic and budgeted as an optional one. It is neither. It's a regulatory surface, and which part of it applies to you is decided by two things you probably haven't mapped: where your customers are, and what you sell them.

That's the part most businesses get wrong. They ask "does accessibility law apply to us?" as though it's one law with one answer. It isn't. There are at least four overlapping regimes in play for a typical commercial website, they use different standards, they have different enforcement mechanisms, and at least one of them follows your customer rather than your company registration.

This is a map, not a checklist. The checklists go stale. The structure of the obligation doesn't.

Web Accessibility Compliance Is a Jurisdiction Problem

The single most consequential thing to understand about the current regulatory landscape: the law follows the customer, not the company.

The European Accessibility Act — Directive (EU) 2019/882 — has explicit extraterritorial reach. Any business placing products or services on the EU market is in scope regardless of where it's headquartered. A studio in Auckland, a retailer in Austin, a SaaS company in Bangalore: if EU consumers can buy from you, the EAA applies.

Businesses reliably miss this because every other compliance question they've handled was answered by their registered address. Accessibility isn't.

Your incorporation tells you nothing about which accessibility law applies. Your customer list does.

The EAA has applied since 28 June 2025. That deadline has passed, all 27 member states have transposed it into national law, and 2026 is the first full year of active supervision — which means a gap is now a live liability rather than a future one.

What Enforcement Actually Looks Like

Enforcement has been slower and stranger than the pre-deadline commentary predicted, and the shape of it is instructive.

In the EU, the earliest significant activity came from civil society rather than regulators. On 7 July 2025, four French disability organisations issued formal legal notices to Auchan, Carrefour, E. Leclerc and Picard demanding accessible websites and apps. When responses were judged insufficient, emergency injunctions followed in November 2025. The Auchan case was heard in May 2026 and dismissed — but the court acknowledged that the site did not conform to accessibility standards, a point Auchan did not dispute.

Read that carefully. The claim failed on procedural grounds. The non-conformance was conceded. That's not a defensive precedent; it's a roadmap for the next filing.

Meanwhile Sweden launched market surveillance in October 2025, and the Dutch ACM is actively enforcing against e-commerce and electronic communications. Penalties vary by national transposition, with reported ceilings reaching into the millions of euros in some jurisdictions.

In the United States the picture inverted. The DOJ's April 2024 final rule adopted WCAG 2.1 Level AA as the technical standard for Title II entities — state and local government. On 20 April 2026 the DOJ published an Interim Final Rule extending those compliance dates by a year, to 26 April 2027 for entities serving populations of 50,000 or more and 26 April 2028 for smaller ones.

The extension changed the deadline. It changed nothing else. Title II's underlying nondiscrimination and effective-communication obligations still support web accessibility claims without a specific technical standard, and private plaintiffs can and do file during the extension window.

And the private sector was never covered by that rule anyway. Businesses fall under ADA Title III, for which no web rule has ever been published. Title III litigation runs on court-developed standards that routinely cite WCAG 2.1 AA as the de facto benchmark — over 3,100 federal filings in 2025, up roughly 27% year on year, with state-court volume on top.

The pattern worth extracting: regulatory deadlines slip. Litigation doesn't. Businesses that time their remediation to the deadline are managing the wrong risk.

The Territorial Map

Territory	Instrument	Who it covers	Standard
EU	European Accessibility Act (2019/882)	Private sector — e-commerce, banking, transport, telecoms, e-books, consumer digital services. Extraterritorial.	EN 301 549, incorporating WCAG 2.1 AA
EU	Web Accessibility Directive (2016/2102)	Public sector bodies	EN 301 549
US	ADA Title II (DOJ rule, 2024)	State and local government	WCAG 2.1 AA — deadlines Apr 2027 / Apr 2028
US	ADA Title III	Private businesses ("places of public accommodation")	No published standard. Courts use WCAG 2.1 AA
US	Section 508	Federal agencies and contractors	Section 508 standards (WCAG-aligned)
US	State statutes	Varies — Colorado, Minnesota, California and others	Per-violation penalties; California statutory damages apply
UK	Equality Act 2010	All service providers — reasonable adjustments duty	No prescribed standard; WCAG 2.1 AA is the practical benchmark
UK	Public Sector Bodies Accessibility Regulations 2018	Public sector	WCAG 2.1 AA
Canada	Accessible Canada Act / AODA (Ontario)	Federally regulated / Ontario organisations	WCAG 2.0 AA and above, per instrument
Australia	Disability Discrimination Act 1992	All service providers	WCAG 2.x AA via Australian Government guidance
New Zealand	Human Rights Act 1993; NZ Government Web Standards	Public sector mandated; private sector via discrimination law	WCAG 2.1 AA for government

Note the asymmetry. Several jurisdictions impose a duty without specifying a standard. The UK Equality Act and the Australian DDA both work this way. That's not a lower bar — it's an unbounded one, resolved after the fact by a tribunal using whatever benchmark it finds reasonable. In practice that benchmark is WCAG.

Industry Overlays

Sector regulation sits on top of the territorial layer, and it's usually stricter, because the consequence of an inaccessible interface scales with what the interface controls.

Healthcare and medical. The most heavily overlapped sector. In the US, providers and organisations receiving Department of Health and Human Services funding fall under a separate Section 504 web accessibility rule with its own timeline — one that has tracked differently from the DOJ's Title II schedule, and where reporting has been inconsistent enough that the current compliance date should be confirmed directly rather than taken from secondary sources. Healthcare is also among the most-litigated verticals under Title III. Layer on top: patient portal access, appointment booking, consent capture, and in most markets a parallel regime governing how treatments may be advertised at all — TAPS in New Zealand, TGA in Australia, MHRA in the UK, MDR for devices in the EU. An accessible medical site can still be non-compliant on advertising grounds, and vice versa. These are separate audits.

Financial services. Explicitly named in EAA scope — consumer banking, payment services, e-commerce checkout. Overlaid with sector conduct rules on clear communication and fair treatment of vulnerable customers, which in several jurisdictions produce accessibility-adjacent obligations independent of disability law.

E-commerce. Named in EAA scope and the most-targeted vertical in US litigation. Checkout, cart and account flows are the highest-risk surfaces because they're where a failure blocks the transaction rather than the information.

Education. Public institutions fall under Title II in the US and public sector regimes elsewhere. Third-party learning platforms are in scope — the Title II rule reaches content "provided or made available" through vendors and licensors, meaning you inherit your suppliers' failures.

Transport, ticketing, telecoms. All explicitly named in EAA scope.

Hospitality. No dedicated regime, consistently among the most-litigated US verticals. Booking engines are the exposure.

The structural point: in every one of these, the third-party component is the weak link. Booking widgets, payment iframes, chat, review embeds, scheduling tools. You are responsible for them and you usually can't fix them. That's a procurement decision disguised as a design decision, and it has to be made before integration rather than after.

What the Standard Actually Is

Cutting through the version confusion, because it generates more anxiety than it deserves.

WCAG 2.1 Level AA is the legal requirement almost everywhere it's specified. The EU references it through EN 301 549. The DOJ adopted it. Courts benchmark against it.

WCAG 2.2 is current best practice, not the legal EAA standard. An updated EN 301 549 incorporating WCAG 2.2 has been anticipated, which will move the legal floor when it lands. Building to 2.2 now is how you avoid remediating twice.

Level AAA is not required and mostly not appropriate as a blanket target. Apply selected AAA criteria where the audience justifies it.

The practical content of AA is narrower than the anxiety around it suggests: keyboard operability with a visible focus indicator, text alternatives for non-text content, sufficient contrast, correct semantic structure and labelling, error identification and instruction on forms, no reliance on colour or sensory characteristics alone, and support for orientation and reflow.

Most of that is decided in the build. Which is the actual finding: accessibility is an architecture property, not a content property, and retrofitting it into a site that wasn't built for it is where the cost lives.

The Overlay Trap

This needs saying directly, because it's sold aggressively and it's where a lot of compliance budget disappears.

Accessibility overlay widgets — the ones that add a floating icon offering contrast toggles and text resizing — do not produce conformance. They sit on top of the DOM and cannot repair structural failures: incorrect semantics, unlabelled controls, keyboard traps, inaccessible custom components. Those are build problems, and a script layered over them doesn't change them.

The evidence is uncomfortable for the vendors. Sites running overlays have continued to be sued, and the presence of an overlay has in some cases been cited as evidence the operator knew about the barrier and chose not to fix it. Disability advocacy organisations have campaigned against them collectively.

Where they have a role: as a temporary user-facing aid while genuine remediation is underway. As a compliance strategy, they're a purchase that converts a technical problem into a technical problem plus a subscription.

Treat the scanning tools with proportionate scepticism too. Automated testing catches roughly a third of WCAG failures — the machine-detectable ones. Keyboard operability, focus order, meaningful alt text and screen-reader logic require manual testing. A vendor scan reporting a clean result on a site nobody has ever tabbed through is measuring the easy third.

On the statistics generally: figures like "96% of websites fail accessibility" circulate widely and originate almost entirely from companies selling remediation, using their own automated scanners as the instrument. The direction is probably right. The number is marketing. Don't build a business case on it — build it on the litigation volume and the enforcement record, which are matters of public record.

The Accessibility Statement Is a Liability, Not a Shield

Most jurisdictions expect a published accessibility statement, and most businesses treat it as a formality. Under active enforcement it functions as a public compliance document that can be tested against the actual site.

A statement claiming conformance while checkout fails keyboard navigation isn't neutral. It's a documented, self-published gap between claim and reality — the kind of thing that turns a remediation conversation into an adversarial one.

What a defensible statement contains: the standard targeted, honest current conformance status including known failures, the date of last assessment, a remediation roadmap with dates, and a working contact route for reporting barriers. Most enforcement authorities issue a notice before escalating, and an active documented remediation programme is the strongest position available at that moment.

Overclaiming is worse than underclaiming. This is the one place where honesty is also the legally safer option.

What to Build

Five decisions, in order, with the conditions attached.

1. Map the surface before scoping the work. Where are your customers, what do you sell, which regimes attach. This takes an afternoon and determines everything downstream. Do it before commissioning an audit, or you'll audit against the wrong standard.

2. Build to WCAG 2.2 AA, claim 2.1 AA. 2.1 is the legal floor almost everywhere; 2.2 is where the floor is heading. The delta is small at build time and expensive as a second remediation pass.

3. Audit manually, not just automatically. Automated scanning first for the cheap wins, then keyboard-only navigation and screen-reader testing of the flows that matter — enquiry, checkout, account, booking. Prioritise by transaction path, not by page count.

4. Make it a procurement rule. Every third-party embed gets an accessibility conformance report before integration. Anything without one is a liability you're adopting on someone else's behalf. This is the single highest-leverage policy change available and it costs nothing.

5. Publish an honest statement and keep it current. Dated, specific, with known gaps named. Review on the same cadence as the site changes.

Where this doesn't apply as written: the smallest service microenterprises have limited relief under the EAA — thresholds are defined around headcount and turnover and vary by national transposition, so confirm against your own jurisdiction rather than the directive text. Relief is also narrower than most businesses assume, and it does not extend to product manufacturers.

The Actual Position

Web accessibility compliance is usually argued as a moral obligation or a legal risk, and both framings understate it.

It's a design constraint with a legal enforcement mechanism attached — closer to fire regulations than to a style guide. Nobody argues about whether a building should have an accessible entrance, and nobody treats it as an optional module bolted on after the structure is complete. It's specified at the start because it's structural, and because retrofitting it costs several times what building it in would have.

Digital is arriving at the same place, more slowly and with more litigation on the way. The enforcement dates will keep moving. The obligation underneath them won't.

Build for it at the start. Everything else is remediation with a deadline attached.

Building something like this? [START A PROJECT]