How to Read a VPAT (and an ACR): A Buyer’s Guide for Procurement

Ask any software vendor for evidence of accessibility and you will be sent a VPAT. Ask three vendors and you will get three documents that look almost identical, all claiming near-total conformance, and no obvious way to tell which one is true. That is the problem with the VPAT: it is a template, not a certificate. Nobody grades it, nobody signs it off, and a vendor can complete it in an afternoon without ever running a screen reader. And yet it is the single most requested artefact in accessibility procurement — required by United States federal buyers under Section 508, expected across European public tenders through EN 301 549, and increasingly demanded by universities before a contract goes anywhere near legal. This guide explains what the document is, how to read the four conformance levels honestly, which patterns should worry you, and the five questions that turn a form into evidence.

VPAT or ACR? The distinction that trips everyone up

The two words are used interchangeably in conversation, and the difference is simpler than the confusion suggests. The VPAT (Voluntary Product Accessibility Template) is the blank form, maintained by the Information Technology Industry Council (ITI). The ACR (Accessibility Conformance Report) is the completed document a vendor produces by filling that form in. So when a procurement office asks for “your VPAT”, what they want is your ACR.

ITI publishes the template in four editions, and which one you receive matters more than most buyers realise:

• WCAG edition — WCAG success criteria only. Fine for a private-sector web product; thin for public procurement.
• Section 508 edition — WCAG plus the Revised Section 508 chapters. The default for United States federal and public-sector buyers.
• EU edition — WCAG plus EN 301 549. What European public bodies should be asking for.
• INT (International) edition — all three in one document. The most useful version to receive, because it lets one report satisfy buyers in several jurisdictions.

The current template revision is VPAT 2.5. If a vendor sends you a 2.0 or 2.1 report, the document predates WCAG 2.2 entirely and cannot speak to the nine success criteria added in October 2023 — including accessible authentication, consistent help and minimum target size. That is not automatically disqualifying, but it tells you when the vendor last took the exercise seriously.

The four conformance levels, and what they actually mean

Every row of an ACR carries one of four terms. Their plain meaning is narrower than it looks:

• Supports — the functionality meets the criterion with no known defects. It does not mean “tested exhaustively”; it means the vendor is unaware of a failure.
• Partially Supports — some part of the product does not meet the criterion. This is the most informative row in the whole document, because the accompanying note tells you which part and how bad it is.
• Does Not Support — the majority of the functionality fails the criterion.
• Not Applicable — the criterion is irrelevant to the product, for example a criterion about pre-recorded audio in a product containing no audio.

Read the remarks column first and the status column second. A row marked “Partially Supports” with the note “the date picker in the reporting module traps keyboard focus; fix scheduled Q4” is worth more to you than ten rows of unqualified “Supports”. It tells you the vendor tested, found something, understood it, and owns it.

Watch the scope statement too, usually a short paragraph near the top. A report that evaluates “the learner-facing web application” has said nothing about the administrative console your staff will live in, the authoring tools your faculty will use, or the mobile experience. Scope is where uncomfortable parts of a product quietly go missing, and narrowing it is entirely legal.

Six red flags in an accessibility conformance report

Most weak reports fail in the same recognisable ways. Look for these before you look at anything else:

1. “Supports” on every single row. Real software of any size has gaps. A perfect column is not a sign of excellence; it is a sign that nobody tested, or that someone decided the form was a marketing asset. Treat total conformance as a claim requiring more evidence, not less.
2. No date, or a date more than 12 months old. An ACR describes a product version at a moment in time. A report from 2023 describes software that no longer exists.
3. No product version. Without it you cannot tell whether the report covers what you are being sold.
4. Empty remarks. A column of “Supports” with no explanatory notes anywhere is a form that was filled in, not a product that was evaluated.
5. No evaluation methodology. A credible report names what was done: which automated tool, which screen readers and versions, which browsers, whether disabled users were involved. “Internal review” is not a methodology.
6. An overlay in the answer. If the response to a criterion is that an accessibility widget or toolbar resolves it, the underlying product does not meet it. Overlays sit on top of markup they cannot repair, and several overlay vendors have themselves been named in accessibility litigation.

Automated tooling detects only an estimated 30–40% of WCAG issues. So a report whose methodology is “we ran an automated scan” has, at best, checked a third of the standard — and specifically the third that does not include whether a screen-reader user can actually complete a task.

One further pattern is worth naming because it is easy to miss: the report that answers a different question than the one you asked. A vendor selling a learning platform may send you an ACR covering their public marketing website, which is a genuinely different product with a genuinely different codebase. The document will be accurate, current and entirely irrelevant. Check that the product name and version in the header match what is on the quote.

