Voluntary Product Accessibility Template (VPAT)

What a VPAT is for

A VPAT is not a certification in itself. It is a supplier statement used to communicate how a product aligns with accessibility criteria, where it complies, where it partially complies, and where exceptions remain. That makes it a procurement artefact as much as a technical one, because buyers use it to compare offerings and understand what evidence sits behind accessibility claims.

In practice, the value of a VPAT depends on the quality of the underlying evaluation. A strong template reflects real testing, clear versioning, and a disciplined account of exceptions, rather than marketing language or a generic “meets requirements” claim.

How VPATs are used in procurement and compliance reviews

VPATs help procurement teams, accessibility reviewers, and legal or compliance stakeholders ask a consistent question: what exactly is supported, under which standard, and with what limitations? They are especially useful when buyers need a repeatable way to compare software, hardware, and services against accessibility expectations before contract award or renewal.

A useful VPAT should map product behaviour to the relevant criteria, identify known gaps, and reference the evidence used to reach each conclusion. That makes it easier to separate a genuinely accessible product from one that only appears compliant on paper. For organisations running formal vendor evaluation, a structured scoring approach such as Buyer's Guide Methodology and Scoring Template can help keep accessibility evidence, exception handling, and procurement decisions consistent.

VPATs also sit inside broader due diligence. Buyers should treat them as one input, not the final answer, because the document may be dated, incomplete, or based on a narrow product configuration. The document is most useful when it is read alongside demonstrations, accessibility test results, and contract commitments.

What makes a VPAT credible

A credible VPAT is specific, current, and traceable. It should identify the exact product or service version covered, explain what was tested, and describe any exceptions in a way that is meaningful to a buyer rather than defensive to a supplier. Vague language, recycled statements, or unexplained “partial support” entries reduce trust quickly.

The best VPATs distinguish between native product capability, customer configuration, and compensating workflow. That distinction matters because accessibility often breaks at the boundary between the product itself and how it is deployed, customised, or integrated. Buyers need to know which gaps are intrinsic and which could be addressed operationally.

Because the template is supplier-produced, the real assurance value comes from disciplined evidence handling, not from the form alone. A well-written VPAT helps procurement teams compare vendors, but it does not replace hands-on accessibility validation or contractual accountability.

Common pitfalls when relying on VPATs

The most common mistake is assuming that a completed VPAT equals an accessible product. It does not. It only documents the supplier's position, and that position may be out of date, incomplete, or framed around a product edition that is not the one being purchased.

Another pitfall is failing to interrogate exceptions. An exception may be acceptable in one buying context and disqualifying in another, depending on how central the affected function is to the user journey. Buyers also need to watch for VPATs that describe accessibility at a high level while avoiding the detailed behaviours that actually matter, such as keyboard navigation, focus order, labels, captions, or assistive technology compatibility.

For organisations that depend on accessibility commitments in tenders, contracts, or public-sector procurement, the document must be treated as evidence to verify, not a label to trust automatically. That is where review discipline matters most.

Practitioner Guidance

Why practitioners should care: A VPAT can speed up accessibility assessment, but only if the organisation treats it as a structured evidence document rather than a marketing attachment. The practical job is to verify whether the stated support matches the product version, deployment model, and user experience being procured.

What to watch for: Pay close attention to unspecified exceptions, stale product references, and broad claims that are not tied to test evidence. Those are the signals that a VPAT may be incomplete or that further validation is needed before procurement decisions are made.

Related resources from NHI Mgmt Group

• What should product and QA teams do when accessibility and usability conflict?
• How should identity teams move from ticket queues to product ownership?
• Why does product thinking matter for IAM governance?
• What is the difference between identity operations and identity product management?