VPAT Testing Workflow
Introduction
A VPAT (Voluntary Product Accessibility Template) is a standardized document that records how a product conforms to accessibility standards like WCAG, Section 508, or EN 301 549. When filled out, it becomes an Accessibility Conformance Report (ACR).
Organizations often require VPATs during procurement to verify that products meet accessibility requirements. If you’re building websites or web applications for government agencies, higher education, or large enterprises, you’ll likely need to produce VPATs.
AAArdvark streamlines VPAT testing by mapping all issues to specific WCAG Success Criteria. This lets you systematically work through each criterion and document your conformance level. This guide walks you through using your AAArdvark site data to complete a VPAT for your own product.
What Goes Into a VPAT
A VPAT documents conformance for each WCAG Success Criterion using these terms:
- Supports: The product fully meets the criterion
- Partially Supports: The product meets the criterion in some cases but not others
- Does Not Support: The product does not meet the criterion
- Not Applicable: The criterion does not apply to this product
- Not Evaluated: The criterion has not been evaluated. Per ITI guidance, this term may only be used for WCAG Level AAA criteria.
For each criterion, you’ll also provide remarks explaining how the product meets (or fails to meet) the requirement.
Choosing Your VPAT Edition and Standard
The template is published by the Information Technology Industry Council (ITI). Download the current templates from their site and pick the edition that matches who’s requesting the VPAT.
VPAT Editions
The template comes in four editions:
- VPAT 2.5 WCAG: for international use or when WCAG is the only standard required
- VPAT 2.5 Rev 508: for U.S. federal government procurement (includes Section 508 + WCAG)
- VPAT 2.5 EU: for European procurement (includes EN 301 549 + WCAG)
- VPAT 2.5 INT: combines all three above
Note: The 508, EU, and INT editions include additional reporting sections beyond WCAG (functional performance, software, documentation, and support). For web-only products, most of these chapters won’t apply, but you’ll need to address them in the report.
If you don’t know which edition the requester wants, ask. When in doubt, the INT edition is the most comprehensive.
WCAG Version and Level
VPATs are typically requested at WCAG 2.1 Level AA or WCAG 2.2 Level AA. Both are in active use across U.S. and EU procurement, so confirm which version the requester wants before testing, since the list of Success Criteria differs between versions.
When you filter by Success Criteria in AAArdvark, you can scope your review to just the criteria included in your target version and level.
Setting Up for VPAT Testing
Before you begin, make sure your site is fully set up in AAArdvark:
- Add all relevant pages – A VPAT should reflect your entire product, so include all page types and templates. See Adding Pages for details. For larger sites, focus on representative pages: one of each template type, your most-trafficked pages, and any pages central to core user journeys (signup, checkout, search, account management, etc.).
- Run an automated scan – Start with a full-site automated scan to catch code-level issues. This gives you a baseline before manual testing.
- Mark false positives – False positives will skew your conformance assessment, so review and dismiss them before you start.
As you set up, note the information you’ll need for the VPAT itself: product name and version, the date range of testing, and the URL(s) in scope. The VPAT template asks for all of this on the first page.
Important: A VPAT documents your product’s current state of conformance. If you fix issues before or during VPAT testing, you’re producing a remediation report instead, which is a different deliverable with a different purpose. We recommend you decide upfront which one you’re creating.
Working Through Success Criteria
The key to efficient VPAT testing is using the Success Criteria filter in the Issues tab to work through WCAG requirements systematically.
Filtering by Success Criteria
- Navigate to the Issues tab for your site
- Click the Success Criteria dropdown
- Select a specific criterion (e.g., “1.1.1 Non-text Content”)

This shows you all issues related to that criterion, making it easy to assess conformance.
Documenting Conformance
For each Success Criterion, review the filtered issues and determine the conformance level.
Both automated scanning and manual testing must be completed before you determine a conformance level for any criterion.
| What You Find | Conformance Level |
|---|---|
| No issues found, after both automated scanning and manual testing | Supports |
| Some functionality meets the criterion, but not all | Partially Supports |
| The criterion’s requirements are not met | Does Not Support |
| The criterion does not apply to this product (e.g., no video content for 1.2.x criteria) | Not Applicable |
| Level AAA criterion you chose not to evaluate | Not Evaluated |
Record your findings in the VPAT template along with specific remarks. For example:
1.1.1 Non-text Content – Partially Supports
All informational images have alt text. Two decorative images on the homepage are missing null alt attributes.
Manual Testing for VPAT Criteria
You cannot create a VPAT from automated testing alone. Most WCAG Success Criteria require manual review, and many can only be evaluated by a human tester. Plan to manually test every applicable Success Criterion at your target conformance level, using the automated scan results as a starting point rather than a complete picture.
Use Visual Mode to record manual issues as you test each criterion. AAArdvark includes a library of hundreds of predefined issues with the Success Criterion already assigned, so most manual findings are mapped for you. You can edit the SC if you disagree. For custom issues, assign the Success Criterion yourself when filing. Either way, your manual issues will appear when you filter by Success Criterion later.
Testing Workflow
For criteria that need manual verification:
- Filter the Issues list by the Success Criterion
- Review any existing automated issues
- Perform manual testing on representative pages
- Record any new issues found using Visual Mode
- Document the conformance level based on your complete findings
Generating Reports for VPAT Completion
Once testing is complete, use AAArdvark’s reporting feature to gather the information you need for your VPAT.
From the Site Dashboard, click the PDF or Excel button to start generating a report. AAArdvark builds the report in the background, which usually takes 10 to 15 seconds (longer for very large sites with many issues).
When it’s ready, the button becomes a download link. Click the button to save the file.

Which Report Format to Use
- PDF report – A visual summary of scan results, issues by severity, and top problematic pages. Good for sharing with stakeholders.
- xlsx report – Detailed, sortable data including issue IDs, WCAG Success Criteria, severity, affected pages, and status. This is the most useful format for filling in your VPAT since you can filter and sort by Success Criteria.
The xlsx report includes the specific issues and page URLs you need to reference in your VPAT remarks.