What is a VPAT? Complete Guide for Government & Enterprise

If you’re managing a website, application, or software product and working with government agencies, educational institutions, or large enterprises, you’ve probably heard someone mention “VPAT.” Maybe you’ve seen it listed as a requirement in an RFP. Or perhaps a procurement officer asked if you had one available.

For many organizations, VPATs remain mysterious documents that seem important but poorly understood. This guide will demystify VPATs, explain when you need one, and help you understand what’s involved in creating one.

What is a VPAT?

A VPAT (Voluntary Product Accessibility Template) is a standardized document that describes how well a digital product conforms to accessibility standards. Think of it as a product specification sheet, but specifically for accessibility features.

The document format was created by the Information Technology Industry Council (ITI) to help vendors communicate their products’ accessibility features to potential buyers—particularly government agencies required to purchase accessible technology under Section 508 of the Rehabilitation Act.

What Information Does a VPAT Contain?

A complete VPAT includes:

Product Information: Basic details about the product being evaluated, including name, version number, release date, and description of what the product does.

Evaluation Methods: How the accessibility testing was conducted, including tools used, manual testing procedures, and who performed the evaluation.

Standards Coverage: VPATs evaluate conformance against multiple accessibility standards simultaneously:

WCAG 2.0, 2.1, or 2.2 (Web Content Accessibility Guidelines) at Levels A, AA, and AAA
Section 508 standards (the U.S. federal accessibility requirements)
EN 301 549 (European accessibility standard)

Detailed Conformance Results: For each relevant success criterion in the standards, the VPAT indicates:

Supports: The product fully meets this requirement
Partially Supports: The product meets this requirement in most but not all instances
Does Not Support: The product fails to meet this requirement
Not Applicable: This requirement doesn’t apply to this product

Supporting Documentation: Specific explanations for each rating, describing exactly how the product supports (or doesn’t support) each criterion, with details about any limitations or known issues.

Important Clarification: VPAT vs. ACR

Technically, the VPAT is the template document you fill out. Once completed with your product’s specific accessibility information, it becomes an ACR (Accessibility Conformance Report).

However, most people use “VPAT” to refer to both the template and the completed report. You’ll hear people say “we need a VPAT” when they really mean “we need an ACR based on the VPAT template.” Don’t worry—this informal usage is widely understood in the industry.

Why Do VPATs Exist?

VPATs solve a practical problem in government and enterprise procurement: How do you compare the accessibility features of different products when every vendor describes their accessibility differently?

The Procurement Challenge

Before VPATs, government agencies faced a confusing landscape when trying to purchase accessible technology:

Vendor A would claim “fully accessible” without specifics
Vendor B would list some accessible features but not others
Vendor C would describe accessibility in technical jargon
There was no standardized way to compare products

Section 508 of the Rehabilitation Act requires U.S. federal agencies to purchase accessible technology, but without standardized reporting, making informed decisions was nearly impossible.

The Solution: Standardized Reporting

The ITI created the VPAT template to provide:

Consistent Format: All vendors describe their accessibility using the same framework, making apples-to-apples comparison possible.

Comprehensive Coverage: The template addresses the full scope of accessibility requirements, not just the features vendors choose to highlight.

Transparent Communication: Rather than vague “accessible” claims, VPATs show exactly which standards are met and which aren’t.

Legal Documentation: VPATs create a clear record of what accessibility features were promised, protecting both buyers and sellers.

Beyond Government: Why VPATs Matter More Broadly

While Section 508 compliance initially drove VPAT adoption, these documents now serve broader purposes:

Enterprise Procurement: Many large private companies require VPATs even when not legally mandated, using them as a due diligence tool for accessibility evaluation.

Educational Institutions: Universities and school districts often require VPATs when purchasing educational technology, driven by their obligations under Section 504 and ADA Title II.

Risk Management: Organizations facing accessibility lawsuits use VPATs to demonstrate good faith efforts to purchase accessible technology.

Competitive Advantage: Having a well-documented VPAT can differentiate your product in competitive bidding situations.

Market Access: Without a VPAT, your product may be automatically disqualified from consideration by certain buyers, regardless of how accessible it actually is.

How to Perform Testing and Documentation for a VPAT

Creating an accurate VPAT requires systematic testing and honest documentation. Shortcuts here undermine the entire purpose of the document and can create significant legal and business risks.

Step 1: Determine Which Standards Apply

Not all parts of the VPAT template apply to every product:

Web Applications: Typically need WCAG 2.x conformance documentation (Levels A and AA are standard; Level AAA is rarely required).

Software Applications: Need both WCAG criteria (for web-based interfaces) and Section 508 software-specific requirements.

