Web Accessibility Compliance: The Developer Guide (2026)

Web accessibility compliance is no longer a niche legal concern. It is a baseline requirement that most production sites currently fail. In 2026, 95.9% of the top one million home pages had detectable WCAG 2 failures, averaging 56.1 errors per page (WebAIM Million, 2026). Because that figure counts only automated detection, the share of sites that pass full conformance is even smaller: fewer than roughly 4% clear even the automated checks.

The legal pressure has caught up with that gap. More than 5,000 digital accessibility lawsuits were filed in the US in 2025, roughly 70% of them against e-commerce sites (UsableNet, 2026). At the same time, the European Accessibility Act became enforceable across all 27 EU member states on June 28, 2025. This guide maps every major law to the exact WCAG version and level it requires, then shows developers how to actually meet it.

TL;DR: Almost every accessibility law points back to one technical standard, WCAG, and WCAG 2.1 Level AA is the near-universal legal floor. The ADA (Title II and III), Section 508, the EU's EAA, Ontario's AODA, and the UK's PSBAR all cite a WCAG version at Level AA. Automated tools catch roughly 57% of issues by volume (Deque, 2021), so compliance means pairing automated scanning in CI with manual and assistive-technology testing. Do not wait for WCAG 3.0; it is still a draft.

What Does Web Accessibility Compliance Actually Mean?

Web accessibility compliance means meeting the legal obligation to make digital products usable by people with disabilities, a group that includes 1.3 billion people, about 16% of the world population (WHO, current). In practice, nearly every law defines "usable" by pointing to one shared technical standard: the Web Content Accessibility Guidelines, or WCAG.

That shared backbone is what makes compliance tractable. Laws differ by region, who they cover, and their deadlines, but they overwhelmingly reference the same success criteria. So if you build to WCAG, you are building toward most of the world's accessibility laws at once. The legal text changes; the engineering target stays remarkably stable.

What are the WCAG conformance levels?

WCAG defines three conformance levels: A, AA, and AAA. Level A covers the most basic requirements, AA adds the criteria that address the most common and significant barriers, and AAA is the strictest tier. Level AA is the one that matters for compliance. It is the near-universal legal floor, cited by the ADA rule, the EAA, Section 508, AODA, and UK regulations alike.

AAA is rarely required wholesale. The W3C itself advises against demanding full AAA conformance as a general policy, because some AAA criteria cannot be satisfied for all content types. Most teams treat AAA as a per-criterion enhancement, not a sitewide target. When a contract or law says "WCAG," it almost always means Level AA.

Citation capsule: Web accessibility compliance is defined by the Web Content Accessibility Guidelines (WCAG), which set three conformance levels: A, AA, and AAA. Level AA is the near-universal legal floor cited by the ADA, EAA, Section 508, AODA, and UK regulations. Accessibility affects 1.3 billion people, about 16% of the world's population (WHO, current).

Which Laws Require Web Accessibility, and What Do They Demand?

At least six major legal frameworks across the US, EU, Canada, and UK mandate web accessibility, and all of them cite a version of WCAG at Level AA. The differences lie in who is covered, the deadlines, and the penalties. More than 5,000 digital accessibility lawsuits were filed in the US in 2025, roughly 70% against e-commerce (UsableNet, 2026), so these are enforced in practice, not just on paper.

The table below is the fastest way to see where you stand. Find the regions you operate in, read off the WCAG target, and note your deadline.

ADA Title II and Title III (United States)

The ADA splits into two parts that developers hit most often. Title II covers state and local government. A 2024 DOJ rule requires WCAG 2.1 Level AA. In April 2026 those compliance dates were extended by a year: April 26, 2027 for populations of 50,000 or more, and April 26, 2028 for smaller entities and special districts (Federal Register, 2026; ADA.gov, 2024).

Title III covers private businesses, "places of public accommodation." There is no codified technical standard here, but DOJ guidance and the courts treat WCAG 2.0/2.1 AA as the de facto benchmark (ADA.gov, 2024). That absence of a fixed rule has not reduced risk. It is the main driver of the 5,000-plus lawsuits filed in 2025.

