What Is a VPAT and Why Do Companies Ask for It?

Jamil HussainPosted on October 2, 2026

9-10 Min Read TimeAdd as preferred on Google

Understanding the accessibility document that software procurement teams now routinely require.

"Can you share your latest VPAT?"

The demo had gone well. Pricing was approved and legal had signed off on the contract. The implementation team was already sketching a rollout plan. Then someone from procurement asked one more question, and the deal stopped: “Can you share your latest VPAT?”

Many software companies hear the term for the first time at this point. Product managers start searching for it. Engineers assume it’s one more compliance checklist, and the sales team worries the deal is about to stall. The question is now routine, because accessibility has become a standard part of enterprise procurement.

A VPAT lets a buyer evaluate how accessible a product is before committing budget to it. It also shows that the vendor took the time to assess accessibility deliberately.

What Exactly Is a VPAT?

VPAT stands for Voluntary Product Accessibility Template. The Information Technology Industry Council (ITI) created it as a standard way to document how a digital product measures up against recognized accessibility standards. The main ones are the Web Content Accessibility Guidelines (WCAG), Section 508 of the Rehabilitation Act and EN 301 549, the EU’s accessibility standard.

Once filled in, the template is formally called an Accessibility Conformance Report (ACR). People often mistake it for a certificate, a seal of approval or a government sign-off, but no external body audits or stamps a VPAT. The vendor discloses its own results and backs each one with evidence. In practice, an accessibility specialist hired by the vendor works through the product criterion by criterion, rates it against each requirement and explains every rating in plain language.

Each criterion gets one of four conformance levels:

The template comes in several editions, one for each standard a buyer might care about. There is a WCAG edition, a Revised Section 508 edition for U.S. federal buyers, an EU edition (EN 301 549) and an International edition that combines all three. Most vendors selling into the U.S. market complete the International edition, since one document then covers the widest range of buyers.

Why Do Companies Ask for a VPAT?

Accessibility used to be a “nice to have.” In a growing number of industries, it is now a condition for getting through procurement. Government agencies, universities, healthcare systems and large enterprises increasingly won’t move a vendor past legal review without a VPAT.

Legal pressure drives much of this. Digital accessibility litigation in the U.S. has grown substantially over the past decade, with well over 5,000 web and app accessibility lawsuits filed in federal and state courts in 2025 alone. Plaintiffs increasingly target the internal software organizations rely on, along with their public-facing websites. If a hospital system or a university licenses a product that turns out to be unusable with a screen reader, the buyer shares the liability with the vendor. Asking for a VPAT before signing is largely how procurement teams manage that exposure.
 

Litigation risk aside, a VPAT gives procurement teams a consistent way to compare products and flag likely accommodation costs early. It also holds vendors accountable for specific claims that can be checked, which is hard to do with marketing copy. For the vendor, a well-prepared VPAT builds credibility because it shows the buyer that the product was tested for accessibility.

What Actually Goes Into Creating a VPAT

Filling out the template comes last. Before anyone assigns a conformance rating, an accessibility specialist has to test the product, and real testing goes well beyond running a browser plugin or an automated scanner.

A typical audit includes:

• Keyboard-only navigation testing, with no mouse at any point
• Screen reader testing across at least two tools, typically NVDA or JAWS on Windows and VoiceOver on macOS/iOS
• Color contrast checks against WCAG’s thresholds of 4.5:1 for normal text and 3:1 for large text and UI components
• Semantic HTML and heading structure review
• ARIA validation, confirming that roles, states and properties are present and used correctly
• Focus management testing, especially inside modals, menus and single-page-app route changes
• Testing of forms, data tables and multimedia, including captions, transcripts and audio description

Each finding is mapped to a specific WCAG success criterion and documented with reproduction steps and evidence such as screenshots, screen reader transcripts and code excerpts. The finding is then reviewed before it rolls up into a conformance rating.

A Concrete Example: Why “Looks Fine” Isn’t Good Enough

Consider two login fields that render identically in a browser.
 

<label for="email">Email Address</label>
<input id="email" type="email">

<span>Email Address</span>
<input type="email">

Only the first one programmatically ties the label to the input through the for/id relationship. A screen reader user who tabs into that field hears “Email Address, edit text.” On the second field, most screen readers announce only “edit text,” so the user has no way to know what to type. An auditor logs this against WCAG 2.1 Success Criterion 1.3.1 (Info and Relationships). The rating is “Does Not Support” or “Partially Supports” depending on how widespread the pattern is, and the exact markup and screen reader output go into the report as evidence.

Dynamic content has the same kind of gap. Suppose a form shows a validation error by injecting text into the DOM with no aria-live region. A screen reader user won’t know the error exists until they happen to tab past it. Adding role="alert" or aria-live="assertive" to the error container is a one-line fix, and it moves the rating on WCAG 4.1.3 (Status Messages) from “Does Not Support” to “Supports.” A VPAT audit is designed to catch small differences like this, which anyone testing by eye alone will miss.

Common VPAT Myths

How to Prepare Before Someone Asks

Starting the first accessibility review only after a procurement request arrives is the expensive route. A few steps are worth taking well in advance:

• Run an internal accessibility audit before the first enterprise deal. Retrofitting a product after launch consistently costs more than building the checks in from the start.
• Keep the VPAT current. A report written two major releases ago tells a buyer almost nothing about the product they’re evaluating today, and experienced procurement teams will ask when it was last updated.
• Report “Partially Supports” and “Does Not Support” ratings honestly. Seasoned buyers treat a suspiciously all-green VPAT as a red flag. Every real product has gaps, and a credible plan for closing them earns more trust than a claim of perfection.
• Make accessibility part of the definition of done. When WCAG checks are a normal part of QA, the VPAT comes out almost as a byproduct. Teams that skip this end up scrambling to document a product that was never tested.

Final Thoughts

A VPAT shows that an organization is willing to be open about where its product stands, and by extension, that it is committed to inclusive design. Customers want reliable information that helps them understand what they’re buying, and few of them expect the software to be perfect.

Organizations that build accessibility into design, development, testing and QA usually find that the VPAT follows naturally from how they already work. A procurement email doesn’t send them scrambling. Their products also reach a wider audience and work better for everyone, which earns more trust from the customers who use them.

So when a customer asks for your VPAT, treat the request as a chance to show that accessibility is part of your product’s quality and your organization’s values.