You asked a vendor for a VPAT. They sent back twelve pages. Row after row says "Supports." You have no idea what any of it actually means, and you're about to sign a six-figure contract based on a document you can't evaluate.
That's not a hypothetical. That's Tuesday for most procurement teams.
The Document Everyone Requests and Almost No One Reads Correctly
Picture a procurement manager at a mid-size healthcare company sourcing a new patient portal vendor. Legal flagged accessibility as a requirement, so procurement dutifully asked for a VPAT. The vendor sent one back — polished, professional, full of green "Supports" answers across dozens of WCAG criteria.
The procurement manager skimmed it, saw mostly checkmarks, and moved the vendor to the shortlist. Nobody on the team actually read the document row by row. Nobody asked how it was produced. Six months after rollout, screen reader users started filing complaints about a portal that, according to its own VPAT, "supported" keyboard access and screen reader compatibility.
This is the gap almost every organization falls into: treating a VPAT as a pass/fail certificate instead of what it actually is — a self-report that requires scrutiny.
First, Remember What a VPAT Actually Is
A VPAT (Voluntary Product Accessibility Template) is a standardized template. Once a vendor fills it out, the completed document is called an ACR — an Accessibility Conformance Report. For every relevant WCAG and Section 508 criterion, the vendor states one of four things: Supports, Partially Supports, Does Not Support, or Not Applicable, along with a Remarks and Explanations column where they're supposed to justify the answer.
That's the whole structure. It sounds simple. The complexity is entirely in how honestly and specifically that Remarks column gets filled out — and that's where your evaluation work actually needs to happen.
The One Fact That Changes How You Should Read Every VPAT
Here's the fact that should be stapled to the front of every VPAT your organization receives: a VPAT is self-reported by the vendor. By default, nobody independently verifies it. There's no auditor stamp, no third-party seal, no regulatory body checking the vendor's homework before it lands in your inbox.
That doesn't mean every VPAT is dishonest. Many vendors invest real effort in accurate self-assessment. But it does mean a document full of "Supports" checkmarks, on its own, proves nothing. The polish of the PDF has zero correlation with the accuracy of its claims.
The Stat: WebAIM's annual "WebAIM Million" evaluation of the top 1,000,000 home pages has repeatedly found the vast majority — in recent years around 95-96% — have detectable WCAG 2 failures, most commonly low-contrast text and missing alt text. If nearly every site on the web has accessibility gaps, a VPAT claiming near-universal "Supports" answers deserves a second look, not automatic trust. (WebAIM: The WebAIM Million)
What to Actually Look At: The Remarks Column, Not the Checkmarks
Most reviewers scan straight down the Supports/Does Not Support column, looking for a wall of green. That's the wrong place to focus. The highest-value thing you can do is read the Remarks and Explanations column, row by row, for the criteria that matter most to your use case.
Here's why. A vague remark like "meets requirement" attached to a genuinely complex criterion — say, 4.1.2 Name, Role, Value (which governs whether custom UI components expose the right information to assistive technology) or 2.1.1 Keyboard (full functionality operable without a mouse) — is a red flag. Those criteria are hard to fully satisfy, especially in a product with custom widgets, dropdowns, modals, or interactive dashboards. A one-line "meets requirement" answer on a criterion like that usually means nobody actually tested it in depth.
Compare that to a remark that says something specific: which components were tested, which assistive technology was used, what edge cases were found and how they were handled. Specificity is a positive signal. Vagueness, especially vagueness that repeats identically across dozens of unrelated rows, is a signal the whole document may have been filled out quickly rather than tested carefully.
Quick diagnostic: what the Remarks column is telling you
| Remarks column pattern | What it likely means | Your next move |
|---|---|---|
| Same generic phrase repeated across every row | Boilerplate, not testing | Ask how the VPAT was produced |
| Detailed, criterion-specific notes | Real testing likely occurred | Ask for the testing methodology/evidence |
| "Partially Supports" with a clear explanation | Honest, credible self-report | Ask for a remediation timeline |
| Blank or missing remarks on complex criteria | No verification happened | Treat as unverified until proven otherwise |
| All "Supports," no exceptions anywhere | Statistically unusual | Request an independent spot-check |
Check the Date and the WCAG Version Before You Read Anything Else
Before you evaluate a single row, check two things at the top of the document: the date the VPAT was completed, and which version of WCAG it was evaluated against — 2.0, 2.1, or 2.2. Each version adds new success criteria (2.1 added things like reflow and target size guidance; 2.2 added more), so a VPAT tested only against the older 2.0 baseline may be silent on criteria your current compliance target actually requires.
Recency matters just as much. A VPAT from two major product versions ago tells you what the product looked like then, not what it looks like today. Software changes fast — new features, new UI components, redesigned workflows — and none of that gets automatically reflected in a document that sits untouched in a sales folder. If the VPAT predates the product's last major release, ask for an updated one, or treat the existing document as historical context rather than current fact.
The Follow-Up Questions That Separate Serious Buyers from Checkbox Buyers
A strong VPAT review doesn't end at reading the document — it ends with a short list of pointed questions back to the vendor. Ask these three, every time:
- How was this VPAT produced? Internal engineering team, a third-party accessibility audit firm, or an automated scanning tool run once and exported? Each answer carries a very different confidence level.
- Can you show evidence of manual testing — specifically keyboard-only navigation and screen reader testing — rather than automated scanning alone? Automated tools are useful, but they can only catch a fraction of real WCAG failures; issues like illogical focus order, missing accessible names on custom components, or confusing screen reader announcements require a human tester.
- What's the remediation timeline for any "Partially Supports" or "Does Not Support" rows that touch your actual use case? A vendor who answers this clearly and specifically is telling you accessibility is a managed workstream, not an afterthought.
How a vendor responds to these three questions often tells you more than the VPAT itself. A defensive or evasive answer is its own data point.
Treat the VPAT as the Start of a Conversation, Not the End of One
The practical mindset shift procurement teams need: a VPAT is a starting point, not a final answer. It's a useful filter to eliminate vendors who haven't thought about accessibility at all. It is not, by itself, sufficient proof that a product will work for the disabled employees or customers who'll actually use it.
Do This / Not This: evaluating a vendor VPAT
| Not This | Do This |
|---|---|
| Scan the Supports column, count green checkmarks | Read the Remarks column row by row |
| Accept any VPAT regardless of its date | Check the date and WCAG version tested against |
| Assume "Supports" means independently verified | Assume self-reported until proven otherwise |
| Sign the contract on the VPAT alone | Ask how it was produced and what testing backed it |
| Skip verification for high-stakes deployments | Commission an independent spot-check for critical products |
For any product headed into a public-facing workflow or a high-stakes internal system, an independent spot-check of the actual product against the VPAT's own claims is the only way to know the document reflects reality. That's especially true given the broader landscape: roughly 1 in 4 U.S. adults live with some type of disability (CDC), and over 1 billion people worldwide — about 16% of the global population — live with some form of disability (World Health Organization). The stakes of getting this wrong aren't abstract; they're your actual user base.
Retail and ecommerce companies already know this the hard way — UsableNet's annual ADA Digital Accessibility Lawsuit Report has consistently found retail among the most-sued industries for web accessibility, alongside a steady stream of federal lawsuits and pre-suit demand letters tracked across recent years (UsableNet). A vendor's unverified VPAT isn't a legal shield. It's a document you're responsible for interpreting correctly.
Get a Second Set of Eyes on the VPAT Before You Sign
You don't have to become a WCAG expert to make a sound procurement decision — you just need someone who already is one to read the document with you. Before you finalize that vendor contract, get an independent VPAT review that tells you which "Supports" rows hold up and which ones need a harder conversation with the vendor.
Get an independent VPAT review before you sign off on a vendor.