Section 508 is a U.S. federal law requiring that federal agencies, and the contractors and vendors who sell information and communications technology to them, make that technology accessible to people with disabilities. Since a 2017 update known as the “508 Refresh” took effect in January 2018, the technical bar has been WCAG 2.0 Level A and AA rather than a separate government-only rulebook. It applies squarely to federal procurement and federal agency websites, not to private businesses in general, though the practical overlap with other accessibility law is large.
What Section 508 actually requires
Section 508, part of the Rehabilitation Act of 1973, requires that electronic and information technology developed, procured, maintained or used by federal agencies be accessible to employees and members of the public with disabilities. That covers a broad set of things: agency websites, internal software and intranets, electronic documents (PDFs, Word files), self-service kiosks, and telecommunications equipment. Before 2017 the requirements were written as their own technical criteria; the refresh replaced most of that with a direct reference to WCAG 2.0 A and AA for web and electronic content, which simplified things considerably for anyone already working toward WCAG.
Who has to comply
Two groups are on the hook. First, federal agencies themselves have to make the technology they build or operate accessible. Second, and this is the part private companies often miss, any vendor or contractor selling ICT products or services to a federal agency has to demonstrate that what they’re selling meets Section 508 requirements, usually documented through a VPAT during the procurement process. A software company, web development shop or SaaS vendor with federal agencies as customers is squarely in scope even though it’s a private business.
How Section 508 maps to WCAG and EN 301 549
Because the 2017 refresh adopted WCAG 2.0 A and AA directly, an organization that has already done real WCAG 2.1 AA work (the more current version most private-sector accessibility programs target) is, in practice, ahead of the Section 508 baseline rather than behind it. The refresh also harmonized U.S. federal technical requirements with EN 301 549, the European standard that similarly incorporates WCAG 2.1 AA in full as its core technical baseline. That alignment matters for vendors selling into both U.S. federal and EU markets: a single WCAG-based remediation effort covers most of the technical ground for both.
Section 508 vs the ADA
It’s worth being precise about the distinction, since the two get conflated constantly. Section 508 is a procurement and federal-agency requirement tied to the Rehabilitation Act. The Americans with Disabilities Act (ADA) is broader civil rights law that courts and the Department of Justice have applied to private-sector websites under Title III, and to state and local government sites under Title II. A private business with no federal contracts doesn’t have a direct Section 508 obligation, but it can still face ADA exposure for an inaccessible website, and the practical fix in both cases is largely the same: build to WCAG 2.1 AA.
Where testing and remediation vendors fit
Federal agencies and their contractors typically need documented, defensible conformance rather than a quick widget install, which is why the vendors most active in this space lean toward developer-level testing and manual audit work. Deque Systems, built around the widely used axe-core testing engine, sells exactly this kind of developer-facing tooling and expert-led audits, and produces VPATs as part of its consulting work. Allyant has a strong public-sector and higher-education client base and focuses heavily on document and PDF remediation, which matters because Section 508 covers electronic documents, not just web pages, and PDF accessibility is frequently the weakest link in an otherwise compliant agency site. Widget-based platforms like Wawsome list Section 508 among the standards they map to, which can help with the public-facing web layer, but a genuine federal procurement conformance claim generally needs the kind of manual audit and VPAT documentation that testing-focused vendors specialize in.
A brief history
Section 508 originated as part of the Rehabilitation Act, with federal accessibility requirements for electronic and information technology dating back to 1998. The original technical standards were federal-specific and grew dated as web technology moved on; the 2017 refresh (effective January 2018) replaced them with direct references to WCAG 2.0 A and AA and harmonized the U.S. federal standard with EN 301 549, so agencies and vendors weren’t testing against two different rulebooks for the same underlying concept. Knowing that history matters mostly because older documentation, older VPATs, or older internal policy language at an agency can still reference the pre-2017 criteria, which is worth flagging if you come across it.
How conformance actually gets tested
Federal agencies commonly use a structured methodology, sometimes called the Trusted Tester process, that combines automated scanning with a defined manual testing protocol mapped to WCAG success criteria. The point of a standardized process like this is consistency: two different testers evaluating the same page should reach the same conclusion about whether it conforms, rather than conformance depending on who happened to run the test. If you’re preparing a product or website for federal review, it’s worth asking whether the agency or contracting officer expects testing against a specific published methodology, since that can shape how you scope your own pre-submission testing.
Getting started if you sell to federal agencies
If your organization is new to Section 508 because you’re pursuing a federal contract for the first time, the practical starting point is a genuine WCAG 2.1 AA audit of whatever product or website is in scope, since that gets you most of the way to the Section 508 baseline in one pass. From there, document the results in a VPAT using the Section 508 or combined edition, and be specific in the remarks column about what was actually tested rather than leaving generic “supports” claims unexplained. Budget time for this before a procurement deadline is looming; a rushed VPAT produced under deadline pressure is exactly the kind of document that tends to overstate conformance and create problems later when a federal accessibility reviewer or end user finds a gap it didn’t disclose.
Common mistakes
The most common misstep is assuming a piece of software is “Section 508 compliant” because a vendor says so in a sales conversation, without ever reviewing an actual VPAT or ACR (Accessibility Conformance Report). The second is treating Section 508 as web-only and forgetting about PDFs, internal tools and kiosks, which are all in scope and are where a surprising amount of real-world non-compliance lives. The third is confusing a partial automated scan with a genuine conformance assessment; automated tools catch a meaningful subset of WCAG success criteria, but a real Section 508 conformance claim depends on manual testing against the full criteria list, including things like logical reading order, meaningful alternative text and correct keyboard operability that scanners can only partly evaluate.