Section 508 compliance in plain English

Published October 9, 2026 · about a 7-minute read

An RFP lands on your desk, and buried in the requirements is a clause: "Product must comply with Section 508." If you've never sold to the government before, that line can stall a deal while you scramble to figure out what it even means. Here's the plain version — who it binds, what standard it points to, and how you actually prove it — so a 508 clause becomes a checklist instead of a roadblock.

What Section 508 is

Section 508 is part of the U.S. Rehabilitation Act. It requires federal agencies to make the information and communications technology (ICT) they develop, buy, maintain, or use accessible to people with disabilities. It's a procurement law, not a general one — which is the key to understanding who it actually touches.

Who's really on the hook

The law names agencies, but its gravity pulls in a much wider circle:

So the practical test isn't "are we a government body." It's "do we want government money." If yes, 508 is yours to meet.

The standard behind it

The Revised Section 508 Standards (from 2017) don't reinvent accessibility — they point to WCAG. For web content, 508 incorporates WCAG 2.0 Level AA by reference. Two things trip people up here:

Section 508 is WCAG with a government wrapper and a wider scope. If you've done the WCAG work, you've done most of 508 — you just have to document it the way the feds expect.

How you prove it: the VPAT

Agencies don't take "yes, we're compliant" on faith. You prove it with a VPAT — a completed one is an Accessibility Conformance Report (ACR) — that goes criterion by criterion marking each as Supports, Partially Supports, Does Not Support, or Not Applicable, with remarks explaining the gaps. For federal sales you typically fill out both the WCAG table and the Section 508 table. I wrote a full VPAT guide, but the one rule worth repeating: be honest. An inaccurate VPAT isn't a shortcut to winning — it's a liability when the agency's accessibility team tests your claims.

How to actually comply

  1. Inventory everything in scope — the website, yes, but also PDFs, Office docs, the application itself, and support materials.
  2. Test to WCAG 2.0 AA at minimum (2.1/2.2 AA if the contract says so). Pair an automated scan — which catches only a third or so of issues — with manual screen-reader and keyboard testing. It's the same automated-plus-manual split from any real accessibility audit.
  3. Remediate, retest, and write the ACR from the verified results.
  4. Keep it up after award. "We'll fix it post-award" is how contractors earn cure notices and withheld payments. Accessibility regresses every release, so it's an ongoing obligation, not a one-time gate.

Why it doesn't stay done

Here's the trap specific to 508: your ACR is dated and tied to a product version, but your product keeps shipping. A redesign reintroduces a contrast failure, a new PDF goes out untagged, and the conformance you certified quietly stops being true — while your signed ACR on the contracting officer's desk still says otherwise. The contractors who stay out of trouble treat accessibility as monitored infrastructure, not a document they filed once.

See where your live pages stand against the WCAG checks behind 508 with our free accessibility checker — and if you're carrying a 508 obligation, a dated, continuous record of conformance is exactly the evidence that keeps an ACR honest between releases.

Keep your 508 conformance honest between releases

Perimeter grades your live pages against WCAG-based checks and re-checks them over time, with dated reports you can keep as evidence — so a regression doesn't quietly contradict your ACR. Free scan, no signup.

Monitor conformance continuously → · Compliance plan $49/mo, with dated reports