How to Get a VPAT: ACR vs VPAT, and What SaaS Companies Need to Know

If you sell software to a university, a school district or a government agency, sooner or later procurement will ask for "your VPAT." This guide explains what that means, the difference between a VPAT and an ACR, what's different for SaaS products, and how to get a report that holds up.

What a VPAT is

VPAT® stands for Voluntary Product Accessibility Template. It's a free template published by the Information Technology Industry Council (ITI). The report goes through accessibility criteria one by one and says, for each, whether your product Supports, Partially Supports, Does Not Support, or the criterion is Not Applicable, with remarks explaining the details.

ACR vs VPAT

The VPAT is the blank template. Once it's filled in for a specific product and version, it's called an Accessibility Conformance Report (ACR). Buyers often say "VPAT" when they mean the completed ACR, so if someone asks for your VPAT, they want your ACR.

Which edition do you need?

The current version is VPAT 2.5, in four editions:

Edition	Reports against	Typical buyers
WCAG	WCAG 2.2	Most buyers; a good default
Section 508	Revised Section 508 (incorporates WCAG 2.0)	U.S. federal agencies, many U.S. universities and states
EU	EN 301 549 (incorporates WCAG 2.1)	Public-sector buyers in Europe
International (INT)	All three	Companies selling in several markets

If a buyer names an edition, use that one. If they don't, the WCAG or INT edition is usually the safest choice.

How to get a VPAT

1. Decide the scope. Which product, which version, which platforms and which edition. Date the report; an ACR describes the product as it was when tested.
2. Test the product. Automated scanning finds some issues. The rest need a person: keyboard-only testing, screen-reader testing, and checking things like error messages, focus order and timeouts against each criterion.
3. Fill in the template honestly. Use "Partially Supports" where that's the truth, and explain it in the remarks. Buyers' accessibility teams read these reports closely, and a report that says "Supports" everywhere tends to raise questions.
4. Keep it current. Update the report after significant releases, or at least once a year.

You can fill in the template yourself, either by downloading it from ITI or with our VPAT generator (score the first 10 criteria free; the completed report is $79). Many companies have the testing done by a third party, both for the expertise and because buyers tend to trust an independent review more.

VPAT for SaaS products

SaaS products raise a few questions that a simple website doesn't:

• Test the logged-in product, not just the marketing site. Buyers care about the app their staff and students will use every day: sign-in, dashboards, forms, editors and settings.
• Cover each platform. If you have web, iOS and Android apps, either write separate ACRs or clearly separate the results for each platform in one report.
• Name the version and date. SaaS changes constantly. State which release you tested, and plan to refresh the report on a regular schedule.
• Account for third-party components. Embedded editors, video players, payment forms and sign-in providers are part of what users experience. Note any you don't control in the remarks.
• Explain your roadmap. For "Partially Supports" items, buyers appreciate a short note on what you're fixing and when.
• Make it easy to find. Many SaaS companies link their latest ACR from an accessibility or trust page, which saves time on every security and procurement questionnaire.

Common mistakes

• Filling in the template without testing the product.
• Marking everything as "Supports."
• Leaving the remarks empty, so buyers can't tell what "Partially Supports" means.
• Sending an old report for a product that has changed a lot since.