The first time a startup gets asked for a VPAT, it usually comes from one person: a solutions engineer on the other side of a sales call, checking a box before a pilot. The document gets a skim, maybe a follow-up question about a screen reader, and the deal moves on.
Enterprise RFPs do not work that way. The same VPAT that satisfied a mid-market buyer gets forwarded to legal, who reads it for exposure. It goes to procurement, who reads it for whether the vendor actually understands what they submitted. It goes to a security or IT accessibility reviewer, who reads it looking for the gap between what the document claims and what a five-minute test of the product would reveal. Three audiences, three sets of questions, one document that has to hold up under all of them at once.
That is the gap that sinks otherwise-good vendors. Not a lack of accessibility work. A VPAT written for a skim instead of a review.
The Stat: IAAP (the International Association of Accessibility Professionals) offers three real, recognized credentials: CPACC, WAS, and CPWA. (Source: IAAP)
Why the same document gets read three different ways
An enterprise procurement process rarely has one gatekeeper. By the time a VPAT reaches a signature, it has usually passed through legal, security or IT, and the business owner who wants the tool. Each reads it for something different, and a VPAT written to satisfy only one of them tends to fail the other two.
Legal is reading for risk. They are not evaluating whether your product is genuinely usable with a screen reader. They are checking whether the document is specific enough to be relied on, and vague enough claims read as a liability rather than a reassurance. A VPAT that says "supports assistive technology" without qualification tells legal nothing they can act on, and unspecific claims are harder to defend than honest gaps.
Procurement is reading for process maturity. Their real question is not "is this product accessible today," it's "does this vendor have a real program behind this document, or did someone fill out a template once and never look at it again." A dated document, a named point of contact, and evidence of periodic review answer that question. A VPAT with no date and no named author does not.
IT or the internal accessibility reviewer, where one exists, is reading for correctness. They may spot-check a handful of criteria against the actual product. This is the audience most likely to catch a mismatch between what the ACR claims and what a real user encounters, and it is the audience a rushed or copy-pasted VPAT is most likely to fail in front of.
The four things that separate a real VPAT from a checkbox one
Every enterprise review, regardless of which stakeholder is doing it, tends to converge on the same four things. Get these right and the document tends to survive scrutiny from all three audiences at once.
1. Testing methodology disclosed, not just a scorecard
A results table with no explanation of how the results were produced is the fastest way to lose credibility with a technical reviewer. Did the vendor test with automated tooling alone, manual keyboard and screen reader testing, or both? Which assistive technologies and browser combinations were covered? A methodology section does not need to be long, but it needs to exist, and it needs to be specific enough that a reviewer could, in principle, attempt to reproduce the testing themselves.
2. Conformance level assigned per criterion, not one blanket score
"Supports" or "partially supports" marked against every single WCAG success criterion, with identical remarks copied down the column, is one of the clearest signs a VPAT was filled out from memory rather than from actual testing. Enterprise reviewers who have seen enough of these documents recognize the pattern instantly. Each criterion should reflect a distinct, considered judgment, even if a large share of them end up "supports." Uniform answers read as unverified answers.
3. A dated remediation roadmap for known gaps
No real product is at perfect conformance across every criterion, and claiming otherwise is itself a red flag. What separates a trustworthy VPAT is not the absence of gaps, it's that the gaps are named, dated, and tied to a plan. "Known issue: X does not support Y, remediation targeted for [quarter]" tells a legal or procurement reviewer that the vendor is actively managing the gap rather than hoping no one notices it. This single addition often does more to build trust than a document with fewer disclosed issues and no roadmap at all.
4. Named accessibility ownership on the vendor team
Enterprise buyers want to know who owns this if a problem surfaces after signature. A generic "accessibility@company.com" is a reasonable minimum, but a named role, even without a named individual (an "Accessibility Program Lead" title, for example), signals that this is a standing responsibility inside the organization rather than a one-time task someone finished before a sales call. It is a small detail that carries outsized weight in a legal review, because it answers the question "who do we escalate to" before anyone has to ask it.
What this looks like from the vendor side
If you are the one preparing the document rather than reviewing one, credentialed expertise matters more at enterprise scale, since a reviewer who has done this before will notice if the person who ran your testing understands the standard. Certifications like the ones tracked by the International Association of Accessibility Professionals are one signal reviewers sometimes look for when they are trying to gauge whether a VPAT reflects genuine expertise. Our own experience preparing these documents for enterprise-bound vendors is that the deals which move fastest through legal review are consistently the ones where the vendor treated the VPAT as a serious artifact from the start, not a form to be filled in the week before a demo.
It also helps to frame the whole exercise around what accessibility work is actually for. The W3C's business case for digital accessibility is a useful reference to have on hand when a business stakeholder on your own side asks why any of this matters beyond compliance. And if your buyer is a government agency or a contractor to one, familiarity with Section508.gov and its procurement-specific guidance will save you a round of clarifying emails.
If you have never produced one of these documents and want the mechanics of writing one, our companion piece on how to write a VPAT or ACR walks through the process from the vendor's side. If you are earlier in your own evaluation and want a plain-language walkthrough of VPAT terminology before you get to the enterprise-specific stakes covered here, start with how to read a VPAT as a first-time buyer. And if you are building a broader vendor evaluation process rather than reviewing a single document, our vendor evaluation guide covers how to weigh accessibility alongside the rest of a procurement scorecard.
Getting it right before the RFP lands
None of this requires perfection. It requires a document that reads as honest, specific, and owned by someone. That is a lower bar than most vendors assume, and a higher bar than most VPATs actually clear.
If you are preparing for an enterprise sales cycle and want a VPAT that holds up once it reaches legal, our enterprise SaaS accessibility solutions are built around exactly this kind of review-ready documentation.
When you are ready to talk specifics, reach a real person on our team at experts@wcag.world, or visit our enterprise SaaS solutions page to see how we help vendors get their VPAT enterprise-ready before it ever reaches a procurement desk.