Digital accessibility is now a key priority for organizations of all sizes. From government agencies to startups, businesses are expected to ensure their digital products are usable by everyone, including people with disabilities. That’s where the VPAT comes in.
A VPAT gives me a structured way to see how the product performs against requirements such as WCAG, Section 508, and EN 301 549.
It is commonly used during procurement and accessibility reviews because it gives buyers a clearer picture of what a product supports and where gaps may still exist. In this article, I’ll break down what a VPAT includes, when you need one, and how to approach it accurately.
Understanding VPAT
Accessibility can directly affect whether a product is considered during procurement. In the US federal market, agencies must evaluate ICT against Section 508 requirements.
Vendors are commonly asked for an Accessibility Conformance Report (ACR), which is typically created using a VPAT. Federal guidance notes that a purchase may not proceed without an ACR unless an applicable exception exists.
The audience affected is also substantial. The World Health Organization estimates that 1.3 billion people, or about 16% of the global population, experience significant disability. That makes accessibility a product and market consideration rather than a requirement that only applies to a small group of users.
- Qualify for accessibility-sensitive procurement. A detailed ACR gives procurement teams evidence they can evaluate instead of relying on a vendor’s accessibility claims.
- Reduce delays during enterprise reviews. Buyers can use the report to identify which accessibility criteria a product supports and where limitations remain. This gives them useful information earlier in the evaluation process.
- Expose accessibility gaps before they become sales blockers. Completing a VPAT requires teams to document areas that partially support or do not support applicable criteria. Those findings can guide remediation before a customer raises them during procurement.
- Give buyers a more credible basis for comparison. A VPAT is not a certification and it does not produce a simple pass or fail result. Its value comes from documenting conformance criterion by criterion so buyers can assess whether the product meets their requirements.
What Does a VPAT Include?
A VPAT typically includes the following sections to document how a product was evaluated and where it stands against the selected accessibility requirements.
- Product Information: Details about the product or service being evaluated, including its name, version, report date, and a short description. This helps buyers confirm that the accessibility findings apply to the exact product release they are reviewing. It may also include company details and a contact for accessibility-related questions.
- Applicable Standards: Lists the accessibility standards used during the evaluation. Depending on the VPAT edition, this may include WCAG, Revised Section 508, EN 301 549, or a combination of these standards. This section gives buyers context on the requirements against which the product was assessed.
- Evaluation Criteria and Results: Breaks the selected standard into individual accessibility requirements and records the product’s conformance against each one. Common conformance levels include Supports, Partially Supports, Does Not Support, and Not Applicable. This level of detail helps buyers identify specific strengths and accessibility gaps rather than relying on a broad compliance claim.
- Test Methods and Notes: Explains how the accessibility assessment was carried out. This may include manual testing, automated accessibility scans, assistive technology testing, or a combination of methods. Notes can also clarify the scope of testing, known limitations, and the reasoning behind individual conformance results.
- Summary Table: Provides a consolidated view of the product’s conformance across the applicable accessibility requirements. Depending on the VPAT edition, the document may contain several tables covering areas such as WCAG criteria, software, hardware, documentation, or functional performance. These tables make it easier for procurement and accessibility teams to review the findings without treating accessibility as a single pass-or-fail result.
How to Create a VPAT
A useful VPAT starts with evidence. You need current test results, the right accessibility standard, and clear explanations for every conformance claim. Treating it as a form-filling exercise usually leads to vague or unsupported entries that procurement teams cannot rely on.
Read More: What is Accessibility Testing?
A practical process looks like this:
1. Gather Relevant Product and Testing Information
Start with the exact product release you are assessing. The VPAT should reflect the product that customers can currently evaluate or purchase, not an older build with different features or accessibility behavior.
Collect the following before you begin.
- Product details such as product name, version, supported platforms, and the scope of the assessment.
- Accessibility test results from recent evaluations. Include the issues found and where they occur.
- Testing methods such as automated scans, manual checks, keyboard testing, and assistive technology testing.
- Known accessibility gaps that remain unresolved at the time of assessment.
Keeping this evidence together makes it easier to support each claim later in the document.
2. Understand the Required Sections and Terminology
Read through the VPAT template before entering results. Different editions cover different standards, so the template should match the market or procurement requirement you are working toward.
Pay particular attention to the conformance terms used in the template.
- Support means the product meets the criterion.
- Partially Supports means some functionality does not meet the criterion.
- Does Not Support means the product does not meet the criterion.
- Not Applicable means the requirement does not apply to the product.
These terms should reflect your test evidence. Avoid replacing them with your own scoring system or broad statements such as “mostly accessible.”
3. Check Your Product Against Accessibility Standards
Next, test the product against the requirements covered by the VPAT edition you selected.
Common standards include:
- WCAG for web and digital accessibility requirements
- Section 508 for ICT used by US federal agencies
- EN 301 549 for ICT accessibility requirements in Europe
Automated testing can identify issues such as missing labels, insufficient contrast, and certain markup problems. Manual testing is still needed for areas such as keyboard operation, logical reading order, screen reader behavior, and interactions that depend on context.
Record the results criterion by criterion. This gives you the evidence needed for the conformance tables rather than relying on assumptions about the product as a whole.
4. Complete the Conformance Tables Carefully
The conformance tables are where buyers will spend much of their time. Each entry should match what was observed during testing.
Use Supports only when the relevant functionality meets the requirement within the scope you tested. If an issue affects part of the experience, record Partially Supports and explain where the limitation appears.
Avoid turning the table into a marketing document. A realistic assessment is more useful than an ACR where nearly every criterion is marked as supported without supporting detail.
5. Explain Each Conformance Result
The remarks column gives buyers context that a conformance label cannot provide on its own.
For example, if keyboard navigation works across most of a form but the date picker cannot be operated without a mouse, document that limitation and mark the criterion accordingly.
For partial or unsupported criteria, explain:
- Which part of the product is affected
- What behavior was observed
- Which environments or workflows are affected
- Whether a workaround exists
Specific notes make the report easier to review and reduce follow-up questions during procurement.
6. Plan Remediation for Identified Issues
Testing for a VPAT will often uncover issues that need product work. Move those findings into the same defect or product management process used for other quality problems.
Prioritize issues based on their impact on task completion. Keyboard traps, inaccessible form controls, missing accessible names, and unusable screen reader interactions can prevent users from completing basic workflows.
Assign owners and track remediation separately from the VPAT itself. If an issue is still present when the report is published, document the current behavior rather than describing a future fix as though it already exists.
7. Re-test and Update the VPAT
A VPAT can become inaccurate when the product changes. New components, redesigned workflows, updated frameworks, or major releases can introduce accessibility issues that were not present during the previous assessment.
Re-test after meaningful product changes and update the report when the findings no longer represent the current version.
Pay particular attention to:
- Major UI redesigns
- New user workflows
- Changes to navigation or forms
- New third-party components
- Accessibility fixes that affect previous conformance results
Keeping the report tied to a specific product version makes it much more useful to buyers and prevents old accessibility claims from carrying forward after the product has changed.
Read More: Regression Testing: A Detailed Guide
Who Should Create or Fill Out a VPAT?
A VPAT is best completed by a cross-functional team with access to current accessibility test results and a clear understanding of the product.
Typical contributors include:
- Product Managers for product scope and feature context
- Developers for implementation details and known limitations
- QA Engineers for accessibility test results and validation
- Designers for interaction and visual accessibility details
- Compliance or Legal Teams for procurement and regulatory review
- Accessibility Specialists for standards interpretation and assistive technology testing
One person should own the final document so the findings stay consistent and traceable to test evidence.
Mistakes to Avoid
Even well-intentioned teams can fall into common pitfalls when creating a VPAT. Here are some mistakes that can reduce the document’s effectiveness, or worse, lead to failed procurement opportunities or legal risk:
- Copy-pasting from other VPATs without real testing: No two products are alike. Reusing someone else’s VPAT template or content can misrepresent your product’s compliance level and lead to inaccuracies that erode trust.
- Overstating compliance (e.g., marking everything as “Supports”): It might seem tempting to present your product as fully compliant. But unless you’ve done extensive testing to verify every WCAG criterion, avoid blanket “Supports” responses.
- Inconsistent Information: Your summary table, evaluation notes, and remarks must all align. For example, if you mark “Partially Supports” for a criterion, don’t write in the summary that all success criteria are met. Procurement teams scrutinize these inconsistencies.
- Not involving accessibility experts in the review: VPATs should not be authored in isolation. Involving accessibility experts ensures the report is grounded in proper testing, uses accurate terminology, and reflects real user experience, especially for assistive technologies.
- Ignoring updates after product changes or feature rollout: Your product is always evolving; your VPAT should, too. An outdated VPAT that doesn’t reflect new features or interface changes can be misleading and risk non-compliance.
How Accessibility Testing Supports Your VPAT
A VPAT is only as strong as the testing behind it. Without robust accessibility evaluations, the document becomes guesswork.
- Informs Accurate Reporting: Testing reveals how your product performs against WCAG or EN 301 549 criteria, ensuring your VPAT reflects real, tested results.
- Identifies Gaps and Fixes: By uncovering accessibility issues early, testing helps you document partial or non-conformance accurately and plan remediation.
- Strengthens Credibility: A VPAT backed by thorough, documented testing builds trust with procurement teams and users who rely on accessibility features.
- Supports Continuous Improvement: Ongoing testing ensures your VPAT stays aligned with your evolving product, helping you maintain compliance over time.
Conclusion
A VPAT gives buyers a structured view of how a product performs against accessibility requirements. Its value depends on the quality of the testing behind it, the accuracy of the conformance claims, and how clearly limitations are documented.
Keeping the report current also matters. As the product changes, accessibility findings can change with it. Regular testing and timely updates make the VPAT more useful during procurement and give internal teams a clearer picture of what still needs attention.
