The request almost always shows up late. The security questionnaire is done, pricing is agreed, legal is happy, and then someone in procurement asks for “your current VPAT.” If you don’t have one, the deal sits in a queue while you scramble to produce a document you’ve never written.
This guide covers what buyers are actually asking for, which version to fill in, how the testing works, and what separates a report procurement trusts from one it sends back.
What buyers are actually asking for
A VPAT (Voluntary Product Accessibility Template) is a blank form. Once you test your product against it and fill it in, the finished document is called an Accessibility Conformance Report, or ACR. When a buyer says “send us your VPAT,” they mean the ACR.
It lists every accessibility criterion in a standard and records, for each one, whether your product supports it, partially supports it, doesn’t support it, or whether it doesn’t apply, with a short explanation beside each answer.
Who asks depends on who you sell to:
| Buyer | What drives the request | Standard they usually cite |
| U.S. federal agencies | Section 508 procurement rules | Revised Section 508 |
| State and local governments, public universities | ADA Title II web rule | WCAG 2.1 AA |
| EU customers | European Accessibility Act, public procurement | EN 301 549 |
| Large enterprises | Internal procurement and vendor-risk policies | Usually WCAG 2.1 or 2.2 AA |
The public-sector row matters more than it did a year ago. The Department of Justice moved the Title II compliance dates to April 26, 2027 for governments serving 50,000 people or more, and April 26, 2028 for smaller ones, but left the WCAG 2.1 AA standard untouched. Agencies working toward those dates are already screening the software they buy, which means vendors get asked now.
Why “we’ll just fill it in ourselves” usually backfires
You’re allowed to complete your own ACR. Nothing stops a product manager from opening the template and marking every row “Supports.” The problem is what happens next.
Accessibility-literate buyers spot-check. They tab through your login screen without a mouse, turn on a screen reader, zoom to 200%. If the report claims full support and the date picker traps keyboard focus, the report stops being evidence and becomes a credibility problem for the whole deal.
Self-assessments tend to go wrong in predictable ways:
• They rely on automated scanners. Scanners are useful, but they only catch part of the picture. They can’t tell whether alt text is meaningful, whether a custom dropdown makes sense to a screen reader, or whether focus order follows the visual layout.
• They test the marketing site, not the app. Buyers care about the logged-in workflows their staff will use every day.
• They skip third-party pieces. Your embedded chat widget, payment iframe and help-center platform are part of the product the buyer experiences.
If nobody on your team has tested against WCAG before, this is where specialist accessible services earn their fee: a manual audit by people who test with keyboards and screen readers daily, remediation guidance your developers can act on, and an ACR written from the same test results. Some government solicitations also require third-party testing, so check the RFP language before you decide.
Pick the right edition before anyone starts testing
This step decides what gets tested, so settle it first.
The Information Technology Industry Council maintains the template and currently publishes version 2.5Rev in four editions of the VPAT template, each mapped to a different standard. ITI also makes clear that there’s no such thing as VPAT certification. It doesn’t review or approve completed reports, so anyone selling you a “certified VPAT” is selling a phrase.
| Edition | Standard covered | WCAG version inside | Pick it when |
| 508 | Revised Section 508 | WCAG 2.0 | You sell mainly to U.S. federal agencies |
| EU | EN 301 549 | WCAG 2.1 | You sell into EU public sector or need EAA documentation |
| WCAG | WCAG only | WCAG 2.2 | Your buyers only cite WCAG |
| INT | All three combined | WCAG 2.2 | You sell to a mix of markets |
For most SaaS companies with customers in more than one market, INT is the safest default. It takes longer to fill in, but you send one document to everyone instead of maintaining three.
How the work actually runs
A first ACR has five stages. Skipping any of them is how teams end up redoing the report.
1. Scope it. Name the product and version being evaluated. List the user flows in scope: sign-up, login, onboarding, the two or three core workflows, settings, billing, notifications and help content. Include third-party components that appear inside your interface.
2. Audit it. Test each flow against the criteria in your chosen edition, using keyboard-only navigation, at least one screen reader, zoom and reflow, and color-contrast checks alongside automated scans.
3. Fix what you can. Most first audits surface a backlog. Prioritize issues that block a task entirely, such as a form you can’t submit without a mouse, over cosmetic ones.
4. Re-test. Confirm each fix works. Fixes that look right in code often fail with an actual screen reader.
5. Write the report. Fill in each row with the conformance level and a specific remark. Record the evaluation date and methods used.
Don’t wait for a clean audit. You don’t need a perfect product to issue an ACR. You need an accurate one. A report published now with honest gaps is more useful to a buyer than a flawless report that arrives after their deadline.
What a credible report looks like
Procurement teams read a lot of these. The ones that pass quickly share a few traits:
• Specific remarks. “Partially Supports: the data export dialog does not return focus to the trigger button when closed” tells a buyer exactly what to expect. “Partially Supports: some issues” tells them nothing.
• Honest use of “Partially Supports.” It isn’t a failing grade. A report full of “Supports” with no remarks looks untested.
• A visible evaluation date and product version, so the buyer knows which release was evaluated.
• Stated methods, including which assistive technologies and browsers were used.
• A remediation timeline for open issues, either in the notes or as a separate roadmap you can share on request.
Keep it current without starting over
An ACR describes one version of your product. If you ship weekly, it starts aging the day you publish it.
You don’t need a full re-audit every quarter. Re-test the areas a major release touched and update those rows. Add basic accessibility checks to your definition of done: keyboard access, labels on form fields, and contrast on new components. Log accessibility bugs in the same tracker as everything else so they get fixed in normal sprints instead of piling up before the next report.
Plan a fuller refresh when you redesign navigation, rebuild a core workflow, or switch component libraries, since those changes touch almost every row.
The short version
Find out which standard your buyers cite, then choose the matching VPAT edition, or INT if you sell to several markets.
Test the logged-in product with keyboards and screen readers, not just a scanner, and include the third-party pieces inside your interface.
Publish an honest ACR now, with specific remarks and a fix timeline, then keep it current release by release. A buyer can work with known gaps. A report that doesn’t match the product is what stalls the deal.
Post Comment
Share your thoughts about this article.
Be the first to post a comment!
