VPAT Procurement Requirements for Enterprise Buyers

Enterprise procurement teams use the completed VPAT — the Accessibility Conformance Report (ACR) — to compare product accessibility across vendors. An ACR that is vague, outdated, or incomplete will stall a deal. One that is accurate, well-scoped, and backed by supporting documentation moves through procurement faster and builds buyer confidence.

The VPAT is the blank template created by the Industry Technology Industry Council (ITI). The ACR is the completed document that maps your product’s conformance against a specific WCAG version and level. Procurement teams review the ACR. Every requirement below applies to the finished ACR, not the blank template.

Which VPAT Edition Does Enterprise Procurement Require?

Four VPAT editions exist: WCAG, Section 508, EN 301 549, and INT (International). The WCAG edition is the default for most SaaS companies and most enterprise procurement processes in the private sector.

U.S. federal and state agencies typically require the Section 508 edition. If your product serves EU markets, the EN 301 549 edition may be requested. The INT edition covers all three standards in a single document and is appropriate when a product serves global buyers.

If procurement does not specify an edition, the WCAG edition at the 2.1 AA conformance level is the safest choice. When in doubt, ask the buyer directly. Submitting the wrong edition creates unnecessary delays.

ACR Accuracy Is the Core Procurement Concern

Procurement reviewers are not looking for a perfect score. They are looking for honesty. An ACR that marks every criterion as “Supports” raises immediate suspicion. No complex product fully conforms across every WCAG criterion without a single gap.

Each criterion in the ACR is assigned a conformance level:

• Supports: the product fully meets this criterion
• Partially Supports: some functionality meets this criterion while other functionality does not
• Does Not Support: the product does not meet this criterion
• Not Applicable: the criterion does not apply to the product

Procurement teams weigh partially supporting criteria against the severity of the gap. An ACR that is transparent about partial conformance and provides a remediation timeline is far more persuasive than one that inflates conformance levels.

Scope and Product Boundaries

An ACR must define exactly what was evaluated. For a web app, this includes the specific features, user flows, and pages covered. For a multi-product suite, each product may need its own ACR.

Procurement teams reject ACRs with ambiguous scope. If the ACR says “Product X” but doesn’t specify whether it covers the admin dashboard, reporting module, or customer-facing portal, the buyer cannot determine whether the ACR applies to their use case.

Include the product name, version number, evaluation date, and a clear description of what was and was not covered. The more precise the scope, the fewer follow-up questions procurement will send.

Why Remarks and Explanations Matter

The Remarks and Explanations column is where an ACR either builds trust or loses it. Generic remarks like “some issues exist” tell the reviewer nothing.

For every criterion marked Partially Supports or Does Not Support, the remarks should describe the specific issue, the user impact, and the planned remediation timeline if one exists. Procurement teams use this column to assess risk. When remarks are specific, the buyer can evaluate whether the gap affects their users. When remarks are vague, the buyer assumes the worst.

How Evaluation Methodology Affects Buyer Confidence

Enterprise buyers increasingly ask how the ACR was produced. An ACR based on a (manual) accessibility audit carries more weight than one generated from automated scans alone, because scans only flag approximately 25% of issues.

The ACR should state the evaluation method, including the assistive technologies used during the evaluation process. Screen reader evaluation with NVDA, JAWS, or VoiceOver, keyboard-only navigation, and color contrast analysis are standard expectations.

If a third party conducted the evaluation, naming that organization adds credibility. Self-assessed ACRs are acceptable but face more scrutiny. Third-party ACRs from a recognized accessibility company signal that the conformance data was independently verified.

Recency and When to Update an ACR

ACRs do not have a formal expiration date. However, an ACR that references a product version from two years ago does not satisfy procurement for the current version.

The standard recommendation is to update the ACR after any significant product change. A major UI redesign, new feature launch, or framework migration all warrant a new evaluation. Minor bug fixes or backend updates typically do not.

Some enterprise buyers set their own recency thresholds. A common expectation is an ACR no older than 12 months. Keeping the ACR current avoids delays when a procurement request arrives unexpectedly.

Supporting Documentation Beyond the ACR

The ACR is the primary document, but procurement teams often request supplementary materials. Having these ready accelerates the process:

• Accessibility statement: a public commitment describing your product’s accessibility status, conformance target, and contact information for reporting issues
• Remediation roadmap: a timeline for addressing known gaps identified in the ACR
• Accessibility policy: internal documentation describing how your organization maintains accessibility over time
• Audit report: the full evaluation report behind the ACR, which provides deeper technical detail than the ACR itself

Not every buyer asks for all of these. But vendors who can produce them on request demonstrate operational maturity around accessibility.

Common ACR Mistakes That Stall Procurement

Procurement reviewers flag ACRs for predictable reasons. Addressing these before submission saves weeks of back-and-forth:

• Missing scope definition: no clarity on what product or version was evaluated
• Inflated conformance levels: marking criteria as Supports when partial conformance is more accurate
• Empty remarks columns: no explanation for partial or non-supporting criteria
• Wrong edition: submitting a WCAG edition when the buyer specified Section 508
• Outdated evaluation: ACR references a product version that no longer exists
• No evaluation methodology: no indication of how conformance was determined

Each of these gaps forces the buyer to request clarification, which extends the procurement timeline and creates friction in the sales cycle.

Can I fill out the VPAT myself?

You can, but self-assessed ACRs face more scrutiny from procurement reviewers. A third-party evaluation from an accessibility company carries more credibility because the conformance data is independently produced. If you self-assess, the evaluation methodology section becomes even more important.

What if my product does not fully conform to WCAG 2.1 AA?

Most products do not fully conform. Procurement teams expect honest reporting. An ACR that accurately reflects partial conformance and includes a remediation roadmap is stronger than one that overstates conformance. Buyers evaluate risk, not perfection.

How often should I update my ACR for procurement?

After any significant product change. Major UI updates, new features, or technology migrations all warrant a fresh evaluation. Many enterprise buyers expect the ACR to be no older than 12 months, though there is no formal expiration standard.

Do procurement teams verify ACR accuracy?

Some do. Larger enterprises may conduct their own evaluation of your product or hire a third party to validate the ACR’s claims. Inaccurate ACRs discovered during verification damage vendor credibility and can disqualify a bid entirely.

An ACR that is accurate, well-scoped, and current is one of the most effective sales documents a software vendor can produce. Getting it right before procurement asks for it removes a common bottleneck from enterprise deals.

Contact us to get a third-party ACR that meets enterprise procurement requirements.