VPATs and Section 508: what they are and why buyers keep asking

Section 508 in one paragraph

Section 508 of the US Rehabilitation Act requires federal agencies to procure, develop, and use information technology that's accessible to people with disabilities. Since the 2017 "refresh," its technical standard incorporates WCAG 2.0 Level AA for web and software interfaces. The practical consequence for vendors: if you want US federal money — directly, or through a contractor, or often through state agencies and universities that mirror the rule — you must document how accessible your product is. That documentation is the VPAT.

What a VPAT actually is

A VPAT — Voluntary Product Accessibility Template — is a standardized report format maintained by the Information Technology Industry Council (ITI). The completed document is formally called an ACR (Accessibility Conformance Report), though everyone calls the document itself a VPAT. It comes in four editions:

• VPAT 508 — against the Section 508 standard,
• VPAT WCAG — against WCAG 2.x directly,
• VPAT EU — against EN 301 549 (the EAA-relevant standard),
• VPAT INT — all of the above in one document.

The core of the document is a table: every applicable success criterion, a conformance level, and remarks. The conformance vocabulary matters:

Term	Meaning
Supports	The functionality meets the criterion without known defects
Partially Supports	Some functionality does not meet the criterion
Does Not Support	The majority of the functionality fails the criterion
Not Applicable	The criterion isn't relevant to the product

Why "fully compliant" is a red flag

Experienced procurement reviewers treat a VPAT with "Supports" on every line the way an engineer treats a test suite that has never failed: as evidence the evaluation didn't happen. Real products have known issues. A credible VPAT says Partially Supports — date pickers in the admin module are not keyboard operable; remediation targeted for Q3. That sentence does three things a blanket claim can't:

1. It proves a real evaluation occurred, criterion by criterion.
2. It lets the buyer make an informed risk decision (maybe their users never touch the admin module).
3. It protects you — an overstated VPAT that a customer relies on is a legal and contractual liability, and the US Department of Justice and agency complaint processes have teeth.

A VPAT is not a marketing document. It's a disclosure document that happens to win deals when it's honest.

How a VPAT gets made (without a six-figure engagement)

1. Scope it. One product, one version, named platforms. "Our company is accessible" is not a scope.
2. Automate the mechanical criteria. Parsing-level issues, missing names and labels, contrast, image alternatives — tooling can evaluate these across the whole codebase and give you per-criterion evidence with file-level precision.
3. Manually test what machines can't judge. Keyboard flows, focus order, screen reader output on the critical paths, error handling. This is where "Supports" claims earn their credibility.
4. Write remarks like an engineer, not a lawyer. Name the failing component, the impact, and the plan.
5. Date it and version it. A VPAT describes a snapshot. Reissue it on major releases — buyers notice a 2022 VPAT attached to a 2026 product.

The EAA connection

If you sell into both the US and the EU, note the convergence: Section 508 wants WCAG 2.0 AA, EN 301 549 (the EAA standard) wants WCAG 2.1 AA, and both are satisfied by building to WCAG 2.1/2.2 AA once. The VPAT INT edition lets you document all of it in a single report — one honest evaluation, three markets covered. We cover the EU side in detail in our EAA field guide.