It often starts the same way. A deal is moving. The product demo went well. Everyone feels good. Then procurement steps in and asks for one document, and the tone shifts.
“Can you send your VPAT?”
Now the sales thread pauses. Someone forwards the request to engineering. Someone else pulls up a template they have never seen before. A smart team that knows accessibility basics still feels stuck, because nobody seems able to answer the question behind the question.
Here is the tension most teams run into. Legally, that document is not always required. Practically, the market can act like it is. And that pressure can lead to rushed paperwork that helps no one.
So let’s answer the thing people avoid saying clearly. You do not need this document just because someone asked for it. You need it when it serves a real purpose in how your product is bought, reviewed, and trusted. We will walk through how to tell the difference, and how to handle accessibility documentation with confidence.
VPAT and ACR, Untangled
First, some quick clarity, because the terms get mixed up constantly.
The Voluntary Product Accessibility Template is the blank form. The Accessibility Conformance Report is the completed report that comes out of it. Procurement teams often ask for “the template” when they mean the finished report. Vendors often say “report” when they mean the template. Everyone nods anyway, and confusion grows.
The word voluntary matters, too. This is not a certification. There is no official stamp. No agency signs off. It is your organization describing how your product supports accessibility standards such as WCAG, Section 508, or EN 301 549.
A strong report does three things well.
- Reviewers address each criterion line by line, so they have exactly what they need without guesswork.
- Teams apply support levels accurately, using “Supports,” “Partially Supports,” and “Does Not Support” as intended.
- Evaluators describe user impact clearly in the remarks, where the real credibility of the evaluation comes through.
What it should not do is pretend to be a legal shield. It is also not a glossy sales brochure. And it is not something you can publish once and forget, because products change. Accessibility changes with them.
When a VPAT Is Expected
There are a few places where accessibility documentation shifts from “nice to have” to “we cannot move forward without it.”
Selling to U.S. federal agencies is the clearest example. Section 508 procurement relies on accessibility conformance reporting as part of how agencies evaluate information and communication technology. Some state and local government contracts mirror that approach, even when the rules are not written the same way.
Higher education adds its own pressure. Many universities enforce procurement policies that require digital accessibility. Their teams actively request documentation from vendors, and internal reviewers know exactly what to check and how to evaluate it.
Large enterprises can be just as strict. Accessibility is frequently bundled into vendor due diligence alongside security, privacy, and compliance. In that environment, the question is less “Do we believe you care about accessibility?” and more “Can we document what we are buying and what the risk looks like?”
This is also where the market has matured. A decade ago, some buyers accepted any report that looked official. Today, many teams have seen too many vague statements and too many copy-pasted claims. Stakeholders expect details, supported testing, and remarks grounded in real behavior.
This is why a VPAT request can feel so urgent. It is not always about the law. It is often about procurement habits and risk management.
The Risk of Treating Documentation Like a Formality
When teams feel rushed, the instinct is to make the report look clean. That is when trouble starts.
A report that marks “Supports” across the board looks impressive at a glance, but it often raises questions for anyone experienced. Most real products have some partial support, even if the overall experience is strong. A perfect-looking report can read as unrealistic.
Overclaiming is where risk grows. If your report says keyboard navigation is supported, but users cannot reach core controls without a mouse, you are not just shipping a bug—you are undermining credibility. When buyers spot the mismatch, they start questioning every accessibility claim you make. When users hit it firsthand, they feel misled, not merely inconvenienced.
There is also an internal cost. Teams that feel pressure to look perfect tend to hide gaps. That keeps issues out of the backlog and out of planning. It also blocks the thing procurement teams truly need, which is a clear view of limitations.
An honest report can be imperfect and still be strong. “Partially Supports” paired with clear remarks is often safer, more useful, and more believable than a wall of “Supports.”
VPAT Myths That Waste Time and Energy
A few misconceptions show up so often that they are worth calling out directly.
One myth is that if you do not have the document, you must not be compliant. Documentation and accessibility progress are connected, but they are not the same thing. You can have a report and still have serious barriers. You can be doing thoughtful accessibility work without having a formal report yet.
Another myth is that anything less than full support is a failure. Partial support is normal, especially for complex interfaces, legacy code, or products with many integrations. Standards are detailed, and not every criterion applies in the same way to every feature.
A third myth is that once the report is done, you are set for years. Products evolve. Design systems change. Third-party tools update. Browsers and assistive technologies shift. A report that is never revisited becomes stale fast.
There is also the perfection trap. Some teams believe they must fix every issue before sharing anything. That can delay deals and delay transparency. In many cases, buyers would rather see an honest picture today with a clear improvement plan than wait for a “perfect” report that arrives too late.
And finally, there is the belief that a developer can fill the template out in an afternoon. Reliable reporting comes from structured evaluation, including assistive technology testing, review of key user flows, and input from multiple roles.
How to Decide If a VPAT Makes Sense for Your Organization
If you are trying to decide what to do next, start with your business reality.
Look at who you sell to today and who you plan to sell to in the next 6 to 12 months. If government, higher education, or enterprise procurement is a real part of your pipeline, documentation may be worth prioritizing.
Next, look at your current accessibility posture. Have you done a recent audit or structured assessment? Do you already know about critical barriers that would make your report read like wishful thinking? If so, you may need to remediate first, or scope the report carefully so it reflects what is true now.
Then separate legal pressure from sales pressure. Legal risk depends on your users and product context. Sales pressure is easier to see. Are deals stalling because your buyer needs documentation for their process?
After that, decide on timing and scope. If an RFP is imminent, you may need the report sooner, even if it is not perfect. If you are not facing procurement demands yet, you may get more value from strengthening accessibility foundations and preparing your internal process first.
The simplest summary is this. If you are consistently being asked for a VPAT in active deals, it is probably time to treat it as a business asset, not a last-minute chore.
How to Make the Document Useful, Even When It Is Not Perfect
The remarks section is where most reports either earn trust or lose it. Generic statements like “Supported” without context do not help reviewers. Clear, specific remarks do.
Anchor your evaluation to real user journeys. Focus on the flows buyers care about, like account setup, checkout, form completion, and core product tasks. Report what works well and where friction still exists.
Be direct about limitations and workarounds when they exist. State the gap when a feature has known limitations. Document any available alternative paths. Outline planned remediation with clear, measured intent.Avoid promises you cannot guarantee.
Tie the report to an accessibility roadmap when possible. Procurement teams respond well to maturity. They want to know you understand your gaps and have a plan to address them.
Also, prepare the people who will share it. Sales, support, and account managers should understand what the report actually says. Nothing undermines trust faster than a confident verbal promise that contradicts the written document.
So, Do You Really Need a VPAT, and Where 216digital Fits
“Others strengthen their accessibility practices first and build documentation once their sales channels make it necessary.
The healthiest mindset is simple. Honest reporting beats perfect-looking reporting. A clear, user-centered document supports better procurement decisions and helps teams focus on meaningful improvements.
At 216digital, we help teams evaluate accessibility in ways that map to real user journeys and WCAG criteria, translate findings into accurate conformance reporting that buyers can trust, and build workflows so documentation stays current as your product evolves.
If you are unsure whether this is a “now” need or a “later” need, we can help you sort that out without pressure. Sometimes the right next step is a VPAT. Sometimes it is an assessment and a plan. Either way, the goal is the same: to communicate accessibility with clarity and to keep improving the experience for the people who rely on it.
