Reading a vendor's VPAT before you buy, and what to ask next

The Voluntary Product Accessibility Template (VPAT) is a template published by the Information Technology Industry Council (ITI). ITI's page says that a VPAT completed for a specific product is an ACR. So the document a vendor sends is their ACR; "VPAT" is the blank form it was made from. The template's instructions say it is "the vendor's responsibility to maintain the integrity of the data in the report": it is the vendor's own statement.

As of 2 November 2026, the current template is VPAT 2.5Rev, dated April 2025, in 4 editions. Check ITI's VPAT page for a later one.

Edition	Covers
WCAG	WCAG 2.0, 2.1 and 2.2
Revised 508	WCAG 2.0, and the Revised Section 508 standards (published 2017, corrected 2018)
EU	WCAG 2.0 and 2.1, and EN 301 549 V3.1.1 and V3.2.1
INT	All of the above

The EU edition of 2.5Rev covers EN 301 549 V3.1.1 and V3.2.1. ETSI published V4.1.1 in September 2026, which the 2.5Rev editions don't list, so an ACR made from them doesn't report against it.

The template lists what every ACR must contain, among them the product's name and version, the report date (month and year at least), contact information, the evaluation methods used, the standards covered, the definitions of the terms used, and an answer in the Conformance Level and Remarks and Explanations columns for each criterion. A document without these is not an ACR in the template's terms, whatever it is called. What it takes for a page to conform to WCAG explains how an ACR differs from a conformance claim.

Each row of an ACR gives one of these terms. These are ITI's definitions, word for word:

Term	ITI's definition
Supports	The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
Partially Supports	Some functionality of the product does not meet the criterion.
Does Not Support	The majority of product functionality does not meet the criterion.
Not Applicable	The criterion is not relevant to the product.
Not Evaluated	The product has not been evaluated against the criterion. This can only be used in WCAG Level AAA criteria.

3 rules in the template change how a row reads:

• For Partially Supports and Does Not Support, the remarks should identify the functions or features with issues and how they fall short. A Partially Supports row with an empty remark gives you nothing to plan around.
• In the WCAG tables, a row may say Supports where nothing on the product falls under the criterion, in keeping with WCAG's own reading of conformance. So a Supports for captions on a product with no video is correct, and not a warning sign.
• A vendor may use other definitions only if the Notes section says so. Read the Terms section before the tables.

Read the header before the tables. It answers the questions that decide whether the rows mean anything:

• Which product and version. The ACR describes one version. If the version on offer is newer, the rows describe software you aren't buying.
• When. The report date, and whether the Notes explain a revision.
• How it was tested. Evaluation Methods Used should say whether the testers knew the product, which assistive technology they used, which manual and automated tools, and which published or in-house method.
• Who tested. The template doesn't require a named tester. If a third party tested the product, this is where the report would say so; if it says nothing, assume the vendor tested it.

The warning signs are plain to see:

• Every row says Supports, and no remark explains any of them.
• Evaluation Methods Used names only an automated scan. A scan can't confirm many criteria, as what automated checks miss shows.
• The product version or the report date is well behind what you are buying.
• The template version is older than the current one, or the report has none of the required parts: a one-page letter claiming compliance is not an ACR.
• The ACR covers the main application, but the product embeds third-party parts it doesn't mention, such as a support chat or a consent banner.

The template says an ACR is there to help buyers make "preliminary assessments". These questions turn a preliminary assessment into one you can stand behind:

• Send the ACR for the version we would get, on the current template, with Evaluation Methods Used filled in.
• Who tested it: an internal team or a third party, and with which assistive technology?
• For each Partially Supports or Does Not Support row, what is the issue, is there a workaround, and when will it be fixed?
• Does the ACR cover the parts the product embeds from other suppliers?
• How do your users report an accessibility problem, and how long does a fix take?
• Will you fill in a self-assessment of your accessibility programme? NASCIO's Policy-Driven Adoption for Accessibility (PDAA) has a vendor self-assessment for this, built on 6 core criteria, from having a policy to making information about policy and progress available to customers.

Then test the product yourself on a trial instance, on your own key tasks: booking a room, cancelling it, finding an event. Use a keyboard alone, a screen reader and 200% zoom, and compare what you find with the rows that cover it. Test what you would deploy, embedded parts included: a support chat that never reads its replies, as in chat widgets that never announce their messages, or a consent banner that hides focus, as in cookie banners that hide keyboard focus and come last, is part of the product your users meet. If the product is itself an accessibility tool that runs on your site, such as an overlay or a monitoring dashboard, EaseWeb's accessibility vendor review sets its claims beside test results.

Few products support every criterion, so the choice is often the one that best meets the requirements, with the gaps written down. Each of these is a proof point in the procurement dimension of the W3C Accessibility Maturity Model, or a core criterion of PDAA:

• A roadmap for known issues: each open row with a fix date. PDAA asks vendors for a plan with dates for inaccessible ICT.
• Contract terms: the W3C model lists proof of vendor testing, warranties and remedies that include accessibility, and vendor corrective actions and remediation plans before and after deployment.
• An alternative access plan: until a gap is fixed, the alternative means people use instead, such as staff taking bookings by email or phone, written down and published, as in accessibility statements that are missing or say nothing.
• Monitoring: a defined way to take users' accessibility complaints to the vendor, and a retest of each new major version against the ACR.
• Renewals: the W3C model's Integrate level includes accessibility criteria in contract renewal negotiations. A renewal is the point at which open rows can still change the price.

A maturity model judges the organisation, not the product. The W3C model's 7 dimensions run from Communications to Support, each at 4 levels: Inactive, Launch, Integrate and Optimize. The model says it took those level names from PDAA, whose maturity model rates its 6 core criteria at Launch, Integrate and Optimize. Use the W3C model's procurement dimension to check your own buying process, and PDAA's self-assessment to compare vendors' programmes beside their ACRs.