A VPAT report is one of the most common documents requested when organizations buy software, web platforms, or digital services—especially in government, education, healthcare, and large enterprise procurement. But many teams receive a VPAT, file it away, and assume it “covers” accessibility. In reality, a VPAT is only as useful as the accuracy behind it and the way you apply it to real-world risk, user needs, and ongoing compliance work.
This article explains what a VPAT report is, what it should include, how to read it critically, and how it connects to standards like WCAG. You’ll also learn practical steps to validate VPAT claims and turn the document into an actionable accessibility plan.
VPAT stands for Voluntary Product Accessibility Template. It’s a standardized document format created to help vendors describe how their product meets accessibility requirements. The VPAT itself is the template; the completed document is often referred to as a “VPAT report,” “ACR,” or “accessibility conformance report.”
A VPAT is most commonly used to document conformance with:
If you’re still building your baseline understanding of WCAG, it helps to start with WCAG in Plain English: What It Really Means (and How to Use It), then come back to the VPAT to see how those requirements get documented in procurement language.
In practice:
Many teams use “VPAT report” as shorthand for the completed ACR. If you’re requesting documentation from a vendor, it’s fine to ask for a “VPAT (ACR) for WCAG 2.1 AA” to be precise.
A strong VPAT report isn’t just a grid of “Supports” checkmarks. It should provide enough detail for a buyer to understand the user impact, limitations, and what’s required to make the product work accessibly in real environments.
The report should clearly state which standard(s) it covers (e.g., WCAG 2.1 Level AA, Revised Section 508, EN 301 549) and which VPAT edition is used.
Look for details such as:
If your organization relies on mobile, a VPAT that only tests desktop web is incomplete for your needs. For mobile-specific expectations, align procurement questions with a checklist like WCAG Mobile App Checklist: A Practical Guide to Accessible iOS and Android Apps.
Most VPATs use ratings such as “Supports,” “Partially Supports,” “Does Not Support,” or “Not Applicable.” The key is the remarks and explanations. A credible VPAT explains:
Beware of vague statements like “Supports with exceptions” without describing the exceptions.
A VPAT is a starting point for risk evaluation—not proof. Use it to drive the right follow-up questions and testing.
If every criterion is marked “Supports,” that’s possible but uncommon for complex products. It may indicate the report wasn’t created through real testing. Ask how the vendor tested and request evidence, such as testing notes or an accessibility testing methodology summary.
A credible VPAT typically mentions:
A product can be “accessible” in general but fail in the workflows you care about. For example, a travel booking flow with date pickers and dynamic filters may introduce barriers that don’t appear on marketing pages. If your organization serves seasonal or high-volume consumer flows, design your validation around real scenarios similar to those discussed in Summer Travel Trends: Accessible Digital Experiences That Every Traveler Can Use.
The most practical approach is to confirm high-risk areas with manual testing plus automated monitoring. Tools like Corpowid (corpowid.ai) can help teams run automated accessibility audits and ongoing monitoring to flag issues that may contradict VPAT claims—especially regressions introduced after product updates.
Some criteria truly don’t apply (e.g., no video content means some captions criteria may be N/A). But “Not Applicable” is sometimes used as a shortcut to avoid testing. If the product has forms, modals, PDFs, or complex interactions, very little is truly N/A.
Good remarks explain what happens to users (e.g., “Screen reader users are not notified when validation errors appear”). Weak remarks are generic (“Meets requirement” or “Supported”).
Accessibility isn’t just the UI. Training materials, help docs, and customer support channels also matter. EN 301 549 and procurement expectations often include documentation requirements.
If your compliance program is aligning to newer requirements (like WCAG 2.2 or EU expectations), a VPAT that only references older baselines may leave gaps. For EU-focused programs, align VPAT review with regulatory context such as EAA Compliance Guide: How to Meet the European Accessibility Act with WCAG.
To reduce back-and-forth and get usable documentation, specify what you need up front:
If accessibility is business-critical (for example, regulated industries like utilities), incorporate these requirements into your procurement checklists and vendor scorecards so you can compare products consistently. Accessibility expectations can vary by sector; for a sector-specific view, see Digital Accessibility for Energy & Utilities Companies.
A VPAT shouldn’t be a one-time procurement artifact. Use it operationally:
Ongoing monitoring matters because product interfaces change constantly. Corpowid (corpowid.ai) can support continuous checks and help teams stay aware of new accessibility issues that appear over time, so the reality of your digital experience stays aligned with what the VPAT claims.
A VPAT report is a valuable tool for accessibility compliance, but it’s not a guarantee. The best results come from treating the VPAT as a transparency document: verify it, test what matters to your users, and build accountability into vendor management. When paired with WCAG-aligned audits and monitoring, a VPAT becomes more than paperwork—it becomes a practical roadmap toward inclusive, compliant digital experiences.
Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.
TR
