Government agencies and large enterprises buy software and digital services through formal procurement processes—and those processes increasingly treat accessibility as a gate, not a nice-to-have. If you’ve heard “Send your VPAT” during a sales cycle, you’re not alone. The real question for many teams isn’t just what a VPAT is, but whether you need one to sell and how to use accessibility documentation to win deals faster.
This article breaks down when a VPAT is expected, what it proves (and what it doesn’t), how it maps to WCAG and Section 508, and which supporting documentation helps you clear security-and-compliance reviews without stalling your pipeline.
VPAT stands for Voluntary Product Accessibility Template. It’s a standardized template used to document how a product conforms to accessibility requirements. In the U.S. public sector, the VPAT is commonly used to support compliance with Section 508 (which references WCAG for web content). Many enterprises also request VPATs because it gives procurement and legal teams a consistent way to compare vendors.
After you complete the VPAT, the resulting document is often referred to as an Accessibility Conformance Report (ACR). In practice, “VPAT” and “ACR” are frequently used interchangeably by buyers.
Usually, no—there’s rarely a universal law saying every vendor must publish a VPAT. But in many sales scenarios, you commercially need it because buyers treat it as mandatory documentation.
Even when not explicitly requested, a VPAT often prevents last-minute surprises—especially given the litigation and regulatory environment. If you need context on how accessibility risk can escalate, the Domino’s case is a useful reminder: Domino’s Pizza: The Accessibility Lawsuit That Reached the U.S. Supreme Court.

Think of a VPAT as one piece of a broader trust package. Government and enterprise buyers want evidence that you can support employees and customers with disabilities, reduce legal exposure, and maintain accessibility over time.
A complete, candid VPAT helps accessibility reviewers answer: What works? What doesn’t? What’s the impact? What’s the plan? Without it, buyers often send long questionnaires that delay approvals and strain your sales engineering team.
Counterintuitively, saying “Supports” for everything can hurt you if it’s not credible. Reviewers know that most products have some limitations. A VPAT that clearly lists exceptions, workarounds, and a remediation roadmap signals maturity and reduces perceived risk.
Accessibility doesn’t exist in isolation. Consent banners, cookie controls, and legal pages can introduce keyboard traps, focus issues, and contrast failures if implemented poorly. If your compliance tooling isn’t accessibility-aware, you may fix one risk while creating another. This overlap is explored in Accessibility and Privacy Are Converging: Why Digital Compliance Needs One Home and practically applied in One Website, Twenty Privacy Laws: A Practical Guide to Multi-Region Cookie Compliance (Without Breaking Accessibility).
Procurement teams don’t just want a document—they want defensible evidence. Here are the signals that typically move a VPAT from “nice attachment” to “approved.”
Most buyers expect WCAG 2.1 AA (and increasingly WCAG 2.2 AA). A strong VPAT maps your product behavior to success criteria with specific remarks, not vague claims.
This is where deals are won or lost. Strong remarks include:
Enterprises may ask how you validated results: automated scans, manual keyboard testing, screen reader testing, and whether audits are repeated each release. Tools like Corpowid (corpowid.ai) can help teams run automated accessibility audits and monitoring so documentation stays current as the product evolves—critical for buyers who fear “compliance drift” after purchase.

These documents complement each other, but they serve different audiences.
Many organizations bundle these into a single “accessibility packet.” If you already maintain an accessibility widget/overlay and legal-page tooling, consider how it integrates with your documentation approach; The Compliance Corner: How One Smart Widget Can Handle Consent, Accessibility, and Legal Pages covers why a consolidated approach can simplify governance without fragmenting user experience.
Creating a credible VPAT is part documentation, part testing, and part cross-functional coordination. A practical approach is to treat it like any other release artifact.
Where you don’t fully support a criterion, explain the impact and timeline. Buyers frequently accept exceptions when they see accountability and a plan.
A VPAT from two years ago can slow procurement because reviewers assume it no longer reflects the product. Monitoring helps you refresh claims each release. Corpowid (corpowid.ai) can support ongoing monitoring and accessibility statement tooling so updates are easier to operationalize, not a quarterly scramble.

If you sell to government, education, healthcare, finance, or any enterprise with mature procurement, a VPAT is often the price of admission. The teams that win consistently treat accessibility documentation as a sales enabler: it reduces friction, builds trust, and demonstrates you can support users with disabilities at scale.
If your current process is ad hoc, start with scoped testing, create an ACR that’s honest and specific, and set up ongoing monitoring so it stays accurate as your product changes. That combination—documentation plus continuous accessibility practice—is what turns “Please send your VPAT” from a blocker into a competitive advantage.