We produce ACRs for clients at Social Animal regularly. Not because it's glamorous work, but because without one, your product doesn't make it past the RFP stage. This article covers exactly what a VPAT is, which edition applies to you, who should write it, and what a bad one costs you.

What exactly is a VPAT?

A VPAT -- Voluntary Product Accessibility Template -- is a structured document that maps specific accessibility criteria from recognized standards (Section 508, WCAG, EN 301 549) to conformance levels for your software product or service. The template was first developed in 2001 by the Information Technology Industry Council (ITI) and the U.S. General Services Administration to give federal procurement officers a consistent way to evaluate accessibility claims.

The "voluntary" label is misleading. While no law forces you to use this exact format, Section 508 of the Rehabilitation Act (29 U.S.C. § 794(d)) requires federal agencies to buy accessible ICT. The VPAT became the default reporting format because it's the only standardized template both buyers and sellers recognize. ITI states directly on their VPAT resource page: "The Accessibility Conformance Report (ACR), based on a completed ITI VPAT, is the leading global reporting format for assisting buyers and sellers in identifying ICT products and services with accessibility features."

Submitting a VPAT is technically voluntary. Not having one disqualifies you from federal procurement and most enterprise RFPs.

What is the difference between a VPAT and an ACR?

The VPAT is the blank template. The ACR is the completed report. That's it.

When you download the VPAT from ITI's website, you get an empty Word document with tables organized by accessibility criteria. Each row contains a specific success criterion -- WCAG 2.2 criterion 1.1.1 (Non-text Content), for example -- with columns for conformance level, remarks, and explanations. When your team fills in those columns with actual findings from testing your product, the completed document is properly called an Accessibility Conformance Report.

Everyone calls the finished document a "VPAT" anyway. Procurement officers say "send us your VPAT." Sales teams say "we have a VPAT." It's technically wrong, but the usage is universal. Section508.gov uses both terms, noting that the completed document should be called an ACR.

When someone asks for your VPAT during procurement, they want the completed ACR, not a blank template.

Which VPAT edition do you need?

VPAT 2.5 comes in four editions. The edition you choose depends on which markets and regulatory frameworks apply to your product.

Edition Standards Covered When to Use It
WCAG Edition WCAG 2.2 Level A and AA You only need W3C Web Content Accessibility Guidelines -- common for private-sector products not sold to governments
Section 508 Edition Revised Section 508 standards (which incorporate WCAG 2.0 Level A and AA) You sell to U.S. federal agencies
EN 301 549 Edition European standard EN 301 549 (which also incorporates WCAG) You sell to EU public sector organizations
INT Edition (International) WCAG 2.2 + Section 508 + EN 301 549 You sell globally and need to cover all three frameworks in one document

For most clients building B2B SaaS or web applications with any government sales ambitions, we recommend the INT Edition. It costs the same effort to produce and covers you in all three markets. There's no upside to limiting your ACR to a single framework unless your product will never cross borders.

One nuance: the Section 508 edition still references WCAG 2.0, because the U.S. Access Board's Section 508 refresh in January 2017 incorporated WCAG 2.0 Level A and AA by reference. WCAG 2.1 and 2.2 added new success criteria (like 2.5.7 Dragging Movements, added in WCAG 2.2, published October 2023), and those aren't technically part of Section 508's legal requirement yet. The INT edition lets you document conformance against WCAG 2.2 alongside Section 508, which matters since procurement officers increasingly look for WCAG 2.1/2.2 conformance as a differentiator.

What accessibility standards does a VPAT cover?

Three primary standards, each with a distinct legal and geographic scope:

Section 508 (United States)

Section 508 of the Rehabilitation Act of 1973, as amended, requires federal agencies to ensure that ICT they develop, procure, maintain, or use is accessible to people with disabilities. The Revised Section 508 Standards, effective January 18, 2018, incorporate WCAG 2.0 Level A and AA success criteria for web content, electronic documents, and software. They also include functional performance criteria and requirements for hardware, support documentation, and services.

