A VPAT (Voluntary Product Accessibility Template) is a standardized document that describes how a software product, website, or digital service meets accessibility standards such as WCAG and Section 508. It is created using the official template from the IT Industry Council (ITI) and, once completed, is formally called an Accessibility Conformance Report (ACR).

What does 'Partially Supports' mean in a VPAT?

'Partially Supports' means the product meets the accessibility criterion for some functionality or in some circumstances, but not all. It is one of five allowed conformance responses: Supports, Partially Supports, Does Not Support, Not Applicable, and Not Evaluated. When you mark a criterion as 'Partially Supports,' you must include specific remarks explaining what works, what doesn't, and any available workarounds.

Can I write a VPAT myself or do I need a consultant?

You can write a VPAT yourself if your team has accessibility testing expertise and understands WCAG criteria. However, many organizations hire accessibility consultants for the initial VPAT because an independent audit adds credibility and consultants catch issues internal teams miss. For government contracts above a certain value, a third-party audit is often expected. Subsequent updates can usually be handled internally once the first version is in place.

VPAT & ACR Documentation: The Complete Guide

Q: What is the difference between a VPAT and an ACR?

A VPAT is the blank template; an ACR (Accessibility Conformance Report) is the completed document you produce by filling out that template. Think of the VPAT as the form and the ACR as your filled-in submission. The terms are commonly used interchangeably in procurement conversations, but technically the ACR is the deliverable.

Q: Is a VPAT legally required?

A VPAT is not legally required by statute, but it is effectively mandatory for selling software to U.S. federal agencies, federally funded universities, and many large enterprises. Section 508 requires federal agencies to procure accessible technology, and agencies enforce this by requesting a completed VPAT (ACR) during procurement. Without one, vendors are typically disqualified.

Q: Which VPAT edition should I use?

VPAT 2.5 comes in four editions: WCAG (international web standard), Section 508 (U.S. federal), EU (European EN 301 549 standard), and INT (all three combined). Use the Section 508 edition for U.S. government sales, the EU edition for European public sector contracts, and the INT edition if you need to cover all markets in a single document. Most U.S. SaaS vendors submit the INT edition.

Q: How often should a VPAT be updated?

A VPAT should be reviewed and updated after every major product release that changes UI, navigation, or interactive features. As a rule of thumb, a VPAT older than 12–18 months raises red flags with government procurement teams. Many organizations review their VPAT quarterly and do a full re-test annually or after any significant release.

What Is a VPAT?

