The deal is almost closed. The demo went well, the price is agreed, the contract is drafted, and then an email arrives from the buyer’s procurement team: “Before we can proceed, please send us your VPAT.”

If you’re the vendor, that sentence can stop a sale cold. If you’re the buyer, you may have sent it without being entirely sure what you’ll do with the document when it arrives. And in both cases, there’s a decent chance everyone at the table is quietly working from the same wrong assumption: that a VPAT is some kind of accessibility certificate, a stamp that says the product is fine.

It isn’t. And that misunderstanding, on both sides of the table, causes more wasted money, stalled deals, and unpleasant surprises than almost anything else in accessibility. We prepare VPATs and ACRs for a living, so in this guide we’ll explain what the document really is, what it absolutely is not, how to read one, what to demand from a vendor who hands you one, and how an honest one gets built. If you’re staring at a VPAT request right now and need help fast, you can also just reach out for a free consultation, this is one of the most common calls we get.

What a VPAT Actually Is (in Plain English)

VPAT stands for Voluntary Product Accessibility Template. Strip away the acronym and it’s exactly what it sounds like: a standardized, fill-in-the-blank form. It lists the accessibility requirements from the major standards, WCAG (the web guidelines used worldwide), Section 508 (the U.S. federal law), and EN 301 549 (the European standard), and next to each requirement, the person filling it out records how the product measures up.

Here’s a distinction worth thirty seconds, because it makes you sound like you know what you’re doing: the empty form is the VPAT. Once it’s filled out with real test results, the finished document is called an ACR, an Accessibility Conformance Report. In everyday conversation almost everyone says “VPAT” for both, and that’s fine. Just know that when a buyer asks for your VPAT, what they actually want is a completed ACR: the template with answers in it.

Who asks for these? Mostly organizations that are careful about legal risk: federal agencies (for whom Section 508 makes it mandatory in procurement), state and local governments, universities, hospital systems, and increasingly large private companies. If you sell software to any of these markets, a VPAT request isn’t a possibility, it’s a certainty. The only question is whether you’ll have a good answer ready when it comes.

The Part Everyone Gets Wrong: A VPAT Does Not Make Anything Accessible

This deserves its own section, in bold letters, because it’s the single most important thing to understand about this document, and the single most misunderstood.

A VPAT does not make a website or a piece of software accessible. It doesn’t fix anything, certify anything, or guarantee anything. All it means, all it has ever meant, is that the product was tested, and that someone wrote down where it complies with accessibility standards and where it does not. That’s it. It’s a report card, not a repair. A map of the potholes, not the road crew that fills them.

Think about what a report card really tells you. A student can bring home a report card full of Ds, the card is accurate, honest, and complete, and the student is still failing. In exactly the same way, a product can have a beautifully formatted, completely truthful VPAT that documents dozens of serious accessibility failures. The document is doing its job perfectly. The product is still broken for disabled users.

This cuts both ways, and both directions matter. If you’re a vendor, having a VPAT doesn’t mean you’re “done with accessibility”, it means you now have a written list of what still needs fixing. If you’re a buyer, receiving a VPAT doesn’t mean the product is safe to purchase, it means you’ve been handed the information you need to make that judgment yourself. A VPAT sitting in a folder protects no user and, honestly, very little of anyone’s legal position. What matters is what happens next: whether the problems it documents actually get fixed.

Here’s the counterintuitive part: an honest VPAT full of “partially supports” answers is usually a better sign than a spotless one. Real products have real gaps, every product we have ever tested has them. A vendor who documents theirs openly is a vendor who actually tested, actually understands the results, and can actually tell you their plan. A flawless scorecard, more often than not, means a shallow test or wishful thinking. A perfect-looking VPAT should raise questions, not settle them.

How to Read a VPAT: The Four Answers

Open any completed VPAT and you’ll find long tables: one row per accessibility requirement, a conformance level for each, and a remarks column explaining the answer. The conformance levels sound bureaucratic, but there are only four, and they’re simple once translated:

• Supports: this part of the product works for people with disabilities the way the standard requires. Full marks.
• Partially Supports: it works some of the time, or for some users, but there are documented failures. This is the answer that deserves your closest reading, because the remarks column tells you exactly where and how it breaks.
• Does Not Support: a known barrier. Some users cannot use this part of the product at all. Every one of these should have your full attention.
• Not Applicable: the product simply doesn’t contain this kind of content (a product with no video, for example, has nothing to caption), so there was nothing to test.

The real information lives in the remarks column. A good remark is specific: it names the feature, describes the failure, and explains the impact, “the date picker in the reporting module cannot be operated with a keyboard.” A bad remark is vague or promotional, “the product is designed with accessibility in mind.” When you evaluate a VPAT, you’re really evaluating the quality of its remarks. Specifics signal a real test. Slogans signal a marketing document wearing a compliance costume.

If You’re the Buyer: What to Do With a Vendor’s VPAT