Hardware Products: Focus on Section 508 hardware requirements and physical accessibility features.

Documents and Content: Evaluate against document-specific accessibility requirements.

Most modern digital products require evaluation against WCAG 2.1 Level AA as the baseline, with Section 508 and EN 301 549 often mapping to the same requirements.

Step 2: Conduct Thorough Accessibility Testing

Quality VPATs rest on quality testing. This isn’t something you can rush through in an afternoon:

Automated Scanning: Use automated accessibility testing tools to identify technical violations like missing alt text, insufficient color contrast, or heading structure problems. However, automated tools only catch 25-30% of accessibility issues.

Manual Testing with Assistive Technology: Test your product with actual assistive technologies including:

Screen readers (JAWS, NVDA, VoiceOver)
Keyboard-only navigation
Voice control software
Screen magnification tools

User Flow Testing: Walk through critical user journeys to ensure all functionality is accessible, not just individual pages or screens.

Real User Testing: If possible, include users with disabilities in your testing process. They’ll identify barriers that technical testing might miss.

Documentation Review: Evaluate whether user documentation, help systems, and support materials are accessible.

Step 3: Document Results Honestly

The most critical part of VPAT creation is honest, detailed documentation:

Be Specific: Rather than just marking “Partially Supports,” explain exactly what works and what doesn’t. For example: “Supports: All form inputs include labels and error messages are announced to screen readers. Exception: The date picker widget is not fully keyboard accessible.”

Document Known Issues: If your product has accessibility problems, document them clearly. Buyers prefer honest disclosure over discovering undocumented issues later.

Provide Context: Explain your testing methodology and any limitations. “Tested with NVDA 2024.1 on Windows 11 using Chrome 120” is more useful than “tested with screen readers.”

Include Workarounds: If a feature isn’t fully accessible but has an accessible alternative, document both the limitation and the workaround.

Version Specificity: VPATs are version-specific. If you update your product, you need to update your VPAT to reflect new features or fixed issues.

Step 4: Have it Reviewed

Consider having your VPAT reviewed by:

Accessibility Specialists: Independent accessibility consultants can verify your testing was thorough and your documentation is accurate.

Legal Review: Ensure your VPAT language doesn’t create unintended legal commitments or contradict your terms of service.

User Testing: Share draft VPATs with actual users who have disabilities to verify your documentation matches their experience.

Common VPAT Mistakes to Avoid

Marking Everything “Supports”: No complex product fully supports every accessibility criterion. Claiming perfect accessibility damages credibility and creates legal risk if issues are discovered later.

Vague Explanations: “Mostly accessible” or “works with most screen readers” provides no useful information. Be specific about what works and what doesn’t.

Outdated Reports: A VPAT for version 2.0 of your product doesn’t cover version 3.0. Keep your VPATs current as your product evolves.

Testing Only with Automated Tools: Automated tools are valuable but insufficient. Manual testing with assistive technology is essential for accurate VPATs.

Ignoring Product Updates: If you release a new version, you need a new VPAT. Many organizations maintain VPATs for multiple supported versions.

Do You Need a VPAT?

Whether you need a VPAT depends on your market, your customers, and your business objectives.

You Definitely Need a VPAT If:

You Sell to Government Agencies: U.S. federal agencies and many state/local governments require VPATs for technology purchases. Without one, you can’t even be considered.

You’re Responding to RFPs: If your business involves responding to Requests for Proposals, especially from government or education, VPATs are often mandatory submission requirements.

You Serve Educational Institutions: Universities and K-12 districts increasingly require VPATs for any technology that will be used by students or staff.

Enterprise Buyers Request Them: Large corporations often require VPATs as part of their vendor due diligence process, even when not legally mandated.

You’re in a Highly Regulated Industry: Healthcare, finance, and other regulated sectors are increasingly scrutinizing accessibility compliance.

You Probably Should Create a VPAT If:

You’re Building SaaS Products: While not always required, having a VPAT ready demonstrates professionalism and accessibility commitment.

You Compete in Enterprise Markets: Even if not specifically required, a well-documented VPAT can differentiate your product from competitors.

You Want to Demonstrate Accessibility Leadership: A thorough VPAT shows you take accessibility seriously beyond marketing claims.

You’re Facing Accessibility Concerns: If customers have raised accessibility questions, a VPAT provides transparent documentation of your product’s status.

You Plan to Pursue Government or Education Contracts: Even if not currently in these markets, having a VPAT ready positions you for future opportunities.

You May Not Need a VPAT If:

You Serve Only Small Business or Consumer Markets: If your customers are small businesses or individual consumers not subject to accessibility requirements, VPATs may not be necessary.

