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, our VPAT services cost guide 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, and our guide to testing PDF accessibility covers the process, along with 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.

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.