How to Read a VPAT
Trust note
This article was written by a person and reviewed against accessibility.chat editorial standards. Treat it as research and education rather than legal advice. We prioritize primary sources and correct material errors.

Read properly, it's your cheapest leverage. Filed unread, it's worse than nothing.
A VPAT — formally an Accessibility Conformance Report (opens in new window), though almost nobody calls it that — is the document a vendor produces about their own product's accessibility. Somebody is going to hand you one this month, probably attached to an email that says something like "see attached, we're fully compliant," and I want to save you from the mistake I watched a lot of new coordinators make: filing it, unread, as proof you did your job.
An unread VPAT isn't evidence of diligence. It's a false record of diligence, which is arguably worse than having nothing on file at all, because it looks like you checked and you didn't.
Here's how to actually read one, and it takes about twenty minutes once you've done it a few times.
First: nobody can "certify" this, and anyone who claims to already told you something
Accessibility isn't a state a product achieves once and keeps forever. It's a practice, maintained continuously, and any given page can regress the day after somebody checks it. A vendor who tells you their product is "fully certified compliant" has either misunderstood their own document or is hoping you won't ask what that word is doing in a sentence where it doesn't belong. Neither one is a great sign.
The eight-point test, before you read a single line
Run this first. It takes five minutes and it filters out most of what you'll receive.
Age. Is the report dated within the last twelve months, or at least newer than the product's last major release? An undated report, or one clearly older than the software it describes, isn't describing the thing you're about to buy.
Product identity. Does it name the exact product, version, and which interfaces are covered? "Our platform" with no version number anywhere is a red flag by itself.
Author. Is there a named author or firm with stated accessibility qualifications, or is this anonymous — or worse, written by sales?
Standard. Is it evaluated against a current version of WCAG (opens in new window), at Levels A and AA, criterion by criterion? A report that only covers an obsolete version, or only A-level, isn't measuring what your legal obligation actually requires.
Method. Does it describe both automated and manual testing, name actual tools and assistive technology used? "Evaluated internally" with no method described tells you nothing about how hard anyone actually looked.
Scope. Does it state plainly what was and wasn't tested? Silent scope is the worst kind — assume the untested parts are exactly where the gaps are hiding, because that's usually true.
Terms. Does it use standard conformance vocabulary correctly, or has someone invented their own rating like "mostly compliant" — a phrase that means nothing and exists specifically so it can't be pinned down?
Ratings explained. Does every rating that isn't a flat "Supports" carry an actual remark explaining why? A bare "Partially Supports" with an empty remarks column is a rating with no information attached to it.
A report that fails three or more of these points isn't evidence of anything. Send it back and ask for a better one before you spend another minute on it. This isn't being difficult. It's the minimum standard for a document you're about to rely on.
Then, and only then, read the actual content
Once a report clears the eight-point test, read every row marked below full support, and every remark under "Supports" too — vendors sometimes bury a meaningful caveat in a row that technically passed. Quote what you find rather than paraphrasing it. Your own words, six months from now, might not mean what you thought they meant when you wrote them. The vendor's exact words will.
Then judge materiality: which of these gaps actually touch what your residents do with this product? A missing alt-text attribute on a decorative background image is not the same finding as a form that can't be completed with a keyboard. Write that judgment down either way — the gaps you decided didn't matter are just as much a record as the ones you flagged.
The discipline that keeps you out of trouble
Here's the one rule I'd want you to remember if you forget everything else in this piece: everything you record is a claim about the document, never a claim about the product.
"The ACR is dated 2021 and names no assistive technology tested" is a fact. It's defensible, it's specific, and nobody can argue with it because it's just describing what's on the page. "This product is inaccessible" is a different kind of statement entirely — it's an assertion about someone's business, and it's not one you're actually positioned to make from a document review. Stick to describing what the paper says, when it was written, and what it leaves out. That discipline is what makes your record something you can stand behind later, instead of something a vendor's attorney picks apart in a room you'd rather not be in.
Read enough of these and you'll start to see the pattern fast — the same three or four gaps show up across most products in a given category, and the good vendors are the ones whose documentation gets more specific every year instead of staying vague forever. That's worth noticing too. A vendor who improves their reporting is telling you something different than one who sends the same boilerplate every renewal cycle.
This isn't legal advice about whether a specific vendor's report clears your obligations — that's a judgment for you and your counsel on your specific facts. If you want a second pass on a page the vendor claims already conforms, ask Luke to check it before you take the report at its word. Our methodology covers how we verify claims like these, and WCAG success criteria is worth bookmarking for whenever a "Partially Supports" row doesn't explain itself.
Previous: procurement language that actually works · Next: building the record
Sources: Accessibility Conformance Report (ACR) overview (opens in new window) · ACR/VPAT Frequently Asked Questions (opens in new window) · WCAG 2 Standards Overview (opens in new window) · U.S. Access Board — Revised 508 Standards (opens in new window)
About Jeff Fryer
Jeff Fryer spent years working kitchens before moving into ADA compliance work for local government. He writes from that experience -- direct, plainspoken, allergic to compliance theater. Contributing writer at accessibility.chat.
Jeff Fryer is a person, not one of the AI analyst lenses this site also publishes under. A named human is accountable for this article.
Specialization: Local government ADA compliance, contributed from direct field experience
Authorship and Editorial Process
Jeff Fryer wrote this article. AI was not used to draft it. It went through the same editorial checks as everything else published here.