You are three weeks into your first real fundraise when an email arrives from a law firm you have never heard of. It uses four different acronyms in a single sentence: ADA, WCAG, EN 301 549, EAA, and it says your website carries legal exposure under one or more of them. Nobody tells you which of these is an actual law, which is a technical rulebook, or whether any of it even applies to a company your size.
That confusion is not a personal failing. Lawmakers, standards bodies, and litigators all talk in shorthand, and almost nobody stops to explain that some of these four letters can get you sued while others are simply engineering specifications you follow to avoid being sued. For a founder trying to ship product and close a round, that distinction changes what you build, when, and why.
This is the plain-language decoder that should have come before that compliance email. Read it once and you will never mix up a law with a standard again.
The Stat: WCAG 2.2 became a formal W3C Recommendation in October 2023, adding 9 new success criteria on top of WCAG 2.1. (Source: W3C)
ADA: The Law With Teeth, No Technical Detail
The Americans with Disabilities Act is a US federal civil rights law. Title III of the ADA prohibits discrimination on the basis of disability in "places of public accommodation," and US courts have increasingly read that phrase to include commercial websites and mobile apps, treating a broken checkout flow or an unlabeled form the same way they would treat a store with no wheelchair ramp.
Here is the part founders usually miss: the ADA itself contains no technical checklist. It states an outcome, equal access, not a method. It never mentions color contrast ratios, alt text, or keyboard navigation. That silence is exactly why plaintiffs' attorneys, the Department of Justice, and most settlement agreements point to WCAG as the practical yardstick for proving a site is accessible, even though WCAG is never written into the ADA's text. You can read the ADA's actual language for yourself at ada.gov, and it is worth doing once so you know what you are actually being accused of violating.
WCAG 2.2: The Technical Standard, Not a Law
WCAG, the Web Content Accessibility Guidelines, is published by the World Wide Web Consortium (W3C), the international body that also maintains core web standards like HTML. WCAG describes, in testable detail, what "accessible" means at the code level: minimum contrast ratios between text and background, whether every interactive element can be reached and operated with a keyboard alone, whether form fields have programmatic labels, whether moving content can be paused. Success criteria are organized into three conformance levels, A, AA, and AAA, with Level AA as the level virtually every legal and regulatory framework treats as the working standard.
Nobody can sue you "under WCAG," because WCAG is not a law. It is the shared technical vocabulary that courts, regulators, and procurement teams reach for when they need to define "accessible" in terms specific enough to actually test. You can read the full current specification directly from the source at w3.org/TR/WCAG22, where every success criterion is documented with its own pass/fail technique.
EN 301 549: Europe's Technical Standard (Yes, It Points Back to WCAG)
EN 301 549 is the European technical standard for accessibility of ICT products and services, developed by the European standards bodies ETSI, CEN, and CENELEC. It was originally built for public sector procurement, so that governments across the EU would have one shared checklist when buying software, websites, and hardware. Structurally, EN 301 549 does not reinvent the wheel: it incorporates WCAG success criteria directly, then extends the same accessibility logic to things WCAG was never written to cover, like native mobile applications, downloadable documents, and self-service kiosks and hardware interfaces.
Think of EN 301 549 as WCAG's European cousin: same technical DNA, broader jurisdiction. You can review the standard itself through the official ETSI deliverable at etsi.org.
EAA: Europe's Law (The One With Actual Enforcement Teeth)
The European Accessibility Act is the EU-level law, not a technical standard, that requires many private-sector businesses selling products and services into the EU market, think e-commerce, banking, e-books, and transport ticketing, to make those offerings accessible. Where the ADA leaves the technical detail to courts and case law, the EAA is more explicit: it points directly to EN 301 549 (and, through it, to WCAG) as the technical benchmark businesses are expected to meet.
The practical relationship across all four acronyms looks like this: ADA and EAA are the laws that create legal exposure. WCAG 2.2 and EN 301 549 are the technical standards that define what "compliant" actually looks like in code. Nobody gets sued for violating WCAG directly, but WCAG (and its European counterpart, EN 301 549) is almost always the technical evidence used to decide whether the law was violated.
So Which One Actually Applies to You?
Run your product through this simple filter:
- If you serve US consumers or US-based users, the ADA is your legal exposure, and building to WCAG 2.2 Level AA is the technical target that gives you the strongest defensible position.
- If you sell into the EU market, the EAA is your legal exposure, and EN 301 549 (which itself leans on WCAG) is your technical target.
- If you do both, which describes most SaaS companies with any EU customers at all, you are working against two overlapping legal frameworks that both ultimately point back to the same underlying WCAG success criteria.
That overlap is exactly why the smartest teams stop treating US and EU accessibility as two separate compliance projects with two separate audits and two separate vendors. Once you know WCAG is the common technical thread running through nearly every framework above, from the ADA to the EAA to US federal Section 508, the efficient move is building one accessible baseline that satisfies all of them at once rather than duplicating the work. We go deep on exactly how to structure that unified approach in our piece on running one accessibility program instead of three, which is the natural next read once the acronyms above stop being a mystery.
The Decoder Cheat Sheet
Keep this nearby the next time a compliance email lands in your inbox:
- ADA = US law. No built-in technical checklist. Applies if you serve the US public.
- WCAG 2.2 = Technical standard, not a law. Defines "accessible" at the code level, in three conformance levels (A, AA, AAA).
- EN 301 549 = EU technical standard. Incorporates WCAG, then extends it to apps, documents, and hardware.
- EAA = EU law. Enforceable, and uses EN 301 549 (and by extension WCAG) as its technical yardstick.
What This Means for Your Roadmap
Because WCAG 2.2 Level AA sits underneath both the US and EU frameworks, it is the single highest-leverage thing to build toward regardless of which market you are focused on first. Start there, document your conformance honestly, and you are simultaneously building your ADA defense and your EAA readiness with the same engineering work. If you want a structured walkthrough of exactly what that first build should include for a US-focused company, our ADA website compliance guide breaks it down step by step.
Acronyms aside, none of this has to be a solo research project. If you want to talk through which of these frameworks actually applies to your product and where to start, reach a real person on our team at experts@wcag.world, or visit our ADA website compliance guide to see the plain-language path from "confused by four acronyms" to "confidently compliant."