The first time a prospect asks "Can you send us your VPAT?" most B2B founders react one of two ways. Either they panic and forward the email to a developer, or they reply "What's a VPAT?" and lose the deal to a competitor who already had one ready. Neither is necessary. A VPAT is a template, not a certification, and any company can produce one if they understand the document, do the underlying accessibility work honestly, and resist the temptation to overstate what their product actually supports.
This guide explains what a VPAT is, what an ACR is, when you genuinely need one, when you don't, what it costs to produce a credible report, and the most common mistakes that turn a VPAT from a competitive advantage into a legal liability. None of this is legal advice; if you are about to publish a VPAT or sign a contract that references one, talk to an accessibility-experienced attorney for your jurisdiction.
VPAT vs ACR: the names matter
The Information Technology Industry Council (ITI) publishes the Voluntary Product Accessibility Template ("VPAT"), which is a blank document with a standard structure. When you fill out a VPAT with your product's actual conformance to accessibility standards, the completed document is called an Accessibility Conformance Report ("ACR"). In practice, almost everyone uses "VPAT" to mean both the template and the completed report, and procurement teams will accept either term. The technically correct phrasing is "we have a VPAT-format ACR for our product."
The current version of the VPAT is VPAT 2.5 Rev, published in 2024, and it covers four standards in a single template:
- WCAG 2.0, WCAG 2.1, and (in the most recent revisions) WCAG 2.2
- Section 508 (Revised 508 Standards from 2017, which are the US federal procurement requirements)
- EN 301 549 (the European harmonized standard referenced by the European Accessibility Act)
You don't have to fill out every section. The template comes in four editions: WCAG-only, 508-only, EN-only, and INT (international, which covers all three). Pick the edition that matches what your buyer is actually asking for.
Who actually needs a VPAT?
The honest answer is "fewer companies than you think, but more than was true five years ago." A VPAT is needed in three buyer contexts:
US federal government, state government, and public universities. Section 508 requires federal agencies to procure information and communication technology that conforms to specified accessibility standards, and most large state agencies and public universities have adopted similar requirements. If you sell software, training, content, or services to these buyers, expect a VPAT request as part of the standard procurement questionnaire.
European public sector and (increasingly) European enterprise. EN 301 549 is the EU's harmonized accessibility standard, and it is referenced by the European Accessibility Act (effective June 28, 2025) for many private-sector products and services as well. Public sector buyers in the EU have required EN 301 549 conformance evidence for years, and enterprise procurement teams are increasingly catching up.
Enterprise buyers in regulated industries. Banks, insurance companies, healthcare providers, and other organizations subject to ADA Title III obligations or sector-specific accessibility rules have started asking vendors for VPATs as part of risk management. They want documentation that the tools they buy will not create new accessibility barriers for their employees or customers.
If you only sell to small businesses, individual professionals, or consumers, you almost certainly do not need a VPAT today. You still need to make your product accessible (the EAA, ADA, AODA, and other laws apply directly to you regardless of whether anyone asks for a VPAT), but you don't need the formal report.
What a VPAT is not
A VPAT is not a certification. No third party signs off on a VPAT. The vendor (you) writes the report and stands behind it. This is why a VPAT prepared by an accessibility consultant has more credibility than one written internally by a sales engineer with no accessibility background. The signature line says "prepared by," not "certified by."
A VPAT is not a guarantee of legal compliance. It documents your product's conformance to specific success criteria at a moment in time. It is evidence of effort, not a defense against a lawsuit. A plaintiff can still allege that your product violates the ADA, AODA, or EAA regardless of what your VPAT says.
A VPAT is not a one-time deliverable. If your product changes (which it does, constantly), the VPAT becomes stale. Most buyers expect the VPAT to be updated at least annually, and some procurement contracts require notification when material accessibility regressions are introduced.
A VPAT is not the same as an audit. A VPAT is the report. An audit is the underlying work that makes the report credible. If you fill out a VPAT without actually testing your product against each WCAG success criterion, you are guessing, and a sophisticated buyer will catch you.
The four conformance levels you'll see in a VPAT
For each WCAG success criterion (or each Section 508 / EN 301 549 requirement), the VPAT asks you to mark conformance using one of these terms:
- Supports: The product fully meets the criterion. Use this only when you have actually tested and the result is conformant.
- Partially Supports: Most of the product meets the criterion, but there are exceptions. You must describe the exceptions in the Remarks column.
- Does Not Support: The product does not meet the criterion. You must describe the gap.
- Not Applicable: The criterion does not apply to your product (for example, audio description criteria do not apply to a product that contains no audio).
- Not Evaluated (Level AAA only): You did not test against this criterion.
The single most common mistake on bad VPATs is marking everything as "Supports" without doing the testing. A buyer who has done a few procurement reviews will spot this immediately, because no real product fully supports every WCAG criterion. A credible VPAT will have a mix of Supports, Partially Supports, and Does Not Support, with honest Remarks that describe the gaps and any planned remediation.
What it actually costs to produce a credible VPAT
The cost depends on the size of your product, the experience of the team doing the work, and how much accessibility work you have already done. As a rough industry range:
- Internal VPAT, small SaaS product, with prior accessibility testing: 20-60 hours of senior engineer time. Often $5,000-$15,000 in opportunity cost.
- Consultant-prepared VPAT, small to mid-size product: $5,000-$25,000, including the underlying audit work needed to produce credible Remarks.
- Consultant-prepared VPAT, large enterprise product: $25,000-$100,000+, including manual testing across multiple browser and assistive technology combinations, screen-reader walkthroughs, and detailed remediation planning.
The cheapest VPATs you can buy on the open market are usually $1,500-$3,000 and consist of a consultant filling out the template based on a brief automated scan. These are worth almost nothing - they will fail any sophisticated procurement review, and they expose you to legal risk because they assert conformance you have not actually verified.
A realistic VPAT workflow for a B2B SaaS company
If you are a small or mid-size SaaS company facing your first VPAT request, here is the workflow that usually works:
Pick the edition that matches the buyer's question. If a US federal agency asks, use the 508 or INT edition. If a European public-sector buyer asks, use the EN or INT edition. If a US enterprise asks for a "WCAG VPAT," the WCAG edition is fine.
Run an honest audit first. Either hire a third-party accessibility consultant to do a manual audit of your product against WCAG 2.2 Level AA (most VPAT requests now ask for 2.2), or have a senior engineer with documented accessibility training do the same work. Automated scans alone are not sufficient - they catch about 30-40% of WCAG failures, and the most expensive failures (keyboard traps, missing labels, broken focus management) are mostly in the part automated tools miss.
Document gaps in the Remarks column. A VPAT that says "Partially Supports" with a Remark like "Custom date picker does not announce selected date to screen readers; remediation planned for Q3 2026" is far more credible than a VPAT that says "Supports" for everything.
Get sign-off from someone who could be deposed. The signature line on a VPAT is not theoretical. If a customer sues over an accessibility issue you marked as "Supports" without testing, your signed VPAT becomes evidence in the case. Make sure the person signing has actually reviewed the underlying audit.
Publish the VPAT or share it on request. Some companies publish their VPAT on a public accessibility page (alongside their accessibility statement). Others share it only on request under NDA. Both are acceptable; the choice usually depends on whether the VPAT exposes details about your product roadmap.
Re-audit and re-publish at least annually. Every major release should include an accessibility regression check, and the VPAT should be updated whenever you find a material change in conformance.
Common mistakes that hurt deals (or cause lawsuits)
A few patterns turn up over and over in failing or risky VPATs:
- Marking everything as Supports. Already covered, but worth repeating. This is the single biggest red flag.
- Mixing up product editions. A VPAT for "Acme SaaS" is meaningless if Acme SaaS has a free tier, a Pro tier, and a mobile app, each with different accessibility behavior. Specify which edition the VPAT covers.
- Citing automated scan results as if they were conformance evidence. Automated tools give you a starting point, not a conformance claim.
- Forgetting third-party components. If your product embeds Stripe Checkout, a Calendly widget, an Intercom chat, or a video player, the accessibility of those components affects your VPAT. Either test them, document their conformance separately, or note the gap.
- Using a stale template. VPAT 1.x and 2.0 are out of date. If a procurement team receives a VPAT 1.3 in 2026, they will ask for a current one and your sale slows down.
- Treating the VPAT as a marketing document. A VPAT that reads like marketing copy is suspicious. A VPAT that reads like a technical compliance document is reassuring.
How a VPAT relates to your accessibility statement
An accessibility statement is a short, public-facing page on your website that describes your conformance target, your approach to accessibility, known limitations, and how users can request help or report issues. The European Accessibility Act and the 2024 DOJ Title II rule both expect public-facing organizations to publish one.
A VPAT/ACR is a longer, technical document used in procurement that documents conformance criterion-by-criterion against a specific standard.
Both should agree with each other. If your accessibility statement says you target WCAG 2.2 Level AA and your VPAT says you do not yet support several Level A criteria, you have a credibility problem. The fix is to update both documents at the same time: scope the accessibility statement to known conformance, list the gaps, and produce a VPAT that matches.
When a VPAT is the wrong tool
Not every accessibility question deserves a VPAT response. If a customer asks "Is your product accessible?", the right answer is usually a brief description of your accessibility commitments and a link to your public accessibility statement. Sending an unsolicited 40-page VPAT to a small business buyer is overkill and can actually slow the deal down. Save the VPAT for procurement teams that specifically ask for one.
If the buyer is asking because they have a specific user with a specific assistive technology need, a focused conversation about that user's workflow is far more useful than a generic VPAT. "Can a JAWS user complete the entire onboarding flow without help?" is a question your VPAT should answer in a Remark, but the buyer may want a live walkthrough as well.
The honest bottom line
A VPAT is a credibility tool, not a compliance tool. It does not make your product accessible. It documents the accessibility work you have already done. The fastest way to produce a useful VPAT is to make your product genuinely conformant to WCAG 2.2 Level AA, hire a qualified consultant or train a senior engineer to do the audit, fill out the template honestly, and update it on every major release.
The fastest way to produce a harmful VPAT is to mark everything as Supports without testing, send it to a procurement team that knows what they are looking at, and lose the deal. Or worse, win the deal and then face a lawsuit when the buyer's users hit the accessibility issues your VPAT claimed didn't exist.
If you are starting from zero, the highest-leverage steps are: (1) commission a manual WCAG 2.2 Level AA audit of your most-used flows, (2) fix the high-impact issues, (3) publish an accurate accessibility statement, and (4) prepare a VPAT that matches. Skipping the first three and producing a VPAT in isolation is the worst-case path.
We're building a simple accessibility checker for non-developers -- no DevTools, no jargon. Join our waitlist to get early access.