Five questions that turn a form into evidence

The ACR is the start of the conversation. These five follow-ups do more to separate genuine conformance from paperwork than any amount of reading:

1. “Who performed the evaluation, and were disabled people involved?” Self-assessment is normal and acceptable — most published ACRs are self-assessments — but the answer should be specific. An independent third-party audit is stronger; a vendor who claims one should be able to name the auditor and share the report.
2. “Show me the remediation plan for every Partially Supports row.” Dates and owners, in writing. This is the question vendors least expect and it is the most revealing.
3. “Does the scope cover the administrative and authoring interfaces?” Your staff and faculty are users too, and in education they are often the users with the most complex workflows.
4. “What happens when we report a barrier?” Ask for the acknowledgement window and the severity classification in writing, then put it in the contract. An accessibility defect that is triaged as a cosmetic bug will never be fixed.
5. “Can we test it ourselves during the trial?” A vendor confident in the report will hand you an account and encourage it. Thirty minutes with the keyboard unplugged and a screen reader running tells you more than the whole document.

Put the answers in the contract rather than the evaluation file. A conformance commitment, a remediation window for reported barriers and a right to re-test at renewal are worth more than any report, because they survive the next three product releases. Our 25-question accessible-LMS buyer’s checklist standardises this conversation across shortlisted vendors.

What is different in higher education

Universities apply an extra layer, and it is worth knowing before you start. Alongside the ACR, most institutions run a security assessment using the EDUCAUSE HECVAT, and larger institutions attach an accessibility rider to the contract — a clause committing the vendor to a conformance level, to remediation within a defined window, and sometimes to indemnify the institution against accessibility claims arising from the product. Harvard is among the institutions that require one.

The regulatory backdrop has hardened too. The United States Department of Justice rule under ADA Title II and the Section 504 rule from Health and Human Services both set WCAG conformance as an explicit obligation for public institutions on fixed dates, which converts “we should look into accessibility” into a named person’s deadline. We cover the timing and what it means for online courses in our guide to the ADA Title II and Section 504 deadlines.

One practical consequence: buy for the whole obligation, not just the platform. An institution can hold a flawless vendor ACR and still be non-conformant, because the courses published inside the platform carry uncaptioned video and untagged PDFs. The platform is the easy half. See what to run alongside Canvas for how the two halves fit together.

If you are the vendor being asked

The advice inverts cleanly. Publish the ACR at a stable public URL rather than emailing a PDF on request — buyers shortlist before they contact you, and a public report gets you into the shortlist. Use the INT edition so one document serves buyers in several jurisdictions. Name your methodology precisely, including screen-reader and browser versions.

Above all, disclose your gaps with dates. It feels commercially risky and it is the opposite. An experienced accessibility reviewer reads an all-green report as evidence of an immature programme; a report with eleven honest “Partially Supports” rows and a dated remediation plan reads as a team that knows its own product. Regenerate the report with each release so its date never embarrasses you, and keep a public accessibility changelog so the claim is auditable between reports.

Eduspera publishes its own Accessibility Conformance Report against WCAG 2.2 AA, EN 301 549 and Section 508, generated from a versioned file in the product repository so it is re-issued with every release rather than written once and left to age. Known limitations are listed openly, axe-core runs in the deployment pipeline, and our HECVAT answers are public so a security reviewer can qualify us before the questionnaire is sent. Institutions can start from the 12-week pilot kit.

Frequently asked questions

Is a VPAT a certification?

No. It is a self-assessment template with no certifying body, no audit requirement and no expiry. Any vendor can complete one. Its value comes entirely from the rigour behind it, which is why the methodology statement and the remarks column matter more than the status column.

How often should a VPAT be updated?

At least annually, and in practice with every significant release. A report older than 12 months describes software that has since changed. The strongest approach is to generate the report from a versioned file in the product repository so it is re-issued automatically with each release.

Who can create a VPAT?

Anyone — the vendor’s own team, an accessibility consultancy, or an independent auditor. Self-assessment is the norm and is acceptable as long as it is declared. An independent third-party evaluation carries considerably more weight in higher-education and government procurement.

Does a VPAT prove ADA or Section 508 compliance?

No. It documents a vendor’s assessment of conformance against a technical standard. It does not discharge your institution’s legal obligation, and it does not cover the content you publish inside the product. A perfect platform ACR and an uncaptioned course library still leave you non-conformant.

What should I do if a vendor has no VPAT at all?

Treat the accessibility claim as unverified and ask for one with a deadline. For a smaller vendor, a credible alternative is a dated accessibility statement naming the standard, the testing methodology and the known gaps. What you should not accept is a verbal assurance with nothing written behind it.