Section 508 and the VPAT for Software Companies: The Accessibility Report Federal Buyers Ask For
#section-508#compliance#saas#federal-market
By Philip Luca — Founder of GovExpress; prior domain experience at Bloomberg Government and GovWin IQ.
Most federal compliance work for a software company is optional until a specific contract makes it mandatory. FedRAMP matters when an agency puts federal data in your cloud. CMMC matters when you handle controlled unclassified information for the Department of War. Accessibility is different. Section 508 applies to every piece of information and communication technology an agency buys, so the question arrives early, often in the first security and compliance questionnaire, and it usually arrives as a request for one document: your VPAT.
This guide covers what Section 508 actually requires, what a VPAT and an Accessibility Conformance Report are, how agencies use them, and how to write one that helps a deal rather than stalling it.
What Section 508 requires
Section 508 of the Rehabilitation Act of 1973, as amended in 1998, requires federal agencies to make the information and communication technology (ICT) they develop, procure, maintain or use accessible to people with disabilities, both federal employees and members of the public.
The obligation sits on the agency, not on you. But an agency can only meet it by buying products that conform, so in practice the requirement flows straight into procurement. The Federal Acquisition Regulation carries it in Subpart 39.2, and contracting officers write accessibility requirements into solicitations for software and services.
The technical standards come from the US Access Board. Its revised standards, often called the 508 Refresh, were published in January 2017 and took effect on January 18, 2018. Their most important feature for a software company is that they incorporate the Web Content Accessibility Guidelines (WCAG) 2.0 at Level A and Level AA by reference, and apply them not only to websites but to software, documents and electronic content generally.
| Part of the standard | What it covers for a SaaS product |
|---|---|
| WCAG 2.0 Level A and AA | Your web application, marketing site, help centre and any electronic documents you ship |
| Software and authoring tools | Desktop or mobile clients, and any feature that lets users create content |
| Support documentation and services | Your documentation and your support channels |
The exceptions, and why they rarely save you
The standards include exceptions. An agency can decline a requirement where meeting it would be an undue burden or would fundamentally alter the product, and there are narrower carve-outs, such as legacy ICT that has not been altered since the 2018 compliance date and equipment located in maintenance spaces.
None of these is a plan for a vendor. Undue burden and fundamental alteration are determinations the agency makes and documents, not claims you can assert on its behalf. When an agency invokes one, it still has to provide the information or data to the affected person by another means. A buyer choosing between a conforming product and one that needs an exception has an easy decision.
VPAT and ACR: the two names for one document
The Voluntary Product Accessibility Template, or VPAT, is a template published by the Information Technology Industry Council (ITI). It is a structured table: one row per accessibility criterion, with a conformance level and remarks for each.
A completed VPAT is called an Accessibility Conformance Report, or ACR. Buyers use the two terms interchangeably. When a questionnaire asks for “your VPAT”, it wants your ACR.
ITI publishes the template in several editions. For federal sales the one you need is the 508 edition, or the INT edition, which combines Section 508, WCAG and the European standard EN 301 549 in one report and suits a company selling in more than one market.
Each criterion gets one of a small set of conformance levels:
- Supports. The functionality meets the criterion without known defects, or meets it with equivalent facilitation.
- Partially Supports. Some functionality does not meet the criterion.
- Does Not Support. The majority of functionality does not meet the criterion.
- Not Applicable. The criterion is not relevant to the product.
The remarks column is where a report earns or loses trust. “Partially Supports” with a specific note, such as “data tables in the reporting module lack header associations; remediation scheduled for Q1”, tells a buyer you have tested and know your product. A column of unexplained “Supports” tells them you have not.
A VPAT is self-attested
An ACR is your own statement about your product. Nobody certifies it, there is no government registry of approved reports, and no agency stamps it before it reaches the buyer. That makes it the same kind of evidence as a vendor’s security questionnaire answers: useful, but self-attested, not verified.
Agencies know this. Many run their own accessibility testing on products they shortlist or deploy, and some federal testers are trained under the Department of Homeland Security’s Trusted Tester programme, which teaches a standard test process for Section 508 conformance. When an agency’s test results disagree with your ACR, the disagreement becomes the story, and an overstated report costs more credibility than an honest “Partially Supports”.
Two practices make a report hold up:
- Base it on a real evaluation. State in the report how you evaluated the product: which version, which assistive technologies, which browsers, and whether the work was done in-house or by an outside accessibility firm.
- Date it and keep it current. An ACR describes one product version. A report written three releases ago describes a product the buyer cannot buy. Update it on a schedule and whenever a major feature ships.
What WCAG version to build to
The 508 standards reference WCAG 2.0, and that remains the federal floor. The guidelines have since moved on: WCAG 2.1 added criteria for mobile use, low vision and cognitive accessibility, and WCAG 2.2 added more. Every WCAG 2.0 Level AA criterion is also in WCAG 2.1 Level AA, so building to 2.1 AA covers the 508 requirement and the expectations of buyers who have moved past the federal minimum, including many state and local governments and enterprise customers.
For a software company the practical work is familiar to any front-end team:
- Every interactive element reachable and operable by keyboard alone, with a visible focus indicator
- Text alternatives for images and icons that carry meaning
- Form fields with programmatic labels and error messages that identify the field
- Sufficient colour contrast, and no information conveyed by colour alone
- Data tables with proper header markup, which matters for any analytics or reporting screen
- Correct names, roles and states on custom components, so screen readers announce them
Automated scanners catch a share of these issues quickly. They do not catch all of them. Keyboard and screen-reader testing by a person is what turns a scan into an evaluation you can put your name to.
Where the ACR appears in a federal sale
You will meet the accessibility question at several points, and it is far easier to have the document ready than to produce it under a proposal deadline:
- Market research. An agency gathering information on available products may ask for an ACR alongside capability information.
- Solicitations. Requirements built with GSA’s Accessibility Requirements Tool, or written by the agency directly, can require an ACR with the proposal.
- Contract vehicles. Getting onto a GSA Schedule or another contract vehicle does not settle accessibility for you; each ordering agency still applies its own requirements to the products it buys.
- Security and compliance review. The ACR often sits in the same package as your security documentation, reviewed by the same people.
GSA maintains Section508.gov, which carries the official guidance, the buyer-side tools and the current links to the standards. Reading the buyer guidance there is the fastest way to see your product the way an agency accessibility reviewer will.
The short version
Section 508 is the one federal compliance requirement that applies to every software product an agency buys. Your evidence of meeting it is an Accessibility Conformance Report written on ITI’s VPAT template. Build to WCAG 2.1 AA, evaluate with people and not only scanners, write remarks that show you know your gaps, and keep the report dated and current.
It is also one of the cheaper federal readiness steps to get right, and one of the most visible when you get it wrong.
Score your company’s federal readiness to see where accessibility and compliance evidence stand next to the other categories buyers look at.
Related reading
The CMMC brief
What the Phase 2 suspension changed and what it did not — the obligations that still bind, the assessment path a contract puts you on, the scoping decision that drives the cost, and the sequence that fits inside a pipeline. Sourced from the primary record.