What is a VPAT (Voluntary Product Accessibility Template)?

What is a VPAT?

The Voluntary Product Accessibility Template (VPAT) is a standardized template published by the Information Technology Industry Council (ITI) that vendors fill in to declare how their products conform to accessibility standards — primarily WCAG (Web Content Accessibility Guidelines), Section 508 of the US Rehabilitation Act, and EN 301 549 (the European standard mandated by the EAA). The blank template is the VPAT; the completed document for a specific product is the Accessibility Conformance Report (ACR). In practice the terms are used interchangeably — "send me your VPAT" usually means "send me your filled-in ACR."

VPAT exists because procurement teams at federal agencies, universities, and large enterprises need a consistent way to compare accessibility across vendors. Without a standard format, every vendor would document accessibility differently, making procurement comparisons impossible. VPAT is the standard format.

VPAT versions and their scope

The VPAT has evolved through several versions. The current latest is VPAT 2.5 (released 2024), which covers four standards in one document:

• WCAG 2.1 (Levels A and AA). 50+ success criteria across the four POUR principles (Perceivable, Operable, Understandable, Robust). The most common reference standard.
• WCAG 2.2. Adds nine new success criteria over WCAG 2.1 (target size, focus appearance, dragging movements, etc.). Becoming the new baseline for buyers in 2025-2026.
• Revised Section 508. US federal procurement standard, harmonized with WCAG 2.0 since 2018.
• EN 301 549. European standard for ICT accessibility, mandated under the European Accessibility Act effective June 2025.

Older versions (VPAT 2.4 and earlier) are still in circulation but increasingly rejected by procurement teams. Submitting an old version signals that the vendor hasn't refreshed accessibility documentation recently.

What's in a VPAT (the structure)

For each applicable success criterion, the VPAT requires:

1. Conformance level: One of Supports, Partially Supports, Does Not Support, or Not Applicable.
2. Remarks and explanations: Concrete details on what was tested, how, with what assistive technologies, known issues, workarounds for unsupported criteria, and roadmap if work is planned.

The conformance level is what procurement teams scan first. The remarks are what buyers' accessibility experts read deeply during evaluation. Honest remarks build credibility; vague "Supports" claims without remarks read as marketing fluff and damage trust.

VPAT vs ACR — what's the difference?

Strictly:

• VPAT = the blank template (an empty form).
• ACR = a completed VPAT for a specific product (the filled-in document).

Casually, the terms are used interchangeably. "Send me your VPAT" → expect a completed ACR. "Do you have a VPAT?" → asking if you've completed an ACR. "Our VPAT shows conformance with WCAG 2.1 AA" → describing what the completed ACR claims.

Who needs a VPAT

• Vendors selling to US federal agencies. Section 508 requires accessible technology; VPATs are the standard procurement artifact. GSA Schedule 70 effectively mandates them.
• Vendors selling to universities and higher-ed institutions. Most US universities now require VPATs in RFPs as part of accessibility compliance procurement.
• Vendors selling to Fortune 500 enterprises. Large corporate procurement teams increasingly include VPAT requirements as standard. Goes far beyond regulated industries.
• Vendors selling in the EU. Under the European Accessibility Act (effective June 2025), accessibility statements are required for many digital products. Vendors with VPAT/ACR documentation are pre-positioned.
• Anyone wanting to demonstrate accessibility leadership. Even without procurement-driven need, a published VPAT signals to customers that accessibility is taken seriously.

How to write a credible VPAT

Test before you fill in

The single biggest mistake: writing the VPAT from product documentation without actually testing. Before any criterion gets "Supports," run automated scanners (axe, WAVE, Pa11y) AND manual screen reader testing (NVDA on Windows, VoiceOver on Mac/iOS, TalkBack on Android, JAWS as a stretch goal). Document what you tested, on what platforms, with what assistive technologies.

Be honest about "Partially Supports"

Almost every real product partially supports many criteria. Common honest scenarios: "keyboard navigation works for the main flows but the dropdown widget on the settings page traps focus," or "alt text is provided for product images but auto-generated charts don't have descriptive alternatives." Documenting these honestly builds buyer trust; hiding them surfaces in the buyer's own audit and kills the deal.

Update with each major release

An 18-month-old VPAT is worse than no VPAT — it actively misleads buyers about current state. Re-test and re-publish with each major UI release. Date the document clearly.

Get an external audit for high-stakes deals

For large government, higher-ed, or regulated-industry contracts, buyers may require third-party audited VPATs. Specialist firms (Deque, Level Access, TPGi) audit your product against WCAG and produce an audited ACR. More expensive but more credible.

Publish it publicly

Posting your VPAT on your website (rather than only sending on request) signals confidence. Procurement teams find it before asking, accelerating sales cycles. Many SaaS companies host VPATs at /accessibility or /legal/accessibility.

Common VPAT mistakes

• Claiming "Supports" without testing. Sales-driven VPATs that say everything works fail buyer audits and damage reputation.
• Outdated VPAT version. Buyers expect VPAT 2.4 or 2.5; submitting a 2.0 from 2018 looks careless.
• No remarks. Just listing "Supports" without explanation provides no useful information. Buyers want evidence.
• Treating VPAT as marketing. A VPAT is procurement documentation, not a sales sheet. Honest, technical, evidence-based.
• Forgetting to update. Stale VPATs are worse than missing ones — they actively misrepresent current state.
• Mixing platforms. Web app + iOS app + Android app + desktop app may each need its own VPAT (or a clearly-segmented combined one with platform-specific remarks per criterion).

FAQ: VPAT

Is a VPAT a certification?

No. A VPAT is a vendor self-attestation, not a third-party certification. Audited VPATs (where an external accessibility firm verifies the claims) carry more credibility than self-attested ones, but neither is a formal "certified" stamp.

Who creates the VPAT?

Internally: an accessibility lead or product manager + engineers who tested specific features. Larger companies have dedicated accessibility programs; smaller companies often hire specialist firms (Deque, Level Access, TPGi) for VPAT engagements.

How long does it take to complete a VPAT?

Small product (single web app): 2-4 weeks of focused testing + writing. Medium (SaaS app + mobile): 4-8 weeks. Enterprise platform: 2-3 months including coordination with multiple product teams. Audited VPATs add 2-4 weeks for the third-party audit cycle.

How much does an audited VPAT cost?

$10,000-50,000+ depending on product complexity. Worth it for high-value contracts where buyers require independent verification or where reputation matters.

Can automated tools generate a VPAT?

No — automated tools (axe, WAVE, Pa11y) catch maybe 30-40% of accessibility issues. They're useful for scanning at scale but the VPAT's credibility comes from manual testing with real assistive technologies. Tools augment human testing; they don't replace it.

Does my SaaS need a VPAT if we don't sell to government?

Recommended even without government customers. Higher education, Fortune 500 enterprises, and EU customers (under the EAA from June 2025) increasingly request VPATs. A published VPAT signals procurement readiness and accelerates enterprise deals.

How LoadFocus relates to VPAT/accessibility work

LoadFocus focuses on performance not accessibility, but accessibility audits often need performance verification too — pages that fail Core Web Vitals create accessibility issues for users on slow networks or low-end devices. Pair your VPAT/ACR work with LoadFocus speed audits across regions to validate accessibility-supporting performance baselines (e.g. ensuring screen reader users on 3G connections still get reasonable page-load times).