Your Product is Simple with Clear Accessibility: If you have a straightforward website or application with obvious accessibility features, informal documentation might suffice.

You’re in Early-Stage Development: Focus first on building accessibility into your product. Document it with a VPAT when you’re closer to market or when prospects request one.

The Cost-Benefit Question

Creating a thorough VPAT requires significant investment:

Professional accessibility testing: $3,000-15,000+ depending on product complexity
Time to document results thoroughly
Periodic updates as your product evolves
Potential remediation work for identified issues

However, the cost of NOT having a VPAT can be higher:

Automatic disqualification from lucrative contracts
Lost sales to competitors who provide VPATs
Time wasted pursuing opportunities you can’t actually win
Legal risk from undocumented accessibility claims

For most B2B products, particularly those targeting enterprise, government, or education markets, creating a VPAT is worthwhile even before it’s explicitly required.

VPAT Best Practices

Maintain Your VPAT Like Product Documentation

Treat your VPAT as living documentation that evolves with your product:

Update with Major Releases: When you ship significant product changes, update your VPAT to reflect new features or fixed issues.

Track Improvement Over Time: Document your accessibility progress across versions, showing commitment to continuous improvement.

Make it Accessible: Ensure your VPAT document itself is accessible (properly structured PDF or HTML version).

Make it Easy to Find: Post your VPAT on your website where prospects can easily locate it—many organizations have a dedicated accessibility page.

Be Transparent About Limitations

The best VPATs honestly document both strengths and weaknesses:

Known Issues: Clearly describe accessibility problems you’re aware of, along with timelines for fixes when possible.

Workarounds: Document accessible alternatives when primary features have limitations.

Roadmap Items: If accessibility improvements are planned, mention them (without making firm commitments that might become contractual obligations).

Honest VPATs build trust. Customers prefer knowing about accessibility limitations upfront rather than discovering them after purchase.

Consider Your Support Capabilities

Creating a VPAT implies you can support accessibility-related questions and issues:

Customer Support Training: Ensure your support team understands accessibility and can help users with disabilities.

Assistive Technology Testing: Maintain the ability to reproduce and address issues reported by users of assistive technology.

Documentation: Provide accessible documentation that explains how to use your product’s accessibility features.

What VPATs Don’t Do

It’s important to understand what VPATs are and aren’t:

VPATs Don’t Guarantee Legal Compliance: A VPAT is documentation, not certification. Having a VPAT doesn’t prevent accessibility lawsuits if your product genuinely isn’t accessible.

VPATs Don’t Replace Accessibility Work: You can’t create a good VPAT for an inaccessible product. The VPAT documents your accessibility work; it doesn’t substitute for it.

VPATs Aren’t Certifications: Unlike WCAG badges or certification programs, VPATs are self-reported documentation. Their credibility depends on the thoroughness and honesty of the creator.

VPATs Don’t Prove Accessibility: A VPAT claiming “Supports” across the board doesn’t prove a product is truly accessible. Users’ actual experience matters more than documentation.

Getting Started with Your First VPAT

If you’ve determined you need a VPAT, here’s how to begin:

1. Download the Current Template: Get the latest VPAT template from the ITI website. The template is updated periodically to reflect new accessibility standards.

2. Assess Your Product’s Accessibility: Before documenting anything, understand your product’s actual accessibility state through testing.

3. Decide: DIY or Professional Help: For simple products, you might complete a VPAT internally. For complex products or high-stakes situations, professional accessibility consulting is worthwhile.

4. Gather Your Testing Data: Collect results from automated scans, manual testing, assistive technology testing, and user feedback.

5. Document Systematically: Work through the VPAT template methodically, providing detailed explanations for each rating.

6. Review and Validate: Have someone else review your VPAT for accuracy and completeness.

7. Publish and Maintain: Make your VPAT publicly available and establish a process for keeping it current.

The Bottom Line

VPATs exist to solve a practical problem: standardized documentation of accessibility features for procurement decisions. They’re not optional for government contractors, increasingly expected in enterprise sales, and valuable for any organization serious about accessibility.

Creating an honest, thorough VPAT requires investment in both accessibility testing and documentation. But for most B2B products, especially those targeting enterprise, government, or education markets, this investment pays off through improved market access, competitive differentiation, and demonstrated commitment to accessibility.

The question isn’t just “Do I need a VPAT?” but “Can I afford to compete in enterprise and government markets without one?” For most organizations, the answer is no.

If you’re evaluating whether your website needs accessibility testing before you can complete a VPAT, schedule a free accessibility scan to understand your current conformance status. Or if you have questions about VPATs or accessibility compliance, reach out to our team—we’re here to help.