EZUD VPAT and ACR: Read the Evidence Before Choosing a Product
VPAT and ACR: Read the Evidence Before Choosing a Product
Start an accessibility procurement review with the product version, the tasks your users must complete and the standards your purchase requires. Then read the Accessibility Conformance Report against that scope. A useful report connects each conformance statement to the functionality evaluated and explains any known limitations.
Keep a separate review worksheet for questions and supporting evidence. This lets procurement staff, accessibility specialists and the product owner examine the same issues without turning the report into a collection of disconnected email answers.
Distinguish the template from the completed report
The Information Technology Industry Council provides the Voluntary Product Accessibility Template, or VPAT®. A completed template for a particular product becomes an Accessibility Conformance Report, or ACR. ITI does not certify products or approve completed reports; its VPAT resource page supplies the template and instructions.
As checked on November 5, 2026, ITI lists VPAT 2.5Rev editions dated April 2025. The 508 edition addresses Revised Section 508, the EU edition addresses EN 301 549, the WCAG edition addresses WCAG, and the INT edition combines those standards. The included WCAG versions differ: 2.0 in 508, 2.1 in EU, and 2.2 in WCAG and INT.
Select the edition and standards that match the procurement requirements. Save the version you used with the evaluation records so later reviewers can understand exactly what the report covered.
Check scope before reading the ratings
Section508.gov’s ACR guidance describes reports as evidence for evaluating ICT accessibility in procurement. Begin by matching the named product to what you intend to purchase. Include its release, modules, platform, configuration and supporting materials.
| Field to verify | Question for the review worksheet |
|---|---|
| Product and release | Does the report cover the version being purchased? |
| Included components | Are the administrator interface, mobile app and exported documents included where relevant? |
| Evaluation date | What changed between testing and the proposed deployment? |
| Methods and environments | Which manual checks, automated tools and assistive technologies were used? |
| Contact | Who can explain findings and provide updated evidence? |
A report for the public marketing site cannot answer whether employees can complete tasks in an authenticated application. Likewise, a desktop evaluation may leave a separately developed mobile app outside its scope. Identify these gaps before comparing vendors’ conformance labels.
Read each conformance statement with its explanation
Section508.gov’s report-authoring instructions describe the standard terms. “Supports” means there is at least one conforming method without known defects, or equivalent facilitation. “Partially Supports” identifies some functionality that does not meet the criterion. “Does Not Support” indicates that most functionality does not meet it. “Not Applicable” means the criterion is irrelevant to the product.
Read the remarks to learn which screens and actions are affected. A broad label without that context gives a buyer little information about actual use. For an inapplicable criterion, request the reason if it is unclear how the conclusion follows from the product’s features.
The authoring instructions reserve “Not Evaluated” for the optional Level AAA table. Treat unevaluated required functionality as an evidence gap to resolve before making a procurement decision. Use the current template’s instructions when preparing the report.
Turn a partial-support row into a task question
Suppose a report says keyboard access is partially supported because a scheduling grid requires a pointer. Write down the specific task: choosing an appointment, changing it and confirming the new time. Ask whether an alternative interface provides the same available slots and produces the same result.
Request a demonstration of the whole sequence in the proposed release. Include validation errors and a return visit to the saved appointment. A workaround that depends on another person or omits a required action needs to be assessed against the service your organization intends to provide.
For each issue, record 4 items: the affected task, the users affected, the available workaround and the evidence supporting it. This converts a standards row into information the service owner can use when assessing operational impact.
Ask for issue detail and a realistic remediation plan
GSA’s ACR Issue Detail Supplement provides a companion structure for describing severity, affected areas, affected users and workarounds. Use that detail to distinguish a blocked core task from a less disruptive issue elsewhere in the product.
Maintain a remediation register with an owner, proposed release, acceptance check and retest result for each unresolved defect. Ask whether a promised correction is available in a released version, a preview or only a roadmap. Those stages carry different deployment implications.
For a recurring subscription, decide how updates will be communicated and rechecked. A fix to one component can change another interaction. Keep the original finding and the verification result so the procurement record shows what was resolved and what remains open.
Validate the claims that matter to your workflow
Section508.gov’s guidance on vendor claims recommends independent conformance validation where possible. Plan a focused demonstration around representative tasks, then use a qualified evaluation process for the required standards.
Prepare the data and roles needed for the demonstration. For example, test both the employee who submits a request and the manager who approves it. Include a long entry, a missing required field and an expired session so the review reaches states that a polished demonstration might omit.
Record the browser, operating system, assistive technology and product configuration with the result. Capture reproducible steps and the expected outcome. This makes a disagreement about a finding easier to investigate and lets the vendor reproduce the same conditions.
Carry the findings into the purchase decision
Federal purchasing requirements come from the applicable standards and solicitation. Section508.gov’s ACR FAQ explains why vendors are asked to provide reports and why an incomplete level of conformance can still be evaluated against other available products. Follow the specific solicitation and the agency’s process when deciding what documentation is required.
For any organization, bring the evaluation back to the intended service: which users can complete the essential tasks, what assistance would be needed, what corrections are committed and how acceptance will be verified. Assign unresolved decisions to the responsible procurement and accessibility staff.
Keep the final ACR, issue details, demonstration notes and acceptance conditions together. Review them when the purchased configuration changes or a new release alters an essential workflow. That creates a usable record for the people operating the service after the purchase is complete.