Someone hands you a PDF. It is twenty pages long, dense with acronyms, and a procurement deadline is sitting three days away. Somewhere in your inbox, a vendor's sales rep wrote "attached is our VPAT" like that settles the question. It does not. You open the file and see a grid of criteria, a column of short codes, and a column of dense remarks, and nothing in your job description ever taught you which of those columns actually tells you whether the product will work for your users.
This happens to buyers, procurement leads, and IT managers constantly, and it is not a knowledge gap you should feel bad about. A VPAT was built by and for accessibility specialists, then handed to people who are not accessibility specialists and expected to make a purchasing decision from it. This guide fixes that. No jargon you have not already been given a definition for, no assumption that you know what "4.1.2" means. Just a working understanding of the document, section by section, so the next time one lands in your inbox you can actually read it.
The Stat: Federal agencies are required under Section 508 to evaluate ICT purchases using a VPAT/ACR before procurement. (Source: Section508.gov)
What a VPAT actually is, in one sentence
A VPAT (Voluntary Product Accessibility Template) is a standardized form a vendor fills out to describe how its product measures up against a set of accessibility standards. Once filled out, the completed document is called an ACR (Accessibility Conformance Report). People use the terms almost interchangeably in conversation, but it helps to keep the distinction straight: VPAT is the blank template, ACR is what you get back when a vendor fills it in. When someone emails you "our VPAT," what they actually mean is "our completed ACR."
The template itself was built by industry groups and government accessibility offices specifically so that every vendor would report against the same criteria, in the same format, instead of everyone writing a free-form accessibility summary that says whatever sounds good. That standardization is the whole point. It means a VPAT from one vendor should be structured the same way as a VPAT from a competitor, which is exactly what makes it possible for you to compare them.
The four things that matter on every page
Strip away the cover page, the revision history, and the legal boilerplate, and every VPAT table comes down to four recurring elements, repeated criterion by criterion for however many pages the standards span.
1. The criterion itself. This is a specific, numbered accessibility requirement, usually pulled from WCAG (the Web Content Accessibility Guidelines) success criteria, like "keyboard operability" or "text alternatives for non-text content." Do not worry about memorizing the numbering scheme. Read the plain-language description next to the number; that description tells you what the row is actually testing.
2. The conformance level. This is the column everyone reaches for first, and reasonably so. It typically reads one of a small handful of terms: Supports, Partially Supports, Does Not Support, Not Applicable, or occasionally Not Evaluated. Each of these means something specific. "Supports" means the product fully meets that criterion. "Partially Supports" means it meets some but not all of it, which is common and not automatically disqualifying, but it is a flag that deserves follow-up. "Does Not Support" is a straightforward miss. "Not Applicable" means the criterion does not apply to this particular product (a criterion about video captions is not applicable to a product with no video content, for example). "Not Evaluated" is the one to treat with real caution: it does not mean the product passes, it means nobody checked.
3. The remarks and explanations column. This is the column non-experts skip and experts read first. It is where the vendor is supposed to explain the conformance rating in detail: which specific screens or components have the issue, what the workaround is, whether a fix is already scheduled. A row marked "Partially Supports" with a thorough, specific remark is far more trustworthy than a row marked "Supports" with an empty remarks field. Vague or missing remarks are a signal to ask more questions, not a signal to move on.
4. The applicable standards section. Near the top of the document, the VPAT will state which edition and version of the standards it is reporting against; commonly WCAG 2.1 or 2.2 at the AA level, and for U.S. federal buyers, the Revised Section 508 standards as well. This matters because a VPAT written against an older WCAG version may not reflect newer criteria that matter to your organization. Always check the date and version before you check anything else.
A five-minute reading order for a first pass
You do not need to read a VPAT front to back the first time. Use this order instead.
- Check the date. A VPAT more than a year or two old, especially for actively developed software, may describe a version of the product that no longer exists.
- Check the standard and edition. Confirm it is reporting against the WCAG version and Section 508 requirements relevant to your context.
- Scan the conformance column for "Does Not Support" and "Not Evaluated." These are your priority follow-up items.
- Read the remarks next to every "Partially Supports." This is where the real, specific detail lives.
- Note the product description. Confirm the VPAT is describing the actual product and version you are buying, not a different tier or a legacy release.
If that scan raises questions, that is normal and expected. A VPAT is a starting point for a conversation with the vendor, not a final verdict you accept silently.
Where this fits next to the rest of your buying process
This guide is deliberately just the glossary: what each part of the document means so you can read one cold. If you are running a full procurement process and need to score and compare VPATs across several competing vendors, our vendor evaluation guide for procurement teams walks through that structured comparison process in detail. If you are on the other side of the table and your own company needs to produce a VPAT for customers, see our guide on how to write a VPAT or ACR as a SaaS vendor. And if you are trying to understand how a VPAT relates to a public-facing accessibility statement, that distinction is covered in our piece on accessibility statements and VPATs.
For the source documents themselves, the Section508.gov site maintains the official federal guidance on VPAT use in procurement, the Information Technology Industry Council maintains and publishes the current VPAT template, and the U.S. Access Board maintains the underlying ICT accessibility standards the reports are measured against. Bookmark all three; you will refer back to them.
The one habit worth building
If you take one thing from this guide, make it this: never treat a VPAT as a pass or fail stamp. Treat it as a structured, honest disclosure that you are entitled to interrogate. A product with a few "Partially Supports" rows and detailed, specific remarks is often a safer and more transparent choice than one with a suspiciously clean sheet of "Supports" and no explanation anywhere. Reading a VPAT well is less about finding the perfect score and more about learning to tell a candid report from a rubber stamp.
Getting comfortable with this takes a handful of real documents, not a checklist alone. If you would rather have someone experienced walk through a specific VPAT with you before a purchase decision, or help your organization request a more complete one from a vendor, our team reviews these documents regularly as part of our SaaS accessibility solutions.
Have a VPAT in hand right now and want a second set of eyes on it? Reach our team directly at experts@wcag.world, or learn more about how we support buyers and vendors at wcag.world/solutions/saas.