Section 508 Compliance Explained: Coverage, WCAG 2.0 AA, and How to Document Conformance

Section 508 applies to all federal executive-branch departments and agencies when they develop, procure, maintain, or use ICT. "ICT" is deliberately broad: public websites and intranets, web applications, native and mobile apps, electronic documents (Word, PDF, PowerPoint), email, kiosks, telecommunications equipment, and the authoring software used to produce all of it.

Contractors and vendors are pulled in through the procurement chain rather than regulated directly. An agency cannot lawfully buy ICT that fails to conform unless a documented exception applies, so the practical burden lands on suppliers to prove their product meets the standard. If you sell a SaaS platform, a content management system, or a hardware device to a federal buyer, you will be asked for evidence of conformance before the purchase can proceed.

• Federal agencies — every public-facing and internal system, plus the electronic content they publish
• Prime contractors and subcontractors — deliverables must conform, and conformance is a contractual obligation
• Commercial ICT vendors — products are evaluated against the standard during acquisition
• State entities under "little 508" laws — many states adopted statutes mirroring the federal standard for their own agencies

Section 508 does not directly regulate private companies with no federal nexus. Those organizations are usually concerned with the ADA instead, which names no specific WCAG version but where WCAG 2.1/2.2 Level AA functions as the de-facto benchmark in settlements and Department of Justice guidance.

The 2017 Revised 508 Standards, codified at 36 CFR Part 1194, incorporate WCAG 2.0 Level A and Level AA by reference, with a compliance date of January 18, 2018. This is the single most important technical fact for any team scoping a project: the binding requirement is WCAG 2.0 AA, not a newer version.

The rule also extends WCAG to non-web content. WCAG was written for web pages, but the Revised Standards apply the same WCAG 2.0 A and AA success criteria to non-web documents and software, with WCAG2ICT guidance translating terms like "web page" into "document" or "software." So a PDF report, a desktop application, and a public website are judged against the same criteria.

Conformance is backstopped by Functional Performance Criteria (Chapter 3, section 302 of the Revised Standards). These are outcome-based requirements, for example that ICT be usable without vision or without hearing, and they apply where the technical success criteria do not fully cover a use case.

What WCAG 2.0 AA actually requires

Concrete, testable obligations under the standard include:

• Text alternatives for images and non-text content (1.1.1)
• Color contrast of at least 4.5:1 for normal text and 3:1 for large text, where large means 18pt or 14pt bold (1.4.3)
• Full keyboard operability with no traps, so every control is reachable and usable without a mouse (2.1.1, 2.1.2)
• Programmatically associated form labels, error identification, and instructions (1.3.1, 3.3.1, 3.3.2)
• Meaningful page structure via headings, relationships, and a correct reading order (1.3.1, 2.4.6)

WCAG 2.0 predates the newer criteria such as 2.5.8 Target Size Minimum (24x24 CSS px), 3.3.8 Accessible Authentication, and 2.4.11 Focus Not Obscured, and it still includes 4.1.1 Parsing (removed in WCAG 2.2). Those newer items are not legally required under Section 508 today, but building to WCAG 2.2 AA fully satisfies 2.0 and protects you against a future rule update.

A credible methodology blends automated and manual checks. Automation is fast and consistent but, by most expert estimates, can only detect a subset of WCAG failures; the rest require human judgment. Treat the two as complementary, not interchangeable.

A practical sequence that maps cleanly onto WCAG 2.0 AA:

• Automated scan first to clear high-volume, machine-detectable issues — run a free pass with AccessScan to catch missing alt text, contrast failures, and unlabeled fields before manual work begins
• Keyboard-only pass — unplug the mouse and tab through every page; confirm a visible focus indicator, logical order, and no traps
• Screen reader testing with NVDA or JAWS on Windows and VoiceOver on macOS/iOS to verify names, roles, states, and reading order
• Zoom and reflow to 200%, plus contrast verification on real UI states such as hover, focus, and disabled
• Document and PDF checks for tagged structure, reading order, and alt text

Many agencies test against the ICT Testing Baseline maintained by the federal Section 508 community at Section508.gov, a standardized set of test conditions that makes results comparable across teams. Aligning your methodology to that baseline makes your evidence far easier for an agency reviewer to accept and reproduce.

Testing only counts if it is written down in a form agencies recognize. The standard artifact is the Accessibility Conformance Report (ACR), produced by filling in a Voluntary Product Accessibility Template (VPAT). A blank VPAT is just the form; once you populate it with real results and a conformance level per criterion, it becomes an ACR.

• Use the VPAT 2.x Revised Section 508 edition (or the INT edition, which also covers EN 301 549 and WCAG) when selling to the federal government
• Report each success criterion as Supports, Partially Supports, Does Not Support, or Not Applicable, with specific remarks — vague "Supports" rows without evidence undermine the report
• Date the report and tie it to a specific product version; conformance claims drift as software changes
• Keep raw test evidence (tool output, screen reader notes, keyboard findings) so you can defend the ACR if challenged

Federal agencies that publish digital services also maintain a public accessibility statement describing conformance status and a feedback channel. Known gaps should be tracked with a dated remediation plan rather than left silent: a documented path to conformance on a failing criterion is far stronger than an unexplained blank.

Section 508 is one of several regimes that lean on WCAG, and the versions differ in ways that matter for multinational or multi-jurisdiction products:

• Section 508 (US federal) — WCAG 2.0 AA, by reference, plus Functional Performance Criteria
• ADA (US, general) — no named version; WCAG 2.1/2.2 AA is the de-facto standard in practice
• European Accessibility Act — applies from 28 June 2025; baseline is WCAG 2.2 A and AA via EN 301 549, covered in the EAA overview
• AODA (Ontario) — references WCAG 2.0 AA, closely paralleling Section 508's baseline

If you build to WCAG 2.2 AA once, you comfortably clear Section 508's 2.0 AA bar and stay aligned with the EAA's 2.2 baseline at the same time, which is usually the most efficient strategy for vendors selling on both sides of the Atlantic.