Section 508 (US federal)

Section 508 governs federal agencies and the vendors that sell to them. Its Revised Standards incorporate WCAG 2.0 Level A and AA by reference, and have been in force since 2018 (Section508.gov, 2018). If you sell software or digital services to the US government, this is the standard your procurement paperwork will reference.

The European Accessibility Act (EU)

The EAA became enforceable on June 28, 2025 across all 27 member states. Crucially for developers, it reaches private digital products and services, including e-commerce, banking apps, e-books, and ticketing, not just the public sector. Technical conformance runs through the EN 301 549 standard, which incorporates WCAG 2.1 AA (ETSI EN 301 549 v3.2.1, 2021).

Penalties are set per member state and must be effective, proportionate, and dissuasive, so the ranges vary widely. Germany sets fines up to 100,000 euros for selling non-compliant products, France up to 50,000 euros, and Italy up to 40,000 euros (or 5% of annual turnover for companies previously covered by the Stanca Law) (Level Access, 2026; Fieldfisher, 2026). There is no single EU-wide fine, so check the specific countries you serve.

AODA (Ontario) and UK regulations

Ontario's AODA Information and Communications Standard requires WCAG 2.0 Level AA, excluding criteria 1.2.4 (live captions) and 1.2.5 (audio description). The deadline of January 1, 2021 already passed for the public sector and private organizations with 50 or more employees (AODA.ca, current).

In the UK, the Public Sector Bodies Accessibility Regulations 2018 require public-sector sites and apps to meet WCAG AA, and the Government Digital Service monitors against WCAG 2.2 from October 2024. Separately, the Equality Act 2010 sets a broader reasonable-adjustments duty that applies to all service providers (GOV.UK, current).

Citation capsule: Six major frameworks mandate web accessibility, all citing WCAG at Level AA: ADA Title II requires WCAG 2.1 AA by April 26, 2027 (Federal Register, 2026), the EU's EAA requires WCAG 2.1 AA via EN 301 549 and became enforceable June 28, 2025, and US ADA Title III drove over 5,000 lawsuits in 2025 (UsableNet, 2026).

Which WCAG Version and Level Do You Need to Meet?

For most teams, the answer is WCAG 2.1 Level AA, which both the ADA Title II rule and the EAA cite. Section 508 and AODA point to the slightly older WCAG 2.0 AA, and the UK public sector now references the newer WCAG 2.2 AA. Because each version builds on the one before it, targeting 2.2 AA satisfies all of them at once. Level AA is the floor everywhere; AAA is rarely required wholesale.

So if you want one target that covers the widest set of obligations, choose WCAG 2.1 AA. It clears 2.0 by definition and sits one minor version below the latest release. The only reason to track versions more closely is to understand what changed in 2.2 and where the standard is heading next.

What changed in WCAG 2.2, and is it required?

