When a customer, procurement team, or government buyer asks for your “VPAT,” they are usually asking for evidence about how accessible your product is. The terminology can be confusing because VPAT and ACR are often used as if they mean the same thing, even though they describe two different things.
The short version is simple: a VPAT® (Voluntary Product Accessibility Template) is the template used to document accessibility information. An Accessibility Conformance Report (ACR) is the completed report that describes how a specific product or service conforms to applicable accessibility requirements.
That distinction matters for SaaS companies, software vendors, digital product teams, and organizations responding to procurement requests. A blank template does not tell a buyer anything about the accessibility of your product. A useful ACR does.
VPAT vs ACR: The Difference at a Glance
| Question | VPAT | ACR |
|---|---|---|
| What is it? | A standardized accessibility reporting template | A completed accessibility conformance report |
| Who publishes it? | Information Technology Industry Council (ITI) | The vendor or evaluator completing the report |
| Does it describe a specific product? | No, not until completed | Yes |
| What does a buyer usually want? | Often says “VPAT” | Usually the completed ACR |
| What should it be based on? | Applicable reporting criteria | Evidence from product evaluation and testing |
In everyday procurement conversations, people often say “send us your VPAT” when they mean “send us your completed accessibility report.” Technically, however, the completed document is the ACR.
What Is a VPAT?
The VPAT is a structured template for reporting how an information and communications technology product or service supports accessibility requirements. It gives vendors a common format for documenting conformance information so buyers do not have to interpret a completely different report structure from every supplier.
The template is especially familiar in government and enterprise procurement. Different VPAT editions are designed for different standards or markets, including editions aligned with U.S. Section 508, WCAG, European requirements, and an international format.
A VPAT by itself is not proof that a product is accessible. It is the reporting framework. The value comes from the product-specific evidence entered into it.
What Is an Accessibility Conformance Report?
An Accessibility Conformance Report documents how a particular product or service performs against the accessibility requirements included in the selected template. It normally identifies the product, version, evaluation methods, applicable standards, conformance level for each criterion, and remarks explaining the determination.
Section508.gov describes the ACR as a representation of how a product meets applicable Section 508 technical requirements and advises product owners and vendors to test the product before completing the report.
That means the ACR should reflect the product that a buyer will actually evaluate or purchase—not a marketing website, an unrelated demo environment, or a previous version of the application.
Why Buyers Ask for a “VPAT”
The word “VPAT” has become shorthand in many sales and procurement workflows. A buyer may include a request such as “Please provide your current VPAT” in a security questionnaire, RFP, vendor review, or procurement checklist.
In most cases, the buyer is not looking for a blank template. They want a completed report that helps them understand:
- which accessibility requirements were evaluated;
- which parts of the product support those requirements;
- where known accessibility gaps remain;
- how the evaluation was performed;
- which product version the report covers; and
- whether the documentation appears current and credible.
For vendors, this makes accessibility documentation part of sales readiness. If your product regularly enters enterprise or public-sector procurement, waiting until a deal is blocked by a VPAT request can create unnecessary pressure.
Which VPAT Edition Should You Use?
The correct edition depends on what the buyer, contract, solicitation, or market requires. Do not choose an edition only because it is the one your team used last time.
For example, a U.S. federal procurement may require documentation aligned with Revised Section 508. A commercial buyer may focus primarily on WCAG. A European procurement may reference EN 301 549. International sales teams may need broader documentation.
If the request comes from a specific procurement document, start there. The requested standard should drive the reporting scope.
For federal procurement context, see our guide to Section 508 for SaaS vendors.
What Goes Into a Strong ACR?
A useful ACR is more than a list of “Supports” entries. Buyers need enough information to understand what was evaluated and why each conformance statement is reasonable.
Strong reports typically include:
- Product identification: the product or service name and relevant version or release.
- Evaluation scope: the components, workflows, platforms, or documentation included in the review.
- Evaluation methods: the automated tools, manual testing methods, assistive technologies, and test environments used.
- Criterion-by-criterion conformance: the appropriate conformance level for each applicable requirement.
- Remarks and explanations: meaningful details that explain partial support, non-support, exceptions, or implementation behavior.
- Date and ownership: enough context for a buyer to understand when the report was prepared and who is responsible for the information.
The report should also be internally consistent. If a criterion is marked as fully supported while the remarks describe a known failure in a core workflow, a buyer may reasonably question the reliability of the rest of the document.
Why Automated Scanning Alone Is Not Enough
Automated accessibility tools are useful, but they cannot evaluate every accessibility requirement or the usability of complex interactions. A scanner can identify many machine-detectable issues, but it cannot reliably determine whether every workflow works with a keyboard, whether focus is managed correctly in dynamic interfaces, or whether a screen reader receives meaningful feedback after an action.
That is why an ACR based only on a quick scan can create a misleading picture of the product. The evaluation methods should match the type of claims being made.
Our guide to automated vs manual accessibility testing explains where each method is useful and where human evaluation is still required.
Should You Mark Everything as “Supports”?
No. An ACR is not supposed to be a perfect scorecard. It is supposed to communicate the product’s actual conformance status.
Section508.gov guidance includes conformance terms such as Supports, Partially Supports, Does Not Support, and Not Applicable. When a product does not fully support a requirement, the remarks should explain the limitation clearly enough for the buyer to understand the impact.
Transparent documentation is more useful than optimistic documentation that cannot be supported by testing. A buyer may validate accessibility claims during procurement, demonstrations, pilot testing, or implementation.
How Often Should an ACR Be Updated?
An ACR should stay aligned with the product it describes. That can become challenging for SaaS products that release changes frequently.
Section508.gov notes that product changes, version updates, and bug fixes may require an updated ACR. In practice, teams should establish a review point for major releases, significant interface changes, accessibility remediation, or material changes to components covered by the report.
A two-year-old ACR for a product that has been redesigned several times may not give a buyer meaningful information about the current experience.
Common VPAT and ACR Mistakes
1. Treating the VPAT as a certification
A completed report documents conformance claims. It is not automatically a third-party certification, legal guarantee, or promise that no accessibility issues exist.
2. Completing the report from a scanner export
Automated results can support part of the evaluation, but they do not replace manual review of interactions, keyboard operation, focus, forms, and assistive-technology behavior.
3. Using vague remarks
Remarks such as “compliant” or “works as expected” give buyers little useful information. Stronger remarks explain the relevant behavior and any known limitations.
4. Documenting the wrong product scope
A public marketing site is not the same as a SaaS application, authenticated dashboard, mobile app, or administrative console. The ACR should match what the customer is buying.
5. Letting the report become stale
Accessibility documentation should be reviewed as the product changes. A current date alone is not enough if the underlying evaluation is based on an old version.
How to Prepare for a VPAT or ACR Request
- Confirm what the buyer is asking for. Identify the required standard, edition, product scope, and deadline.
- Define the product version. Document the application, modules, platforms, and major workflows that will be evaluated.
- Run a structured accessibility evaluation. Combine automated checks with manual testing appropriate to the product.
- Remediate significant barriers. Fix confirmed issues before finalizing claims where practical.
- Retest corrected functionality. Verify that fixes work and did not introduce new barriers.
- Complete the ACR accurately. Use clear conformance levels and useful remarks.
- Create an update process. Tie future review to major releases, remediation milestones, or procurement needs.
If you are unsure what should be included in the evaluation itself, our guide to what a website accessibility audit should include explains the expected scope, testing methods, reporting, remediation guidance, and retesting process.
Can ADA Access Group Help With VPAT and ACR Readiness?
Yes. ADA Access Group provides accessibility testing, manual evaluation, remediation guidance, and reporting support for websites and digital products. For teams preparing an ACR, the first step is usually establishing reliable evidence about the product’s current accessibility—not filling out a template before the product has been meaningfully evaluated.
Our website accessibility audit service combines automated checks with manual keyboard and screen-reader testing and can support the evidence-gathering process used for accessibility documentation.
If a customer or procurement team has asked for a VPAT or ACR, start by defining the product, standard, and deadline, then evaluate the actual experience before making conformance claims.
Frequently Asked Questions
Is a VPAT the same as an ACR?
No. The VPAT is the reporting template. The completed product-specific document is the Accessibility Conformance Report.
When a customer asks for a VPAT, what should I send?
In most procurement contexts, the customer is asking for a completed accessibility conformance report, not a blank VPAT template. Confirm the required edition and standard before sending documentation.
Can we create an ACR from automated scan results?
Automated testing can contribute evidence, but it cannot evaluate every accessibility requirement or user interaction. Manual testing is typically needed to support accurate conformance statements for complex digital products.
Does an ACR mean a product is fully accessible?
No. An ACR can document full support, partial support, non-support, or non-applicability depending on the criterion and product. Its purpose is to report conformance accurately.
How often should an ACR be updated?
Review it when material product changes, major releases, accessibility remediation, or buyer requirements make the existing report no longer representative of the current product.
This article provides general technical accessibility information and is not legal advice. Procurement and accessibility requirements vary by buyer, contract, jurisdiction, and product.