Guides
Section 508 procurement guide for US employers buying accessible technology
Section 508 procurement means asking vendors for an ACR, testing the product with real users, and writing fixes into the contract before you sign.
What to take away
- Section 508 binds federal agencies when they buy technology, not only when they build it. The solicitation is where compliance is won or lost.
- The U.S. Access Board standards are the technical baseline. They incorporate WCAG 2.0 Level A and AA by reference, which is why most vendors report against WCAG 2.1 or 2.2 AA.
- Ask for a completed Accessibility Conformance Report with the offer. A VPAT is the blank template; the ACR is the filled-in claim.
- An ACR is a claim, not a test result. Test the five tasks that matter with a screen reader and a keyboard before you accept delivery.
- Write remediation timelines, a reporting duty, and remedies into the contract. "Contractor shall comply with Section 508" tells nobody what happens when a barrier appears.
What Section 508 actually requires of a federal buyer
Section 508 of the Rehabilitation Act requires federal agencies to buy, develop, and use information and communication technology that works for employees and members of the public with disabilities. The duty attaches when the agency buys.
That makes the contracting officer the gatekeeper. A solicitation that never asks for accessibility evidence can still leave the agency exposed after award. The cheaper fix is early: put the requirement in market research, in the statement of work, and in the evaluation criteria.
The rule covers hardware, software, electronic documents, websites, and telecom. A laptop, a time-and-attendance portal, a call center platform, and a fillable PDF all sit inside it.
Two audiences have to be served. Employees must be able to do their jobs with their own assistive technology. Members of the public must be able to use agency services. A tool that works for staff but blocks a public portal still fails.
Section 508 does not demand a flawless product at delivery. It demands that the agency identify barriers, record them, and manage them through remediation or an equally effective alternative.
Complaints can land with an agency's Section 508 coordinator, its civil rights office, or Congress. A documented, tested buy is both the strongest defense and the cheapest one to run.
When you are assembling the evidence file, our cloud storage checklist covers the records a contracting officer should expect to see in a response.
The Access Board standards and where WCAG fits
The U.S. Access Board maintains the Section 508 standards and the related Section 255 guidelines for telecommunications. Those are the technical requirements agencies cite in solicitations.
The standards are organized by function rather than by product category. They cover these areas:
- software
- operating systems
- web content
- hardware
- support documentation
- telecom functions Each provision says what a feature must do for a user with a disability.
WCAG is where most vendors actually live. The Access Board standards incorporate WCAG 2.0 Level A and AA success criteria by reference for web and non-web content. That is why an ACR often reports WCAG 2.1 or 2.2 AA results even when the contract cites the Access Board rule.
The mapping is not one-to-one. Some provisions have no WCAG equivalent at all: certain hardware controls, audio output, and closed functionality. A vendor that tested only a website has not tested the product.
Ask which standard version the vendor tested against, at which level, and which success criteria failed. "WCAG compliant" with no version and no level is not something a contracting officer can evaluate.
The Board also publishes best practices and technical assistance. Cite those in a statement of work when a requirement is ambiguous, so "accessible" has a definition for that deliverable.
| Contract requirement | Access Board basis | WCAG step | Evidence to request |
|---|---|---|---|
| Public website and forms | Web content provisions | WCAG 2.2 AA | ACR plus test scripts and results |
| Desktop and mobile app | Software provisions | WCAG 2.2 AA where applicable | ACR plus keyboard and screen reader tests |
| Hardware with controls | Hardware provisions | No direct WCAG mapping | Usability test with assistive technology users |
| Documentation and help | Support documentation provisions | WCAG 2.2 AA for electronic docs | Accessible PDF or HTML samples |
| Telecom functions | Section 255 guidelines | WCAG 2.2 AA for interfaces | ACR plus relay and captioning evidence |
Keep that mapping in the contract file. If a protest or a complaint arrives, the agency has to show it specified the right standard and evaluated against it.
Writing the requirement into the solicitation
Accessibility belongs in the solicitation, not in a conversation after award. If it is not in the solicitation, a vendor can argue it is not in the contract.
Start with market research. Ask likely vendors for an ACR or VPAT before you draft the requirement. That shows what the market can deliver and where you will need an alternative.
Then write requirements a tester can check. "The product shall be accessible" is not testable. "The product shall conform to the Access Board standards and WCAG 2.2 Level AA for all web interfaces, documented in an ACR" is.
- Name the audiences: federal employees, members of the public, or both.
- List the product functions that touch each audience, including support and documentation.
- Cite the Access Board standards and the WCAG version and level in the statement of work.
- Require an ACR or VPAT with the offer, not after award.
- Ask for a named accessibility contact and a remediation history covering the last two years.
- Set the evaluation weight for accessibility and state that a missing ACR is a deficiency.
- Require the vendor to allow agency testing with assistive technology before acceptance.
A vendor questionnaire makes responses comparable. Force a yes, no, or partially supported answer for each relevant provision, with a place to attach evidence.
Ask which ACR template version the vendor used, who ran the tests, and whether any tester used assistive technology. Ask what failed and when the fix ships. Ask whether any customer has reported a barrier in the last 24 months.
A company that cannot describe its own accessible technology practices is unlikely to support yours. That question belongs in the questionnaire, not in a reference call.
Small businesses may need help responding. Point them to the Access Board guidance and the ACR template without writing the response for them. That keeps competition open and the record clean.
Reading an ACR and the evidence behind it
An ACR is an Accessibility Conformance Report. A VPAT is the Voluntary Product Accessibility Template that structures it. Vendors use the terms together: a completed VPAT becomes the ACR.
The ACR is a claim about how a product conforms to a named standard. A good one names the standard version, the WCAG level, the evaluation methods, the date, and the product version tested.
Weak ACRs share patterns. They cite an old WCAG version, mark everything "supports" with no explanation, omit the product version, or leave the remarks column empty. Any of those should trigger a clarification request.
Test evidence is what turns a claim into a record. Ask for the test scripts, the assistive technology used, the browser and operating system combinations, and the list of known defects. A screenshot of a passing check is not a test report.
A vendor self-assessment is acceptable when it is detailed. Third-party testing carries more weight for public-facing services and for anything people use to claim benefits.
Review the ACR at renewal. Products change, and a report from three years ago may not describe the version now deployed. A stale ACR is a finding waiting to happen.
Where a product does not fully conform, document the exception: the barrier, its impact, the alternative, and the remediation date. Silence is the problem, not the gap.
Testing before you accept delivery
Acceptance testing is the agency's best moment to catch failures. The vendor still has an incentive to fix them, and the agency has not yet accepted the risk.
Test the tasks that decide whether the product works, not every page. A benefits application, a timecard submission, a document upload, and a support call will surface most of what matters. Automated scanners catch some issues and miss many others.
A short trial settles real questions. Our home network checklist shows how a two-week trial exposed barriers a vendor ACR never mentioned. Schedule the trial before acceptance, not after rollout.
Cover these areas:
keyboard access
screen reader output
magnification at high zoom
captions and transcripts
color contrast
forms Cover the support channel too, because a user who cannot reach help has no remedy.
Confirm the ACR matches the version being delivered.
Run the top five user tasks with at least one screen reader.
Complete every task using only a keyboard.
Check zoom at 200 percent and reflow at 400 percent.
Verify captions and transcripts on all media.
Test the support and escalation path.
Record defects with steps to reproduce and severity.
If a defect is severe, do not accept the product. Use the acceptance clause to require a fix or a dated remediation plan. Conditional acceptance with a written plan usually beats a rejection that restarts the buy.
Testers choosing assistive tools for those tasks should start with our laptop upkeep checklist. It covers the combinations that hold up under daily use.
Contract clauses that survive a barrier report
A clause saying the contractor will "comply with Section 508" is a start. It does not say what happens when a barrier appears.
Write the standard into the contract by reference, including the version. Then add deliverables: an ACR at award, an updated ACR at each major release, and a defect report on request. Those deliverables are the paper trail.
Set remediation timelines by severity. A barrier that blocks a core task gets a shorter window than a cosmetic one. Start the clock when the agency reports the defect, not when the vendor acknowledges it.
Include a reporting duty. The contractor tells the agency when it learns of a new barrier, when a fix ships, and when a third-party component changes. Silence should carry a consequence.
Add remedies that fit the risk: withholding acceptance, withholding payment, requiring a corrective action plan, terminating for cause. Require the contractor to keep accessibility records for the contract term.
Subcontractors and resellers are covered. A reseller should pass the requirements to the manufacturer and hand over the ACR. The agency should not have to chase the supply chain.
Training and support count as deliverables. The contractor should train agency staff on accessible use and provide support that works for users with disabilities. A help desk that only takes phone calls is not accessible support.
The FCC accessibility program is a working example of an agency publishing its accessibility commitments and complaint routes. That pattern translates into contract language.
Watch the Federal Register health and public welfare index for rule changes tied to accessibility and public programs. Procurement-specific changes usually appear in the Federal Register business and industry index. Check both before a major solicitation.
A public accessibility policy as the front end of procurement
USAGov's accessibility policy is short and does four useful things. It states the commitment, names the standard, explains how to report a barrier, and says what the agency will do next. That structure works for a procurement program too.
Adapt it in four parts: a commitment to Section 508 and the Access Board standards, a description of how the agency buys and tests technology, a reporting route for the public and employees, and a review cycle.
The USA.gov accessibility policy is the reference point. It shows how plain language can sit alongside technical requirements without replacing them.
Link the policy to the procurement process. A reader who reports a barrier should see how the agency routes it to the program office and, when needed, into a contract remedy. That link is what makes the policy operational.
Publish a contact and a complaint path. A policy without a route for complaints is a poster, not a process. Use a role rather than a person so it survives staff changes.
Review the policy when standards change. WCAG and the Access Board requirements are updated from time to time, and a policy citing an old version undermines the contract clauses that depend on it.
Tie the policy to the device security checklist your field team already uses. Real defects reported through that route become the evidence for the next version of the policy and the next solicitation.
Common questions
Does Section 508 apply to contractors?
Yes, when a contractor supplies information and communication technology to a federal agency. The contract should pass the accessibility requirements down, including ACR delivery and remediation duties. The agency remains accountable for the outcome.
Is a VPAT the same as an ACR?
A VPAT is the template; a completed VPAT is an ACR. Ask for the completed report, the standard version, the WCAG level, and the test evidence behind it. A blank template tells you nothing about the product.
Which WCAG version should a solicitation require?
Cite the version the Access Board standards incorporate, at the level your agency can test. WCAG 2.2 Level AA is a common baseline for web and software interfaces. State the version explicitly so vendors cannot quietly test against an older one.
Can an agency accept a product with known barriers?
Yes, if it documents the barrier, the impact, the alternative, and the remediation date. Undocumented gaps are the real risk. A recorded gap with a dated plan is a managed one.
When should testing happen?
Before acceptance, while the vendor still has an incentive to fix defects. Test the core user tasks with assistive technology and make the fixes a condition of acceptance. Testing after rollout moves the cost to the agency.
