What is a VPAT? The complete guide to accessibility conformance reports
Table of contents
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.
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.
VPAT meaning: What does VPAT stand for?
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.
Why VPATs matter: The legal and business context
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.
Section 508 and U.S. federal procurement
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 ADA and private sector
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.
The European Accessibility Act (EAA)
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.
VPAT template: What VPAT 2.5 covers
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:
- WCAG edition — Reports against the Web Content Accessibility Guidelines (currently WCAG 2.2)
- Section 508 edition — Reports against the Revised Section 508 Standards for U.S. federal procurement
- EU edition — Reports against the European ICT accessibility standard (EN 301 549)
- INT edition — A combined “international” edition that covers all three standards in one document
Most enterprise vendors publish the INT edition, since it satisfies procurement requirements across all major markets.
What’s inside a VPAT
A completed VPAT (ACR) lists every applicable accessibility success criterion and, for each one, reports:
- Conformance level — One of Supports, Partially Supports, Does Not Support, Not Applicable, or Not Evaluated
- Remarks and explanations — Specific details about how the product meets or falls short of the criterion, along with any relevant context
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.
How to read and evaluate a VPAT
Whether you’re in procurement, compliance, or engineering, here’s what to look for when reviewing a vendor’s VPAT.
Check the date and version
A VPAT is a snapshot in time. Look for:
- The VPAT template version — It should be 2.5 (or later). Older versions (2.4, 2.3) reference outdated standards.
- The evaluation date — If it’s more than 12–18 months old, the product may have changed significantly since the assessment.
- The product version tested — Make sure it matches the version you’re actually evaluating.
Look at who completed it
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.
Focus on your critical success criteria
You don’t need every criterion to say “Supports.” Focus on the ones that matter most for your use case:
- If your users rely on screen readers, prioritize WCAG criteria around text alternatives (1.1.1), meaningful sequence (1.3.2), keyboard accessibility (2.1.1), and name, role, value (4.1.2).
- If your product handles documents or forms, check criteria related to information and relationships (1.3.1, which covers form labels), error identification (3.3.1), and input purpose (1.3.5).
- For PDF-heavy workflows, look for conformance with the PDF/UA (ISO 14289) standard in addition to WCAG.
Read the remarks column
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.
VPAT testing: How vendors create an ACR
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.
Step 1: Choose the right VPAT template
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.
Step 2: Define the evaluation scope
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:
- The web application UI
- The API and its documentation
- Mobile apps (if applicable)
- Embedded viewers or editors
Step 3: Test against each criterion
For each success criterion in the template, test the product using a combination of:
- Automated testing — Tools such as axe, Lighthouse, or WAVE can automatically detect around 57 percent of accessibility issues by volume (according to Deque’s research(opens in a new tab)), covering common failures such as missing alt text, color contrast, and missing form labels. They cover fewer WCAG success criteria when counted individually, so automated testing alone is never sufficient.
- Manual testing — Keyboard navigation; screen reader testing with NonVisual Desktop Access (NVDA), Job Access With Speech (JAWS), or VoiceOver; and cognitive walkthroughs. This is essential for the issues automated tools can’t catch.
- Assistive technology testing — Test with the actual screen readers, magnifiers, and input devices your users rely on.
Step 4: Document conformance levels and remarks
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.
Step 5: Review and publish
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.
VPAT compliance for document and PDF workflows
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.
The PDF accessibility challenge
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.
What to look for in a document SDK’s VPAT
If you’re evaluating a PDF SDK or document processing tool, the VPAT should address:
- Screen reader support — Does the viewer render tagged PDFs as semantic HTML that screen readers can navigate?
- Keyboard navigation — Can users navigate pages, annotations, forms, and menus without a mouse?
- Form accessibility — Are form fields properly labeled, and do they announce errors to assistive technology?
- Annotation accessibility — Can comments, highlights, and markup be read by assistive technology?
- PDF/UA conformance — Does the SDK produce or process PDF/UA-compliant documents?
How we approach accessibility conformance at Nutrient
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:
- WCAG 2.2 AA support in the Web Viewer SDK — This isn’t a bolt-on. We test every release against NVDA, JAWS, and VoiceOver. Keyboard navigation works across pages, annotations, forms, and menus because we build for it from the start, not as an afterthought.
- Tagged PDF rendering — Our SDK converts PDF tags into their semantic HTML equivalents. This sounds straightforward, but getting it right for complex documents with nested tables, multicolumn layouts, and form fields took years of iteration.
- PDF/UA auto-tagging — Our Document Web Services (DWS) API can take an untagged PDF and convert it into a fully PDF/UA-compliant document. This matters because the majority of PDFs in the wild are untagged, and manually remediating them is prohibitively slow.
- Localization — Accessibility strings are localized for all built-in languages so that assistive technology can properly parse and announce content regardless of the user’s locale.
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.
ACR vs. VPAT: Clearing up the confusion
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.
Key takeaways
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:
- For evaluators — The most important things in a VPAT aren’t the conformance levels; they’re the remarks column and the date. A current VPAT 2.5 INT edition with honest “Partially Supports” entries and detailed remediation notes tells you far more than a suspiciously perfect one.
- For builders — Treat the VPAT as a living document that gets updated with every major release, not a one-time compliance checkbox.
- For integrators — Your product’s accessibility conformance includes every layer of the stack. Choose third-party components that ship with their own VPAT and build for accessibility by default.
FAQ
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.
