What a VPAT Is and What Enterprise Buyers Actually Check For

Accessibility compliance has moved from an afterthought to a hard gate in enterprise software procurement. Buyers above a certain deal size — typically $50K ACV and above — now routinely ask for an Accessibility Conformance Report (ACR) before a vendor makes the shortlist. If your sales team has been losing enterprise and public-sector deals without a clear reason, the absence of a credible VPAT may be the silent disqualifier.

This post explains exactly what a VPAT is, where the requirement originated, and — most importantly — what enterprise buyers actually look at when they open the document. The goal is not to help you produce a compliance checkbox. The goal is to help you understand the evaluation criteria so you can produce an ACR that accelerates deals rather than stalling them.

What a VPAT Is and What It Produces

The Voluntary Product Accessibility Template (VPAT) is a standardized document template published by the IT Industry Council (ITI). When a software vendor fills out a VPAT for a specific product, the resulting document is called an Accessibility Conformance Report (ACR). The two terms are often used interchangeably in procurement conversations, but technically the VPAT is the blank form and the ACR is the completed assessment.

The template organizes accessibility criteria into structured tables. Each row represents a specific accessibility requirement — a WCAG success criterion, a Section 508 provision, or an EN 301 549 clause — and asks the vendor to declare one of three conformance levels:

• Supports: The product fully meets this criterion.
• Partially Supports: The product meets this criterion in some cases but not all.
• Does Not Support: The product does not meet this criterion.

Each row also includes a "Remarks and Explanations" field. This field is where the real signal lives — for buyers who know how to read an ACR.

The current version as of 2026 is VPAT 2.5, which covers WCAG 2.1 Level AA, WCAG 2.2, Section 508, and EN 301 549 (the European standard). Vendors can issue an ACR covering any combination of these standards depending on their target markets.

Where the Requirement Comes From: Section 508 and Federal Procurement

The VPAT format was created specifically to satisfy Section 508 of the Rehabilitation Act of 1973, as amended by the Workforce Investment Act of 1998. Section 508 requires U.S. federal agencies to procure electronic and information technology that is accessible to people with disabilities — both employees and members of the public.

When a federal agency evaluates software, it must document that the product meets Section 508 standards (which are now harmonized with WCAG 2.0 Level AA, with agencies increasingly expecting 2.1 AA). The ACR is how vendors provide that documentation.

What began as a federal procurement requirement has expanded significantly. State and local governments that receive federal funding are often subject to similar requirements. Higher education institutions governed by ADA Title II have adopted equivalent standards. Large enterprises — particularly in healthcare, financial services, and insurance — now include ACR requirements in their vendor due diligence processes as part of ADA Title III risk management.

According to research published by WebAIM, approximately 96.3% of home pages analyzed in their 2024 accessibility study had detectable WCAG 2 failures. This backdrop makes it clear why enterprise buyers treat the ACR as a risk-filtering instrument rather than a formality.

Understanding the Section 508 conformance gates for public sector deals is essential context for any vendor selling into government or federally-funded institutions, because the procurement process treats accessibility documentation differently than private-sector due diligence.

What Buyers Actually Read in a VPAT

This is the most important section for revenue-focused readers. Enterprise procurement teams — especially those at mature buyers — do not read VPATs linearly. They use a specific scanning pattern.

First scan: "Does Not Support" flags. A buyer's first action is to filter the ACR for any row marked "Does Not Support." These are immediate red flags. If any core interaction criterion — keyboard accessibility (WCAG 1.3.1, 2.1.1, 2.1.2), screen reader compatibility (4.1.2), focus management (2.4.7) — is flagged as not supported, the vendor may be disqualified before the technical team even reviews the document.