Section 508 is not optional for federal agencies. If your product can't demonstrate conformance through an ACR, procurement officers have a legal basis -- and usually a policy mandate -- to reject your bid.

EN 301 549 (European Union)

EN 301 549 is the European harmonized standard for ICT accessibility. The current version (V3.2.1, published March 2021) incorporates WCAG 2.1 Level A and AA and adds requirements for non-web documents, software, hardware, and other ICT categories. EU Directive 2016/2102 on the accessibility of public sector websites and mobile applications references EN 301 549. The European Accessibility Act (Directive 2019/882), with compliance required from June 28, 2025, extends accessibility requirements to private-sector products and services including e-commerce, banking, and transport.

If you sell into EU public sector or plan to do business in the EU after June 2025, EN 301 549 conformance documentation is mandatory.

WCAG 2.2 (Global)

The Web Content Accessibility Guidelines, maintained by the W3C's Web Accessibility Initiative, are the technical backbone referenced by both Section 508 and EN 301 549. WCAG 2.2, published as a W3C Recommendation on October 5, 2023, includes 86 success criteria across three conformance levels (A, AA, AAA). Level AA conformance is the standard target for legal compliance and procurement.

WCAG is not itself a law, but it's referenced by laws everywhere. ADA Title III case law in the United States has increasingly pointed to WCAG 2.1 AA as the benchmark for commercial website accessibility, even though the ADA doesn't explicitly reference WCAG. It's a consensus technical standard, not a regulation, but regulators worldwide adopt it by reference.

Why do government agencies and enterprises require VPATs?

Because an ACR is the only standardized way to compare accessibility claims across competing products during procurement.

Federal procurement officers operate under FAR (Federal Acquisition Regulation) requirements and Section 508 mandates. When evaluating bids, they need a document that maps each relevant accessibility criterion to a conformance level with supporting remarks. The VPAT template gives them that structure. As Section508.gov explains, agencies use ACRs during market research and evaluation to assess accessibility, but they "will not have enough time or information to examine the truthfulness of every line."

That last point is critical. Procurement officers rely on the accuracy of your ACR. They rarely conduct their own full accessibility audit of your product. This creates both an opportunity (a well-documented ACR can differentiate your product) and a risk (an inaccurate ACR can lead to contract disputes, failed acceptance testing, and reputational damage).

Enterprise buyers have followed suit. We see ACR requests in RFPs from universities, healthcare systems, financial institutions, and Fortune 500 companies -- not just government. Any organization with legal exposure under the ADA, Section 508, or EU directives wants documented evidence of accessibility before signing a contract.

The procurement numbers

U.S. federal IT spending hit roughly $100 billion in FY2024. State and local government IT spending adds billions more. Higher education institutions collectively spend tens of billions on technology. None of that money flows to products without an ACR.

If your product doesn't have a current ACR, you're not losing deals on merit. You're losing them on paperwork.

Who should author your VPAT?

An ACR should be authored by someone who has conducted hands-on accessibility testing of the product against every applicable success criterion -- not by someone who read the marketing docs and checked boxes.

The ideal author has:

Deep technical knowledge of WCAG 2.2 -- not just familiarity with the guidelines, but experience interpreting edge cases. Does a custom drag-and-drop interface satisfy criterion 2.5.7 (Dragging Movements) if it provides a single-pointer alternative? The answer depends on implementation specifics that only testing reveals.

Experience with assistive technology -- testing with screen readers (NVDA, JAWS, VoiceOver), screen magnifiers, switch devices, and voice control. Automated scanners (axe-core, WAVE, Lighthouse) catch roughly 30-40% of WCAG issues. The rest require manual testing with real assistive tech.

Understanding of the VPAT format and conformance levels -- the VPAT uses specific conformance levels (Supports, Partially Supports, Does Not Support, Not Applicable) with precise definitions from ITI. Misusing these levels undermines the entire report's credibility.

