VPAT Documentation Masterclass
The VPAT (Voluntary Product Accessibility Template) has become essential for organizations that need to show how accessible their digital products are. As we move through 2025, the requirements for creating accurate VPAT documentation have evolved, with updated standards and more detailed reporting expectations. This article breaks down everything you need to know about creating effective VPAT documentation that meets current requirements for Section 508, EU standards, and international guidelines.
The Evolution of VPAT Templates in 2025
VPAT documentation has changed significantly over the years; with the current version 2.4 offering multiple formats to address various accessibility standards. Understanding these changes is key to creating documentation that properly shows how your digital products meet accessibility requirements.
Understanding VPAT 2.4 Format Requirements
VPAT 2.4, released in February 2020, continues to be the standard template in 2025 for creating Accessibility Conformance Reports (ACRs). The template includes structured sections that help organizations thoroughly document their product’s accessibility features.
The basic structure of a VPAT 2.4 document includes:
- Product Information Section: This part contains details about the product being evaluated, including name, version & description.
- Evaluation Methods Used: This section documents the testing approaches used to check accessibility features.
- Applicable Standards & Guidelines: Lists which accessibility standards were used for testing (WCAG 2.1, Section 508, etc.).
- Conformance Tables: These tables form the core of the VPAT, with each row representing a specific accessibility requirement. For each requirement, you must indicate one of four conformance levels:
- Supports (S): The product fully meets the accessibility requirement with no known issues
- Partially Supports (PS): Some aspects of the product meet the requirement, others don’t
- Does Not Support (DNS): The product doesn’t meet the requirementNot Applicable (NA): The requirement doesn’t apply to the product
- Not Evaluated (NE): The requirement hasn’t been checked yet
When filling out each section of the VPAT, clear explanations are needed and especially for items marked as “Partially Supports” or “Does Not Support.” For example, if a web application partially supports keyboard navigation, you must explain which features work with keyboard and which don’t.
Key Differences Between VPAT Editions (INT, EU, 508)
One of the most confusing aspects of VPAT documentation is choosing the right edition for your needs. VPAT 2.4 comes in four different editions, each designed for specific markets and compliance requirements:
1. VPAT Section 508 Edition
This edition focuses on U.S. federal government requirements. It’s designed for:
- Products being sold to U.S. federal agencies
- Software and digital services that need to comply with Section 508 of the Rehabilitation Act
- Products that need to meet WCAG 2.0 Level A and AA requirements
The Section 508 edition covers specific requirements like:
- Software applications and operating systems
- Web-based information and applications
- Telecommunications products
- Video and multimedia products
- Self-contained products
2. VPAT EU Edition
The EU edition addresses European accessibility requirements based on EN 301 549 standards. This edition is best for:
- Products sold in European markets
- Digital services that need to comply with European accessibility laws
- Organizations with European customers or users
Beyond WCAG requirements the EU edition also covers:
3. VPAT WCAG Edition
This edition focuses specifically on the Web Content Accessibility Guidelines and is ideal for:
- Web-based products and services
- Mobile applications
- Organizations selling primarily to private businesses in markets where WCAG is the standard
4. VPAT International (INT) Edition
The INT edition is the most complete template, combining all three standards (Section 508, EN 301 549, and WCAG) into one document. This edition is best for:
- Multinational companies selling products globally
- Organizations that want to demonstrate compliance with all major accessibility standards
- Products that will be used in both public and private sectors across different countries
The choice of VPAT edition affects which standards you’ll need to test against, the level of detail required, and how you’ll need to format your documentation. For companies operating globally, the INT edition often makes the most sense as it covers all bases, though it requires more testing and documentation work.
Creating Complete VPAT Documentation
Producing accurate, detailed VPAT documentation requires careful testing, clear documentation, and attention to detail. Here’s how to create VPAT documentation that meets 2025 requirements.
Testing Methodologies for Accurate Reporting
Good VPAT documentation starts with thorough testing. Here are the key testing approaches that should be used to create accurate reports:
1. Automated Testing
Automated accessibility testing tools can scan your product for common issues like:
- Missing alt text for images
- Color contrast problems
- Keyboard navigation issues
- Missing form labels
While automated tools are helpful, they typically only catch about 30% of accessibility issues, so they should be just one part of your testing approach.
2. Manual Expert Testing
Manual testing by accessibility experts is essential for finding issues that automated tools miss. This includes:
- Testing with actual screen readers (like JAWS, NVDA, or VoiceOver)
- Keyboard-only navigation testing
- Testing with screen magnifiers
- Checking for logical reading order and structure
Manual testing should follow specific test cases that cover all product features and user flows.
3. Assistive Technology Testing
Testing with actual assistive technologies gives you the most accurate picture of how your product works for people with disabilities. This should include:
- Screen reader testing with different browsers
- Testing with alternative input devices (switches, voice control)
- Testing with screen magnification
- Testing with speech recognition software
When documenting your testing methodology in the VPAT, be specific about which tools you used, which version of each tool, and how testing was conducted.
Documenting Conformance Levels Effectively
The heart of any VPAT is the conformance level tables, where you document how well your product meets each accessibility requirement. Here’s how to fill these sections effectively:
1. Be Specific About “Supports” Claims
When marking a requirement as “Supports,” include specific examples that demonstrate compliance. For example, instead of just writing “Supports,” say:
“Supports. All images in the application include descriptive alt text. All buttons have proper labels that communicate their purpose to screen readers. Tables include proper headers and row/column associations.”
2. Be Honest About “Partially Supports”
When using “Partially Supports,” clearly explain which aspects meet the requirement and which don’t. For example:
“Partially Supports. Most of the application’s form fields have proper labels but the advanced search form fields lack visible labels. The calendar widget can be navigated with a keyboard, but date selection requires a mouse.”
3. Provide Details for “Does Not Support”
When marking items as “Does Not Support,” explain the current limitations and any planned fixes. For example:
“Does Not Support. The data visualization charts rely on color alone to communicate information and cannot be interpreted by users with color blindness. A fix is planned for Q3 2025 to add pattern differentiation and text alternatives.”
4. Justify “Not Applicable” Claims
When marking requirements as “Not Applicable,” always explain why they don’t apply to your product. For example:
“Not Applicable. The product does not contain any pre-recorded audio content, so audio description requirements do not apply.”
5. Use Clear Language for “Not Evaluated”
When certain features haven’t been tested yet, be transparent about it:
“Not Evaluated. The mobile version of the application has not yet been evaluated for keyboard accessibility. This evaluation is scheduled for Q2 2025.”
Functional Performance Statements Best Practices
Functional Performance Statements describe how people with different abilities can use your product. These statements are especially important in Section 508 compliance reporting. Here are best practices for creating effective statements:
1. Address Each User Group Separately
Create separate statements for users with:
- Visual disabilities
- Hearing disabilities
- Motor limitations
- Cognitive limitations
2. Describe Actual User Experience
Instead of just listing technical features, explain how someone actually uses the product. For example:
“Users who are blind can navigate the entire checkout process using a screen reader. All form fields have proper labels, error messages are announced by screen readers, and order confirmation details are fully accessible.”
3. Include Specific Examples
Provide concrete examples that show how the product works with assistive technologies:
“Users with limited mobility can complete all tasks using keyboard navigation alone. All interactive elements are reachable via tab key, and keyboard shortcuts are provided for common actions.”
4. Link Features to Standards
Connect functional statements to specific requirements in the standards:
“The product supports users who are deaf or hard of hearing by providing captions for all video content (WCAG 1.2.2) and visual alternatives for all audio alerts (WCAG 1.3.3).”
Common VPAT Documentation Pitfalls to Avoid
Even well-intentioned organizations make mistakes when creating VPAT documentation. Avoiding these common pitfalls will help your VPAT stand up to scrutiny.
Over-claiming Compliance Without Evidence
One of the biggest mistakes in VPAT documentation is claiming higher levels of compliance than can be supported by evidence. Here’s what to watch out for:
1. Beware of Perfect Compliance Claims
It’s extremely rare for complex digital products to have perfect accessibility compliance. If your VPAT shows 100% “Supports” across all criteria, this is often a red flag for procurement teams. They may question whether proper testing was done.
For example, an emergency response software claiming perfect keyboard accessibility across all features would raise suspicion if complex mapping features are included, which often have accessibility challenges.
2. Avoid Generic Responses
Generic statements like “Product supports keyboard navigation” without specifics about which features were tested and how they work are problematic. Instead, describe specific workflows that were tested:
“The dispatch queue interface supports keyboard navigation. Users can tab through all action buttons, use arrow keys to navigate between incidents, and use keyboard shortcuts to assign priority levels.”
3. Don’t Hide Behind Technical Language
Using overly technical language to obscure accessibility issues is another common problem. For example:
Poor example: “The UI components utilize ARIA when DOM semantics are insufficient for expressing UI behaviors.”
Better example: “Custom dropdown menus include ARIA labels and expanded/collapsed states so screen reader users can understand their purpose and current state.”
4. Back Claims with Testing Evidence
For each “Supports” claim, you should have testing evidence that backs it up. This doesn’t all need to appear in the VPAT, but you should have it available if asked. Include details like:
- Which screen readers were used for testing
- Browser and assistive technology combinations tested
- Who performed the testing (in-house team, third party experts, etc.)
Using Automated Tools for Quick Insights (Accessibility-Test.org Scanner)
Automated testing tools provide a fast way to identify many common accessibility issues. They can quickly scan your website and point out problems that might be difficult for people with disabilities to overcome.
Visit Our Tools Comparison Page!
Inadequate Remediation Planning in VPATs
Another common pitfall is poor handling of accessibility issues that have been identified. Here’s how to improve remediation documentation:
1. Include Specific Timelines
Rather than vague promises about future fixes, include specific timeframes:
Poor example: “Will be fixed in a future release.”
Better example: “The color contrast issues in the dashboard will be resolved in version 5.4, scheduled for release in August 2025.”
2. Prioritize Remediations
Not all accessibility issues have equal impact. Your remediation plan should prioritize fixes based on:
- How many users are affected
- How severely the issue impacts core functionality
- Technical complexity of the fix
For example: “High priority: Form submission errors that are not announced to screen readers will be fixed in the next sprint (May 2025). Medium priority: Improved keyboard navigation for the data visualization tools is scheduled for Q3 2025.”
3. Document Interim Solutions
While working on permanent fixes, document any workarounds users can employ:
“While developing native keyboard support for the mapping feature, users can access an alternative text-based view of location data by selecting the ‘List View’ option, which is fully keyboard accessible and screen reader compatible.”
4. Update VPAT Documentation Regularly
Many organizations make the mistake of treating VPAT documentation as a one-time project. In reality, VPATs should be updated:
- At least annually
- After major product updates
- When significant accessibility improvements are made
VPATs older than two years are generally considered outdated and unreliable by procurement teams.
Run a FREE scan to check compliance and get recommendations to reduce risks of lawsuits
Creating solid VPAT documentation requires a mix of technical knowledge, clear communication, and honest assessment. By following the guidelines presented in this article you can create VPAT documentation that accurately represents your product’s accessibility features while also serving as a roadmap for future improvements.
Remember that a VPAT is more than just a compliance document—it’s a communication tool that helps organizations make informed decisions about the accessibility of your products. By investing time in creating detailed, accurate VPAT documentation, you demonstrate your commitment to digital accessibility and inclusion.
Run a FREE scan to check compliance and get recommendations to reduce risks of lawsuits.