Section 508 vs WCAG vs ADA: What Each Requires

Three terms dominate almost any conversation about digital accessibility in the United States: Section 508, WCAG and the ADA. They appear side by side in procurement checklists, vendor contracts and accessibility statements, often as if they were interchangeable labels for the same obligation. They are not. One is a technical guideline, one is a federal procurement rule, and one is a civil-rights law. Confusing them leads teams to buy the wrong kind of assurance, or to claim a kind of compliance they do not actually have.

This post sets out what each of the three actually is, who it binds, and how they reference one another, so that a single body of technical work can satisfy more than one of them at once. The aim is a clear mental model for buyers and content owners deciding what to ask a vendor for, not a legal treatise. Where a specific date, version or legal detail matters to your situation, treat what follows as orientation and confirm the current text with counsel before you rely on it.

The single most useful step is to stop treating the three as a list of competing standards and start seeing them as different layers of the same problem. WCAG describes, in technical terms, what makes digital content accessible. Section 508 and the ADA are legal instruments that, in different ways, make certain organizations responsible for achieving that outcome. WCAG is the 'how'; the two American laws are the 'who must, and when'.

Kept in those lanes, the relationship becomes straightforward. A law rarely reinvents the technical detail of accessibility from scratch; instead it points to an existing standard and gives it legal force for a particular audience. That is essentially what has happened in the United States, where WCAG has become the common technical reference that both the federal procurement regime and civil-rights enforcement lean on. The rest of this post takes each layer in turn.

The Web Content Accessibility Guidelines, published by the World Wide Web Consortium (W3C), are the technical standard the other two frameworks ultimately rest on. WCAG is deliberately technology-neutral: rather than prescribing how a particular format must be built, it describes outcomes, organized under four principles that require content to be perceivable, operable, understandable and robust. That outcome-based design is why the same guideline can apply to a website, a PDF, a mobile app or an e-learning package without being rewritten for each.

WCAG defines three conformance levels — A, AA and AAA — with Level AA serving as the practical benchmark that most policies and contracts adopt. The current version is WCAG 2.2, which builds on 2.1 rather than replacing it; our companion post at /blog/wcag-2-2-document-compliance/ covers what 2.2 added and how it reaches into everyday documents. The crucial point for this comparison is that WCAG has no legal force on its own. It becomes enforceable only when a law or a contract adopts it — which is precisely what Section 508 does directly, and what the ADA does increasingly by reference.

Section 508 is a provision of the US Rehabilitation Act [HV: verify before publish — Section 508 sits within the Rehabilitation Act of 1973, added by later amendment] that requires federal agencies to make their information and communication technology accessible to people with disabilities. Its reach is defined by who is spending public money: it binds federal agencies directly, and through them the vendors that sell websites, software, documents and hardware to the government. If your organization neither sells to nor operates as a US federal agency, Section 508 does not bind you directly — though its standards frequently reappear in state and commercial contracts by choice.

What makes Section 508 central to this comparison is that it does not define accessibility itself. The revised standards adopt WCAG by reference, aligning the federal requirement with the same success criteria used everywhere else [HV: verify before publish — the Revised Section 508 Standards incorporate WCAG 2.0 Level A and AA by reference; confirm version and levels]. The standards themselves are maintained by the US Access Board [HV: verify before publish — the US Access Board maintains the Section 508 standards], while individual agencies remain responsible for compliance in what they procure and publish. In practice, vendors demonstrate conformance through VPAT and ACR documentation — the same artifacts that surface in commercial accessibility deals.

The Americans with Disabilities Act is a different kind of instrument altogether: a broad civil-rights law prohibiting discrimination on the basis of disability [HV: verify before publish — ADA enacted 1990]. Its relevance to digital accessibility comes through the parts that govern public services and businesses open to the public [HV: verify before publish — ADA Title II covers state and local government; Title III covers public accommodations]. Unlike Section 508, the ADA is not limited to organizations that deal with the federal government; it reaches state and local governments and a wide range of private businesses that serve the public.

The complication is that the ADA's original text predates the modern web and names neither WCAG nor any other technical standard. For years, its application to websites and apps was worked out through litigation and settlements, which frequently pointed to WCAG Level AA as the remedy. More recently, federal rulemaking has begun to make that reference explicit for public-sector web content and mobile apps [HV: verify before publish — 2024 US DOJ final rule under ADA Title II adopts WCAG 2.1 Level AA for state and local government websites and mobile apps; confirm scope, version and compliance dates]. For private businesses, obligations are still shaped largely by case law rather than a single published technical rule, which is why legal advice matters more here than it does with Section 508.

Seen together, the three form a stack rather than a menu. WCAG sits at the technical base, defining what accessible content looks like. Section 508 adopts those criteria and gives them legal force for federal technology procurement. The ADA, through decades of enforcement and more recent rulemaking, increasingly treats the same WCAG criteria as the measure of whether a public service or business is accessible. The practical upshot is that WCAG conformance is the work; the two laws largely determine who is obliged to do it and what evidence they must keep.

This is why a single, well-run accessibility effort can satisfy more than one framework at once. A document remediated to WCAG 2.2 Level AA, tested with real assistive technology and recorded in a VPAT, is defensible whether the question comes from a federal contracting officer citing Section 508 or a customer invoking the ADA. The frameworks differ in their legal audience and their paperwork, but they point at the same technical target — which is what makes a WCAG-anchored programme efficient rather than duplicative.

For a buyer, the useful question is not 'which standard is strictest?' but 'which of these actually binds my organization, and what evidence will someone ask me for?' The answer usually follows from who your users and customers are. Selling technology to the US federal government pulls you into Section 508 and its VPAT expectations. Operating a public-facing service, or a business open to the public in the United States, exposes you to the ADA. And almost everyone benefits from treating WCAG 2.2 Level AA as the working baseline, because it is the target both laws converge on.

None of these are mutually exclusive, and many organizations sit under two or three at once — a university, for instance, may face Section 508 through federal funding, the ADA as a public accommodation, and WCAG as the technical spec that satisfies both. If your market also extends into the European Union, a further layer applies: the European Accessibility Act, which our post at /blog/wcag-2-2-document-compliance/ covers alongside WCAG 2.2. The mapping below is a starting point rather than legal advice, and the specifics of any obligation should be confirmed for your jurisdiction and sector.

Because the three frameworks converge on WCAG, the most efficient response is to build a single accessibility programme against WCAG 2.2 Level AA and then document how that work maps to whichever law applies. That means auditing content and applications against the guideline, remediating what fails, testing with real screen readers such as JAWS, NVDA and VoiceOver rather than relying on automated checkers alone, and recording the result in the VPAT and ACR documentation that both procurement officers and legal teams expect.

This is the approach our technology service line takes, delivered with our parent company Squash Apps: WCAG 2.2 AA audits, document remediation to PDF/UA, screen-reader testing and VPAT support, with retesting after fixes built in. The details are on /technology/. Whether you run the work in-house or with a partner, the strategic point holds — understand the three frameworks as one technical target wearing three legal hats, and you can stop buying overlapping assurances and start building accessibility once, properly, for all of them.