If you sell software to government agencies, large enterprises, or educational institutions, you have almost certainly been asked for a VPAT. The term gets used loosely, and the process of creating one can seem opaque. This guide explains what VPATs and Accessibility Conformance Reports (ACRs) actually are, when you need one, how to create one that procurement teams will accept, and how to keep it current as your product evolves.

What Is a VPAT?

VPAT stands for Voluntary Product Accessibility Template. It is a standardized document template created by the Information Technology Industry Council (ITI) that vendors use to describe how their product or service conforms to accessibility standards. The term "VPAT" technically refers to the blank template. When a vendor fills in the template with information about their specific product, the resulting document is called an Accessibility Conformance Report (ACR). In practice, people use "VPAT" to refer to both the template and the completed report, which can cause confusion.

The current version is VPAT 2.5, which supports evaluation against three standards: WCAG 2.x (any version), the Revised Section 508 Standards (used by U.S. federal agencies), and EN 301 549 (the European harmonized standard referenced by the EAA). The template includes separate sections for each standard, and vendors can choose which sections to complete based on their target markets.

When You Need a VPAT / ACR

There are several scenarios where having a current ACR is essential:

  • U.S. federal government procurement: Section 508 of the Rehabilitation Act requires federal agencies to purchase accessible information and communication technology (ICT). During procurement, agencies evaluate vendor ACRs to assess whether a product meets accessibility requirements. Without an ACR, your product may be disqualified from consideration.
  • State and local government sales: Many state and local agencies follow similar procurement practices and request ACRs. Some states have their own accessibility requirements that reference Section 508 or WCAG.
  • Higher education: Universities and colleges increasingly require ACRs as part of their software procurement process, driven by legal obligations under the ADA and Section 504.
  • Enterprise sales: Large corporations with accessibility programs often request ACRs during vendor evaluation, particularly for software that will be used by employees, customers, or both.
  • European market compliance: With the EAA now in effect, companies selling products and services in the EU may need to demonstrate conformance with EN 301 549. An ACR based on the VPAT template is an accepted way to document this.

How to Write an ACR

Creating a credible ACR requires a genuine accessibility evaluation of your product. You cannot fill out the template by guessing or by copying another product's report. Here is the process:

Step 1: Define the Scope

Determine exactly what product (or product version) the ACR covers. Specify the platform (web, iOS, Android, desktop), the version number, and the date of evaluation. If your product has multiple modules or features, clarify which are included. Procurement teams need to know whether the ACR reflects the product they are actually evaluating.

Step 2: Conduct the Evaluation

Evaluate your product against the relevant standards — WCAG 2.1 or 2.2 Level AA at minimum, Section 508 if targeting U.S. government, and EN 301 549 if targeting the EU market. The evaluation should include automated testing (using tools like axe-core), manual testing (keyboard navigation, screen reader testing), and testing with assistive technologies across platforms. Document the testing methodology, tools used, and the assistive technology / browser combinations tested.

Step 3: Determine Conformance Levels

For each success criterion or requirement in the template, you must indicate the conformance level using one of these terms:

  • Supports: The functionality of the product has at least one method that meets the criterion without known defects or that meets a conforming alternate version.
  • Partially Supports: Some functionality of the product does not meet the criterion.
  • Does Not Support: The majority of product functionality does not meet the criterion.
  • Not Applicable: The criterion is not relevant to the product (for example, a text-only product may mark audio description criteria as Not Applicable).

For each criterion marked "Partially Supports" or "Does Not Support," provide a clear explanation in the Remarks column describing the specific barriers and, ideally, your remediation timeline.

Step 4: Write the Remarks

The Remarks and Explanations column is where the real value of an ACR lives. Generic remarks like "some issues exist" are useless to procurement evaluators. Be specific: "Form fields in the account settings page lack programmatic labels, affecting screen reader users. Remediation is scheduled for Q3 2026." This specificity builds trust and demonstrates that you understand the issues and are actively addressing them. Procurement teams do not expect perfection — they expect honesty and a clear path to improvement.

Common Sections in an ACR

A VPAT 2.5-based ACR typically includes:

  • Product information: Name, version, date of evaluation, contact information, and a description of what the product does.
  • Evaluation methods used: Testing tools, assistive technologies, browser/platform combinations, and methodology.
  • WCAG 2.x report: Tables covering each relevant success criterion at Level A, Level AA, and optionally Level AAA, with conformance levels and remarks.
  • Section 508 report: (If applicable) Covers the Revised 508 Standards, including chapters on software, web, hardware, and support documentation.
  • EN 301 549 report: (If applicable) Covers the European standard, including requirements that go beyond WCAG for software, hardware, and documentation.

Keeping Your ACR Current

An ACR is a snapshot in time. It reflects your product's accessibility status as of the evaluation date. When your product changes — new features, redesigns, platform updates — the ACR becomes outdated. Procurement teams know this, and a stale ACR raises red flags.

Best practices for maintaining your ACR:

  • Re-evaluate and update the ACR at least annually, or after any major product release.
  • Date the ACR clearly and include the product version it applies to.
  • Maintain an internal accessibility testing process so that you are continuously aware of your conformance status, rather than scrambling before each ACR update.
  • Publish the ACR on your website where procurement teams can find it without having to contact sales. Many organizations publish ACRs on an accessibility page or in their trust center.
  • When a procurement team requests a VPAT and your current ACR is more than a year old, consider conducting a targeted re-evaluation before sending it. An up-to-date ACR demonstrates that accessibility is an ongoing priority, not a one-time exercise.

The Business Case for a Strong ACR

Beyond unlocking government and enterprise sales, a well-written ACR signals organizational maturity. It tells procurement teams that you take accessibility seriously, that you have a testing process, and that you are transparent about your current status. In competitive procurement evaluations, a detailed and honest ACR can be the deciding factor between vendors. Investing in a quality ACR is not just about compliance — it is about winning business.