Procurement asked for your VPAT. Here's what to send.

The security questionnaire is done, the SOC 2 report is attached, and one line in the vendor packet stops the deal: "Please provide your VPAT." Someone searches for it, sees "VPAT certification" in the suggestions, and starts shopping for something that doesn't exist.

A VPAT is a template. What procurement wants is the filled-in version, an Accessibility Conformance Report (ACR), and it's only as credible as the testing behind it. Here are the five questions behind the request, and what to send for each.

What is a VPAT, and what is an ACR?

VPAT stands for Voluntary Product Accessibility Template. The Information Technology Industry Council (ITI), a tech industry association, publishes it; the current version is 2.5Rev, from April 2025. In ITI's words: "Once completed, the VPAT with documented testing results is referred to as an Accessibility Conformance Report (ACR)."

ITI doesn't review or approve VPATs, and there's no pass or fail. Each criterion gets one of four answers: Supports, Partially Supports, Does Not Support, or Not Applicable. So there's no VPAT certification to buy. An ACR is your own statement about how your product performs against a named standard, and your buyer will read it like any other representation in the deal.

Which accessibility standard is the buyer asking about?

Usually WCAG, the W3C's Web Content Accessibility Guidelines. The current version, WCAG 2.2, is a W3C Recommendation (last updated December 2024), approved in October 2025 as ISO/IEC 40500:2025. It adds nine success criteria to WCAG 2.1, six of them at Level A or AA, and removes one, 4.1.1 Parsing.

The laws behind it differ by market and often name older versions:

The European Accessibility Act. Directive (EU) 2019/882 has applied since June 28, 2025 to a listed set of products and of services provided to consumers, including e-commerce and consumer banking. Microenterprises providing services (fewer than 10 people, and turnover or balance sheet of €2 million or less) are exempt, and each member state writes the rules into national law. The services list is consumer-facing, so B2B-only software usually isn't directly in scope, but your customers may be: if a bank's consumer app or a retailer's checkout runs on your software, expect the requirement in your contract, as with fintech and healthtech compliance.
EN 301 549. The European standard behind the Act and the public-sector Web Accessibility Directive. Version 4.1.1, published online on September 2, 2026, moves the web baseline to WCAG 2.2 Level AA. Ireland's National Disability Authority reports that its citation in the EU's Official Journal is expected on December 16, 2026, and only that citation gives it a presumption of conformity with both laws. Until then, version 3.2.1 from 2021, built on WCAG 2.1, remains in force.
The United States. Federal buyers work from Section 508. For state and local governments, the Justice Department's ADA Title II rule requires WCAG 2.1 Level AA for web content they provide "directly or through contractual, licensing, or other arrangements." An interim final rule published in April 2026 moved compliance to April 26, 2027 for public entities with a total population of 50,000 or more, and to April 26, 2028 for smaller ones. Sell edtech to public universities and that clause is why the question is in your RFP.

Our recommendation: test against WCAG 2.2 Level AA now. The W3C says content that conforms to 2.2 also conforms to 2.0 and 2.1 (a policy citing those may still expect 4.1.1 tested and reported), and its working group recommends 2.2 as the target even where obligations cite earlier versions. This isn't legal advice; ask counsel which law binds your buyer.

Which VPAT edition should you fill in?

ITI publishes four: 508 for the US federal standard, EU for EN 301 549, WCAG for the W3C guidelines (2.2 included), and INT, which covers all three. Selling only to US private companies? The WCAG edition usually does the job. Selling in the US and Europe? Fill in INT once and stop rebuilding it per deal.

Who tested it, and how?

Most ACRs lose credibility here. Name the product version, the evaluation date, who tested, and how: automated checks, a keyboard-only walk through the core flows, and screen reader testing.

WebAIM's 2026 analysis of the top 1,000,000 home pages found detected WCAG 2 failures on 95.9% of them, an average of 56.1 errors per page, with low-contrast text on 83.9%. Those are popular home pages, not B2B product interfaces, and WebAIM notes that not every conformance failure can be detected automatically. Read it as a measure of how common the basics are, not a benchmark.

An overlay widget doesn't fix the product underneath either. In April 2025 the US Federal Trade Commission finalized an order requiring an overlay vendor to pay $1 million; the FTC had alleged that the vendor's claim that its plug-in could make any website WCAG compliant was false, misleading, or unsubstantiated.

What fails, and when will it be fixed?

Every real product has gaps, and a buyer who sees "Supports" on every row assumes nobody tested. Mark partial support as Partially Supports, explain it in the remarks, and attach a remediation roadmap: each gap, who it affects, the fix, and a target date. Never write "fully compliant" in an RFP answer. One failed contrast check by the buyer's tester and every other answer gets reread.

Our own accessibility statement follows that rule: it says "partially conformant" and lists each known issue with a plan.

Where does WCAG 2.2 conformance actually come from?

Mostly from the design system. The common failures are decisions made once and copied everywhere: a text color, a focus style, a button size. Fix them in tokens and components developers actually use and every screen inherits the fix.

Contrast. Normal text needs at least 4.5:1 against its background (1.4.3). Pair each text token with its background in light and dark mode.
Focus. Keyboard focus must be visible (2.4.7), and new in 2.2, your own sticky header or cookie banner can't entirely hide the focused element (2.4.11).
Target size. Pointer targets of at least 24 by 24 CSS pixels, with a few exceptions (2.5.8). Icon buttons in dense tables fail first.
Login. No step may require a cognitive function test, such as remembering a password or solving a puzzle, without an alternative or a mechanism that helps, like allowing paste and password managers (3.3.8, with narrow exceptions).

We'd also ship a reduced-motion variant with every animation. It costs little at design time and a lot to retrofit. Build then keeps the fixes from regressing with semantic markup and automated checks such as axe-core on every pull request.

The packet to have ready

An ACR in the edition your markets need, with version, date and testing methods; a dated remediation roadmap; and a public accessibility statement. File them next to your SOC 2 report, because they travel in the same procurement packet.

This work touches four practices. Studio owns the design system that makes conformance repeatable, Build the markup and CI checks, and Secure the security questionnaire the ACR ships with. Sales needs all of it before the RFP, not after. That's why we'd scope it as one piece of work.