Here’s where most organizations leave enormous value, and legal protection, on the table. They request the VPAT, receive it, confirm it exists, and file it away. That ritual accomplishes nothing. Remember: the document only tells you where the product does and doesn’t comply. If it documents problems and you ignore them, you’ve essentially signed a receipt acknowledging the barriers you’re about to buy. When that vendor’s inaccessible checkout page or learning platform triggers a complaint, “the vendor gave us a VPAT” will not help you, the complaint lands on your organization because your users don’t know or care whose code it is.

So when a vendor’s VPAT arrives, work through it like this:

First, read every “Partially Supports” and “Does Not Support” row. Skip the executive summary and the marketing preamble, the truth lives in those rows and their remarks. This takes less time than you’d think; most VPATs concentrate their real findings in a couple of dozen rows.

Second, ask how each gap affects your users specifically. Not every failure matters equally to every buyer. A gap in an admin feature only two staff members use may be tolerable for now. The same gap in the login page, the checkout, or the course player is a dealbreaker, it stands between entire groups of your users and the whole product. Map the documented failures against the tasks your people actually need to do.

Third, and this is the step almost everyone skips, request a written action plan for the non-compliance issues. If the VPAT shows real gaps, go back to the vendor and ask, in writing: what will be fixed, how it will be fixed, and when. Real dates, not “on our roadmap.” A serious vendor can answer this, because a serious vendor already has that plan, their VPAT is a snapshot of work in progress, not a confession filed and forgotten. A vendor who can’t or won’t produce a plan is telling you, plainly, that the documented barriers are permanent. That’s worth knowing before you sign.

Fourth, follow up until the dates are met. Put the action plan in the contract if you can, accessibility commitments with deadlines make excellent contract language. Ask for an updated ACR after each round of fixes, and diary the dates. Vendors prioritize what customers follow up on; a plan nobody checks is a plan that quietly evaporates.

Red Flags: When a VPAT Shouldn’t Be Trusted

Not all VPATs are created equal, and part of reading one well is knowing when to be suspicious. These are the warning signs we see most often:

• Every single row says “Supports.” We’ll say it again: real products have real gaps. A flawless scorecard usually means a shallow test, an automated-only test, or a document written by the marketing department.
• No mention of how the product was tested. A trustworthy ACR describes its testing approach, which pages or screens, which assistive technologies, manual or automated. “Tested with automated tools” alone is a red flag in itself, because automated tools can only check a fraction of the requirements.
• It’s dated years ago. A VPAT describes one version of a product at one moment in time. If the product has shipped major releases since, the document describes software that no longer exists. Ask for one that matches the version you’re actually buying.
• Marketing language where specifics should be. “We are deeply committed to accessibility” is a sentiment. “Focus indicators are not visible on dropdown menus” is a finding. Documents heavy on the former and light on the latter weren’t built from real testing.
• Nobody at the company can answer questions about it. Ask the vendor to walk you through two or three specific rows. If no one can, the document is an orphan, and if no one owns the document, no one owns the fixes either.

One red flag means read more carefully. Several together mean the document isn’t telling you what you need to know, and you’re within your rights to ask for a proper third-party assessment before you buy.

If You’re the Vendor: Why an Honest VPAT Wins Deals

Now flip the table. You sell software, a VPAT request just landed, and you have two options: produce something fast that makes the product look perfect, or produce something honest that documents real gaps. Counterintuitively, honesty is the stronger sales position, and not just ethically.

Procurement teams at agencies and universities read these documents every week. They know what a real one looks like, and a suspiciously perfect VPAT triggers exactly the skepticism described above, often followed by the buyer commissioning their own testing, which surfaces everything you glossed over, at maximum embarrassment. An honest VPAT paired with a credible remediation roadmap tells a much better story: we tested thoroughly, here’s where we stand, here’s the plan, here are the dates. Buyers can work with that. Many are required to, procurement rules often let an agency accept a product with documented gaps if there’s a concrete plan to close them. Your honesty literally becomes the paperwork that keeps you eligible.

There’s also a legal dimension. A VPAT that overstates your product’s accessibility isn’t harmless optimism, it’s a written claim that a motivated plaintiff’s lawyer or an unhappy customer can hold up next to the actual product. Documented honesty ages far better than documented exaggeration.

Why We Don’t Recommend the DIY (or Scanner-Only) VPAT

Can you fill out a VPAT yourself? Legally, yes, it’s a self-disclosure document, and nothing stops your team from completing one. Practically, two problems get in the way.

The first is skill: scoring a product against WCAG and Section 508 accurately requires knowing how to test, with a keyboard, with screen readers, with zoom and contrast checks, and knowing what each criterion actually demands. Teams without that background consistently score themselves wrong in both directions: marking things “Supports” that fail badly, and occasionally flagging non-issues. The second is credibility: buyers discount self-graded homework, and sophisticated ones increasingly ask point-blank whether the ACR was prepared by an independent party.

