VPAT (Voluntary Product Accessibility Template)

Two words get used interchangeably and they are not the same thing.

The VPAT is the blank form. It is published by the Information Technology Industry Council, a Washington trade association, and it is free to download. ITI describes it as a template that translates accessibility requirements and standards into actionable testing criteria. Nothing more: it is a structured questionnaire with a row per success criterion.

The Accessibility Conformance Report, or ACR, is what you get when a vendor fills that form in for a specific product at a specific version. Section508.gov defines an ACR as a document that explains how information and communication technology products such as software, hardware, electronic content and support documentation conform to the Revised 508 Standards.

So a buyer who asks for "your VPAT" is asking for your ACR. Nobody in procurement will correct you on this, and the ITI form itself is titled as an Accessibility Conformance Report, which is why the two terms collapsed together in practice.

One naming rule that does matter legally: VPAT is an ITI registered service mark. ITI states that the VPAT name and report form should not be altered without its express written permission. You can use the form as published and you should not rebuild it into your own branded variant and keep calling it a VPAT.

There is also a second route worth knowing about, because it is free and machine readable and most vendors have never heard of it. The GSA publishes the OpenACR Editor at acreditor.section508.gov, which produces an ACR in a structured format rather than a Word document. If you have ever tried to diff two versions of a fifty page Word table to see what changed between product releases, the appeal is obvious.

ITI publishes the current form as VPAT 2.5Rev, dated April 2025, in four editions. Downloading the wrong one is the most common wasted afternoon in this whole exercise, because the tables differ and a buyer will notice.

• VPAT 2.5 508 covers the Revised Section 508 standards, the US federal accessibility standard. This is the one you want if you are selling to a US federal agency.
• VPAT 2.5 WCAG covers WCAG 2.0, 2.1 and 2.2 only. Use it for commercial US buyers, universities, health systems and state agencies whose contract names WCAG rather than 508.
• VPAT 2.5 EU covers EN 301 549, the European procurement standard.
• VPAT 2.5 INT is the international edition and incorporates all three of the above. It is the longest form by a distance and the right choice only if you genuinely sell into all of those markets.

For a US software vendor the practical answer is usually 508 or WCAG, and if you are unsure which, ask the buyer which standard their solicitation names. It will be in the document.

A version note that catches people out: if you produced an ACR against the original 2001 Section 508 standards, Section508.gov states you must update it using the Revised Section 508 Standards published in 2017. A report against the 2001 standard is not merely old, it is scored against requirements that no longer apply.

Only Level A and Level AA are required in an ACR intended to inform US federal procurement. Level AAA rows exist in the WCAG edition and you are not obliged to complete them. Filling them in anyway is a reasonable competitive choice if you do well on them, and an expensive way to advertise gaps if you do not.

Not by statute, and yes in practice. The distinction is worth understanding because vendors regularly talk themselves out of producing one on a technicality.

No US law says "every software vendor must publish a VPAT". What the law does is bind the buyer. Section 508 requires federal agencies to procure accessible information and communication technology, which pushes the requirement down into every solicitation they issue. Section508.gov puts the consequence about as bluntly as a government website ever does: "it is not voluntary to complete an ACR if you wish the government to consider purchasing your product."

The pressure does not stop at federal. State procurement offices, public universities, school districts and health systems routinely request an ACR, and increasingly so do large private enterprises whose own accessibility programs require it of their suppliers. ADA Title II adds a separate stream: state and local government entities now have a fixed WCAG 2.1 Level AA deadline for web content and conventional electronic documents, and their duty flows into their vendor contracts. Those deadlines moved in 2026, and our accessible PDF generation page carries the current dates read from ada.gov.

The realistic way to think about it: a VPAT is not a legal obligation, it is a sales prerequisite. The cost of not having one is not a penalty, it is being screened out of a bid before anyone reads your pricing. If you are weighing an internal self-assessment against hiring a third party, the section on what VPAT services cost, further down this page, compares what the vendors who publish a rate actually charge.

Anyone can fill in the form. There is no accreditation, no licensing body, and no government approval step. Nobody stamps your ACR.

ITI recommends the manufacturer do the testing, stating that the Original Equipment Manufacturer is likely the best source to conduct the testing necessary to complete the VPAT. That is sound: you know your product, its configurations and its edge cases better than a contractor reading your documentation for a week.

Section508.gov describes ACR authors as organizations that develop or provide ICT products or services to federal agencies, including commercial companies and contractors. It also settles a question that comes up constantly with embedded components: "You are responsible for completing an ACR for the product you developed." If your application embeds a third party PDF viewer or charting library, that vendor is responsible for their ACR and you are responsible for yours, including for how your product uses theirs.

So a self-assessment is legitimate and it is the norm. What a self-assessment does not do is protect you from the consequences of being wrong. An ACR is a vendor claim that a buyer relies on, and an inaccurate one is a misrepresentation in a procurement process, not a paperwork error. The rational middle path most serious vendors take is to test and write the report internally, then have someone with accessibility expertise review it before it goes out. That is much cheaper than a full third party audit, where the ADA compliance audit cost published by the two providers that publish anything runs from $500 for a narrow evaluation to $7,000 for a large interactive site, and it catches the confident wrong answers, which are the dangerous ones.