A Voluntary Product Accessibility Template (pronounced "VEE-pat") is a standardized document that describes how a software product, website, or digital service meets (or doesn't meet) accessibility standards. It's created and maintained by the Information Technology Industry Council (ITI), and it's the industry-standard way to communicate accessibility compliance.

The completed VPAT is formally called an Accessibility Conformance Report (ACR). So you'll often hear these terms used interchangeably: you write a VPAT, and the result is an ACR. Think of the VPAT as the template and the ACR as your completed document.

The current edition is VPAT 2.5, released in 2021. It covers three major accessibility standards:

WCAG 2.x (Web Content Accessibility Guidelines): the global standard for web accessibility
Section 508 of the Rehabilitation Act: U.S. federal government accessibility requirements
EN 301 549: European Union accessibility standard for ICT (Information and Communication Technology)

Who Needs a VPAT?

The short answer: if you're selling to government, higher education, or large enterprises, you likely need a VPAT. More precisely:

Any software sold to the U.S. federal government: Section 508 compliance is required by law
State government agencies: most states have accessibility requirements equivalent to or stricter than Section 508
Universities and higher education institutions: typically required as part of ADA Title III compliance
Large enterprise purchases: procurement teams increasingly require VPATs to evaluate vendor compliance
Healthcare organizations: especially those receiving federal funding
Financial services: increasing regulatory requirements around digital accessibility

The common trigger: a government RFP (Request for Proposal) or a procurement team's due diligence checklist. A missing or outdated VPAT can kill a deal before your sales team even gets a chance to pitch the product.

Which VPAT Edition Do I Need?

VPAT 2.5 comes in four different editions. Each covers different standards and serves different markets. Choosing the right edition depends on where you're selling.

Edition	Standards Covered	Best For	Typical Use Case
WCAG Edition	WCAG 2.1 and 2.2 only	Web products, SaaS platforms, digital services	Web-only products, especially private sector or international sales
Section 508 Edition	Section 508 standards (incorporates WCAG 2.0 AA)	U.S. federal government and contractors	Software sold to federal agencies
EU EN 301 549 Edition	European standard (similar to WCAG 2.1 AA)	Products sold in the European Union	SaaS with European customers, EU government contracts
INT Edition (Combination)	WCAG, Section 508, and EN 301 549	Enterprise SaaS serving multiple markets	Products sold to U.S. government and EU customers simultaneously

Quick rule of thumb: If you're selling enterprise SaaS that touches U.S. government, federal contractors, or EU markets, use the INT Edition. If you're only targeting a single market, choose the appropriate edition. Most mature products end up using the INT Edition because it's future-proof. If you're already documenting compliance for three standards, adding more is minimal extra work.

What Are the VPAT Conformance Response Options?

For each accessibility criterion, you mark the product's status with one of five response options. Understanding the difference between these options is critical. Vague responses create legal risk.

Response	What It Means	When to Use It
Supports	The product fully meets the criterion without exceptions. Testing confirms compliance across the product scope.	When you've tested and verified the feature works accessibly
Partially Supports	The product meets the criterion in some areas but not all. You must specify exactly which parts and why in the remarks.	Only when there's a legitimate reason and you explain it clearly
Does Not Support	The product does not meet the criterion. This is a compliance failure.	When a feature is inaccessible and won't be fixed in the near term
Not Applicable	The feature described by this criterion doesn't exist in the product.	Example: If your product has no video, WCAG 1.2 (video captions) is N/A
Not Evaluated	You haven't tested this criterion yet, but you acknowledge it applies to your product.	Rarely appropriate in final VPATs, but acceptable when submitting early drafts

Critical rule: Never leave a criterion blank. If you don't know the status, mark it "Not Evaluated" rather than leaving it empty. Procurement teams view blank fields as red flags.

How Do You Write a VPAT Step by Step?

Writing a VPAT is a methodical process that requires both technical testing and clear communication. Here's the step-by-step approach used by successful accessibility teams:

Step 1: Get the Official Template

Download the VPAT 2.5 template directly from itic.org (the Information Technology Industry Council). Don't use older versions or modified templates. Procurement teams expect the official format.

Step 2: Define Your Product Scope

Start with a clear statement of what you're documenting. Example:

"This ACR covers the web application dashboard of Product X, version 2.5.0, accessed via modern browsers (Chrome, Firefox, Safari, Edge from 2022 onward). Mobile app and legacy browser support are documented separately."

Clear scope prevents misunderstandings about what you've actually tested.

Step 3: Test Each Criterion Systematically

This isn't just visual testing. You need to:

Test with keyboard navigation only (no mouse)
Test with at least one screen reader (NVDA or JAWS for Windows, VoiceOver for Mac/iOS)
Test color contrast using automated tools and manual verification
Check mobile accessibility and touch interactions
Review for focus management, ARIA implementations, and semantic HTML

Many teams use a combination of automated tools (Axe, Lighthouse, WAVE) and manual testing. Automated tools catch obvious issues; manual testing finds the subtle ones that break real user workflows.

Step 4: Write Honest, Specific Remarks

This is where VPATs separate good compliance teams from mediocre ones. For every "Partially Supports" response, write remarks that explain:

Which parts of the product support the criterion
Which parts don't, and why
Any workarounds users can employ
Timeline for fixes, if applicable

Bad example: "Partially Supports: some color contrast issues"
Good example: "Partially Supports. Primary text meets WCAG AA contrast requirements (4.5:1 minimum). Secondary UI elements in the reporting module use a custom gray that measures 3.8:1 against the white background, failing the 4.5:1 requirement. This will be remediated in Q2 2026. Users can enable high-contrast mode in settings as a temporary workaround."

Step 5: Document Workarounds and Accommodations

If a feature is inaccessible but users have a workaround, document it. Examples:

"Custom data visualization doesn't support keyboard navigation, but the underlying data is available as an accessible CSV export"
"This legacy module doesn't meet WCAG 2.1 AA, but we provide phone support for users needing assistance"
"Mobile map interface is not fully keyboard-accessible; desktop version is fully accessible and recommended for users with mobility disabilities"

Workarounds don't replace accessibility fixes, but they demonstrate commitment to accommodating users.

Step 6: Sign and Date Your ACR

The VPAT should include the name and title of the person responsible for its accuracy. This creates accountability. Include a date, and update it whenever you refresh the document.

Legal Risk Warning

Vague or inaccurate VPATs create legal exposure. If you claim "Supports" but testing reveals the feature fails for screen reader users, you've made a false claim in a legal document. When in doubt about a criterion, either mark it "Partially Supports" with detailed remarks, or conduct more rigorous testing before claiming full support.

How Do I Document Special Content Types in a VPAT?

PDFs

PDFs receive special attention in accessibility compliance because they're widely distributed but notoriously difficult to make accessible:

Must be tagged with proper heading hierarchy, list structure, and table structure
Must have reading order: the logical flow of content must make sense to screen reader users
Must pass color contrast: text on colored backgrounds must meet WCAG AA standards (4.5:1 for normal text, 3:1 for large text)
Images must have alt text: convey the purpose or content of every image
Forms must be properly structured: form fields must be labeled and properly associated

If your product includes PDFs, test them with a PDF accessibility tool (like PAC or Adobe Acrobat's accessibility checker) and a screen reader. Document the WCAG criteria specific to PDF accessibility in your VPAT.

Video Content

Video accessibility involves multiple layers:

Captions are required (WCAG 1.2.2 AA): must be accurate, include speaker identification, and cover all dialogue and relevant audio
Audio descriptions are required (WCAG 1.2.5 AA) for any visual information that isn't conveyed through dialogue, such as actions, expressions, scene changes
Transcripts recommended (WCAG 1.2.1 A): provide a complete text transcript of all video content
Video player must be accessible: keyboard controls, screen reader compatibility, caption toggle visibility

If your product has video, note which videos are captioned and which have audio descriptions. If some are missing, mark the criterion "Partially Supports" and commit to remediation.

Pre-Built Component Libraries

If your product uses third-party UI component libraries (like Material Design, Ant Design, React Bootstrap), document their accessibility status separately. Note:

Which library version you use
Which components are certified accessible
Any custom overrides to those components (which might introduce accessibility issues)
Whether you've tested those components in your actual implementation

Example VPAT remark: "Form inputs use Material-UI v5 components, which are WCAG 2.1 AA certified. Custom color themes apply a primary blue (#0066CC) on white backgrounds, which meets WCAG AA contrast requirements (4.75:1). All form error states include both icon and text labels, supporting users with color blindness."

Government-Specific Features

If your software serves government use cases, you may need to address:

Government ID verification flows: ensure identity confirmation doesn't rely on visual patterns alone
Digital signatures: must be keyboard and screen reader accessible
Multi-factor authentication: WCAG 2.2 has specific criteria around cognitive load and accessibility during authentication
Accessible PDF generation for official documents: certificates, licenses, notices must be tagged and structured

How Often Should a VPAT Be Updated?

Version Your ACRs

Maintain a document history. When you update your VPAT, include version numbers and dates. Example naming convention:

ProductX-ACR-v2.5.0-March2026.pdf
ProductX-ACR-v2.4.0-December2025.pdf (previous version)

This way, procurement teams know exactly which product version the VPAT covers, and you have a record of compliance history.

Review After Major Releases

Accessibility compliance isn't a one-time checklist. When you release significant new features:

Review any new criteria affected by the feature
Re-test existing functionality that might have regressed
Update your VPAT remarks
Update the version number and date

Address the Audit Reality

Government customers often require independent third-party accessibility audits. When an audit finds issues:

Fix the actual problem: update your code and re-test thoroughly
Update your VPAT: change the conformance status and document the fix
Provide evidence: save testing records that demonstrate the fix works
Establish a timeline: if fixes aren't immediate, provide a concrete remediation date

Watch the Deadline: 12-18 Months

A VPAT older than 12-18 months raises red flags in procurement. Updated your major version? Released significant new features? Your old VPAT is no longer credible. Create a refresh schedule:

After every major version release (e.g., 2.0, 3.0)
After significant feature launches
Annually, at minimum, if you're selling to government

Implement Automated Regression Testing

Track accessibility compliance over time with automated tests. Tools like Axe, Cypress with accessibility plugins, or Deque's axe-core can be integrated into your CI/CD pipeline. This won't catch everything, but it will alert you to obvious regressions before they reach customers.

Cross-Reference: VPAT Lookup Tool

Need help understanding a specific WCAG criterion for your VPAT? Use the VPAT Success Criteria Lookup Tool to find plain-English explanations and specific documentation guidance for any WCAG criterion.

External Resources

ITI VPAT 2.5 Templates and Guidance

Official VPAT 2.5 templates from the Information Technology Industry Council, including all four editions.

Section 508.gov

Official U.S. government resource for Section 508 compliance guidance, standards, and technical requirements.

WCAG 2.2 Quick Reference

W3C's customizable reference guide to WCAG 2.2 success criteria with detailed techniques and understanding documents.

Frequently Asked Questions

What is the difference between a VPAT and an ACR?

A VPAT (Voluntary Product Accessibility Template) is the blank standardized form published by the IT Industry Council (ITI). An ACR (Accessibility Conformance Report) is what you produce when you fill in that form for your specific product. Think of the VPAT as the template and the ACR as your completed document. The terms are used interchangeably in procurement conversations, but strictly speaking the ACR is the deliverable that gets submitted.

Is a VPAT legally required?

A VPAT is not mandated by statute, but it is effectively required for selling software to U.S. federal agencies and federally funded organizations. Section 508 of the Rehabilitation Act requires federal agencies to procure accessible technology, and agencies enforce this by requesting a completed VPAT/ACR during procurement. Without one, vendors are routinely disqualified before pricing is even discussed.

Which VPAT edition should I use: WCAG, 508, EU, or INT?

Use the Section 508 edition for U.S. federal government sales. Use the EU edition for European public sector contracts under EN 301 549. Use the INT edition if you need to cover all three standards (WCAG, Section 508, and EN 301 549) in a single document — which most enterprise SaaS vendors do. The WCAG-only edition is for purely international contexts not covered by either U.S. or EU law.

How long does it take to complete a VPAT?

A first-time VPAT for a mid-size web application typically takes 3–6 weeks when done thoroughly: 1–2 weeks of systematic testing against all relevant WCAG criteria, 1–2 weeks writing specific remarks and documenting workarounds, and at least one week for review and sign-off. Hiring an accessibility consultant can compress this to 2–3 weeks. Enterprise products with complex features, mobile apps, or multiple user roles can take 2–3 months.

What does "Partially Supports" mean on a VPAT?

"Partially Supports" is one of five allowed conformance responses in a VPAT. It means the product meets the accessibility criterion for some functionality or in some circumstances, but not all. The five responses are: Supports, Partially Supports, Does Not Support, Not Applicable, and Not Evaluated. Every "Partially Supports" entry must be accompanied by a specific remark explaining what works, what doesn't, and any available workarounds. Vague remarks are a legal risk.

How often should a VPAT be updated?

A VPAT should be reviewed after every major product release that changes UI, navigation, or interactive features. A VPAT older than 12–18 months raises red flags with government procurement teams and may be rejected. Many organizations review their VPAT quarterly and conduct a full accessibility re-test annually. Always version and date your ACRs so buyers can see how recently it was validated.

Can I write a VPAT myself or do I need a third-party consultant?

You can write a VPAT internally if your team has accessibility testing expertise and understands WCAG criteria. However, many organizations engage an independent accessibility consultant for the first VPAT because a third-party audit carries more credibility with government buyers and consultants typically surface issues that internal teams overlook. For large federal contracts, an independent audit is often expected. Once an initial compliant VPAT is in place, subsequent updates can usually be handled in-house.

Does a VPAT cover mobile apps as well as web products?

Yes. A VPAT can and should document mobile app accessibility separately from the web product. VPAT 2.5 includes criteria for software applications as well as web content. When documenting a product that spans web, iOS, and Android, define the scope clearly at the top of the ACR — typically you document each platform separately in the same document, noting any platform-specific conformance differences.