And running an automated scanner over the product before filling in the form doesn’t solve either problem. Scanners can evaluate only a minority of the criteria a VPAT covers, the mechanical ones. The majority require human judgment: does the reading order make sense, can every workflow actually be completed by keyboard, does the screen reader experience hold together? A VPAT built on scanner output alone is mostly blank guesswork dressed as a report. This is exactly the same reason we test websites and documents by hand in our audit and remediation work, the important findings are the ones only a person can make.

How We Build a VPAT You Can Stand Behind

So what does doing it properly look like? Here’s our process, step by step, no mystery, no black box:

Step 1: Scope the product and the standards. We pin down exactly what’s being reported on, which product, which version, which modules, and which edition of the VPAT fits your market: the 508 edition for U.S. federal buyers, the WCAG edition for general commercial use, the EU edition for European procurement, or the international edition that covers all three. Getting this right up front prevents the classic mistake of handing a federal buyer the wrong flavor of report.

Step 2: Test every criterion, by hand. Our specialists work through the product the way real users with disabilities do: keyboard only, with screen readers, at 200 percent zoom, checking contrast and color use, filling out the forms, completing the real workflows. Automated tools assist — they’re good at the mechanical checks, but every judgment call is made by a person, because most of the criteria on the form are judgment calls.

Step 3: Score every answer honestly. Including, especially, the ones that come back “Does Not Support.” We don’t massage results, because a flattering VPAT is a worthless VPAT. The document’s entire value rests on being an accurate map.

Step 4: Write remarks a human can read. Every gap gets a plain-English explanation: what fails, where it fails, and what it means for actual users. Your sales team should be able to discuss the document with a buyer without needing an interpreter, and the buyer’s procurement reviewer should find real specifics in every row.

Step 5: Pair it with a remediation roadmap. This is what turns the report card into a plan. Every documented gap gets a recommended fix and a priority, so you can walk into any procurement conversation with both halves of the story: where we are, and how we’re closing the distance. It’s also exactly the “action plan” that smart buyers, like the ones reading this article, will demand.

Step 6: Retest and update as the product changes. Software ships; the report has to keep up. We retest after significant releases and after remediation rounds, and issue updated ACRs, so the document buyers always see describes the product that exists, not the one from three versions ago.

The VPAT Is the Map, Remediation Is the Journey

One last piece of the picture. Because a VPAT only documents problems, the organizations that get the most from the exercise treat it as step one of two. Step two is actually fixing what the testing found, by hand, in the real code and content, and then updating the report to show the progress. That’s why our VPAT work so often runs alongside our website remediation and PDF remediation services: the same manual testing that fills in the form accurately is the foundation for fixing what it uncovered. Each remediation round shrinks the “Does Not Support” rows, and each updated ACR is documented, dated proof that your accessibility story is moving in the right direction, which is precisely what buyers, auditors, and courts respond to.

What We Need From You

Very little, as usual. Access to the product, a demo environment or test account works fine. A short conversation about which markets you sell into, so we choose the right VPAT edition. And someone on your team who can answer occasional product questions while we test. From there, the testing, scoring, remarks, and roadmap are our job. Most clients are surprised how painless it is compared to the internal attempt that stalled for three months.

Frequently Asked Questions

Is a VPAT legally required?

There’s no law that says every company must have one. But if you sell to the U.S. federal government, Section 508 makes accessibility documentation effectively mandatory in procurement, no ACR usually means no bid. State agencies, universities, and school systems have widely adopted the same requirement, and large private buyers are following. So while the “V” technically stands for voluntary, in practice a VPAT is the price of admission to a growing share of the market.

What’s the difference between a VPAT and an ACR?

The VPAT is the blank template; the ACR (Accessibility Conformance Report) is that template filled out with real test results. When someone “asks for your VPAT,” they want the completed ACR. Everyday usage blurs the two words together, and no reasonable person will mind, but using them correctly signals that you know the territory.

How often should a VPAT be updated?

Whenever the answer to “does this document still describe the product?” becomes no. In practice that means after major releases, after significant accessibility fixes, and as a general rule at least annually for actively developed software. An out-of-date ACR isn’t just unhelpful, to a careful buyer, it’s a red flag that suggests accessibility isn’t being maintained.

Won’t “Partially Supports” answers scare buyers away?

Far less than you’d fear, and far less than getting caught overstating. Experienced procurement reviewers expect real products to have gaps; what they’re evaluating is whether you know your gaps and have a credible plan. An honest report plus a dated roadmap routinely wins against a competitor’s suspiciously perfect scorecard, because one of those two documents survives scrutiny and the other doesn’t.

Need a VPAT You Can Actually Stand Behind?

Whether you’re a vendor with a procurement deadline bearing down or a buyer holding a vendor’s VPAT and wondering what it really says, this is exactly what we do all day. Our VPAT and ACR service is built on manual testing, honest scoring, and plain-English remarks, paired with a remediation roadmap so the report is the beginning of the fix, not the end of the conversation. Get in touch for a free consultation, or see our published pricing. A VPAT can’t make your product accessible, but the right one, backed by the right plan, is how you get there with proof in hand.