What Is a VPAT? A Clear Guide to Accessibility Conformance in Procurement

VPAT is one of those terms that shows up when organizations buy software, websites, mobile apps, or digital services—especially in government and higher education—and suddenly it feels like “accessibility paperwork.” In reality, a VPAT can be a practical tool for making better buying decisions and reducing accessibility risk.

This article breaks down what a VPAT is, what it’s for, how it relates to WCAG and other standards, and how to use it responsibly in accessibility compliance and inclusive design.

What is VPAT?

VPAT stands for Voluntary Product Accessibility Template. It’s a standardized document format used by vendors to describe how well their digital product conforms to accessibility requirements. A completed VPAT is often called an Accessibility Conformance Report (ACR).

The VPAT format is commonly requested during procurement so buyers can evaluate whether a product meets applicable accessibility standards (or where it falls short). While “voluntary” is in the name, VPATs are frequently required in real-world purchasing processes.

VPAT vs. ACR: What’s the difference?

  • VPAT: The template/form provided by the ITI (Information Technology Industry Council).
  • ACR (Accessibility Conformance Report): The completed document that includes the vendor’s responses.

In practice, people often say “VPAT” to mean “the vendor’s completed accessibility report.”

What standards does a VPAT cover?

A VPAT can be completed for different accessibility standards depending on what the buyer needs. The most common editions include:

  • WCAG (Web Content Accessibility Guidelines), typically WCAG 2.1 or WCAG 2.2 at Level A/AA
  • Revised Section 508 (U.S. federal accessibility requirements for ICT)
  • EN 301 549 (a key European accessibility standard used in public procurement)

If you’re still getting comfortable with WCAG concepts, the article WCAG in Plain English: What It Really Means (and How to Use It) can help you understand what VPAT claims are actually referencing.

Accessibility procurement team reviewing a VPAT document on a laptop during a meeting

Why VPAT matters for digital accessibility and inclusive procurement

A VPAT is useful because it makes accessibility an explicit part of the buying decision—before you sign a contract, launch a tool, or integrate it into critical workflows.

When procurement teams request accessibility information early, it helps organizations:

  • Reduce legal and compliance risk (e.g., Section 508, ADA-related exposure, or public-sector requirements)
  • Avoid costly retrofits after implementation
  • Protect user experience for people who use screen readers, keyboard navigation, captions, zoom, or voice input
  • Compare vendors consistently using a known template

This is especially important for SaaS purchases, where accessibility issues can scale across an entire organization. If your team builds or buys software products, Digital Accessibility for SaaS Companies: Build WCAG-Compliant Products That Scale provides helpful context on how accessibility becomes a product and operational requirement—not a one-time checkbox.

What information is included in a VPAT?

VPATs are structured around specific requirements (for example, WCAG success criteria or Section 508 provisions). For each requirement, the vendor typically indicates:

  • Conformance level (e.g., Supports, Partially Supports, Does Not Support, Not Applicable)
  • Remarks and explanations describing how the feature works, limitations, and any known issues
  • Testing notes such as assistive technologies used, platforms tested, and known constraints

A strong VPAT doesn’t just mark “Supports.” It explains real behavior (e.g., “keyboard focus is visible on all interactive controls except the date picker”) and identifies where workarounds or roadmap items exist.

For a deeper dive into the typical sections and how to apply them, see VPAT Report: What It Is, What It Includes, and How to Use It for Accessibility Compliance.

Who needs a VPAT?

VPATs are most commonly requested by:

  • U.S. federal, state, and local government buyers (Section 508 obligations)
  • Universities and K–12 institutions
  • Healthcare and finance organizations with higher compliance expectations
  • Enterprises with supplier accessibility programs

They’re also increasingly relevant in Europe. While VPAT isn’t itself an EU law, EN 301 549 is widely referenced in European public procurement and compliance programs. If you’re aligning to upcoming obligations, EAA Compliance Guide: How to Meet the European Accessibility Act with WCAG can clarify how WCAG fits into that landscape.

Accessibility procurement team reviewing a VPAT document on a laptop during a meeting

How to read a VPAT (and spot red flags)

VPATs can range from high-quality, evidence-based reports to vague documents that don’t reflect real testing. When reviewing one, pay attention to these signals.

Good signs

  • Specific remarks that describe actual UI behavior and limitations
  • Clear test scope (which pages/features, which platforms, which assistive technologies)
  • Honest “Partially Supports” with details and remediation plans
  • Versioning (product version, report date, and update frequency)

Red flags

  • Too many “Supports” answers with no explanation
  • Outdated VPATs that don’t match the current product
  • Statements like “supports accessibility” without naming WCAG level or criteria
  • No mention of mobile, PDFs, or key workflows when those are central to the product

Procurement teams should treat a VPAT as one input, not the only proof. If the product is business-critical, consider validating with an independent audit or hands-on testing.

How to use VPATs effectively in procurement

A practical way to use VPATs is to connect them to decision-making and contract requirements:

  • Request VPAT/ACR early during vendor evaluation, not after selection.
  • Ask follow-up questions on any “Partially Supports” areas that affect your key user flows.
  • Require an accessibility roadmap with timelines for known gaps.
  • Include accessibility language in contracts (e.g., maintenance of conformance, notification of major changes, remediation commitments).
  • Verify through sampling, testing, or an independent assessment for high-risk tools.

Organizations with seasonal spikes or public-facing services (like travel and booking) should be particularly careful: accessibility failures can impact large audiences quickly. The article Summer Travel Trends: Accessible Digital Experiences That Every Traveler Can Use shows how inclusive digital experiences support real customer needs at scale.

Creating and maintaining an accurate VPAT

If you’re a vendor producing a VPAT (or a buyer supporting a supplier), accuracy comes from repeatable testing and clear documentation. Common best practices include:

  • Test against applicable WCAG success criteria on real user flows
  • Include keyboard-only testing, screen reader testing, zoom/reflow, color contrast, and error handling
  • Document known issues and provide workarounds where possible
  • Update the VPAT when major UI changes ship

Tools can help you stay on top of issues between releases. For example, Corpowid (corpowid.ai) supports automated accessibility audits and ongoing monitoring that can surface WCAG-related regressions, making it easier to keep the evidence behind your VPAT current rather than treating it as a once-a-year scramble.

Accessibility procurement team reviewing a VPAT document on a laptop during a meeting

VPAT is not a guarantee—treat it as a starting point

A VPAT is valuable, but it’s not a certification and it doesn’t automatically mean a product is accessible for all users in all contexts. Accessibility depends on implementation details, configuration, content, and the specific workflows your users rely on.

The most effective approach is to combine VPAT review with practical validation: test critical tasks, confirm assistive technology compatibility, and ensure your organization has an accessibility process for procurement and ongoing governance. If you need a repeatable way to identify common WCAG failures and document progress, Corpowid (corpowid.ai) can complement manual testing by continuously tracking issues and helping teams prioritize fixes.

Key takeaways

  • A VPAT (completed as an ACR) explains how a product meets accessibility requirements such as WCAG, Section 508, and/or EN 301 549.
  • VPATs are widely used in procurement to assess accessibility risk and vendor readiness.
  • Look for specific remarks, test scope, and honest limitations—not just “Supports” everywhere.
  • Use VPATs alongside validation testing and contract commitments for the best outcomes.

Corpowid is recognized by Gartner

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.

Have questions about Corpowid?

Let’s connect.

We will get back to you as soon as possible.