This guide explains what a VPAT is, how it relates to WCAG and Section 508, how to read and evaluate one, and why it matters with the European Accessibility Act.
If you’ve ever gone through enterprise software procurement, you’ve probably been asked: “Do you have a VPAT?” We get this question regularly at Nutrient — from government agencies, from healthcare companies, from any organization that takes accessibility seriously. The acronym appears in RFPs, vendor questionnaires, and compliance checklists, but its meaning and implications aren’t always clear.
TL;DR
A Voluntary Product Accessibility Template (VPAT) is a standardized form vendors fill out to disclose how their product conforms to accessibility standards like Web Content Accessibility Guidelines (WCAG), Section 508, and EN 301 549. The completed document is called an Accessibility Conformance Report (ACR). This guide covers VPAT 2.5 editions, how to read and evaluate a VPAT, how vendors create one, and what to look for in document and PDF workflows.
A VPAT is a standardized document format created by the Information Technology Industry Council (ITI)(opens in a new tab) that technology vendors use to disclose how well their product conforms to accessibility standards.
The key word in the acronym is template. A VPAT is the blank form. Once a vendor fills it out — documenting how their product meets (or doesn’t meet) specific accessibility criteria — the completed document is called an Accessibility Conformance Report (ACR).
In practice, most people say VPAT when they mean either the template or the completed report. You’ll hear “send us your VPAT” in procurement conversations, even though what they’re really asking for is the ACR. This guide follows that common usage.
VPATs sit at the intersection of three different regulatory frameworks: U.S. federal procurement, broader U.S. accessibility law, and EU regulation. Each shapes how vendors are expected to disclose accessibility conformance.
In the United States, Section 508 of the Rehabilitation Act(opens in a new tab) requires federal agencies to buy information and communication technology (ICT) that’s accessible to people with disabilities. When a government agency evaluates software, it requests VPATs to verify that the product meets the accessibility standards referenced in Section 508 — specifically, the WCAG 2.0 Level AA success criteria.
This isn’t optional. If you sell software to the U.S. federal government, you need a VPAT. Increasingly, state and local governments apply the same requirement.
The Americans with Disabilities Act (ADA) doesn’t explicitly reference VPATs, but courts and regulators have increasingly interpreted it to require digital accessibility. Many private enterprises — particularly in healthcare, finance, and education — now request VPATs as part of their procurement process, even when there’s no direct government mandate. A VPAT demonstrates due diligence.
Since 28 June 2025, the European Accessibility Act(opens in a new tab) has required that a wide range of digital products and services sold in the EU meet the EN 301 549 accessibility standard. The VPAT 2.5 template includes an EU edition specifically designed to report against EN 301 549 — making it the de facto disclosure format for European compliance as well.
If your product serves EU customers, having a current VPAT is now a regulatory expectation.
The latest version of the VPAT template is VPAT 2.5(opens in a new tab), released by ITI. It comes in four editions, each mapping to a different standard:
Most enterprise vendors publish the INT edition, since it satisfies procurement requirements across all major markets.
A completed VPAT (ACR) lists every applicable accessibility success criterion and, for each one, reports:
The conformance levels are critical. Here’s what they mean:
| Level | Meaning |
|---|---|
| Supports | The product fully meets the criterion. No known deficiencies. |
| Partially Supports | Some aspects of the product meet the criterion; others don’t. |
| Does Not Support | The product does not meet the criterion. |
| Not Applicable | The criterion doesn’t apply to this product. |
| Not Evaluated | The criterion hasn’t been tested. |
Important: “Not Evaluated” is only permitted for Level AAA criteria. Level A and Level AA criteria must be assessed — leaving them as “Not Evaluated” is an error in the VPAT.
A credible VPAT will have a mix of “Supports” and “Partially Supports” entries. Be skeptical of a VPAT that claims “Supports” across the board — no complex software product is perfectly accessible in every dimension. Our own VPAT includes “Partially Supports” entries where we know there’s work to do, because that honesty is what makes the document useful.
Whether you’re in procurement, compliance, or engineering, here’s what to look for when reviewing a vendor’s VPAT.
A VPAT is a snapshot in time. Look for:
VPATs can be self-assessed by the vendor or completed by an independent accessibility firm. Neither is inherently better, but an independent review (from firms such as Level Access, Deque, or TPGi) adds a layer of credibility. Some vendors do both: self-assess first, then have an external firm validate.
You don’t need every criterion to say “Supports.” Focus on the ones that matter most for your use case:
The most valuable information in a VPAT is often in the remarks, not the conformance level. “Partially Supports” with a detailed explanation of what works and what’s being remediated tells you more than “Supports” with no detail. When we review third-party VPATs for components we’re evaluating for integration, the remarks column is where we spend most of our time.
If you’re on the vendor side — building software and needing to produce a VPAT — here’s how the process typically works. This five-step process is what accessibility firms refer to as a VPAT audit: a systematic evaluation of your product against each accessibility criterion. We’ve been through this cycle multiple times at Nutrient, and the biggest lesson is that it’s not a one-time project. Every major release triggers a reassessment.
Download the latest VPAT template from ITI’s website(opens in a new tab). Pick the edition that matches your market. For most enterprise software vendors, the INT (international) edition is the safest choice.
A VPAT covers a specific product (or product version) and specific features. Clearly define what’s in scope. For a complex product, this might mean:
For each success criterion in the template, test the product using a combination of:
For each criterion, record whether the product supports it, partially supports it, or doesn’t support it. In the remarks column, explain specifically what works, what doesn’t, and what your remediation timeline looks like for known gaps.
Have the completed ACR reviewed — ideally by someone who wasn’t involved in the testing. Publish it where procurement teams can find it. Some vendors put VPATs on a public accessibility page; others gate them behind a nondisclosure agreement (NDA), accessible only through a trust center.
Accessibility conformance gets particularly nuanced when your product handles documents — especially PDFs. This is the area we know best at Nutrient, and it’s where we’ve seen the widest gap between what vendors claim and what actually works with a screen reader.
PDFs are one of the most common document formats in enterprise workflows, but they’re also one of the hardest to make accessible. A PDF that looks fine visually may be unreadable to a screen reader if it lacks proper structural tags, reading order, and alternative text.
The accessibility standard for PDFs is PDF/UA (ISO 14289), which defines requirements for tagged PDF structure, alternative text, reading order, and more. WCAG success criteria also apply to PDF content when it’s delivered through a web interface.
If you’re evaluating a PDF SDK or document processing tool, the VPAT should address:
We maintain a VPAT 2.5 that covers Nutrient Web SDK and DWS API, available on request through our accessibility page. We treat it as a living document — not a checkbox we fill out once and forget.
The work that matters most isn’t the VPAT itself; it’s the engineering behind it. A few things we’ve invested heavily in:
We’re not done — accessibility is a moving target, and each release cycle surfaces new edge cases. But we’d rather be transparent about where we are than claim perfection.
You can explore the details in our Web Viewer SDK accessibility documentation or our broader PDF accessibility guide.
One of the most common points of confusion: VPAT and ACR are related but different.
| VPAT | ACR | |
|---|---|---|
| What it is | The blank template | The completed report |
| Who creates it | ITI (the standards body) | The software vendor |
| What it contains | Empty criteria and columns | Conformance levels, remarks, and evaluation details |
| What procurement teams actually want | — | The filled-out report — that’s what they want. |
When someone asks for your “VPAT,” they want the ACR. When someone says they’re “filling out a VPAT,” they’re creating an ACR. The industry uses the terms interchangeably, and that’s fine — just know the distinction if you’re talking to accessibility specialists.
A VPAT is the standard way technology vendors disclose accessibility conformance. What you do with it depends on which side of the procurement conversation you’re on:
A VPAT gives procurement teams a standardized way to compare accessibility conformance across vendors without running independent audits on every product they evaluate. In practice, it shows up in RFPs and vendor questionnaires as a gate: If you don’t have one, you’re often disqualified before the conversation starts — particularly for U.S. federal contracts, healthcare systems, and financial institutions. For vendors, it’s both a compliance document and a signal of how seriously you take accessibility.
Creating a VPAT is free if you self-assess — the template is available at no cost from ITI. If you hire an independent accessibility firm to conduct or validate the evaluation, costs typically range from $5,000 to $20,000 or more, depending on product complexity and the scope of testing required. Many vendors self-assess first and then bring in a third party to validate the results.
Not directly. No law mandates that vendors produce a VPAT. However, U.S. federal agencies require VPATs as part of Section 508 procurement, and many state governments and private enterprises follow the same practice. Without one, you’re effectively disqualified from those deals.
A VPAT is the blank template created by ITI. An Accessibility Conformance Report (ACR) is what you get when a vendor fills out that template for their product. In practice, most people use “VPAT” to mean both — but technically, what procurement teams request is the ACR.
At minimum, with every major product release. A VPAT older than 12–18 months may not reflect the current state of the product. If your product ships frequent updates, reassess at least annually.
You can self-assess. Many vendors do. However, having an independent accessibility firm (such as Level Access, Deque, or TPGi) conduct or validate the evaluation adds credibility — especially for enterprise and government procurement.
For most enterprise vendors, the INT (international) edition is the best choice. It covers WCAG, Section 508, and EN 301 549 in a single document, satisfying procurement requirements across the U.S. and EU.
It means some aspects of the product meet the criterion while others don’t. The remarks column should explain specifically what works, what doesn’t, and whether remediation is planned. A VPAT full of “Partially Supports” with detailed remarks is more trustworthy than one that claims “Supports” everywhere with no explanation.
Not automatically. The ADA doesn’t reference WCAG directly, but courts and regulators increasingly treat WCAG 2.1 Level AA as the benchmark for digital accessibility under the ADA. Meeting WCAG is strong evidence of due diligence, but it’s not a legal guarantee.
Yes. PDFs have their own accessibility standard — PDF/UA (ISO 14289) — which covers tagged structure, reading order, and alternative text. WCAG criteria also apply when PDFs are delivered through a web interface. If your product generates or displays PDFs, your VPAT should address PDF-specific accessibility.
Are you building accessible document workflows? Nutrient Web SDK ships with WCAG 2.2 AA support and a VPAT 2.5 available on request. Explore the accessibility features.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。