VPAT & Accessibility Conformance Reports (ACR) for PDF Documents

A VPAT (Voluntary Product Accessibility Template) is a standardized form you fill out to document how a product conforms to accessibility standards. When you complete it for a real product, the finished document is an Accessibility Conformance Report (ACR) — the artifact buyers actually ask for. For anything that produces or distributes PDFs, an honest, well-evidenced ACR is increasingly part of doing business with government and large institutional buyers.

This guide explains what the VPAT is, the four editions, how to complete one for a PDF or document-producing product, and how to keep your reporting credible.

VPAT vs. ACR: what's the difference?

The two terms get used interchangeably, but they aren't the same thing:

• A VPAT is the blank template, published and maintained by the Information Technology Industry Council (ITI). It's a structured form with rows for each applicable accessibility criterion.
• An ACR is what you get after you complete that template against a specific product version — your conformance claims, with supporting remarks and evidence.

In other words, the VPAT is the form; the ACR is your filled-in answer. Buyers request "a VPAT," but what they're evaluating is your ACR.

The four VPAT editions

ITI publishes the VPAT in four editions so a single template can map to different legal regimes. You pick the edition that matches what your buyer is held to:

A few practical notes:

• The INT edition is the most common choice for vendors selling across regions, because one report addresses U.S. and EU buyers at once.
• The Section 508 edition is the one most U.S. federal agencies and their contractors will expect. If you're chasing government work, this is your baseline — see our federal contractor PDF requirements guide for how it shows up in solicitations.
• Whichever edition you use, it ultimately resolves to WCAG success criteria, because both Section 508 and EN 301 549 incorporate WCAG by reference.

The conformance terms (and what they really mean)

Every row in an ACR gets one of four conformance levels. Using them precisely is what separates a credible report from a marketing document:

• Supports — the functionality meets the criterion with no known defects.
• Partially Supports — some functionality works, but there are exceptions or gaps. This is the most honest answer for most real products, and reviewers expect to see it.
• Does Not Support — the majority of functionality does not meet the criterion.
• Not Applicable — the criterion doesn't apply to the product (for example, an audio-only criterion for a product with no audio).

A row that says "Partially Supports" with a clear, specific remark is far more trustworthy than a wall of "Supports." Evaluators read the remarks column closely; vague or absent remarks are a red flag.

How to complete a VPAT for a PDF or document-producing product

The process differs slightly depending on whether you're reporting on individual PDFs, or on software that generates PDFs (a report builder, a form engine, an export feature).

1. Define the scope. State exactly what you're evaluating: the product name, the version, and what's in or out. For a document-producing tool, clarify whether you're claiming conformance for the authoring interface, the output documents, or both.

2. Pick the right edition and standard version. Most U.S. work uses the Section 508 or INT edition. Note which WCAG version applies — Section 508 currently incorporates WCAG 2.0 A and AA, while EN 301 549 references WCAG 2.1 AA. If you've tested against the newer 2.1 or 2.2 criteria, say so.

3. Test against the criteria. For PDFs specifically, conformance means real structural accessibility: tagged content, a logical reading order, alternative text on images, properly marked-up tables, accessible form fields, and correct document metadata and language. PDF/UA (ISO 14289) defines how these are implemented inside the file; WCAG defines what accessibility means at the content level. A thorough evaluation usually combines automated checks with manual review and assistive-technology testing.

4. Record conformance and remarks per criterion. For each applicable row, assign Supports / Partially Supports / Does Not Support / Not Applicable, and write a remark that explains the basis for the rating and notes any known limitations.

5. Add product and evaluation metadata. Include the evaluation methods used, the date, and contact information. Buyers want to know whether the report reflects automated tooling, manual auditing, or both.

If your products are the documents themselves, the practical bottleneck is usually fixing the files before you can honestly claim conformance. Our walkthrough on how to remediate an inaccessible PDF covers the tagging and reading-order work that turns a "Does Not Support" into a defensible "Supports."

Who requests ACRs, and why

ACRs aren't busywork — they're a procurement gate:

• U.S. federal agencies require them under Section 508, which obligates agencies to procure information and communication technology that's accessible. Vendors supply an ACR so the agency can document due diligence. This is the core of Section 508 PDF compliance, the pillar topic this report supports.
• State and local governments, universities, and health systems increasingly ask for ACRs as part of RFPs, often referencing WCAG directly.
• European public-sector buyers request EN 301 549–aligned reports.
• Large private enterprises with mature accessibility programs request them too, both to manage their own legal exposure and to keep their supply chain accountable.

The "why" is consistent across all of them: the buyer is on the hook for the accessibility of what they deploy, and your ACR is how they transfer some of that diligence to a documented vendor claim.

Standards keep moving — so should your ACR

Because the underlying standards evolve, an ACR is a snapshot, not a permanent certificate. The Revised Section 508 Standards (the "508 Refresh," effective January 2018) modernized the rules by incorporating WCAG by reference; our Section 508 Refresh explainer covers what changed. As WCAG moves from 2.0 to 2.1 to 2.2, and as buyers raise their expectations, you'll need to re-test and re-issue. Treat the ACR as a living document tied to a product version and a standard version, and re-publish when either changes.

Tips for credible, honest reporting

• Don't overclaim. A report that's all "Supports" invites skepticism. Accurate "Partially Supports" entries with specific remarks build more trust than a perfect-looking sheet.
• Show your methods. State whether you used automated tools, manual testing, assistive technology, or all three.
• Be specific in remarks. "Tables lack header associations on the summary page" tells a reviewer far more than "minor issues."
• Version everything. Tie the ACR to a product version and a standard version, and date it.
• Fix, then claim. The strongest ACR is one where you remediated the real defects first rather than papering over them.

This is general information, not legal advice.

Key takeaways

• A VPAT is ITI's template; a completed VPAT is an ACR, the report buyers actually evaluate.
• There are four editions — WCAG, Section 508, EN 301 549, and INT — and they all ultimately resolve to WCAG success criteria.
• Use the four conformance terms precisely; honest Partially Supports entries with clear remarks beat a sheet full of Supports.
• For PDFs, real conformance means tags, reading order, alt text, accessible tables and forms, and correct metadata — tested with both automated and manual methods.
• An ACR is a versioned snapshot; re-test and re-issue as standards and products change.