Accessibility procurement is full of acronyms, and few cause more confusion than VPAT and ACR. Sellers often say they “have a VPAT” when a buyer asked for an “ACR,” and buyers sometimes request a “VPAT” when what they actually want is a clear, credible statement of conformance to WCAG and Section 508.
Understanding the difference matters because these documents influence real decisions: whether you can respond to an RFP, pass security and compliance gates, or get approved as a vendor for a public-sector or enterprise customer.
VPAT stands for Voluntary Product Accessibility Template. It’s a standardized template created by the ITI (Information Technology Industry Council) and used widely in accessibility procurement. The VPAT provides a structured way for vendors to describe how their product supports specific accessibility requirements.
Important nuance: a VPAT is the template, not the finished report.
ACR stands for Accessibility Conformance Report. An ACR is the completed report produced using the VPAT template. In other words, the ACR is what you submit to customers; the VPAT is the form it’s written in.
If you remember one thing: VPAT = the template; ACR = the filled-out deliverable.
In practice, many procurement teams use “VPAT” as shorthand for “an accessibility conformance report in VPAT format.” It’s like asking for “a PDF” when you mean “the report, delivered as a PDF.”
Still, wording matters. Some organizations are strict: they will ask for an ACR (based on the current VPAT version) and reject older or incomplete documents.
The VPAT template has editions that map to different accessibility requirements. A typical ACR may cover:
Which one you need depends on where your buyer operates and what they’re purchasing. For SaaS vendors selling into enterprise procurement, aligning the ACR to the right standard set is often the difference between “approved” and “come back later.” If you’re building your process, the guide VPAT for SaaS: How to Meet Accessibility Requirements and Win Enterprise Deals is a useful companion for the operational side of getting this done.
A strong ACR should be evidence-based, but it is still largely a self-reported document unless it includes third-party validation. It does not automatically mean your product is “fully accessible,” nor does it replace ongoing accessibility work. Buyers know this and increasingly ask follow-up questions like:
Most buyers want an ACR (the completed report). They may call it a VPAT, but they are usually looking for a document they can file, compare, and use to assess risk.
Here’s how it tends to break down by buyer type:
These buyers often require an ACR aligned to Revised Section 508 (and sometimes EN 301 549 for non-U.S. contexts). They expect the report to be current, specific, and consistent with procurement language.
Enterprises frequently request a “VPAT,” but what they evaluate is the quality of the ACR: how transparent it is, whether it includes exceptions, and whether it comes with a credible remediation plan. Industries like healthcare also scrutinize accessibility because it ties directly to patient access and trust; see Digital Accessibility for Hospitals & Clinics: WCAG Compliance, Inclusive Design, and Patient Trust for how compliance expectations intersect with real-world outcomes.
Job portals and HR platforms often face heightened scrutiny because inaccessible application flows can create discrimination risk. Buyers may request an ACR and also ask for proof of testing in key candidate journeys. This is especially relevant for platforms in recruiting and talent management; Digital Accessibility for Job Portals & HR Platforms highlights what tends to break in these experiences.
Buyers want a report built on the current VPAT edition and scoped to the product they are buying. “Our company is accessible” is not a scope. A credible ACR specifies:
Statements like “Supports” without explanation can look like box-checking. Strong ACRs describe how the criterion is met and where limitations exist. If something partially supports a criterion, buyers would rather see candid detail than marketing language.
Automated checks are helpful, but they don’t catch everything buyers care about (focus order, meaningful labels, error recovery, screen reader interaction patterns). Many procurement and accessibility teams now ask whether manual and assistive technology testing was included. If you need to make the case internally for deeper evaluation, Why User Testing With People With Disabilities Beats Any Automated Tool outlines why lived-experience testing is hard to replace.
No complex product is perfect. Buyers are often comfortable with known issues if they see:
Send your ACR in VPAT format and label it clearly (for example, “Accessibility Conformance Report (VPAT 2.x)”). Confirm which standards they need covered (508, WCAG, EN 301 549) and whether they require a specific WCAG version.
Send the completed ACR and be ready to answer follow-up questions about testing methods, scope, and remediation. In mature procurement processes, the ACR is just the start of the conversation.
You may still benefit from having an up-to-date ACR ready. Accessibility requests often appear late in the sales cycle, and scrambling can delay procurement. Proactively maintaining documentation is particularly helpful for organizations running high-visibility, public-facing digital experiences where inclusion is part of the brand promise, like civic initiatives and large campaigns; America’s 250th Anniversary: Building a Digital Celebration Everyone Can Access is a good reminder that accessibility is also about participation at scale.
An ACR is a snapshot in time. If your product ships weekly, the report can become outdated quickly—especially for UI components, navigation patterns, and content templates. Teams that handle this well treat conformance reporting as an ongoing practice: monitor changes, retest critical flows, and update documentation on a predictable cadence.
Tools can help you stay ahead of regressions. For example, Corpowid (corpowid.ai) can support ongoing accessibility efforts with automated audits and monitoring so teams can spot recurring WCAG issues earlier and reduce surprises when procurement asks for updated conformance information.
Buyers want an ACR—a completed, scoping-clear, evidence-based conformance report—though many will casually call it a VPAT. If you provide a current ACR in the right format, with specific remarks and a realistic remediation plan, you’ll meet what most procurement teams are truly trying to achieve: a defensible way to assess accessibility risk.
If your organization is building a repeatable process, combining disciplined evaluation with ongoing monitoring can make accessibility documentation far less painful. Corpowid (corpowid.ai) is one option teams use to continuously identify issues so their reported conformance stays closer to reality as the product evolves.
A VPAT helps SaaS vendors document accessibility conformance for enterprise and public-sector procurement. This guide explains how VPATs work, how to complete one credibly, and how to keep it current as your product evolves.
Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.
TR
