You are in the final week of a procurement review. Legal has signed off, infosec is cleared, and the one file everyone is still waiting on is the vendor's VPAT.
A VPAT, or Voluntary Product Accessibility Template, is the standardized report vendors use to disclose how their product conforms to accessibility standards like WCAG and Section 508. You open it and find "Supports" in every row and an empty remarks column.
If you are reviewing the document, that is a reason to look more closely.
If you are the vendor fielding the request, the questions are different: What exactly should you provide? When should you provide it? And what happens if the report you have on file shows accessibility gaps?
This guide covers both sides of the exchange: how to evaluate an Accessibility Conformance Report and how to approach producing and sharing your own.
VPAT vs. ACR: What's the Difference?
The terms are often used interchangeably, but they are not technically the same thing.
VPAT: The Voluntary Product Accessibility Template published by the Information Technology Industry Council (ITI).
ACR: The Accessibility Conformance Report created when a vendor completes the VPAT with the results of its accessibility evaluation.
When someone asks a vendor for "a VPAT," what they usually want is the completed ACR.
The current template is VPAT 2.5Rev, released in April 2025.
Why VPATs Matter in Procurement
A completed ACR is also not a certification. It is a report of what the vendor's testing found. ITI does not review or certify the conclusions in it.
That is why the testing evidence, scope, and documented accessibility gaps matter more than simply having the document.
If You Are Reviewing a Vendor's ACR
Request the Right VPAT Edition
Asking only for "a VPAT" may not give you the information you need.
| Edition | Reports against | Who should request it |
|---|---|---|
| 508 | Revised Section 508, which incorporates WCAG 2.0 | U.S. federal procurement and organizations whose policies reference Section 508 |
| WCAG | WCAG 2.0, 2.1, and 2.2 | Most commercial and private-sector procurement |
| EU | EN 301 549, which incorporates WCAG 2.1 | European public sector procurement and organizations with EU obligations |
| INT | All of the above | Organizations buying or selling across multiple regulatory regions |
The edition is only part of the request.
If your organization requires WCAG 2.2 Level AA, for example, a 508-edition ACR built against WCAG 2.0 does not tell you whether the product meets the newer success criteria in WCAG 2.1 and 2.2.
Specify both the VPAT edition and the WCAG version you need.
How to Read an ACR in 60 Seconds
Before working through a long conformance matrix, check five things.
1. Date
How recent is the report?
As a practical rule, a report more than 12 months old deserves additional scrutiny, especially for software that changes frequently.
2. Scope
Does the report cover the exact product, version, modules, and platforms you are buying?
For modular products, separate ACRs may be appropriate if individual modules can be purchased independently.
3. Evaluation Methods
Look for the operating systems, browsers, testing tools, and assistive technology used during the evaluation.
Some reports name these specifically. Others describe methods more generally, for example listing "screen reader testing" as a category without naming the tool or version. That level of detail varies by vendor and report, so treat it as one data point among several rather than a pass or fail on its own.
4. Remarks
The remarks column is where the testing should become visible.
Specific explanations tell you much more than a conformance label by itself.
5. Known Exceptions
Look for accessibility gaps and how clearly they are documented.
A strong report does not pretend defects do not exist. It tells you what they are and, when possible, what the vendor plans to do about them.
Understand the Conformance Levels
ITI defines four primary conformance terms for applicable Level A and AA criteria:
Supports: The product has at least one method that meets the criterion without known defects or meets it through equivalent facilitation.
Partially Supports: Some functionality does not meet the criterion.
Does Not Support: The majority of the relevant functionality does not meet the criterion.
Not Applicable: The criterion does not apply to the product.
A fifth term, Not Evaluated, is restricted to Level AAA criteria.
The overall pattern matters.
Complex enterprise software is rarely completely free of accessibility defects. A report containing a realistic mix of Supports and Partially Supports entries can therefore provide more useful evidence than a report that marks every criterion Supports without explanation.
What a Thin ACR Looks Like
A weak report often reflects limited testing, expertise, or resources.
Warning signs
- Every criterion is marked Supports with no exceptions.
- The remarks column is blank or filled with generic statements.
- The report significantly predates the current product.
- The scope is so broad that you cannot tell what was actually tested.
- The accessibility plan relies primarily on adding an accessibility widget rather than fixing the underlying experience.
Signs of a stronger report
- Specific remarks describing known barriers.
- Clearly defined product, version, and platform scope.
- Partially Supports entries that explain what does not work.
What to Do When the Report Is Weak
A weak ACR is not automatically a reason to reject a vendor.
It is a reason to ask more questions before signing.
Consider asking the vendor to:
- Share its accessibility remediation backlog and target dates.
- Explain how much of the evaluation was manual and who performed it.
- Demonstrate your most important workflows using a screen reader.
- Clarify who owns accessibility fixes for third-party components.
- Address accessibility requirements and remedies in the contract.
In one procurement process we're familiar with, the buyer scored the ACR criterion by criterion against a minimum passing threshold. Accessibility findings affected the resulting score, illustrating how issues documented in an ACR can become concrete procurement considerations.
If You Are the Vendor Being Asked for a VPAT
You Do Not Always Need to Send the Full ACR First
Not every accessibility inquiry requires the same level of documentation.
Some buyers have a detailed procurement requirement. Others simply want to understand whether your organization has an accessibility program.
Match the documentation to the request.
Level 1: Accessibility Statement or FAQ
Explain your accessibility commitment, how concerns are handled, and who buyers can contact.
For many early-stage inquiries, that may be enough.
Level 2: Confirmation of Your Accessibility Program
You may provide evidence that you work with an accessibility testing partner, conduct audits, or maintain an active remediation program.
This demonstrates investment without necessarily disclosing detailed findings.
Level 3: Accessibility Strategy or Policy
For buyers who need more information, provide documentation explaining how accessibility is tested, prioritized, monitored, and remediated.
Level 4: The ACR
The ACR is the most detailed and standardized level of disclosure.
Provide it when the buyer specifically requests it, procurement requires it, or contractual requirements call for it.
Holding the ACR until it is needed is not about hiding accessibility findings. It is about providing the level of detail appropriate to the request.
Expect Buyers to Have Questions
Once an ACR is shared, buyers may need help interpreting it.
This is especially true when the document is passed from a procurement team to another department or downstream customer that is less familiar with accessibility terminology.
Being able to explain what the report covers, what it does not cover, and what is being remediated can be part of getting a deal across the line.
An ACR should also evolve as the product improves.
As accessibility defects are fixed and validated, a revised report can reflect that progress.
Do Not Build an ACR From Automated Testing Alone
Automated testing is useful, but it cannot support an ACR on its own.
Automated tools, including platforms like UsableNet's AQA, can meaningfully evaluate roughly 30% of WCAG success criteria.
You may also see numbers closer to 57%. Those usually measure the percentage of total accessibility defects a scanner can identify rather than the percentage of WCAG criteria it can fully evaluate. High-frequency issues such as color contrast can also increase the defect percentage.
For an ACR, the criteria measure is the more important one.
You have to assign a conformance level to every applicable criterion, and a scanner cannot fully determine things such as:
- Screen reader behavior
- Keyboard interaction
- Focus management
- Whether labels and instructions provide enough context
- Whether a multi-step workflow can actually be completed without a mouse
That is why an ACR requires manual evaluation in addition to automated testing.
A Better Sequence: Audit, Remediate, Report
A stronger process generally looks like this:
1. Conduct the accessibility audit.
Evaluate the relevant product, version, and user flows using automated and manual methods, including assistive technology. Accessibility audit services typically combine both approaches rather than relying on either alone.
2. Review and remediate the findings.
Give product and engineering teams an opportunity to address priority barriers. Building a remediation roadmap from the audit findings, rather than tackling issues on an ad hoc basis, makes it easier to track what has actually been fixed by the time the ACR is produced.
3. Produce the ACR.
Complete the VPAT based on the verified testing results.
The exact timeline depends on the product's size and complexity, as well as whether the work involves a first-time audit or a re-evaluation of previously tested flows.
Some organizations also produce an initial as-is ACR immediately after testing, before remediation is complete.
That report documents the current state and demonstrates that testing has occurred.
A revised ACR can then be issued after fixes are implemented and validated.
Both approaches can be appropriate as long as the document clearly represents the state of the product at the time it was produced.
What Goes Into a Complete ACR
At minimum, the report should clearly identify:
- The correct VPAT edition.
- The VPAT template version used.
- The company and product name.
- The specific product version.
- The report date.
- Evaluation methods.
- Testing tools and environments.
- Operating systems and browsers, when applicable to the testing performed.
- A conformance level for every applicable criterion.
- Remarks explaining criteria that do not fully support the standard.
The report should also use ITI's required structure and terminology.
Two details are easy to overlook:
Remove the VPAT instruction pages before distributing the completed report.
Make sure the finished ACR is itself accessible.
An inaccessible PDF undermines the accessibility work the document is meant to describe.
Does an ACR Need an Independent Audit?
Not necessarily.
ITI does not require third-party testing or review. A vendor can produce an ACR using its own internal accessibility evaluation.
However, individual buyers or solicitations may require independent testing.
Even when it is not required, third-party evaluation can give buyers additional confidence that the findings accurately represent the product.
A credible ACR need not claim perfection.
A report that openly documents "Partially Supports" criteria, explains the barriers, and includes a remediation plan can be stronger than a report that claims "Supports" everywhere without meaningful evidence.
Frequently Asked Questions
How often should a company update its VPAT?
As a practical best practice, review the ACR at least annually and sooner after a major interface redesign, platform migration, or significant feature release.
An ACR describes a product at a particular point in time. If the product changes substantially, the report may no longer accurately describe what customers are buying.
Re-auditing on a set cadence, rather than only after something breaks, is easier to sustain as part of an ongoing accessibility process than as a one-time project.
Can a company be sued or denied a contract for not having a VPAT?
Both are possible, and they work differently.
On the contract side: yes, depending on the procurement requirements. Although the VPAT template itself is voluntary, many government, higher education, healthcare, and enterprise buyers require accessibility documentation as part of procurement. A vendor that cannot provide the requested documentation may be eliminated before the technical review progresses.
On the legal side: not having a VPAT does not, by itself, create legal exposure, since the template is voluntary and no law requires a company to produce one. But its absence does not shield a company either. Accessibility lawsuits under the ADA and similar laws target the underlying inaccessibility of a product, not the paperwork.
A VPAT is documentation of that state, not a substitute for it. A company with a genuinely accessible product but no VPAT is in a better legal position than a company with a VPAT that misrepresents it as inaccessible. Recent litigation trends reinforce the same point from the other direction: an old audit or conformance report offers little protection if the current site no longer reflects what that report described.
Do Small Businesses or Startups Need a VPAT?
Company size does not determine whether a buyer will request one.
If you sell into government, higher education, healthcare, or enterprise organizations, your customers may require accessibility documentation as part of their own procurement obligations.
Can We Have Separate VPATs for Different Products or Modules?
Yes.
For modular platforms, separate ACRs may make it easier for buyers to understand exactly what was evaluated.
If individual modules are purchased separately, buyers may reasonably request documentation specific to the module they are licensing.
Do We Have to Send Our Full VPAT Every Time Someone Asks About Accessibility?
No.
Many initial inquiries can be answered with an accessibility statement or a description of your accessibility program.
Provide the full ACR when the buyer specifically requests it, procurement requirements call for it, or it is contractually required.
What an ACR Can and Cannot Tell You
An ACR tells you what testing found for a particular product, version, date, and accessibility standard.
Used well, it creates a starting point for a practical conversation about accessibility gaps, remediation, responsibilities, and risk.
Used only as a procurement checkbox, it provides far less value.
The strongest buyers treat an ACR as evidence to evaluate.
The strongest vendors make sure the evidence can withstand that evaluation.
In practice, that can include module-specific VPATs, reports produced at different stages of remediation, and guidance on what documentation is appropriate to share at each stage.
The result is an ACR with defined scope, specific remarks, and documented accessibility findings that can hold up when a procurement reviewer starts asking questions.
