VPAT comes up in a specific, recognizable moment: late in a sales cycle, usually from procurement rather than the person you've been talking to for weeks. By the time the question arrives, most of the deal has already been discussed — pricing, integrations, timeline — and this is often the one requirement nobody on the vendor side saw coming.
It's worth understanding before that moment happens, not during it.
The two terms people mix up
VPAT (Voluntary Product Accessibility Template) is the blank form. ACR (Accessibility Conformance Report) is what you get once someone fills it in. In practice, most people say "VPAT" to mean both, and that's fine for everyday conversation — but the distinction matters the first time you're asked to "share your VPAT," because what a buyer actually wants is the completed report, not the empty template.
The template itself was created by the Information Technology Industry Council (ITI) as a standard structure vendors could use to document how a product measures up against recognized accessibility requirements — primarily WCAG, but also Section 508 (the U.S. federal standard) and EN 301 549 (the EU equivalent). Having one shared format means a buyer evaluating five different vendors can compare all five documents side by side, instead of five completely different write-ups in five different formats.
What's actually inside one
A completed VPAT works through a list of accessibility requirements one at a time, and for each one, assigns a rating:
- Supports — fully meets the requirement
- Partially Supports — meets it in some situations, not consistently
- Does Not Support — doesn't meet it
- Not Applicable — the requirement doesn't apply to this product
Each rating is expected to come with a short explanation, not just the label alone. "Partially Supports" on its own tells a buyer almost nothing; "Partially Supports — keyboard navigation works throughout except the date picker component, remediation scheduled for Q3" tells them exactly what they're getting and when it changes.
One thing worth understanding clearly: nobody checks your homework
A VPAT is self-reported. There's no accessibility inspector who reviews it, no government body that signs off, no certification that gets issued. The document is only as credible as the testing behind it — which is exactly why a rushed, superficial VPAT is often easy for an experienced buyer to spot. A conformance report with no "Partially Supports" or "Does Not Support" ratings anywhere in it tends to raise more suspicion than confidence, since real products almost always have at least a few honest gaps.
Why buyers started asking
Three things are pushing this, and they compound each other:
Legal exposure. Accessibility lawsuits have become a real, growing category of litigation, and increasingly they don't stop at a company's own public website — internal tools and third-party software a company purchased are being named too. If an organization buys a platform that turns out to be unusable with a screen reader, that risk doesn't stay with the vendor.
Procurement standardization. Large buyers — universities, government agencies, healthcare systems, enterprise IT departments — have simply added "accessibility documentation" as a standard line item in vendor evaluation, the same way security questionnaires became routine a decade earlier.
Genuine due diligence. Some buyers are asking because accessibility is a real requirement for their own users, not just a legal safeguard. A university buying software that students with disabilities will use has a direct, practical reason to check before committing.
What it actually takes to produce one
Filling out the form is the last step. Everything that makes the answers accurate happens before that:
- Testing the product with a keyboard only, no mouse
- Testing with at least one screen reader — commonly NVDA or JAWS on Windows, VoiceOver on Mac
- Measuring color contrast against WCAG's actual thresholds
- Reviewing the underlying HTML for correct heading structure and semantics
- Checking that ARIA attributes are used correctly, not just present
- Testing focus behavior inside modals, menus, and dynamic page changes
None of this is optional if the ratings are going to mean anything. A VPAT built from a five-minute automated scan and a guess at the rest is a real liability if a buyer ever tests the product themselves and finds the gap between the document and reality.
A small example of why this matters
Two form fields can look identical on screen — same label, same position, same styling — and behave completely differently for a screen reader user if only one of them has the label properly connected to the input in the markup. Automated scanners often can't tell the difference; a person testing with a screen reader immediately can. That gap is exactly what a real audit is built to catch before it ends up as an inaccurate "Supports" rating.
If you're the one being asked
A few things make this less painful the next time it comes up:
Don't wait for the request. Commissioning an accessibility audit before your first enterprise deal is on the table is far cheaper than doing it under deadline pressure once a deal is already stalled on it.
Keep it current. A VPAT written two product versions ago tells a buyer very little about the product they're actually evaluating. Experienced procurement teams know to ask when it was last updated.
Be honest about gaps. A credible remediation plan for known issues builds more trust than a document claiming everything works perfectly. Buyers who've seen a few of these know what a realistic one looks like.
Build it into normal QA, not a special event. Teams that check accessibility as part of everyday development find that producing an accurate VPAT becomes a matter of pulling together existing evidence, not starting from zero.
The underlying point of a VPAT isn't the document itself — it's what the document represents: whether accessibility was something the team actually checked, or something they're hoping nobody asks about too closely.