David works with organizations on digital accessibility evaluations, VPAT/ACR documentation, remediation planning, and accessibility procurement readiness.
When a customer, procurement team, government agency, university, or enterprise buyer asks about accessibility, two requests often appear close together:
“Can you provide a VPAT?”
and
“Has the product been accessibility tested?”
Those questions are related, but they are not asking for the same thing.
An accessibility audit evaluates the product. A VPAT is a reporting template used to document accessibility findings, and once that template is completed with the results of an evaluation, the finished document is generally referred to as an Accessibility Conformance Report, or ACR.
For organizations selling software or other digital products, the distinction matters. A polished ACR cannot substitute for meaningful testing, and a detailed accessibility audit does not automatically give procurement teams the standardized accessibility documentation they may expect.
The strongest approach connects the two:
Evaluate the product → document the findings → remediate important barriers → update the evidence → support procurement.
That is the accessibility workflow buyers increasingly expect.
What is an accessibility audit?
An accessibility audit is a structured evaluation of a website, web application, software product, or other digital experience against applicable accessibility requirements.
For web and software products, that commonly includes evaluation against the Web Content Accessibility Guidelines (WCAG), along with other requirements when they apply.
A meaningful audit typically goes beyond running an automated scanner. Automated tools can identify some categories of accessibility issues, but W3C explains that no evaluation tool alone can determine whether a site meets accessibility standards; knowledgeable human evaluation is also required.
Depending on the product and scope, an accessibility evaluation may include manual review, keyboard testing, screen-reader or other assistive-technology testing, automated testing, review of representative workflows and interface states, and documentation of findings for product and engineering teams.
W3C’s current WCAG Evaluation Methodology describes a structured process that includes defining the evaluation scope, exploring the product, selecting a representative sample, evaluating that sample, and reporting the results. WCAG-EM 2.0, published in July 2026, extends that methodology beyond traditional websites to digital products such as applications and kiosks.
Source references:
W3C — Evaluating Web Accessibility
W3C — Website Accessibility Conformance Evaluation Methodology (WCAG-EM)
What should an accessibility audit deliver?
The value of an audit is not simply a pass/fail label.
A useful audit should give the organization enough evidence to understand:
- what was evaluated;
- which accessibility requirements were applied;
- what testing methods were used;
- where accessibility barriers were identified;
- the user impact of those barriers;
- enough detail for development teams to reproduce and address findings; and
- what should be retested after remediation.
That evidence becomes especially important when the organization later needs to make accessibility representations to customers or procurement teams.
What is a VPAT?
The Voluntary Product Accessibility Template®, or VPAT®, is a standardized reporting template maintained by the Information Technology Industry Council (ITI).
ITI currently provides VPAT 2.5Rev editions for Revised Section 508, WCAG, European requirements, and an International edition that combines those standards.
A VPAT is the template.
Once an organization evaluates its product and enters the resulting conformance information into that template, the completed report is called an Accessibility Conformance Report (ACR). ITI describes the ACR as the completed VPAT containing the documented testing results.
That distinction is worth keeping straight because buyers often use “VPAT” conversationally when what they actually want is the completed ACR.
Source reference:
Information Technology Industry Council (ITI) — VPAT resources and editions
What does an ACR tell a buyer?
An ACR gives a purchaser a standardized way to review how a product supports particular accessibility requirements.
Depending on the edition being used, the report can address requirements associated with WCAG, Revised Section 508, EN 301 549, or a combination of standards.
For each applicable criterion, the report generally identifies a conformance level such as Supports, Partially Supports, Does Not Support, or Not Applicable, accompanied by explanations where appropriate.
The report should also identify the product and version evaluated, the date of the report, and the evaluation methods used.
That last point is important.
An ACR is most useful when the statements inside it can be traced back to actual evaluation evidence.
Does a VPAT require an accessibility audit?
There is not one universal procurement process that applies to every organization, but the underlying principle is straightforward:
The accessibility claims in an ACR should be based on actual testing of the product.
Section508.gov is particularly explicit for federal accessibility reporting. Its guidance states that the product owner or developer must first test the product against the applicable standards in order to complete an ACR. It also directs authors to document the evaluation methods used, including whether testing was manual, automated, or both.
That does not mean every organization must purchase a separate document called an “accessibility audit” before an ACR can exist.
It means the conformance statements inside the ACR need credible evaluation behind them.
For many organizations, the most defensible workflow is therefore:
Accessibility evaluation → remediation → verification → ACR preparation or update.
That sequence makes the procurement document a reflection of the actual product rather than a paperwork exercise.
Source reference:
Section508.gov — How to Create an Accessibility Conformance Report Using a VPAT
Accessibility audit vs. VPAT/ACR
| Comparison | Accessibility Audit | VPAT / ACR |
|---|---|---|
| Primary purpose | Evaluate accessibility of the product | Communicate accessibility conformance in a standardized format |
| Primary audience | Product, engineering, design, accessibility teams | Procurement, customers, agencies, compliance teams |
| Typical content | Findings, barriers, evidence, remediation guidance | Conformance levels and explanations by criterion |
| Does it identify defects? | Yes, usually in detail | May describe gaps, but is not normally a developer defect report |
| Does it replace testing? | It is the testing/evaluation process | No |
| Useful for remediation? | Yes | Limited compared with a detailed audit |
| Useful for procurement? | Supporting evidence | Often a principal procurement artifact |
| Should it be updated? | When the product or evaluation scope changes | When the report no longer accurately represents the product |
The two documents solve different problems.
The audit helps the organization understand and improve accessibility.
The ACR helps the organization communicate accessibility to the buyer.
What does procurement actually need?
The answer depends on the purchaser.
Some commercial buyers may simply ask whether a product conforms to WCAG. Others may ask for an ACR, accessibility statement, audit results, remediation roadmap, testing methodology, accessibility contact, or additional evidence.
Federal procurement has more formal accessibility requirements. Section508.gov specifically identifies ACRs as an important source of accessibility information used in ICT acquisition and provides guidance to agencies on evaluating those reports.
That means a seller should not think of accessibility documentation as a single file that gets created once and forgotten.
Procurement readiness is better understood as a body of consistent evidence.
The buyer should be able to understand what product was evaluated, what standards were used, how the testing was performed, what limitations are known, and what the organization is doing about them.
When those pieces contradict each other, procurement questions tend to multiply.
When they align, accessibility review becomes considerably easier to navigate.
Source reference:
Section508.gov — Accessibility Conformance Report / VPAT procurement guidance
Can automated accessibility testing support a VPAT?
Yes, but automated testing should generally be considered one component of the evaluation rather than the entire basis for an ACR.
W3C notes that accessibility evaluation requires human judgment in addition to automated tools.
Automated testing is valuable for identifying certain programmatically detectable issues and for monitoring large digital environments. But many accessibility requirements involve context, interaction, usability, keyboard behavior, screen-reader output, focus management, error handling, or other conditions that cannot be reliably assessed by automation alone.
A procurement-facing accessibility report is stronger when its evaluation methodology reflects the actual range of testing necessary for the product.
Source reference:
W3C — Evaluating Web Accessibility
Should you remediate before creating the ACR?
Not necessarily.
An ACR is intended to describe the accessibility of the product being evaluated. It does not require every criterion to be fully supported.
Section508.gov specifically notes that a product does not have to conform to every applicable Section 508 requirement in order to be considered for federal purchase. The report can identify criteria that are partially supported or not supported and explain the corresponding limitations.
That makes transparency more valuable than trying to make the report appear perfect.
In practice, an organization may choose to evaluate the product, remediate important barriers, retest affected functionality, and then prepare the ACR.
Another organization may need an ACR sooner and document current limitations accurately while remediation continues.
The right sequence depends on the procurement timeline, product maturity, severity of the findings, and the expectations of the buyer.
Source reference:
Section508.gov — ACR and VPAT Frequently Asked Questions
When should a VPAT/ACR be updated?
An ACR should remain representative of the product being offered.
That means teams should consider a refresh when:
- significant product releases change the evaluated experience;
- accessibility remediation materially changes conformance;
- applicable standards or procurement requirements change;
- the existing report becomes outdated; or
- the product scope represented by the report no longer matches what customers are buying.
Section508.gov recommends creating an ACR when procuring or releasing ICT in order to document how the product or service conforms to the applicable standards.
For SaaS companies in particular, that makes accessibility documentation an ongoing product artifact rather than a one-time compliance project.
Source reference:
Section508.gov — ACR and VPAT Frequently Asked Questions
Which VPAT edition should you use?
ITI currently publishes four VPAT 2.5Rev editions.
The appropriate edition depends on the standards and markets relevant to the product and procurement request.
For example:
- the 508 Edition addresses Revised Section 508;
- the WCAG Edition addresses WCAG;
- the EU Edition addresses EN 301 549; and
- the INT Edition combines the principal requirements contained in the other editions.
The correct choice should follow the actual procurement requirement rather than simply selecting the longest template.
For organizations selling across multiple markets, the International edition may sometimes be appropriate, but the reporting scope should still match what was actually evaluated.
Source reference:
Information Technology Industry Council (ITI) — VPAT resources and editions
A more useful way to think about accessibility procurement
The question should not be:
“Do we need an audit or a VPAT?”
The better question is:
“What evidence do we need to accurately evaluate, improve, and communicate the accessibility of this product?”
For many software organizations, the answer includes both.
An accessibility audit creates the technical evidence.
Remediation improves the product.
Retesting verifies changes.
The ACR communicates the product’s current accessibility to the buyer.
Procurement readiness connects those pieces so the organization can respond consistently when customers ask questions.
Frequently asked questions
Is a VPAT the same as an accessibility audit?
No. An accessibility audit evaluates the product; a VPAT is the template used to report its accessibility conformance. The completed template is an Accessibility Conformance Report (ACR). Audit findings can support the ACR, but the report does not replace the evaluation.
Can you create a VPAT without accessibility testing?
A credible ACR needs accessibility testing evidence. You do not necessarily need to purchase a separate report called an accessibility audit, but the conformance statements should reflect an evaluation of the actual product. Section508.gov directs product owners and developers to test against the applicable standards before completing an ACR.
Does procurement require a VPAT?
It depends on the buyer and the procurement requirements. Buyers often use “VPAT” to mean the completed ACR. Federal, education, and enterprise purchasers may request an ACR and supporting evidence; confirm the solicitation, required standards, edition, and product scope rather than assuming every purchase has the same requirements.
How often should an ACR be updated?
Update an ACR when it no longer accurately represents the product or the requirements it needs to address. Review it after significant releases, accessibility fixes, changes in scope, or new buyer requirements. There is no single update interval that fits every product and procurement process; keep the report tied to the evaluated version and current evidence.
Which VPAT edition should a SaaS company use?
Use the edition that covers the buyer’s required standards. The WCAG Edition addresses WCAG, the 508 Edition addresses Revised Section 508, the EU Edition addresses EN 301 549, and the INT Edition combines those standards. SaaS delivery alone does not determine the edition. Confirm the requested WCAG version, applicable requirements, and evaluation scope before preparing the ACR.
How CompliCorp helps
CompliCorp works with organizations that need to understand the accessibility of their digital products and communicate that information effectively to customers and procurement teams.
Our work can include manual accessibility evaluations, WCAG testing, assistive-technology testing, VPAT/ACR preparation, remediation planning, retesting, and accessibility procurement readiness support.
The objective is not simply to produce another document.
It is to give product teams useful findings, give leadership a clear roadmap, and give buyers accessibility information that accurately reflects the product being offered.
If your organization is preparing for an RFP, responding to a customer accessibility request, updating an existing ACR, or trying to determine what testing should happen first, CompliCorp can help you define the appropriate path.
Primary source references
- W3C — Evaluating Web Accessibility
- W3C — Website Accessibility Conformance Evaluation Methodology (WCAG-EM)
- Information Technology Industry Council (ITI) — VPAT Resources
- Section508.gov — How to Create an Accessibility Conformance Report Using a VPAT
- Section508.gov — Accessibility Conformance Report / VPAT Frequently Asked Questions