If you’ve been researching digital accessibility compliance, you’ve probably come across all three of these: the Americans with Disabilities Act (ADA), Section 508 of the Rehabilitation Act, and WCAG (Web Content Accessibility Guidelines). They often get listed together, and it can feel like you need someone who specialises in each one separately.
You don’t. Here’s why.
How the three relate to each other
WCAG is the technical standard. It sets out what “accessible” actually means for digital content: things like colour contrast, keyboard navigation, screen reader compatibility, focus management. It’s published by the W3C and is updated periodically (we’re currently on 2.2, with 3.0 in development).
The ADA and Section 508 are legal frameworks. They establish who must comply and what the consequences of non-compliance are. They don’t define their own technical criteria in detail. They reference WCAG. Section 508, which applies to US federal agencies and their vendors, formally incorporates WCAG 2.0 Level AA into its standard (the 2017 refresh). ADA compliance for web, while more legally complex since it wasn’t written with the web in mind, has been interpreted by courts as requiring WCAG AA as the benchmark in the overwhelming majority of cases.
So if your product meets WCAG 2.1 Level AA, you’re in good shape technically for ADA and Section 508. You don’t need three separate specialists. You need someone who knows WCAG thoroughly and understands the legal context each framework sits in.
What’s different between them in practice
The technical work is largely the same. The differences are mostly around documentation and process.
Section 508 often involves producing an Accessibility Conformance Report (ACR), also known as a VPAT (Voluntary Product Accessibility Template). This is a structured document that states your product’s conformance level against each relevant criterion. If you’re selling to US federal government customers, they’ll likely ask for one. Writing a good VPAT requires knowing WCAG well enough to make honest, defensible claims about each criterion.
ADA work tends to be more reactive. Teams often engage accessibility specialists after receiving a demand letter, or when getting ahead of threatened litigation. The deliverable might be a remediation plan, an audit report, or an accessibility statement.
Section 508 also covers procurement, not just the products themselves — there are requirements around how federal agencies evaluate and document their own purchasing decisions.
The certification question
You’ll see some specialists advertise DHS Trusted Tester certification, which is a Section 508-specific testing methodology. It’s a real certification and it signals familiarity with federal accessibility requirements. If you’re specifically selling into the US federal market and want your testing methodology to align exactly with what agencies use to evaluate products, it’s worth looking for.
For most organisations that aren’t selling directly to federal customers, a WCAG specialist with strong manual testing skills is what you actually need, regardless of whether they hold that specific certification.
Who needs to worry about which
US federal agencies and their direct vendors: Section 508 is your primary framework. You likely need ACR/VPAT documentation alongside the audit work.
US private sector: ADA is the relevant legal framework. WCAG AA is the de facto technical standard for compliance. Courts have been consistent on this.
EU and UK businesses: WCAG AA via the European Accessibility Act (EAA) or the Public Sector Bodies Accessibility Regulations. The technical work is identical to ADA compliance; the documentation requirements are slightly different.
Selling into multiple markets: One good WCAG audit covers the technical ground for all of them. Adjust the documentation layer for each jurisdiction.
The practical answer
Stop searching for someone who specialises in all three separately. Search for someone who understands WCAG , has experience with manual testing using real assistive technologies, and can produce the documentation your specific situation requires and actually fix your issues.
That combination is what I do.
If you’re trying to navigate which of these frameworks applies to your product and what the compliance work actually involves, Contact me.