Second scan: "Partially Supports" without remarks. The second pass looks for "Partially Supports" entries that have empty or vague remarks fields. A "Partially Supports" with a clear explanation — "this criterion is not met in the bulk import workflow; all other workflows are conformant; remediation is planned for Q3 2026 release" — is manageable. A "Partially Supports" with a blank remarks field or a generic note like "some exceptions apply" signals that the vendor either has not actually tested against the criterion or does not want to disclose the scope of the failure.

Third check: document date and product version. Experienced buyers check whether the ACR is dated within the last 12–18 months and whether the product version matches what is being sold. An ACR from 2022 for a SaaS product that ships continuous updates is not credible. It will not pass procurement review at a federal agency or a sophisticated enterprise buyer.

Fourth check: testing methodology. Mature procurement teams — and any accessibility auditor the buyer has retained — will look for evidence of actual testing. Who performed the evaluation? Was it a self-assessment or a third-party audit? What assistive technologies were tested (NVDA, JAWS, VoiceOver, TalkBack)? What browsers were used? A credible ACR answers these questions, either in a methodology section or in the remarks fields throughout.

For vendors who are also navigating security and compliance questionnaires alongside accessibility documentation, the dynamics are similar to what is covered in the SaaS vendor security questionnaire preparation guide — preparation and specificity matter far more than completeness theater.

Common VPAT Failure Modes That Kill Deals

There are four failure modes that appear repeatedly when reviewing ACRs that have stalled or killed enterprise deals.

Failure mode 1: Every row says "Supports" with no remarks. A product in which every single WCAG 2.1 AA criterion is fully supported — with no exceptions, no caveats, and no explanation — is statistically implausible. The WebAIM annual study consistently shows that even accessibility-forward products have some conformance gaps. An ACR where every row is marked "Supports" with blank remarks fields reads as a marketing document, not a conformance assessment. Buyers with any sophistication will reject it.

Failure mode 2: Using an outdated WCAG version. Many vendors still have VPATs based on WCAG 2.0, which was superseded by WCAG 2.1 in 2018 and by WCAG 2.2 in 2023. Federal agencies now expect WCAG 2.1 AA at minimum. A VPAT referencing WCAG 2.0 will trigger a follow-up request for an updated assessment — which is a friction event that can derail a deal timeline. In competitive procurement with fixed evaluation windows, not having the right version can result in automatic disqualification.

Failure mode 3: Scope limited to a single feature or demo environment. Some vendors produce VPATs that cover only the most commonly demonstrated part of their product — the login screen and the main dashboard, for example — without disclosing that the evaluation did not cover the administration interface, the reporting module, or the mobile experience. A buyer who purchases the product and discovers that the ACR scope was narrow will treat it as a misrepresentation, which creates legal and relationship risk.

Failure mode 4: No remediation timeline for known gaps. When failures exist — and in any real product, some will — buyers expect a remediation commitment. An ACR that discloses "Does Not Support" for a criterion but offers no timeline or plan for addressing it signals that the vendor treats accessibility as a one-time exercise rather than an ongoing product quality dimension.

VPAT 2.x for WCAG 2.1 AA vs. WCAG 2.2: What Changed

WCAG 2.2 was published in October 2023 and introduced nine new success criteria. Several of these are highly relevant to enterprise SaaS products:

• 2.4.11 Focus Appearance (Minimum) — requires that focus indicators meet minimum size and contrast ratios.
• 2.4.12 Focus Appearance (Enhanced) — a stricter version of the above.
• 2.5.7 Dragging Movements — requires alternatives to drag-and-drop interactions.
• 2.5.8 Target Size (Minimum) — requires touch targets to be at least 24x24 CSS pixels.
• 3.2.6 Consistent Help — requires help mechanisms to appear in consistent locations.
• 3.3.7 Redundant Entry — reduces cognitive load by not requiring users to re-enter information already provided.
• 3.3.8 Accessible Authentication (Minimum) — restricts cognitive function tests in authentication flows.

WCAG 2.2 removed one criterion from 2.1: 4.1.1 Parsing, which has been deprecated.

