Checking Vendor Accessibility Claims and VPATs
Vendors arrive with VPATs and conformance claims that range from rigorous to fictional. A practical guide to reading claims and testing the parts that matter.
Every platform and app vendor now claims accessibility conformance, and many produce a VPAT document to prove it. Some are careful audits. Others are template documents where every criterion supports a product the author never tested.
Stores inherit vendor claims when they publish vendor components. This guide covers how to read a VPAT with a sceptical eye, which claims to test yourself in an afternoon, and what to write into contracts so claims have consequences.
Read for specificity, not conclusions
A credible report names the version tested, the date, the methods, and the assistive technologies used, and its remarks describe actual behaviour. Rows marked supports with remarks like fully compliant throughout are assertions, not evidence.
Look hardest at the criteria vendors fail quietly: keyboard operation, focus visible, name role value for custom components, and status messages. Generic claims are thinnest exactly where interactive widgets most often break.
Test the claims that affect your shoppers
You do not need to re audit the vendor. Test the journeys your shoppers take through their component: open, complete, error, close, by keyboard and one screen reader. A claims document that survives contact with its own checkout, portal, or widget earns some trust.
Record what you tested and when. If a claim later proves false during a complaint, your dated spot checks show the store exercised judgement rather than pasting a vendor badge into its accessibility statement.
Ask the awkward questions directly
Ask who performed the evaluation, whether any criteria were marked partially supports or does not support and what the remediation timeline is, and how regressions are handled after updates. Vendors with real programs answer these fluently.
Ask how you will be notified of accessibility regressions in updates. The honest answer at most vendors is that you will not be, which is information: it means your own spot checks after updates are the monitoring system, and they should be scheduled as such.
Put accessibility into the contract
Contracts can require conformance to a named standard, remediation timelines for reported barriers, and notice for changes to the components you publish. None of this guarantees accessible code. It converts your complaint from a favour request into a contractual obligation, which changes vendor prioritisation.
At renewal, bring the register: findings, dates, vendor responses, fix times. Vendors improve fastest for customers whose records show the topic will return every renewal with better documentation than last time.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Keeping Evidence of Accessibility Remediation, ADA Risk in Subscription and Account Portals, and Documenting Accessibility Fixes for Legal and Insurance Reviews.
Frequently asked questions
What is a VPAT in plain terms?
It is a vendor filled template reporting how a product meets accessibility criteria, criterion by criterion. Its value depends entirely on who tested what, when, and how honestly the remarks describe real behaviour.
What makes a conformance claim look weak?
No version, date, or method, every row marked supports with boilerplate remarks, and silence on the hard criteria like keyboard and focus. Specific, dated, partially honest reports are more credible than perfect ones.
Should stores test vendor components themselves?
Yes, as spot checks on the journeys shoppers actually use, by keyboard and screen reader. The aim is not a full audit. It is verifying that headline claims survive contact with the vendors own component.
What contract language helps?
A named standard to meet, timelines for remediating reported barriers, and update change notice. It will not write accessible code, but it makes your findings obligations rather than requests.