Independence or at least objectivity -- a vendor self-assessing their own product has an obvious conflict of interest. While self-assessment is common and accepted, the credibility of your ACR increases when produced or validated by an independent third party.

We author ACRs as part of our web accessibility compliance work. Our process involves full manual + automated audits against WCAG 2.2 AA, assistive technology testing across multiple platforms, and detailed per-criterion documentation. The resulting ACR is a document we're willing to stand behind because we've actually tested every criterion.

Why do self-serve VPAT templates fail audits?

Because filling in a template without conducting actual testing produces a fiction, and procurement officers are increasingly good at spotting fictions.

What goes wrong with DIY VPATs:

Over-claiming "Supports"

The most common failure. A team marks dozens of criteria as "Supports" without testing. Then a procurement officer's accessibility SME spot-checks three criteria with a screen reader and finds two failures. The entire ACR loses credibility instantly. One false "Supports" claim casts doubt on every other claim in the document.

Missing or vague remarks

The VPAT template has a "Remarks and Explanations" column for a reason. A bare "Supports" with no explanation is a red flag. Strong ACRs include specific details: "All images include programmatic alt text. Decorative images use empty alt attributes. Complex charts include long descriptions via aria-describedby." Weak ACRs say "Supports" and nothing else.

Testing only with automated tools

A team runs axe-core or Lighthouse, gets a clean report, and marks everything as "Supports." Automated tools only test a subset of WCAG criteria. Criteria like 1.3.1 (Info and Relationships), 2.4.3 (Focus Order), and 3.3.2 (Labels or Instructions) require manual evaluation. An ACR based solely on automated scans will have gaps that any knowledgeable reviewer will identify.

Wrong edition or outdated version

We've seen companies submit ACRs based on VPAT 2.3 (which referenced WCAG 2.0 and the original Section 508 standards) for 2024 procurement processes. The current VPAT version is 2.5. Submitting an outdated format signals that accessibility isn't a priority and the report may not reflect the product's current state.

No product version or date

An ACR without a clear product version number and evaluation date is functionally useless. Products change. An ACR from 18 months ago may not reflect the current UI. ITI's template includes fields for this information, but self-serve authors often leave them blank or vague.

How often should you update your VPAT?

Update your ACR whenever you make significant UI changes, and at minimum annually.

There's no legal cadence mandated by Section 508 or any other regulation. But procurement officers look at the evaluation date. An ACR dated more than 12-18 months ago raises questions about whether it reflects the current product. If you've shipped a major redesign, a new feature area, or migrated to a new frontend framework since your last ACR, it's time for a new one.

We recommend clients plan ACR updates on the same cadence as major product releases. If you ship quarterly, review your ACR quarterly. If you ship continuously, set a calendar reminder for every 6 months and evaluate whether changes warrant a re-assessment.

Some organizations maintain a living ACR, updating it incrementally as features ship. This is ideal but requires embedding accessibility testing into your CI/CD pipeline and having someone on staff who can write VPAT-quality documentation. For most companies, periodic third-party re-evaluation is more practical.

What does a strong ACR actually look like?

A strong ACR is specific, honest, and useful to a procurement officer who has 20 minutes to review it.

Characteristics of a strong ACR:

Clear product identification: exact product name, version number (e.g., "v4.2.1"), and evaluation date

Stated evaluation methods: "Manual testing with NVDA 2024.1 on Chrome 120, JAWS 2024 on Edge 120, VoiceOver on Safari 17.2, iOS 17.2. Automated testing with axe-core 4.8.2."

Honest conformance levels: "Partially Supports" with a clear explanation is far more credible than a blanket "Supports" with no details. Procurement officers know that no complex application is 100% conformant -- they're looking for awareness and a remediation path.

Specific remarks per criterion: not boilerplate, not copy-pasted from another product's ACR

