A VPAT, or Voluntary Product Accessibility Template, is a standardized document a vendor completes to describe how well a specific product or service conforms to accessibility standards like WCAG, Section 508 and EN 301 549, evaluated criterion by criterion. Enterprise, government and higher-education buyers commonly request one during procurement before purchasing software or digital services. Once filled out for a specific product, the completed document is technically called an Accessibility Conformance Report (ACR), though most people just call the whole thing a VPAT.
What’s actually in a VPAT
A VPAT is a long, structured table, not a short summary. It’s published and maintained by the Information Technology Industry Council (ITI), with editions covering different standards: a WCAG-only edition, a Section 508 edition, an EN 301 549 edition (for the EU), and a combined “INT” edition covering all three at once. For each individual success criterion, the vendor marks the product as Supports, Partially Supports, Does Not Support, or Not Applicable, and is expected to add specific remarks explaining that rating, ideally pointing to what was actually tested rather than an unexplained checkbox.
Why buyers ask for one
Enterprise and government procurement teams need to document that the software they’re buying meets legal accessibility requirements, particularly under Section 508 for U.S. federal purchases, similar state procurement rules, and EN 301 549 for EU public-sector and EAA-related purchases. A VPAT gives them that documentation without needing to run their own full independent audit of every vendor they evaluate. It also creates a paper trail: if a purchased product turns out to have significant accessibility gaps the VPAT didn’t disclose, the buying organization has a record of what the vendor claimed at the time of purchase.
VPATs and the standards behind them
A VPAT is only as meaningful as the standard it’s tested against and how rigorously that testing was actually done. The Section 508 edition maps to WCAG 2.0 A and AA, since that’s what the 2017 Section 508 refresh incorporated by reference. The EN 301 549 edition maps to that standard’s requirements, which as of version 3.2.1 fully incorporate WCAG 2.1 AA. Because of that shared WCAG foundation, a vendor that has done genuine WCAG 2.1 AA testing is generally well positioned to complete an accurate VPAT across all three editions without starting from scratch for each one.
Who produces VPATs
| Feature | Deque Systems | Allyant | UserWay |
|---|---|---|---|
| Approach | Enterprise accessibility testing and remediation company built around the open-source axe-core engine, sold as developer tooling (axe DevTools, axe Monitor, axe Auditor) plus expert manual audits and training, not a consumer widget. | Formed in 2022 by Thompson Street Capital Partners combining Accessible360, ReadSpeaker's document services and other accessibility businesses; focuses on enterprise document, PDF and publishing remediation alongside broader digital accessibility consulting, with an AI-assisted PDF remediation product launched in 2025. | AI-driven accessibility widget with an in-house automated remediation engine, sold mainly as a self-serve script install with tiered plans and a separate professional audit add-on. |
| Pricing | Enterprise quoted pricing by seats and scan volume; axe-core itself is free and open source. | Enterprise quoted engagements, typically scoped per document volume or project. | Freemium widget with paid tiers that unlock more automated checks; enterprise and professional audit services quoted separately. |
| Standards supported | WCAG 2.0, WCAG 2.1, WCAG 2.2, Section 508, EN 301 549 | WCAG 2.1, Section 508, PDF/UA, EN 301 549 | WCAG 2.1, ADA, Section 508, EN 301 549 |
| Best for | Engineering teams that want to test and fix code directly; Large enterprises needing audits, training and VPAT documentation | Enterprises and government agencies with large volumes of PDFs and documents to remediate | Very small sites wanting a no-cost starting point; Teams that want a widely recognized brand name |
Producing a credible VPAT depends on real testing behind it, which is why it’s often handled by vendors with dedicated audit expertise rather than done as a quick internal exercise. Deque Systems does expert-led manual audits and VPAT production as a core part of its enterprise consulting work, building on the axe-core testing engine it also maintains. Allyant works extensively with enterprise and government clients on document and broader digital accessibility, including the kind of detailed conformance documentation VPATs require. UserWay offers a professional manual audit and VPAT service as an add-on alongside its widget product, which is worth knowing about if you’re already using UserWay and need documentation for a specific enterprise sale.
Common mistakes when creating one
The most damaging mistake is having a VPAT completed based only on an automated scan rather than genuine manual testing; automated tools catch a meaningful subset of WCAG success criteria but can’t reliably evaluate everything a VPAT is supposed to certify, so a scan-only VPAT risks overstating conformance in ways that can surface later as a real problem, both reputationally and, in some circumstances, legally. A second common mistake is letting a VPAT go stale: it describes a product’s accessibility at a point in time, and a significant redesign or feature addition without a corresponding VPAT update leaves buyers relying on outdated information. Finally, vague remarks columns (“meets requirement” with no detail) undermine the document’s credibility; a buyer’s procurement or accessibility team will generally trust a VPAT more when the remarks are specific about what was tested and how.
Reading someone else’s VPAT as a buyer
If you’re on the buying side, evaluating a VPAT is a different skill from producing one. Look past the top-line summary and check the remarks column for specific criteria that matter to your use case, a “Partially Supports” rating on keyboard operability or form labeling deserves more attention than the same rating on something less central to how your users will actually interact with the product. Check the date the VPAT was completed and, if it’s more than a year or two old, ask whether the product has changed materially since then. And treat a VPAT with no remarks at all, just checkboxes with no explanation, as a signal to ask follow-up questions before relying on it for a purchasing decision, since the remarks are usually where the real substance of the assessment lives.
How VPATs fit into a broader compliance picture
A VPAT documents a single product’s conformance; it isn’t the same thing as your organization’s overall accessibility compliance, and having one for a piece of purchased software doesn’t automatically make everything you build on top of it accessible. A company that buys a well-documented, VPAT-backed platform can still build an inaccessible custom interface within it, so a VPAT is best treated as one input into procurement decisions and vendor risk assessment, not a substitute for testing your own final product, website or application once everything is assembled and configured for your specific use.
How long a VPAT process typically takes
For a small to mid-sized product, real conformance testing followed by producing a well-documented VPAT is not a same-week deliverable; expect it to take several weeks once you account for scheduling manual testing across the relevant success criteria, retesting anything that fails, and writing up specific remarks rather than generic pass or fail marks. Larger, more complex products with many interactive components or a broad feature surface take longer still. Building that timeline into a sales cycle or procurement deadline in advance avoids the common trap of trying to produce a rushed, thin VPAT under deadline pressure just to satisfy a buyer’s request, which tends to produce exactly the kind of unreliable, vague documentation that undermines buyer trust rather than earning it.
Plan the timeline into your product roadmap alongside major releases, not as a reaction to a single procurement deal that suddenly requires one. A VPAT produced calmly, on your own schedule, against a product you’ve already tested thoroughly, is a fundamentally different (and more trustworthy) document than one assembled hastily to close a deal, and buyers who review VPATs regularly can often tell the difference from the quality of the remarks alone.
If you need one for your product
Start by confirming which edition you actually need (WCAG-only, Section 508, EN 301 549 or the combined INT edition) based on who’s asking and what market you’re selling into. Then get real testing done against the relevant success criteria, either through an in-house accessibility specialist or an outside testing and audit vendor, before filling out the document itself. Treat the finished VPAT as a living document you’ll need to revisit after major product changes, not a one-time deliverable you file away once the initial sale closes.