A wording note that tells you how carefully these terms were chosen: ITI records that Partially Supports replaced the earlier phrase "supports with exceptions" at the request of the US Access Board. The old phrasing let vendors bury real gaps in a footnote. The new one puts the gap in the rating column where a buyer sorting fifty reports will see it.

The other thing that makes a report credible is what goes in the Remarks and Explanations column. Section508.gov guidance is explicit that where a product Partially Supports or Does Not Support a criterion, you should explain how the standard is not met. A report that is all Supports with empty remarks reads as untested to anyone who has evaluated more than a handful, and evaluators do read these comparatively. A report with candid Partially Supports rows and specific, informed remarks reads as a vendor who actually did the work.

Here is the gap that this page exists for, and it is a large one.

Almost every VPAT walkthrough treats the product as a user interface. Teams test their web app carefully, get their screens into good shape, and complete the tables honestly. Then the product generates a PDF invoice, a monthly statement, an exported report, a permit, a benefits letter, and that file is never tested at all.

Under the Revised 508 Standards this is not an oversight you can wave away. Section508.gov guidance names Electronic Documents as one of the product categories that requires evaluation against the WCAG tables, alongside Web Content, Software and Authoring Tool. Your generated PDFs are electronic documents produced by your product. They belong in the same report.

Two consequences follow, and they pull in opposite directions.

The uncomfortable one: if your product emits untagged PDFs, several Level A rows in your ACR are not Supports. 1.3.1 and 1.3.2 in particular are difficult to claim with a straight face for an untagged file, because there is no structure and no defined reading order in the document at all. Writing Supports anyway is exactly the kind of claim a buyer with an accessibility team will test.

The encouraging one: generated documents are the cheapest accessibility problem you will ever have. A remediation team fixing existing PDFs works file by file forever. You have one template and one render configuration, and fixing them corrects every document your system will ever produce, including all the ones that do not exist yet. Very little else in an accessibility program has that shape.

The practical sequence is short. Put real semantic structure in the template: heading levels in order, real lists, tables with th and scope, alt text on meaningful images and empty alt on decorative ones, and lang on the html element. Switch tagging on at render time, which is one parameter and off by default in many wrappers. Set a document title in metadata. Then validate what actually came out with a free checker rather than trusting what you intended. Our PDF accessibility checker comparison covers which tools decide PDF/UA conformance formally, the testing process, and the failures no checker can catch. Do that once and the document rows in your next ACR stop being the ones you hope nobody asks about.

A VPAT service costs $350 to $950 for the report, depending on the edition, and that fee does not include the accessibility audit the report has to rest on. The audit is the real line item, published at $100 to $250 per primary page or screen and typically $1,250 to $2,750 for a small product. Budget for two purchases, not one. The two published rate cards below were re-read on each provider's own pricing page on 15 October 2026.

The two published cards quote the same four numbers for the four editions, which makes the report fee close to a market rate. Quotes differ on the audit. For a small SaaS product with a handful of unique screens, the realistic all in figure is about $1,600 to $3,700. A product with forty distinct templates and several complex flows can pass $10,000 for the audit alone. Two things push the number up for no benefit: buying the INT edition when you only sell to US buyers, which adds $600 over the WCAG edition, and discovering mid audit that your product generates documents nobody has tested.

That second one is where budgets break. Both cards price PDF remediation per page, so a six page monthly statement costs $24 to $48 to fix by hand at $4.00 to $8.00 a page, and a product issuing 500 statements a month faces $12,000 to $24,000 a month, every month. Nobody signs that, so in practice the documents go untested and the ACR says nothing useful about the files the product actually sends. Ask whoever scopes the audit to price the template rather than the archive, because one template rendered 500 times is one fix. The checks that confirm the fix are on our PDF accessibility checker comparison.

Much of the rest can be done in house. There is no accreditation for VPAT authorship, and ITI recommends that the manufacturer do the testing. Run the automated checks, measure contrast across your palette, switch tagging on in your PDF generation pipeline, fix template structure and draft the remarks column yourself. Then buy the manual assistive technology testing and an expert review of your draft, which is where an outside specialist earns the fee. What the audit itself costs across ten providers is on our ADA compliance audit cost comparison.

More often than most vendors assume. Section508.gov states that "Every time your product is changed or updated (e.g. version change, bug fix, etc.), an updated ACR may be required to address any changes in the product's accessibility."

Read literally that is per release, which for a SaaS product shipping continuously is not a workable cadence. What serious vendors do instead is treat the ACR as a versioned artifact tied to a product version, review it on a fixed schedule, and re-test whenever a release touches anything in scope. A change to your PDF template, your rendering configuration, your component library or your color palette is in scope. A backend performance fix is not.

Every ACR names the product version and the evaluation date on its title page, and buyers do look at that date. A report dated three years ago against a product on a weekly release train tells an evaluator something specific about how the vendor treats accessibility, and it is not flattering.

This is where the machine readable route earns its keep. An ACR kept in the OpenACR format can live in version control next to the product, be diffed between releases and be regenerated as part of a release process. A fifty page Word table cannot realistically do any of that, which is a large part of why so many published ACRs are stale.