Remediation notes for gaps: where the product does not fully support a criterion, state what the issue is and what the remediation plan and timeline look like

Contact information: a named accessibility contact, not a generic support email

Deque makes a good point on their VPAT page that the ACR "warns users about any accessibility blockers they may encounter." That framing is useful -- the ACR isn't just a compliance checkbox. It's a disclosure document. Treat it like one.

How does a VPAT fit into an accessibility compliance program?

The ACR is an output of your accessibility program, not the program itself. It documents the current state, but it doesn't create accessibility.

A real accessibility compliance program includes:

Design standards -- components designed with accessibility in mind from the start, not retrofitted

Development practices -- semantic HTML, ARIA used correctly (not as a band-aid), keyboard operability, color contrast ratios meeting WCAG 2.2 AA (4.5:1 for normal text, 3:1 for large text and UI components)

Automated testing in CI/CD -- tools like axe-core integrated into your build pipeline to catch regressions

Manual testing protocols -- regular testing with assistive technology by people who know how to use it

User testing with people with disabilities -- the most valuable and most frequently skipped step

Documentation -- the ACR, plus an accessibility statement, plus internal documentation

Remediation tracking -- a backlog of known issues with severity ratings and target fix dates

The ACR sits at step 6. If you skip steps 1-5, the ACR will either be dishonest or embarrassing.

We help clients build this full pipeline. The ACR is often the entry point -- a client needs one for an upcoming RFP -- but the real value is in the program that supports it. Our web accessibility compliance work covers the full spectrum from audit through remediation through documentation.

FAQ

Is a VPAT legally required?

No specific law mandates the VPAT format. However, Section 508 of the Rehabilitation Act requires federal agencies to procure accessible ICT, and the VPAT/ACR is the universally accepted format for demonstrating compliance. Without one, you're effectively excluded from federal procurement.

What does VPAT stand for?

VPAT stands for Voluntary Product Accessibility Template. It was created by the Information Technology Industry Council (ITI) in partnership with the U.S. General Services Administration (GSA) starting in 2001. The current version is VPAT 2.5.

Is there a pass/fail score on a VPAT?

No. As ITI states on their official VPAT page, "There is no 'pass/fail' scale for determining whether a product is accessible or inaccessible." Each criterion is rated individually, and procurement officers evaluate the overall picture based on their specific needs.

Can I fill out a VPAT myself?

Yes, self-assessment is permitted. However, without genuine accessibility testing expertise, self-authored ACRs frequently over-claim conformance or omit critical details. A procurement officer who spot-checks and finds inaccuracies will discount the entire document.

How much does a VPAT cost to produce?

Costs vary based on product complexity. For a straightforward web application, expect $3,000-$8,000 for a third-party audit and ACR production. Complex SaaS platforms with multiple user roles and interaction patterns can run $10,000-$25,000 or more. DIY costs less in dollars but more in credibility risk.

Does WCAG 2.2 replace WCAG 2.1?

WCAG 2.2 is the current W3C Recommendation as of October 5, 2023. It builds on WCAG 2.1 and adds 9 new success criteria. WCAG 2.1 remains a valid W3C Recommendation. Section 508 still references WCAG 2.0 by law, but testing against 2.2 covers 2.0 and 2.1 by design since WCAG versions are backward-compatible.

What is the European equivalent of Section 508?

EN 301 549 is the European harmonized standard for ICT accessibility, referenced by EU Directive 2016/2102 for public sector websites and mobile apps. The European Accessibility Act (Directive 2019/882) extends requirements to certain private-sector products and services starting June 28, 2025.

How does ADA Title III relate to VPATs?

ADA Title III prohibits discrimination by places of public accommodation, and courts have increasingly applied this to websites and digital services. While Title III doesn't specifically reference WCAG or require a VPAT, settlement agreements and court rulings frequently cite WCAG 2.1 AA as the technical standard. An ACR can serve as evidence of your accessibility posture in ADA-related proceedings.