Section 508 of the Rehabilitation Act (29 U.S.C. 794d) requires federal agencies to make their electronic and information technology accessible to people with disabilities — both federal employees and the public. That obligation flows downhill: if you build, configure, or deliver IT for a federal customer, your deliverable has to conform to the Revised 508 Standards, and non-conformant work can be rejected before acceptance. This is the plain-English version, written for small businesses selling software and technical services to government. It’s educational, not legal advice — always verify against Section508.gov and the specific solicitation.
Section 508 in one paragraph
A federal accessibility law that became a procurement requirement.
Section 508 (codified at 29 U.S.C. 794d) was first added to the Rehabilitation Act in 1986 and then substantially amended and strengthened by the Workforce Investment Act of 1998 — the version that turned it into the enforceable procurement requirement contractors deal with today. It requires that when federal agencies develop, procure, maintain, or use information and communication technology (ICT), people with disabilities — federal employees and members of the public alike — get access to and use of information that is comparable to what’s available to everyone else, unless doing so would impose an undue burden on the agency.
“ICT” is broad. It covers websites and web applications, software, electronic documents (PDFs, presentations, forms), electronic content like email and training, hardware, and the multimedia attached to all of it. The U.S. Access Board — an independent federal agency — writes the technical standards; the standards are then incorporated into the procurement rules agencies follow. So Section 508 is two things at once: a civil-rights obligation on agencies, and a set of measurable technical requirements that show up in your contract.
Why this lands on contractors: agencies can only meet their 508 obligation if the ICT they buy and the custom systems they commission actually conform. That requirement is passed through to you in the solicitation and the contract. Build something inaccessible and the government can decline to accept it.
The Revised 508 Standards and the WCAG 2.0 baseline
The 2017 “ICT Refresh” set the technical bar you’re measured against.
For nearly two decades, 508 ran on the original technical standards the Access Board issued in 2000. The Access Board published a final rule on January 18, 2017 — known as the ICT Refresh or the Revised 508 Standards — that overhauled them. Federal agencies and their contractors have had to comply with the revised version since the compliance date of January 18, 2018.
The single most important change: the Revised Standards incorporate WCAG 2.0 Level A and Level AA by reference as the technical baseline for web content, electronic documents, and software. Instead of a separate, U.S.-only checklist, federal accessibility now points to the same globally recognized W3C standard the rest of the world uses. The standards live in regulation at 36 CFR part 1194 (appendices A and C). If you’ve targeted WCAG before, you already know most of the work — see our WCAG 2.1 AA guide for the success-criteria detail.
It’s WCAG 2.0, not 2.1
The Revised 508 Standards reference WCAG 2.0 A and AA. WCAG 2.1 and 2.2 add criteria (mobile, low-vision, cognitive) that aren’t legally required by 508 today — but many agencies ask for them by name in the solicitation. Read the requirement, don’t assume.
FPC and software rules too
508 also has Functional Performance Criteria and hardware/software provisions that go past web content. A pure WCAG pass is necessary, not always sufficient. Check what type of ICT you’re delivering.
Limited, documented escapes
“Undue burden,” national-security systems, and certain incidental ICT can be excepted — but exceptions are narrow, must be documented by the agency, and are not yours to declare. Verify against the solicitation and your CO.
How conformance is tested — and why “automated” isn’t the answer
An automated scan is a floor, not a certification.
Real 508 conformance requires both automated checks and manual testing. Automated tools catch only a portion of the issues — missing alt text, low contrast, empty form labels, bad heading structure. They cannot judge whether your alt text is meaningful, whether the keyboard focus order makes sense, whether a screen reader announces your custom widget correctly, or whether your error messages are actually usable. Those are human judgments.
| Method | Catches | Misses |
|---|---|---|
| Automated scan | Contrast, missing labels/alt, parse errors, structural gaps | Meaning, context, focus logic, screen-reader behavior |
| Manual testing | Keyboard-only paths, screen reader (NVDA/JAWS/VoiceOver), zoom/reflow, cognitive flow | Nothing — but it’s slower and needs skill |
Run a free accessibility checker first to clear the obvious defects, then test the keyboard path and a screen reader on every interactive component. The deliverable proof is usually an Accessibility Conformance Report (ACR) — completed on the ITI’s VPAT template — submitted for each ICT item before acceptance. And note: the government reserves the right to independently test your ICT to validate the conformance claims you make. An honest “partially supports” with a remediation plan beats an inflated “supports” that fails the agency’s own scan.
Honesty caveat: a green automated report is not a certification of conformance. It means the machine-checkable subset passed. Claiming full 508 conformance on the strength of a scanner alone is how deliverables get rejected at acceptance.
Where 508 shows up in your acquisition
Treat it as an acceptance criterion, not an afterthought.
Federal IT acquisitions handle accessibility under FAR Subpart 39.2, which implements Section 508 and the Access Board’s ICT standards at 36 CFR 1194.1. When you provide custom ICT development or commercial off-the-shelf products, the expectation is that the ICT conforms to the applicable Revised 508 Standards before delivery and final acceptance, unless a documented exception or exemption applies. Bake it into the build — retrofitting accessibility after the fact is far more expensive than designing for it.
Do this
- Read the 508 / accessibility clause in the solicitation before you bid.
- Design to WCAG 2.0 AA from sprint one; treat it as a definition-of-done item.
- Test automated + manual on every release; keep evidence.
- Deliver an honest ACR/VPAT per ICT item.
- Document any exception with the CO — never self-grant one.
Avoid this
Treating 508 as a checkbox at the end. Submitting a VPAT you didn’t actually test against. Relying on a scanner alone. Assuming COTS is automatically conformant. Promising “supports” when the truth is “partially supports.” Each of these can stall acceptance, invite rework, and damage past-performance.
BrandShyp bids federal and state IT work every week and eats its own cooking — we hold our own NIST 800-171 posture and build accessibility in by default. If you need a system built right or an existing deliverable remediated, our services cover both. This page is educational, not legal advice — confirm the binding requirements against the solicitation, Section508.gov, and your contracting officer.