Section 508 Compliance Explained: A Plain-English Guide

Section 508 is part of the Rehabilitation Act of 1973, added by amendment in 1998. It says that when federal agencies develop, procure, maintain, or use electronic and information technology, that technology has to be accessible to people with disabilities — both federal employees and members of the public. That is the whole idea: the government should not buy or build digital tools that lock disabled people out.

The critical word is federal. Section 508 binds federal agencies directly. It does not, on its own, apply to your local coffee shop's website or a private SaaS company that never touches a government contract. That is where most of the confusion starts — people assume “508” is the catch-all accessibility law for the entire United States. It is't. The law that reaches private businesses is the Americans with Disabilities Act, and the two are easy to mix up. We untangle that relationship in detail in WCAG vs ADA.

Here is the part that saves you a lot of reading. In 2017 the U.S. Access Board issued what is usually called the “Section 508 Refresh,” and it did something genuinely useful: it adopted the Web Content Accessibility Guidelines (WCAG) 2.0 Level A and Level AA as the official technical standard. So when a contract says “must be Section 508 conformant,” what it actually means, for web content, is “must meet WCAG 2.0 AA.”

That is enormously clarifying. You do not have to learn a separate, parallel rulebook. The same success criteria that drive ADA expectations and global standards drive Section 508: text alternatives for images, sufficient color contrast, keyboard operability, clear labels, logical structure, and so on. If you already understand WCAG, you already understand the substance of 508. Our WCAG 2.2 guide covers the newer criteria layered on top, and the WCAG checklist breaks the requirements into something you can actually work through page by page.

One honest caveat: Section 508 points at WCAG 2.0, while the rest of the world has moved on to 2.1 and 2.2. If you build to the current version, you are comfortably above the 508 floor — so when in doubt, target the newer standard and you cover both.

Because 508 conformance is really WCAG conformance, you test it the same way you test any site — with one important dose of honesty about what each method can and cannot find. Anyone who tells you a single tool delivers full Section 508 compliance is selling you something.

1. Start with an automated scan. Run your key pages through a checker like CompliaScan's free WCAG checker, which is built on the open-source axe-core engine. Automated testing is fast, repeatable, and great at catching the machine-detectable failures — missing alt text, contrast problems, empty labels, broken structure.
2. Know the ceiling. Automated scanning reliably catches only about 30–40% of WCAG success criteria. The rest — whether alt text is actually meaningful, whether focus order makes sense, whether a screen reader announces a custom widget correctly — requires human judgment. Any vendor claiming 100% automated coverage is misrepresenting how the technology works.
3. Test manually with a keyboard and screen reader. Unplug the mouse and tab through every page. Then try it with a screen reader. This is where the criteria machines can't judge get verified, and it is non-negotiable for a credible VPAT.
4. Don't skip documents and media. PDFs, Word files, and videos are squarely in Section 508 scope. Tagged PDFs and captioned video are where a lot of “compliant” agencies and vendors quietly fall down.

When CompliaScan flags an issue, it can also suggest a code-level fix using AI — but on your own API key, with your own OpenAI, Anthropic, or Gemini account and no markup from us. We do not resell tokens, and we do not pretend the suggestions are a substitute for human review. For the full picture of how a real audit comes together, see our accessibility audit guide.