VPAT · SaaS · Procurement

What a VPAT Actually Signals to a SaaS Buyer (And What It Doesn't)

An oxblood and cream editorial illustration of a document with three status rows labeled Supports, Partially Supports, and Does Not Support, with a magnifying glass hovering over the middle row.
  • VPAT
  • SaaS
  • Procurement

A procurement lead who has never audited a line of code is handed a forty-page VPAT by a vendor mid-negotiation. Somewhere in it, a row reads "Supports with Exceptions" next to Success Criterion 2.1.1 Keyboard. The buyer has a real, practical question with no obvious answer on the page in front of them: does this mean the tool will actually work for the screen-reader-using employee it needs to work for, or does it mean something much smaller and much less reassuring?

This is the gap a VPAT does not close on its own, and understanding it is worth more to a buyer than reading the document cover to cover without knowing what to look for.

The Stat: A self-reported VPAT with no third-party evaluation is routinely rejected or flagged during federal and enterprise procurement review, because nothing in the document verifies the vendor's own claims. (Source: Section508.gov, ACR/VPAT FAQ)

A VPAT document with a magnifying glass over its middle status row A simple document shape containing three labeled rows: Supports, Partially Supports, and Does Not Support. A magnifying glass icon hovers over the middle row, representing closer scrutiny of ambiguous vendor claims. Supports Partially Supports Does Not Support

What a VPAT Actually Is

A VPAT, Voluntary Product Accessibility Template, is a standardized document format a vendor fills out to produce an Accessibility Conformance Report, or ACR. It walks through the relevant WCAG success criteria (and, for some editions, Section 508 and EN 301 549 requirements) and asks the vendor to self-report, for each one, whether their product Supports, Partially Supports, Does Not Support, or the criterion is Not Applicable. It is a real, useful, standardized format. It is also, in the vast majority of cases, entirely self-reported by the vendor, with no independent party verifying a single claim in it.

That is not a flaw in the format. The format was never designed to be an independent audit. It was designed to be a standardized way for a vendor to disclose what they know about their own product's accessibility, and a standardized way for buyers to compare disclosures across vendors. Treating it as proof of an outcome, rather than a structured disclosure of a claim, is the single most common way buyers get burned by a VPAT that looked reassuring on the page.

The Phrase Worth Reading Twice: "Supports With Exceptions"

This is the specific phrase that causes the most confusion, and it deserves direct attention. "Supports with Exceptions" (sometimes written "Partially Supports") means the vendor believes the criterion is substantially met, with some specific, named gaps. The value of the row lives entirely in whether those gaps are actually named specifically, in a remarks column, with concrete detail, versus left vague or blank.

A well-written VPAT will say something like: "Supports with Exceptions. The bulk product-import modal does not currently support keyboard-only operation; a remediation is scheduled for Q2." That is a specific, evaluable claim a buyer can act on, ask follow-up questions about, or accept as a known limitation. A VPAT that simply marks "Partially Supports" with no remarks at all is disclosing almost nothing, and should be read as a prompt to ask the vendor directly what specifically does not work, not as a status a buyer can quietly accept at face value.

The Question a VPAT Cannot Answer By Itself: Who Actually Tested This

A VPAT does not, by itself, tell a buyer whether the underlying testing was performed by an internal team with genuine accessibility expertise, an external specialist firm, or filled out by someone in marketing who copied a template from a similar product without running a single manual test. All three produce a document that looks identical on the page. The only way to close that gap is to ask directly: who performed the evaluation, what tools and manual testing methods were used, and when. A vendor confident in their own conformance work will answer this specifically and quickly. A vendor who cannot answer it, or answers vaguely, is effectively telling a buyer the same thing a blank remarks column does.

What to Actually Do With a VPAT as a Buyer

Three concrete steps turn a VPAT from a document a buyer skims and files away into one that actually informs a purchase decision. First, read every row marked anything other than a clean "Supports" and specifically check whether the remarks column names a concrete gap or is empty. Second, ask directly who performed the underlying testing and whether it involved real assistive technology, not just automated scanning. Third, if the tool will be used by an employee who relies on assistive technology, ask for a short guided walkthrough of that specific employee's core workflow with their actual assistive technology running, before signing, not after.

None of this requires the buyer to become an accessibility expert themselves. It requires treating a VPAT the way a careful buyer already treats any other vendor-supplied claim in a sales process: useful as a starting point for questions, not as a substitute for verification on the specific things that actually matter for this purchase.

A Short, Real Example of Reading a VPAT Row Correctly

Picture two vendors, both selling a similar project-management tool, both returning a VPAT with the same row: Success Criterion 1.4.3 Contrast (Minimum), marked "Partially Supports." Vendor A's remarks column says: "The secondary navigation sidebar uses a 3.8:1 contrast ratio against its background in the current release; a fix increasing this to 4.5:1 is scheduled for the next quarterly release, tracked as issue A11Y-204." Vendor B's remarks column is blank.

Both vendors are technically disclosing the same underlying fact: a known contrast gap somewhere in the product. Only one of them has given a buyer anything usable. Vendor A's answer lets a buyer decide whether that specific gap, in that specific part of the interface, on that specific timeline, is acceptable for their use case. Vendor B's answer forces the buyer to either accept an unknown risk or go back and ask the exact question the remarks column should have already answered. This is the pattern worth internalizing more than any specific WCAG criterion: the presence of a remark, and its specificity, tells a buyer more than the status label next to it ever will.

When "Not Applicable" Is Doing More Work Than It Should

One more pattern worth watching for: rows marked "Not Applicable" for criteria that plausibly should apply to the product being evaluated. A tool with any video content marking every media-related criterion "Not Applicable" is either genuinely free of any video anywhere in the product, which is worth confirming directly, or is using the label to skip evaluating something that does, in fact, apply. This is a smaller, quieter version of the same blank-remarks problem: a label that looks like a clean answer but is actually withholding the information a careful buyer needs.

This piece is written specifically for the buyer's seat at the table. If you are on the vendor side writing a VPAT rather than evaluating one, our guide to writing a VPAT or ACR walks through that process directly, and our broader VPAT buyer's guide covers the full vendor-evaluation workflow this piece zooms in on. If your organization is evaluating a specific vendor's VPAT right now and wants a second opinion, our team is reachable directly at experts@wcag.world, and you can see how our own accessibility work for SaaS teams is structured at our SaaS accessibility page. The official Section 508 ACR FAQ and ITIC's VPAT resource are both worth reading directly for the format's own documentation.