Section 508 VPATs: What Government Buyers Get Wrong

Section 508 procurement requires a VPAT. So vendors produce VPATs. Most buyers request them, file them, and assume the compliance question is settled. It isn't. A VPAT is a self-reported document the vendor writes, in language the vendor chooses, against criteria the vendor interprets. A confident "Supports" can mean anything from "independently tested, fully compliant" to "we believe this probably works."

We review VPATs for a living, across GSA MAS and NASPO ValuePoint procurements, and the pattern repeats: government buyers who don't know how to read a VPAT accept documents that describe a rosier compliance picture than the deployed product delivers. That matters because Section 508 PDF compliance and web accessibility failures in deployed government technology become the agency's problem, not the vendor's, the day a complaint lands.

What Is a VPAT and What Does It Actually Prove?

A VPAT, formally an Accessibility Conformance Report, maps a product against Section 508, WCAG 2.1, or EN 301 549. For each criterion the vendor marks Supports, Partially Supports, Does Not Support, or Not Applicable. It is a vendor's self-assessment at a single point in time, not an independent audit, not a legal guarantee, and not proof the product works for someone using a screen reader today.

What a VPAT Is Not

It is not a real-time document. The product may have shipped three releases since the VPAT was written. It is not a complete test. Automated scans and manual audits catch different failures, and a VPAT built on scans alone misses the failures that matter most to assistive technology users. And it tells you nothing about severity. A cosmetic contrast issue and a keyboard trap that locks a user out of a workflow both show up as "Partially Supports," with no way to tell them apart from the table alone.

Five Ways Vendors Obscure Failures in a VPAT

1. "Partially Supports" With No Explanation

The Remarks column is supposed to describe exactly what doesn't work. Too many VPATs leave it blank, or write something like "some elements may not be fully accessible in all configurations." That tells a buyer nothing actionable. Ask the vendor, in writing, to specify what partial support means for every criterion where it appears.

2. Scoping Out the Hardest Components

A search widget marked "Not Applicable" because "the widget doesn't include this functionality" is a common evasion for features that exist but weren't tested. Autocomplete, filter controls, and dynamically loaded results are never N/A. They're the hardest components to get right, and a VPAT that claims N/A for them deserves a direct follow-up question.

3. An Outdated VPAT on a Current Product

Check the VPAT date against the current product version. A document written for version 2.1 of a tool now shipping version 4.6 describes a product that no longer exists. Major UI releases introduce new accessibility risk. Anything more than 18 months old, or more than one major version behind, isn't a reliable picture of what you'd actually deploy.

4. Automated Scans Passed Off as Manual Testing

Automated tools like axe, WAVE, and Lighthouse catch roughly 30 to 40 percent of WCAG failures. They catch none of the keyboard-flow problems, screen reader announcement errors, or cognitive-load issues that matter most to real users. A VPAT built solely on automated results shows "Supports" for criteria that fail the moment a screen reader user tries the product.

5. Conformance That Requires an Opt-In Setting

"The accessible version is available when high-contrast mode is enabled" is not conformance. A product must be accessible in its default, deployed state. If a user has to know a setting exists and know where to find it, that setting is a barrier, not a fix.

6. Silence on Assistive Technology Compatibility

A thorough VPAT states which screen readers and browser combinations were actually tested: NVDA with Firefox, JAWS with Chrome, VoiceOver with Safari. A VPAT that never names a screen reader anywhere in the document was probably never tested with one. That silence is itself an answer, and it's one buyers routinely miss because they're scanning the Conformance Level column, not checking for what's absent from the Remarks.

What Three Questions Should You Ask After Reading a VPAT?

Ask for the independent audit report, not the VPAT. Ask for a live keyboard-only demo of the primary workflow. Ask which criteria were manually tested with a screen reader versus scanned by a tool. The answers reveal more about a vendor's accessibility maturity than the document itself.

1. 1Provide your most recent independent accessibility audit report, not the VPAT. The third-party report with methodology, test cases, and findings. If none exists, ask when the last one was done and why the interval is what it is.
2. 2Demonstrate keyboard navigation through the product's primary workflow with no mouse. For a search tool: open search, type a query, reach the first result, follow the link. Any step that requires a mouse is a WCAG 2.1.1 failure that belongs in the VPAT as "Does Not Support."
3. 3Which success criteria in your VPAT are based on manual screen reader testing, and which on automated scanning only? A vendor who can't answer this doesn't have a reliable VPAT methodology.

We stopped accepting VPATs at face value after a vendor's document showed full conformance and our own screen reader test found the search results couldn't be navigated by keyboard at all. Now every VPAT gets the same three questions before it goes in the procurement file.

IT accessibility coordinator, state government agency

What to Actually Require in a Procurement

The VPAT is a starting point, not an ending point. A credible accessibility procurement requires three things beyond the document itself.

First, a contractual accessibility warranty. The vendor warrants the product meets WCAG 2.1 AA at delivery and commits to a defined timeframe for fixing reported failures. "We'll address accessibility in a future release" is not a warranty.

Second, acceptance testing that includes accessibility. Before the contract is considered complete, your accessibility lead, or a contracted specialist, tests the deployed product against defined WCAG success criteria using both automated tools and real assistive technology. Failures found during acceptance testing are the vendor's obligation to fix, before final sign-off.

Third, a live demonstration during evaluation. Before shortlisting, ask every vendor to run their product for 10 minutes using only keyboard navigation and a screen reader. What you see in that demo is what a user with a disability experiences every day your agency runs the software.

Why the Agency Carries the Risk, Not the Vendor

Section 508 of the Rehabilitation Act requires federal agencies, and any organization receiving federal financial assistance, to ensure electronic and information technology is accessible. When an agency procures non-compliant technology, it isn't the vendor who faces the complaint. It's the agency. The remediation requirement falls on the agency. So does the reputational damage.

The VPAT review is your due diligence. Do it properly. The two hours it takes to review a VPAT and send follow-up questions is a small cost against the risk of deploying technology that generates complaints, forces remediation, and tells federal auditors your accessibility procurement process doesn't hold up.

What to Put in the RFP, Not Just the Contract

Most accessibility requirements show up too late, buried in contract boilerplate after the vendor is already selected. Put them in the RFP instead, where they can actually shape who responds and how.

• Require a VPAT no older than 12 months, matched to the exact product version being proposed.
• Require written responses to the three follow-up questions above as part of the technical proposal, not as a post-award formality.
• Score accessibility maturity as a weighted evaluation criterion, not a pass/fail gate that disappears once a vendor clears a minimum bar.
• Require a live keyboard and screen reader demonstration for any shortlisted vendor before final selection.
• Include a contractual remediation SLA: a defined number of business days to fix a reported Section 508 failure, tiered by severity.

One state agency we worked with added the live demonstration requirement to a search platform RFP and watched two of five shortlisted vendors quietly withdraw rather than demo. That's the requirement doing its job before the contract is even signed. The vendors who stayed submitted stronger VPATs the second time around, because they knew someone would actually check.

Request Keyspider's own VPAT, then ask us the three questions above. Book a demo and we'll answer them live.