David works with organizations on digital accessibility evaluations, VPAT/ACR documentation, remediation planning, and accessibility procurement readiness.
Why procurement teams review VPATs and ACRs
A buyer asks for accessibility documentation to understand the product it may purchase. The VPAT® is ITI’s reporting template; an Accessibility Conformance Report (ACR) is the completed report. Buyers often say “VPAT” when they mean the ACR.
An ACR helps a reviewer examine the product against applicable accessibility requirements. The buyer may consider it alongside testing methods, demonstrations, remediation information, questionnaires, and other documentation. Commercial organizations do not all follow the same process.
Federal ICT purchasing has specific guidance. Section508.gov describes accessibility information agencies can request from vendors, including evidence beyond the ACR. Use that guidance in its federal context and confirm the requirements of the actual solicitation.
Sources: ITI’s VPAT and ACR guidance and Section508.gov’s vendor-information guidance.
VPAT/ACR Review Checklist
Use this checklist to identify useful follow-up questions. A possible warning sign calls for context and additional review; it does not, by itself, invalidate a report or decide a purchase.
| What buyers may review | Why it matters | Possible warning sign |
|---|---|---|
| Product and version | Establishes what the ACR covers | Report refers to an older product release |
| Report date | Helps determine whether evidence is current | Significant product changes occurred after the report |
| VPAT edition | Shows which standards are being reported | Edition does not match buyer requirements |
| Evaluation methods | Supports confidence in conformance claims | Methodology is missing or unclear |
| Conformance ratings | Summarizes support for individual criteria | Ratings conflict with known product behavior |
| Remarks and explanations | Provides product-specific context | Generic or repetitive boilerplate |
| Known limitations | Helps the buyer understand actual barriers | Important limitations are unexplained |
| Remediation status | Indicates whether known issues are being addressed | No information on significant known barriers |
| Supporting evidence | Helps procurement validate accessibility claims | Documentation cannot be explained or supported |
| Vendor responsiveness | Helps resolve follow-up questions | No clear accessibility contact or ownership |
1. Does the report identify the correct product and version?
The report should tell the buyer exactly what was evaluated. Confirm the product name, version or release, modules and editions included, and relevant platform scope. A report covering a web application does not necessarily describe a separate mobile or desktop application.
Look for exclusions and configuration limits. For example, an ACR may cover a standard module while the offered package includes a different interface or integration. Ask whether that difference affects the report’s conclusions.
Warning sign: the ACR describes a product version substantially different from the one being offered, without explaining what changed or whether the evidence still applies.
2. How current is the ACR?
An ACR is current when its scope and findings still accurately represent the product. There is no universal expiration period for every report. A recent report date is useful, but it does not replace checking the version and underlying evaluation.
Ask about major releases, redesigns, new workflows, platform changes, verified accessibility fixes, and standards or reporting updates since the assessment. Any of these may warrant review or additional testing; a cosmetic change and a replacement of a core workflow have different implications.
Section508.gov’s ACR/VPAT FAQ explains that product changes may require an updated report. Also check any freshness requirement specified by the buyer.
3. Was the appropriate VPAT edition used?
ITI currently publishes VPAT 2.5Rev in four editions. The edition determines the standards represented in the report:
- WCAG: Web Content Accessibility Guidelines reporting, including WCAG 2.2.
- Revised Section 508: the U.S. federal ICT standards, including their incorporated WCAG requirements.
- EU: EN 301 549 accessibility requirements.
- INT: combined coverage of WCAG, Revised Section 508, and EN 301 549.
Choose based on the buyer, market, and applicable requirements. INT is not automatically superior. For federal work, check the requested Section 508 evaluation and reporting scope rather than assuming that a WCAG-only report covers every relevant ICT provision.
Source: ITI’s current VPAT templates and edition descriptions.
4. What evaluation methods support the conformance claims?
The methods should explain how the evaluator reached the report’s conclusions. A list of tool names alone does not tell the buyer which features were tested, under what conditions, or how results were interpreted.
Depending on the product and scope, useful evidence may describe:
- Manual testing of content, controls, forms, and interaction states.
- Keyboard testing of navigation, focus, and complete tasks.
- Assistive-technology testing, with the relevant tools and configurations identified.
- Automated checks and the role they played in the evaluation.
- Representative workflows, user roles, components, and states.
- Code or component inspection where it helps explain behavior.
- Browser and platform coverage appropriate to the product.
Automated testing is useful for detecting some issues, but it cannot evaluate every accessibility requirement. W3C’s evaluation guidance explains that tools alone cannot determine conformance and that knowledgeable human evaluation is needed. Coverage should be appropriate to the product; every engagement need not use every technology or method.
A manual accessibility audit can supply technical evidence behind the ratings. Our comparison of accessibility audits and VPAT/ACR documentation explains the separate roles of testing and reporting.
5. Are the conformance ratings supported by useful explanations?
Read each rating together with its remarks, applicable criteria, and product scope. The labels are not a substitute for understanding the affected functionality:
- Supports: the functionality has a way to meet the criterion without known defects, or through equivalent facilitation.
- Partially Supports: some functionality does not meet the criterion.
- Does Not Support: most of the relevant functionality does not meet the criterion.
- Not Applicable: the criterion does not apply to the product’s functionality.
Useful remarks identify the affected feature or task and explain its behavior. Repeated boilerplate, text that only restates a criterion, or a Supports claim that conflicts with a known barrier deserves clarification. Ask how the rating follows from the evidence.
A Partially Supports rating is not automatically a procurement problem. Its significance depends on the barrier, user impact, intended use, and buyer’s requirements. Section508.gov’s ACR preparation guide explains the conformance terms and remarks, while its vendor-claims guidance addresses federal review of the report.
6. Are known accessibility limitations described honestly?
A clear description lets the buyer understand what a limitation means for its users. Identify the affected task, the barrier, and any conditions or alternatives that matter. Avoid describing a planned correction as if it were already available and verified.
Unexplained gaps, inconsistent claims, unsupported Supports ratings, or discrepancies with observed behavior can raise more questions about the evidence than a specific, candid limitation. For example, “export has accessibility issues” is less useful than explaining which export format or task is affected and how.
Disclosure does not automatically satisfy legal or procurement requirements. It gives the buyer information to evaluate against those requirements.
7. Does the ACR match the actual product being demonstrated or purchased?
The report, test results, demonstrations, questionnaire answers, and accessibility statement should tell a consistent story about the offered product. Where a trial environment differs from the evaluated release or configuration, explain the difference instead of treating the environments as interchangeable.
A demonstration that exposes an undocumented barrier may prompt the buyer to ask whether the ACR needs correction or further testing. An outdated questionnaire answer can create the same problem even when the report itself is accurate.
Accessibility procurement readiness brings these materials together so the team can explain the evidence and respond consistently.
8. Is there evidence of remediation or an accessibility roadmap?
A buyer may ask whether significant barriers are being addressed, who owns the work, and whether completed fixes have been retested. A formal roadmap is not a universal requirement, but the vendor should distinguish unresolved findings, work in progress, and verified improvements.
Use remediation dates and commitments that the organization has actually approved. If a fix is included in a later release, make clear which version was verified and whether the ACR has been updated. Accessibility remediation and retesting can connect implementation work to new evidence.
9. Can the vendor answer follow-up accessibility questions?
Submitting an ACR may start a discussion rather than end it. Procurement staff, accessibility specialists, security or compliance teams, customers, and product stakeholders may need clarification.
Identify someone who can explain what was tested, how it was tested, the report date, known limitations, current remediation status, and internal accessibility ownership. Sales should know when to bring in a technical reviewer instead of guessing at an answer.
Include follow-up responsibilities when planning support for accessibility questionnaires and procurement reviews, so the report and the team’s responses stay aligned.
10. Does the accessibility evidence match what the buyer actually requested?
Compare the response with the request item by item. The buyer may need an ACR in a particular edition, testing information, an accessibility statement, questionnaire responses, a demonstration, remediation information, or other supporting documentation.
A well-prepared report can still leave the request unanswered if it covers a different standard, product, or use case. Clarify ambiguities and identify missing evidence before submission.
For federal standard ICT, Section508.gov describes supporting information such as evaluation methods and issue details, and recommends considering demonstrations, remediation plans, content examples where relevant, and hands-on testing. Those examples do not mean every commercial purchaser requires the same materials.
Red flags that deserve a closer look
Potential VPAT/ACR red flags include:
- An old report for a rapidly changing product.
- No clear product or version identification.
- No evaluation methodology.
- Every criterion marked Supports without useful context or remarks.
- Repeated boilerplate explanations.
- A mismatch between product behavior and ACR statements.
- A report that omits standards requested by the buyer.
- Accessibility limitations the vendor cannot explain.
- Significant product changes since the report was prepared.
These are reasons for additional review, not automatic evidence that an ACR is invalid. A Supports rating is not itself suspicious, and remarks are not mandatory for every such rating. The question is whether the available evidence and explanations are sufficient for the review.
What a strong ACR looks like
A strong ACR lets a buyer understand the evaluated product and ask informed follow-up questions. It generally:
- Identifies the product, version, and scope clearly.
- Uses the appropriate VPAT edition.
- Explains the evaluation methods.
- Provides specific, useful remarks.
- Describes limitations accurately.
- Aligns with current product behavior.
- Reflects current accessibility evidence.
- Provides enough context for an informed buyer review.
Report quality depends on accuracy and evidence, not on having the fewest disclosed limitations. The buyer still evaluates the product against its requirements.
Procurement readiness before the request arrives
The best time to organize accessibility evidence is before an active procurement deadline. Review the existing ACR, product testing, accessibility statement, remediation status, common questionnaire responses, internal ownership, and customer-facing accessibility language while there is time to resolve gaps.
For SaaS and software vendors, product releases can change the facts behind an answer. Assign responsibility for checking the evidence after relevant changes and for keeping customer-facing materials consistent.
CompliCorp can help organize the evaluation, reporting, and response work around the buyer’s request. Preparation supports a clearer review; it does not guarantee approval.
Frequently asked questions
What does procurement look for in a VPAT?
Reviewers commonly look for the product and version evaluated, report date, relevant standards, testing methods, clear ratings, and explanations of known limitations. They may compare the ACR with demonstrations, other documentation, or their own requirements. A useful report gives them enough detail to understand what the product supports and what needs further discussion.
How can you tell if a VPAT is current?
Compare the ACR’s product version, scope, and evaluation dates with the product being offered. Ask what has changed since testing and whether those changes affect the findings. A recent cover date alone does not establish that the underlying evidence is current.
Is a VPAT enough for procurement?
A completed ACR may answer an initial request, but it may not cover the buyer’s entire review. The purchaser can also ask for testing details, explanations, demonstrations, questionnaire responses, or remediation information. Read the actual request before deciding that sending the report completes the response.
What makes a good Accessibility Conformance Report?
A good ACR clearly connects its product scope, testing methods, ratings, and explanations. It uses the appropriate edition, describes known limitations, and reflects the evaluated product accurately. A reviewer should be able to understand the basis of a claim and identify useful follow-up questions.
Do procurement teams care how a product was tested?
They may, because evaluation methods help reviewers judge what the conformance claims are based on. Useful details include representative workflows, platforms, assistive technologies, and the role of manual and automated checks. The depth of review varies by purchaser and product.
Is “Partially Supports” bad in a VPAT?
It identifies a limitation that needs to be understood, not a universal procurement rejection. The buyer should examine the affected functionality, user impact, available alternatives, and applicable requirements. A clear explanation is more useful than an unsupported Supports rating, but disclosure does not guarantee acceptance.
Can a buyer request more accessibility evidence than a VPAT?
Yes. A buyer may request supporting test information, a demonstration, access to the offered product, an accessibility statement, or a remediation plan. Federal guidance provides specific examples for ICT purchasing; other buyers may use different processes. Ask which materials are needed for the particular review.
How often should an ACR be updated?
Review the ACR whenever product or reporting changes could affect its accuracy, rather than assuming a universal expiration period. Significant releases, redesigned workflows, verified accessibility fixes, and changed requirements can all warrant an update. Confirm any report-age conditions in the buyer’s request.
Can a SaaS company prepare for accessibility procurement before an RFP?
Yes. A SaaS vendor can review its ACR, test evidence, known limitations, remediation status, and common questionnaire answers before a deal creates a deadline. Assign an accessibility contact and a process for checking documentation after product changes. That preparation gives the team a clearer starting point for each buyer’s request.
Primary source references
ITI is the source for VPAT terminology and current editions. Section508.gov supports the federal reporting and procurement examples; W3C supports the discussion of human accessibility evaluation. The checklist organizes these topics into practical review questions and is not a universal procurement standard.
- ITI — VPAT terminology, current templates, and editions
- Section508.gov — Request Accessibility Information from Vendors & Contractors
- Section508.gov — Understanding Vendor Claims in Accessibility Conformance Reports
- Section508.gov — How to Create an Accessibility Conformance Report Using a VPAT
- Section508.gov — ACR/VPAT Frequently Asked Questions
- W3C — Evaluating Web Accessibility Overview