vpat and acr beginners guide

Most accessibility problems don’t look like problems at first. In demos, software behaves. Navigation works. Screens load. Nothing crashes. From a distance, it’s easy to assume the product is “accessible enough.” That assumption holds—until someone tries to use it without a mouse, without full vision, or without relying on visual cues that most teams take for granted.

Procurement teams tend to encounter accessibility at a different moment. Not during development. Not during sales demos. But when contracts are being reviewed, and someone asks a simple, uncomfortable question: How do we know this product has actually been evaluated?

That’s the gap a VPAT is meant to fill.

Not as a promise. Not as marketing. As documentation that makes accessibility claims visible before decisions are locked in.

Why Accessibility Issues Slip Through So Often

Accessibility failures are rarely dramatic. They don’t usually bring systems down. They introduce friction instead.

A button that can’t be reached by keyboard.

A modal that traps focus.

A chart that communicates meaning only through color.

For teams building or buying software, these issues are easy to miss because they don’t affect everyone equally. Internal QA may never surface them.

But once software is rolled out across an enterprise—or adopted by a government agency—those gaps stop being theoretical. They affect real users, real workflows, and sometimes, legal exposure.

This is where structured accessibility documentation starts to matter. VPAT accessibility reporting exists to surface these issues earlier, when teams still have options.

What a VPAT Is (Without the Buzzwords)

A Voluntary Product Accessibility Template, or VPAT, is a standardized way for vendors to explain how their product aligns with recognized accessibility standards. That’s it.

It’s not a certification. It’s not an accessibility score. And it’s not a declaration that a product is “fully accessible.” Those assumptions cause more confusion than clarity. The value of a VPAT is specificity. Instead of broad statements, vendors are expected to respond to individual accessibility criteria and explain—plainly—how their product behaves in each case.

When that template is filled out with real findings, it becomes an Accessibility Conformance Report (ACR). That report is what procurement teams actually review and rely on.

In practice, the VPAT is the structure. The ACR is the substance.

Why VPAT and ACR Get Used as the Same Thing

If you sit in enough procurement meetings, you’ll notice people rarely separate the terms. Buyers ask for a “VPAT.” Vendors send a completed report. No one stops to clarify vocabulary.

The distinction matters behind the scenes, though. A blank template doesn’t reduce risk. A completed ACR does—assuming it’s accurate. Once submitted as part of procurement, that document represents the vendor’s formal accessibility claims. In many cases, it becomes part of the contract record. That’s why precision matters. Accessibility documentation isn’t aspirational. It’s declarative.

How VPATs Became a Procurement Baseline

Accessibility documentation used to be associated almost exclusively with federal procurement. That’s no longer true.

Today, VPATs show up across:

• Government agencies at all levels
• Public universities and education systems
• Healthcare and insurance organizations
• Financial institutions
• Large enterprises with internal accessibility policies

The reason is practical, not philosophical. These organizations are accountable for the technology they deploy. They need a way to evaluate accessibility claims consistently and defensibly.

For vendors, not having a VPAT often stops conversations before they start. For buyers, a poorly written one raises immediate questions. Either way, the document carries weight.

The Four VPAT 2.4 Editions (What Actually Changes)

VPAT version 2.4 comes in four editions. On paper, they look similar. In procurement, choosing the wrong one creates friction.

The Section 508 edition is typically used when selling into U.S. federal environments or organizations that mirror federal requirements.

The WCAG edition focuses on the Web Content Accessibility Guidelines and is commonly used in private-sector procurement.

The EU edition, aligned with EN 301 549, reflects European accessibility requirements and includes criteria beyond WCAG.

The International (INT) edition combines multiple standards into one document. Vendors selling across regions often choose it to avoid maintaining multiple reports. The right choice depends on who is buying your product—not who built it.

The Standards Behind the Document (Briefly)

Accessibility standards aren’t meant to intimidate, but they often do. WCAG, which underpins most VPAT reporting, is based on four principles: content should be perceivable, operable, understandable, and robust. These principles translate into expectations like keyboard access, readable text, predictable navigation, and compatibility with assistive technologies.

Section 508 applies these ideas to federal information and communication technology. EN 301 549 extends them further for European use cases. Most procurement teams don’t want a lecture on standards. They want to know whether the VPAT reflects them accurately.

What a Real VPAT Audit Looks Like

A meaningful VPAT doesn’t come from guessing.

A credible VPAT audit involves manual testing of the product against relevant criteria. Automated tools can catch some issues, but they miss context and user experience.

Real evaluations typically involve:

• Keyboard-only navigation
• Screen reader interaction
• Visual contrast checks
• Review of error messaging and feedback

The goal isn’t to label a product as “accessible” or “not accessible.” It’s to understand how it behaves for users who interact with it differently—and to document that behavior honestly.

Reading VPAT Conformance Levels Without Overthinking Them

VPAT reports use standardized conformance labels. They’re easy to misinterpret if you assume “Supports” is the only acceptable answer.

“Supports” means the requirement is met without known issues.

“Partially Supports” means there are limitations—and details matter.

“Does Not Support” identifies known gaps.

“Not Applicable” explains why something doesn’t apply.

“Not Evaluated” discloses what wasn’t assessed.

From a buyer’s perspective, clarity matters more than perfection. From a vendor’s perspective, honesty reduces downstream risk.

Why VPATs Can’t Be One-Time Documents

Software changes. Features are added. Interfaces evolve. Accessibility can improve—or quietly regress.

That’s why VPATs shouldn’t be treated as permanent artifacts. Many procurement teams expect them to be updated regularly, especially for actively developed products. Reports that are several years old often trigger additional scrutiny. Keeping documentation current signals that accessibility is part of ongoing product governance, not a one-off exercise.

When Accessibility Documentation Actually Helps the Business

Handled poorly, VPATs feel like paperwork. Handled well, they become operational tools.

Clear documentation reduces procurement back-and-forth. It surfaces issues early. It gives internal teams a clearer picture of where accessibility investment is needed. For organizations selling into enterprise or government environments, accurate VPAT accessibility reporting often shortens sales cycles and builds credibility faster than broad claims ever could.

Where AccessifyLabs Comes In

Accessibility documentation sits between technical evaluation and procurement reality. Both sides matter, and both are easy to misunderstand.

AccessifyLabs supports organizations across that gap—conducting structured audits, creating defensible VPAT and ACR documentation, and reviewing vendor-provided reports during procurement.

The focus isn’t just compliance. It’s clarity. We help teams understand what their documentation actually communicates—and what it leaves unsaid.

Making Accessibility Claims You Can Stand Behind

VPATs and ACRs exist to make accessibility visible before decisions become difficult to undo.

When they’re accurate, buyers make better choices, vendors reduce risk, and users benefit from technology that works as intended. When they’re vague or outdated, everyone pays the price later.

If your organization needs support with VPAT audits, documentation, or procurement review, AccessifyLabs is ready to help.

Reach out to AccessifyLabs to strengthen your accessibility reporting—and move forward with confidence.