Legal Landscape: EAA, ADA & Section 508
Understand how the Americans with Disabilities Act, Section 508, and the EU Accessibility Act create legally binding accessibility obligations — and what WCAG conformance level satisfies each.
10 min read
The full lesson
Accessibility lawsuits, regulatory fines, and government procurement requirements are real, active risks — not distant possibilities. In the US, ADA-based web accessibility lawsuits have exceeded 4,000 federal cases per year since 2022. The EU Accessibility Act started enforcement across member states in June 2025. For product teams, knowing which law applies, what it demands, and how WCAG fits in is a practical design skill — not a niche compliance specialty.
Why Designers Need to Know This
It’s tempting to hand legal questions entirely to counsel. But that leads to avoidable mistakes.
A designer who knows that EN 301 549 (a European technical standard) references WCAG 2.1 AA as its baseline — and that the EAA requires EN 301 549 conformance — can make smart tradeoffs when a feature deadline competes with an accessibility backlog. A designer who treats accessibility as “someone else’s legal problem” sets their team up for expensive fixes, lost government contracts, or a lawsuit.
Legal knowledge also changes how accessibility gets prioritized. When engineers and product managers understand that WCAG 2.2 AA is the current legal floor in most jurisdictions — not a nice-to-have — the prioritization conversation shifts.
The Americans with Disabilities Act (ADA)
The ADA (passed in 1990) prohibits discrimination against people with disabilities in public accommodations, employment, and government services. Title III covers businesses open to the public. Title II covers state and local government entities.
The ADA predates the web. But courts and the Department of Justice (DOJ) have consistently ruled that websites and mobile apps run by covered entities are “places of public accommodation” under Title III. No ADA amendment explicitly names WCAG — instead, courts use WCAG as the accepted industry benchmark when evaluating each case.
Key points for product teams:
- Almost any company running a US consumer-facing website is covered under Title III if it has a physical location (restaurant, retail store, hotel, hospital) or does commerce with the public.
- Private companies with 15 or more employees are also covered under Title I for employment-related tools and applications.
- In April 2024, the DOJ issued final rules stating that Title II entities (state and local government) must meet WCAG 2.1 AA. This is the first time the DOJ formally named a WCAG version in federal rulemaking for this category.
- Title III standards for private businesses are still shaped by litigation rather than a formal rule. Even so, courts routinely treat WCAG 2.1 AA — and increasingly WCAG 2.2 AA — as the de facto standard.
The Litigation Landscape
ADA web accessibility cases are filed at scale. Common targets include e-commerce sites, restaurant ordering flows, healthcare portals, and financial services platforms. The typical complaint: a screen reader user could not complete a core task — add an item to a cart, book an appointment, read a statement.
Settlements commonly require:
- A remediation plan with a defined timeline
- Third-party auditing
- Ongoing monitoring and testing
- Staff training
The total legal cost — settlement, auditing fees, and engineering fixes — typically dwarfs what a proactive accessibility program would have cost. This is the business case practitioners use when pushing for accessibility investment.
Section 508 of the Rehabilitation Act
Section 508 (1973, strengthened 1998, refreshed 2018) applies to federal agencies and any organization that receives federal funding or sells technology to the federal government. Its scope is narrower than the ADA — it does not directly regulate private-sector consumer products — but its purchasing power is enormous.
The Access Board’s 2018 “Section 508 Refresh” formally incorporated WCAG 2.0 AA as the technical standard for web content and software. In practice, procurement reviewers now expect WCAG 2.1 AA or higher. The Access Board has signaled alignment with WCAG 2.2 in updated guidance.
Practical implications:
- A VPAT (Voluntary Product Accessibility Template) is the standard disclosure document for Section 508 compliance. If you sell software to federal agencies, you will need a current VPAT describing your product’s conformance for each WCAG success criterion.
- A VPAT that claims “Supports” for criteria your product actually fails is a legal liability. Organizations have faced contract termination and False Claims Act exposure for inaccurate VPATs.
- The current VPAT format is called an ACR (Accessibility Conformance Report), version 2.5. It covers WCAG 2.1 AA, Section 508, and EN 301 549. Preparing an honest, thorough ACR requires a real accessibility audit — not a quick scan.
| Scope | ADA Title II | ADA Title III | Section 508 |
|---|---|---|---|
| Who it covers | State/local government | Private businesses open to public | Federal agencies + federal contractors |
| Technical standard | WCAG 2.1 AA (DOJ 2024 rule) | WCAG 2.1/2.2 AA (de facto via litigation) | WCAG 2.0 AA (formal), 2.1/2.2 in practice |
| Enforcement | DOJ / private litigation | Private litigation | Contract/procurement + DOJ |
| Disclosure mechanism | N/A | N/A | VPAT / ACR |
Do
- Treat WCAG 2.2 AA as your working standard across all products — it satisfies Section 508, ADA, and EAA at once.
- Prepare an ACR (VPAT) based on real testing before any federal procurement process begins. Build time for this into enterprise sales timelines.
- Keep your VPAT current — reassess it after major releases that change user flows, add new components, or modify interactive patterns.
- Involve your legal or compliance team early when entering regulated sectors (healthcare, financial services, government) where multiple laws overlap.
Don't
- Claim “WCAG 2.2 AA conformance” on a VPAT without conducting and documenting a real audit. False claims in federal contracting carry serious legal consequences.
- Assume Section 508 only matters for government agencies. Any company selling software to a federal client, receiving federal grants, or building tools used by federal workers falls under its scope.
- Use WCAG 2.0 as your target. It was published in 2008, lacks the mobile and cognitive criteria added in 2.1 and 2.2, and no longer represents the legal or practical standard in any major jurisdiction.
- Treat a passing automated scan as evidence of conformance. Automated tools catch roughly 30–40% of WCAG failures. Manual testing and assistive technology testing are required for a credible conformance claim.
The EU Accessibility Act (EAA)
The European Accessibility Act (EAA, Directive 2019/882) came into force across EU member states in June 2025. It is the most significant expansion of digital accessibility law in Europe since EN 301 549 was first published in 2014.
Unlike Section 508 (government procurement) or the ADA (primarily enforced through litigation), the EAA is a proactive regulatory regime. It has enforcement authority and can impose economic penalties. It covers:
- E-commerce platforms selling to EU consumers
- Banking and financial services
- Passenger transport (websites, mobile apps, ticketing machines)
- Consumer electronics with digital interfaces
- E-books and e-readers
- Audiovisual media services
The EAA’s technical standard is EN 301 549. Its 2021 revision aligned with WCAG 2.1 AA as the web content accessibility standard. As WCAG 2.2 gains regulatory traction, expect EN 301 549 to follow in its next revision cycle.
EAA scope specifics that catch teams off-guard:
- It applies to private-sector businesses selling to EU customers, regardless of where the company is headquartered. A US-based SaaS company with EU subscribers is in scope.
- Microenterprises — fewer than 10 employees AND annual turnover under EUR 2 million — are exempt from most provisions.
- “Fundamental alteration” and “disproportionate burden” exceptions exist, but they are narrow escapes, not routine opt-outs. Companies claiming disproportionate burden must document their analysis.
How WCAG Maps to Legal Requirements
WCAG is not a law. It is a technical specification published by the W3C. Laws and regulations reference WCAG as their technical standard, which is why keeping up with WCAG versions matters legally — not just technically.
| Regulation | Jurisdiction | Referenced Standard | Minimum Level |
|---|---|---|---|
| ADA Title II (DOJ 2024 rule) | US government entities | WCAG 2.1 | AA |
| ADA Title III (de facto) | US private sector | WCAG 2.1 / 2.2 | AA |
| Section 508 (formal) | US federal procurement | WCAG 2.0 | AA |
| EN 301 549 (2021) / EAA | EU | WCAG 2.1 | AA |
| Equality Act + PSBAR | UK | WCAG 2.2 (updated 2024) | AA |
| AODA (Ontario) | Canada (Ontario) | WCAG 2.0 | AA (Level A by 2012, AA by 2021) |
The practical takeaway: WCAG 2.2 AA satisfies all of the above simultaneously. It is backward compatible with every prior version. Targeting 2.2 AA is a convergence strategy — you comply with every listed jurisdiction in one effort, rather than maintaining separate compliance tracks.
Conformance Claims and What They Actually Mean
A “conformance claim” is a formal statement that a web product meets WCAG at a specified level. Making a credible claim requires:
- Scope definition — which pages or components are covered. A claim covering only your marketing homepage is not meaningful for an application with a complex UI.
- Testing methodology — automated scanning, manual expert review, and assistive technology testing (screen readers, switch access, voice control). WCAG’s own understanding documents describe testing approaches for each criterion.
- Known exceptions — third-party content you do not control (embedded maps, social widgets, payment iframes) may be excluded, but must be documented.
- Date of claim — conformance claims decay as products change. Date-stamping and committing to update cycles is honest practice.
An Accessibility Statement is both a legal expectation in the EU (required under the EAA) and a trust signal for users. At minimum, it should describe: the applicable standard and version, known conformance gaps, and a contact method for users to report barriers.
Procurement, Disproportionate Burden, and the Real Business Case
Two concepts come up repeatedly in legal contexts that product teams often misunderstand.
Disproportionate burden is a defense available under Section 508 and the EAA. It applies when full compliance would impose costs grossly disproportionate to the benefit achieved. It is not an indefinite exemption. The analysis must be documented and renewed periodically. Even when a disproportionate burden defense applies, the organization must still give users with disabilities an alternative way to access the content or service. The bar to invoke it legitimately is high — it was designed for small nonprofits and edge-case constraints, not Fortune 500 product decisions.
Procurement leverage is the more immediately actionable concept. Governments and large enterprises increasingly require accessibility conformance — documented via VPAT/ACR — as a condition of purchase. If your product cannot demonstrate WCAG 2.2 AA conformance, it is disqualified from an expanding share of public sector and enterprise deals. Accessibility investment has a direct revenue line when viewed through the procurement lens.
Building Compliance Into the Development Process
Legal compliance is not achieved by a single accessibility audit before launch. It requires weaving accessibility into your design and engineering workflow at every stage.
- Design-time: use components with built-in accessible semantics; audit color contrast to WCAG 2.2 AA (4.5:1 for text under 18pt, 3:1 for large text and UI components); verify touch targets at 44px design intent, even if 24px is the WCAG minimum.
- Development-time: integrate axe-core or Lighthouse into CI pipelines to catch automated regressions early. Automate what can be automated; save manual testing hours for complex interaction patterns.
- Pre-release: test with keyboard-only navigation and at least one screen reader. NVDA + Chrome and VoiceOver + Safari together give the broadest representative coverage.
- Post-release: treat accessibility bug reports from users as P1-equivalent issues. A user who cannot complete a purchase or access their account is a concrete failure — legally and experientially.
- Annually or on major releases: refresh your VPAT/ACR and your public Accessibility Statement.