For enterprise buyers evaluating products in 2026, WCAG 2.1 AA remains the contractual baseline in most public-sector procurement. However, progressive enterprises and accessibility-focused buyers are beginning to reference WCAG 2.2. A vendor that proactively addresses WCAG 2.2 criteria in their ACR — even when not contractually required — signals product maturity and forward-looking accessibility investment.

Building a WCAG conformance roadmap for your product team should be driven by both the current standard and the trajectory of buyer expectations, not just the minimum contractual requirement.

What a Credible VPAT Looks Like vs. a Marketing-Grade VPAT

The difference between a credible ACR and a marketing-grade one comes down to specificity and honesty.

A credible VPAT includes:

• A clearly stated scope: which product, which version, which modules were evaluated.
• A testing methodology section: who performed the evaluation, what assistive technologies were used, what browsers and operating systems were tested.
• Differentiated conformance levels: a mix of "Supports," "Partially Supports," and in some cases "Does Not Support," reflecting real product state.
• Substantive remarks: for every "Partially Supports" or "Does Not Support," a clear explanation of what works, what does not, which user scenarios are affected, and what the remediation plan and timeline are.
• A date within the past 12–18 months that corresponds to the current product version being sold.

A marketing-grade VPAT looks like this: uniform "Supports" across all criteria, blank remarks fields, a generic statement like "our product is designed with accessibility in mind," and a date that does not correspond to the current release. It protects the vendor from an immediate no but creates downstream liability when the buyer's accessibility team or users encounter the actual product.

The distinction matters beyond procurement optics. Disability:IN's procurement surveys consistently show that enterprise buyers are increasing scrutiny of accessibility claims and moving toward third-party validation requirements. A marketing-grade VPAT that passes a naive procurement check today may become a legal and reputational liability in a mature buyer relationship.

Accessibility Documentation as a Deal-Acceleration Asset

For most SaaS vendors, the accessibility conversation happens too late — after a buyer has already asked for the VPAT and the sales team has to scramble to produce one. The revenue opportunity is in treating the ACR as a proactive sales asset rather than a reactive compliance document.

Vendors who publish a current, credible ACR on their website — or include it as a standard attachment in their security and compliance documentation package — compress the procurement cycle for enterprise and public-sector deals. The buyer's accessibility reviewer receives the document before they ask for it, which eliminates a follow-up round-trip and signals that the vendor has a mature compliance posture.

This posture is part of a broader pattern covered in the compliance certification sequencing roadmap: accessibility documentation, like SOC 2 Type II, is most valuable when it is ready before the deal requires it, not assembled under deadline pressure.

The connection between accessibility conformance and enterprise deal velocity is also addressed in accessibility as a market expander, not a compliance cost, which covers the revenue-side argument for investing in accessibility beyond the procurement gate.

Vendors pursuing enterprise deals at scale should also review how accessibility fits into the broader context of enterprise SaaS procurement tactics, particularly how documentation packages are evaluated relative to competing vendors in a shortlist scenario.

Conclusion

A VPAT — properly completed as an Accessibility Conformance Report — is not a compliance checkbox. It is a structured disclosure that enterprise and government buyers use to assess legal risk, product quality, and vendor maturity. The buyers who read these documents with real scrutiny are looking at a narrow set of signals: the presence of "Not Supported" flags on core interaction criteria, the quality of remarks fields, the testing methodology, and the age of the document.

Producing a credible ACR requires actual accessibility testing against WCAG 2.1 AA (and increasingly WCAG 2.2), honest disclosure of known gaps with remediation timelines, and regular updates that keep pace with product releases. A marketing-grade VPAT — uniform "Supports" claims with no evidence — may pass a cursory check but will fail with any sophisticated buyer and creates downstream liability.

For SaaS vendors competing for enterprise and public-sector deals, the ACR is increasingly a table-stakes requirement. The question is not whether to produce one, but whether the one you produce is credible enough to accelerate the deal rather than stall it.