VPAT and accessibility for B2B SaaS: what buyers ask for and what it changes in the product

A VPAT is a blank template; the document you send a buyer is the Accessibility Conformance Report (ACR) you complete with it. The report records, criterion by criterion, how your product measures up to a standard such as WCAG. It is your own statement, written from testing, and a buyer's accessibility request is really a question about how the product was built. What follows is how to read that request, and which design decisions make a truthful answer achievable.

What a VPAT is, and how it differs from an ACR

VPAT stands for Voluntary Product Accessibility Template. The Information Technology Industry Council (ITI) publishes it and describes a completed VPAT as an Accessibility Conformance Report. Many people say "VPAT" when they mean the finished report, which is why searches for "VPAT vs ACR" exist at all: the template is the form, the ACR is your filled-in answer for one product at one point in time.

The current release is VPAT 2.5Rev, dated April 2025, in four editions:

• 508, for the revised US Section 508 standards.
• WCAG, for the W3C guidelines, including WCAG 2.2.
• EU, for EN 301 549, the European standard for public procurement of ICT.
• INT, which combines the other three.

Three facts matter before you start. ITI states that there is no certification for a VPAT, and that it does not review or approve them. Nobody stamps your report. Third-party review is optional, though a solicitation may require one. Finally, ITI points out that the product owner holds the most accurate information about the product, and that the template exists to document the results of testing it. Section 508 guidance recommends vendors produce an ACR for any ICT they intend to market to the US federal government, and says contracting officials use it when doing market research and evaluating proposals.

Conformance testing and the VPAT itself are your responsibility, done with qualified testers. We do not produce VPATs or ACRs, we do not certify conformance, and nothing here is legal advice.

What enterprise and public-sector buyers check

A report where every row says "Supports" invites doubt. These gaps are the ones a reviewer can spot, and any of them can stall a deal:

• No evidence of testing. The report does not say which pages, flows or versions were tested, with which browsers and assistive technologies, or when.
• Public marketing pages only. Buyers use your product after sign-in, in tables, filters, dialogues and settings, and a report that tests only the login page tells them nothing.
• Blanket answers. A product with data grids, charts and drag-and-drop does not support every criterion without remarks, and reviewers know it.
• A stale report. The ACR describes a version that has since changed.
• Weak remarks. Where a criterion is only partly met, buyers want to know what fails and whether there is a workaround or a date.

The scale of the underlying problem is large. The WebAIM Million 2026 found detectable WCAG 2 failures on 95.9% of the million home pages it analysed, an average of 56.1 errors per page. The most common were low-contrast text (83.9% of pages), missing image alternative text (53.1%) and missing form input labels (51%). Automated tools find only a subset of problems, so these figures are a floor.

Which rules sit behind the request

This is orientation for product teams, not legal advice; ask counsel what applies to you.

• WCAG 2.2 became a W3C Recommendation on 5 October 2023; the current updated version is dated 12 December 2024. It adds nine success criteria to 2.1 (and retires 4.1.1 Parsing). Four of the new criteria are at Level AA: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum) and Accessible Authentication (Minimum). Each lands on common SaaS patterns: sticky headers, sortable boards, small icon buttons and sign-in flows.
• Section 508 and EN 301 549 are the procurement standards behind the 508 and EU editions of the template, as ITI describes them.
• The European Accessibility Act (Directive (EU) 2019/882) applies to products and services placed on the market after 28 June 2025, according to Your Europe. The European Commission lists consumer-facing areas such as banking services, e-books and e-commerce. Your Europe describes an exemption for service businesses with fewer than 10 employees and a turnover below two million euros. Whether and how it reaches a B2B product depends on what the product does and on national law, so take advice before assuming either way.
• ADA Title II covers US state and local governments, including web content and apps they provide through contracts. ADA.gov says the rule requires WCAG 2.1 Level AA, and that an interim final rule in April 2026 set the compliance dates at 26 April 2027 for entities with populations of 50,000 or more and 26 April 2028 for smaller ones. If your customers are public bodies, their deadlines become your sales deadlines.

What the buyer asks, and what it means in the product

Fix the system, not the screens

When a deadline lands, teams audit screens and file tickets. The backlog is long, and the next release adds more of the same defects. Our argument is that most of those defects have a common source in decisions made once, in the design system, and the cheaper order is to fix those first.

1. Tokens. Set colour pairs so every text and UI-component combination meets contrast in light, dark and any custom theme. The most common failure in the WebAIM data becomes impossible to ship by default.
2. Focus and keyboard behaviour. Define one focus style and one focus-order rule, and check it against sticky headers and side panels (the new Level AA criterion on obscured focus).
3. Core components. Buttons, inputs, selects, dialogues, menus and tabs get names, roles, states and keyboard behaviour once, and are tested with assistive technology before teams reuse them. Build on the WAI-ARIA Authoring Practices patterns rather than inventing new keyboard models.
4. Forms and errors. One label, hint and error pattern, with target sizes that meet the 24 by 24 pixel minimum in WCAG 2.2 (Target Size (Minimum)).
5. Complex widgets. Data grids, drag and drop, charts and date pickers need their own decisions: a non-drag alternative (Dragging Movements), a table view for each chart, and explicit keyboard maps. These are the places where you should expect partial results and write honest remarks.
6. Then the screens. What remains is page-level: heading structure, page titles, content, and the flows your tester finds.

This works only if someone owns the decisions. See who decides in a design system for governance models. New screens then start close to compliant instead of adding to the debt.

A word on overlays. The FTC approved an order in April 2025 requiring one overlay vendor to pay a penalty after alleging its claim that its plug-in could make any website WCAG compliant was false or unsubstantiated, FTC press release. A script layered over an inaccessible interface is not a substitute for fixing the interface.

What to ask a testing provider

Conformance testing needs qualified people, and you will commission it. Before you do, ask:

• Scope. Which standard and level? Which product areas, and which release will the report describe?
• Authenticated states. Will they test signed-in views, roles, settings, empty and error states, and the admin area? Which sample of pages and flows, and how was it chosen?
• Assistive technology. Which screen readers, browsers and operating systems? Is there manual keyboard testing, and testing by people who use these tools daily?
• Method. How do automated and manual checks combine? Automated tools catch only some failures.
• Output. Will you get issue-level detail, reproduction steps and remarks you can reuse in the ACR, in an editable form?
• Retest. Who verifies the fixes, and when does the report get reissued?
• Ownership. You sign and publish the report. Make sure you understand every row of it.

Where our work fits

We are a digital product design studio, not a testing provider, and we do not issue VPATs, ACRs or certifications. Our UX Product Audit looks at a live product's experience so a team can see where design decisions create friction, including for people with disabilities. For the wider design thinking, read our guide on inclusive product design for older and disabled people, which covers the users rather than the procurement angle taken here.