WCAG 2.2 became a W3C Recommendation on October 5, 2023. It adds nine new success criteria and removes the old 4.1.1 Parsing criterion (W3C/WAI, 2023; W3C What's New in 2.2, 2023). Three of the additions matter most to developers in day-to-day work.

• 2.5.8 Target Size (Minimum): interactive targets need at least a 24 by 24 CSS pixel hit area, with some exceptions.
• 2.4.11 Focus Not Obscured (Minimum): when an element receives keyboard focus, it must not be entirely hidden by sticky headers, footers, or overlays.
• 3.3.8 Accessible Authentication (Minimum): do not force a cognitive function test (like solving a puzzle or retyping a code) without an accessible alternative.

Most laws still point to 2.1 or 2.0, so 2.2 is not yet a widespread legal requirement. It is the current Recommendation and clear best practice, and the UK already monitors against it. Building to 2.2 now is the safer bet, since it is where the legal references are drifting.

Should you wait for WCAG 3.0?

No. WCAG 3.0 is still a Working Draft, last updated March 3, 2026, and W3C does not expect it to be a finished standard for several more years (W3C/WAI, 2026). It proposes a different structure and scoring model, but none of it carries legal weight yet, and WCAG 2 remains fully in force.

Treat 3.0 as a horizon, not a plan. Any effort spent meeting WCAG 2.2 AA today transfers directly to your legal obligations and to real users right now. Delaying remediation to "wait for 3.0" means staying non-compliant for years while lawsuits and the EAA continue to bite.

Citation capsule: WCAG 2.1 Level AA is the near-universal compliance target, satisfying both newer laws (ADA Title II, EAA) and the WCAG 2.0 AA cited by Section 508 and AODA. WCAG 2.2 became a Recommendation on October 5, 2023, adding nine success criteria including 2.5.8 Target Size (W3C/WAI, 2023). WCAG 3.0 remains a Working Draft and is not expected to be finished for several more years (W3C/WAI, 2026).

What Is a VPAT, and When Do You Need One?

A VPAT (Voluntary Product Accessibility Template) is the document you use to declare how your product conforms to accessibility standards. VPAT 2.5 (Rev 508) is the current template from the Information Technology Industry Council, and a completed VPAT becomes an Accessibility Conformance Report, or ACR, the standard format for ICT procurement (ITI, current; Section508.gov, current).

You need one mostly in business-to-business and government sales. A single VPAT can document conformance against Section 508, the EU's EN 301 549, and WCAG all at once, which is why procurement teams ask for it. If you sell software to a federal agency, a university, or a large enterprise, expect the ACR to be a gating item in the purchase.

How is a VPAT different from a scan report?

A scan report tells you what is broken right now. A VPAT or ACR is a structured conformance claim, organized criterion by criterion, that a buyer's procurement team can evaluate. The two work together: you run scans and manual testing to gather evidence, then summarize the results in the ACR format buyers expect.

That distinction matters because a VPAT is only as honest as the testing behind it. An ACR built on automated results alone will overstate conformance, since automation cannot verify most success criteria on its own. The next section explains why.

Citation capsule: VPAT 2.5 (Rev 508) is the Information Technology Industry Council's current template, and a completed VPAT becomes an Accessibility Conformance Report (ACR), the standard format for ICT procurement covering Section 508, EN 301 549, and WCAG (ITI, current; Section508.gov, current). ACRs are commonly required in B2B and government purchasing.

How Do You Actually Achieve and Maintain Compliance?

Compliance is a process, not a one-time scan, and it depends on combining automated and manual testing. Automated tools catch roughly 57% of accessibility issues by volume (Deque, 2021), which means a large share still requires human judgment. The goal is to automate the detectable issues continuously, then layer manual testing over the rest.

The fastest way to make progress is to measure your starting point and stop new regressions from landing. After that, you work the backlog down while manual testing covers what machines miss. Here is how the pieces fit.

How much can automated testing really cover?

There are two figures in circulation, and they describe the same limit from different angles. Deque measured that automation catches about 57% of issues by volume, meaning count of individual defects (Deque, 2021). A separate "around 30%" figure refers to the share of WCAG success criteria that are machine-testable, a different denominator entirely.

So the two numbers are not in conflict. One counts defects, the other counts criteria. The practical takeaway is the same either way: automation is necessary but not sufficient. Keyboard operability, screen-reader behavior, focus order, and cognitive accessibility all need a human in the loop.

In our own scanning work across many sites, the violations that recur most, and that draw the most legal complaints, are precisely the automatable ones: low contrast text, missing form labels, empty links, and unlabeled buttons. Automating those first is the highest-leverage move you can make.

How do you shift accessibility testing left?

Move detection into development, where it is cheapest. Run a scanner in CI so a contrast change or a missing label fails the build before it merges, rather than surfacing in a lawsuit later. Our developer's guide to web accessibility testing covers the full workflow, and our GitHub Actions setup shows how to gate pull requests with axe and Playwright.

Choosing the right tool for each layer matters too. Our comparison of accessibility testing tools breaks down where each engine fits, and for programmatic scanning across many pages or services, an accessibility scanning API lets you wire checks into any pipeline. Combine these with manual audits on a regular cadence.

Why overlays are not a compliance shortcut

Accessibility overlay widgets promise instant compliance from a single line of JavaScript. They do not deliver it. Overlays cannot fix the underlying markup, they often break assistive technology, and they have been named in a growing share of lawsuits rather than preventing them. We cover the evidence in detail in why accessibility overlays fail.

The reason ties back to the coverage numbers. Since automation cannot detect or repair most success criteria, an automated overlay applied at runtime cannot achieve conformance. Real compliance comes from fixing source code and content, then proving it with combined automated and manual testing. There is no widget that substitutes for that work.

Citation capsule: Automated accessibility testing catches roughly 57% of issues by volume (Deque, 2021), while a separate figure of about 30% describes the share of WCAG success criteria that are machine-testable, a different denominator. Both confirm the same limit: automation is necessary but not sufficient, and keyboard, screen-reader, and cognitive testing require manual review.

Frequently Asked Questions

Which WCAG version and level do I actually need to meet?

WCAG 2.1 Level AA covers most obligations, including ADA Title II and the EAA. Section 508 and Ontario's AODA cite the older WCAG 2.0 AA (which 2.1 already includes), while the UK public sector now references WCAG 2.2 AA. Level AA is the legal floor everywhere; AAA is rarely required wholesale. Target 2.2 AA to satisfy every current regime at once.

Does the ADA apply to my private website?

Likely yes in effect. ADA Title III has no codified technical standard, but courts and DOJ guidance treat WCAG 2.0/2.1 AA as the benchmark for places of public accommodation (ADA.gov, 2024). More than 5,000 digital accessibility lawsuits were filed in 2025, roughly 70% against e-commerce (UsableNet, 2026).

What's the EAA deadline, and does it cover private companies?

The European Accessibility Act became enforceable on June 28, 2025 across all 27 EU member states. Yes, it covers private digital products and services, including e-commerce, banking apps, e-books, and ticketing, with technical conformance through EN 301 549 (WCAG 2.1 AA) (ETSI EN 301 549 v3.2.1, 2021).

Is WCAG 2.2 legally required yet?

Mostly not yet. Most laws still reference WCAG 2.1 or 2.0, so 2.2 is not a broad legal requirement, though the UK public sector now requires it (GOV.UK, current). WCAG 2.2 is the latest Recommendation, finalized October 5, 2023, and is best practice (W3C/WAI, 2023). WCAG 3.0 is still a draft.

What is a VPAT, and when do I need one?

A VPAT (currently version 2.5) documents how your product conforms to accessibility standards, and once completed it becomes an Accessibility Conformance Report (ITI, current). You typically need one in business-to-business and government procurement, where buyers require an ACR covering Section 508, EN 301 549, and WCAG before purchase.

Can automated tools make me compliant?

No. Automated testing catches roughly 57% of accessibility issues by volume (Deque, 2021), leaving keyboard operability, screen-reader behavior, and cognitive accessibility for manual testing. Overlay widgets cannot close that gap either, which is why we explain why overlays fail. Compliance requires automated scanning plus human review.

The Bottom Line

Web accessibility compliance comes down to one engineering target shared across borders: WCAG 2.1 Level AA. The ADA, Section 508, the EU's EAA, Ontario's AODA, and UK regulations all cite a WCAG version at Level AA, so building to 2.1 AA (or 2.2 AA to stay ahead) satisfies the widest set of laws at once. The deadlines are live now, with ADA Title II landing April 26, 2027 and the EAA already enforceable since June 28, 2025.

The stakes are concrete. With over 5,000 lawsuits filed in 2025 (UsableNet, 2026) and 95.9% of top sites still failing automated checks (WebAIM Million, 2026), the gap between obligation and reality is wide and risky. Close it by shifting testing left: scan in CI to catch the detectable majority, then layer manual and assistive-technology testing for the rest. Skip the overlays. Start with our developer's guide to web accessibility testing, then wire a gate into your pipeline with accessibility testing in GitHub Actions.