Blog Post
VPAT Template for Web QA Teams
Last updated: April 1, 2026
A VPAT (Voluntary Product Accessibility Template) documents how your software product conforms to accessibility standards. This guide explains what a VPAT is, when your team needs one, and provides a practical template for documenting accessibility conformance during procurement.
What Is a VPAT?
A VPAT is a standardized document that describes how a technology product meets Section 508 standards and WCAG 2.1 success criteria. Vendors complete the VPAT template to produce an Accessibility Conformance Report (ACR) that procurement teams review when evaluating tools. If you sell to government, higher education, or enterprise buyers, a VPAT is table stakes.
When Do You Need a VPAT?
You need a VPAT when selling to U.S. federal agencies (Section 508), state and local governments (many now require it), universities and school districts, large enterprises with accessibility procurement policies, or any organization subject to ADA Title II compliance requirements for digital services.
VPAT vs. ACR: What's the Difference?
The VPAT is the blank template published by the IT Industry Council (ITI). The ACR is the completed document describing your product's specific conformance. In conversation, people use "VPAT" for both. What buyers actually want is a completed ACR.
The VPAT Template Structure
The ITI VPAT 2.5 template covers four reporting standards: WCAG 2.1, Revised Section 508, EN 301 549 (EU), and a combined international edition. Most web applications use the WCAG 2.1 edition. Each section maps success criteria to conformance levels: Supports, Partially Supports, Does Not Support, or Not Applicable.
How to Fill Out a VPAT Step by Step
Step 1: Choose the Right Edition
For web-based SaaS products, select the WCAG 2.1 edition. If you also sell to EU public sector, use the EU edition (EN 301 549). For U.S. government sales, the Revised Section 508 edition covers your requirements.
Step 2: Audit Your Product
Run a thorough accessibility audit before filling out conformance levels. Test with screen readers, keyboard-only navigation, and automated scanners. Document what works, what partially works, and what does not.
Step 3: Document Conformance Levels
For each WCAG criterion, assign a conformance level and add remarks explaining how your product meets or fails to meet the requirement.
Step 4: Write Honest Remarks
Procurement reviewers read the remarks column. Partial support with a credible remediation plan is better than a blanket "Supports" claim that falls apart during testing.
VPAT Template: Key Sections
A completed VPAT includes product information, evaluation methods used, applicable standards, conformance level for each success criterion (Perceivable, Operable, Understandable, Robust), and remarks with explanations.
Section 508 and ADA Title II: What QA Teams Should Know
Section 508 applies to federal agencies and their vendors. ADA Title II compliance increasingly applies to state and local government digital services. Both reference WCAG 2.1 Level AA as the baseline. QA teams building 508 compliance checks into their workflow catch issues before they block procurement.
OverlayQA's Accessibility Commitment
OverlayQA is committed to building an accessible product. We follow WCAG 2.1 Level AA guidelines in our Chrome extension and dashboard, use semantic HTML, maintain keyboard navigability, and test with screen readers. Our accessibility audit workflow is in development to help teams catch accessibility issues alongside visual QA.
| Edition | Standards Covered | Best For |
|---|---|---|
| WCAG 2.1 | WCAG 2.1 Level A and AA | Web-based SaaS products with global customers |
| Revised Section 508 | Section 508, WCAG 2.0 Level A and AA | U.S. federal government sales |
| EN 301 549 | EN 301 549, WCAG 2.1 | EU public sector sales |
| INT (International) | All three combined | Products sold to government buyers in both the U.S. and EU |
| Level | Meaning | When to Use |
|---|---|---|
| Supports | The product fully meets the criterion | Your implementation passes testing with no known issues for this criterion |
| Partially Supports | Some functionality meets the criterion, but gaps exist | Core flows are accessible but edge cases or specific components have known issues |
| Does Not Support | The product does not meet this criterion | You have identified failures and do not yet have a fix in place |
| Not Applicable | The criterion does not apply to this product | Example: "captions for prerecorded audio" on a product with no audio content |
| Criterion | Level | Remarks |
|---|---|---|
| 1.1.1 Non-text Content | Supports | All images include descriptive alt text. Decorative images use empty alt attributes. Icon buttons have accessible labels. |
| 1.4.3 Contrast (Minimum) | Partially Supports | Primary UI meets 4.5:1 contrast ratio. Three data visualization charts use colors that fall below 3:1 for graphical elements. Remediation planned for Q2 2026. |
| 2.1.1 Keyboard | Partially Supports | All core navigation, forms, and actions are keyboard accessible. The drag-and-drop reorder feature in the dashboard does not have a keyboard alternative. Keyboard alternative in development. |
Frequently Asked Questions
What is a VPAT and who needs one?
A VPAT is a standardized document describing how software conforms to accessibility standards. Any vendor selling to government agencies, universities, or enterprises with accessibility requirements needs one.
What is the difference between a VPAT and an ACR?
A VPAT is the blank template. An ACR is the completed document for a specific product. Most people say "VPAT" when they mean both.
How often should a VPAT be updated?
Update after every major release or at minimum annually. A stale VPAT signals that accessibility is not actively maintained.