Section 508 and WCAG: What Each One Actually Requires

Two Different Kinds of Document

Section 508 and WCAG are quoted together so often that they blur into a single requirement. Separating them is worth doing properly, because they answer different questions and they fail in different ways.

Section 508 is part of the Rehabilitation Act. It is United States law, and it governs procurement: when a federal agency develops, buys, maintains or uses information and communication technology, that technology has to be accessible to people with disabilities, both members of the public and federal employees. It tells you that you must be accessible and when the obligation attaches.

WCAG, the Web Content Accessibility Guidelines, is a technical standard published by the W3C. It is not a law anywhere. It is a structured list of testable success criteria organized under four principles: content must be perceivable, operable, understandable and robust. It tells you what accessible actually means in terms you can check.

The link between them is incorporation by reference. The Section 508 standards adopt WCAG success criteria as the technical requirement, which is why a procurement document can say "must meet Section 508" and an engineer can answer with a list of WCAG criteria. The law supplies the obligation; the standard supplies the test.

Conformance Is Claimed Per Criterion

The most common misunderstanding in procurement language is treating conformance as a property of a website. It is not. WCAG conformance is claimed against individual success criteria, and a real conformance claim is a list, not a yes.

Criteria are graded A, AA and AAA. A is the floor. AA is what public sector work is normally held to and what most contracts mean when they say "accessible". AAA includes criteria that cannot be satisfied for all content types, which is why no serious program commits to blanket AAA conformance.

This matters when you write or read a requirement. "The vendor shall deliver a WCAG 2.1 Level AA conformant application" is meaningful and testable. "The vendor shall deliver an accessible application" is not, and it will be argued about at acceptance. If you are writing the requirement, name the version and the level. We go into how that claim gets documented in our accessibility compliance audits.

Who Is Actually Covered

Coverage is where teams get caught out, because the obligation reaches further than the agency that owns the site.

• Federal agencies are directly covered by Section 508 for the technology they build, buy and use.
• Vendors and contractors are covered through the contract. The law binds the agency, and the agency binds you in the solicitation.
• State and local government falls under Title II of the Americans with Disabilities Act. The Department of Justice issued a rule setting explicit technical requirements and compliance dates for web content and mobile apps, with the deadline turning on the size of the population served.
• Recipients of federal funding frequently inherit obligations through their grant terms even when they are not themselves government.

If you are a subcontractor, read the flow-down clauses rather than assuming the prime absorbed the requirement. Accessibility obligations flow down well.

What This Changes About How You Build

The expensive version of accessibility is the one that starts after the build. A color contrast failure caught in a design token is a one-line change. The same failure caught in an audit six weeks before launch is a design review, a rebuild of every component that inherited the token, and a regression pass.

Several of the most-cited criteria are decided by architecture, not by styling:

• Semantic structure. Headings, landmarks and lists have to describe the document honestly. A screen reader user navigates by them the way a sighted user skims.
• Keyboard operability. Everything reachable by mouse must be reachable and operable by keyboard, in a sensible order, with focus you can see.
• Programmatic names and roles. A control has to announce what it is and what it does, which custom components silently break.
• Error identification. Failures must be described in text, tied to the field that caused them, not signaled by color alone.

None of these are visual polish. They are decisions about markup and component design, and they are cheap while the component library is still being written. That is why we treat it as part of custom application development rather than a separate workstream bolted on at the end.

Reading a Requirement Properly

When an accessibility clause appears in a solicitation, three questions tell you what you are actually committing to:

• Which standard and which version. WCAG 2.0, 2.1 and 2.2 are not interchangeable; later versions add criteria, several aimed at mobile and cognitive accessibility.
• Which level. AA unless stated otherwise, and be wary of a blanket AAA demand.
• What evidence is expected at delivery. A conformance report, an audit by a third party, and remediation timelines are three different commitments with three different costs.

That last one is where the money is, and it is the one most often left vague. If you want to see how we scope the work against a specific solicitation, talk to us.