How to generate a VPAT report: step-by-step guide for product teams

If your product sells to government agencies, universities, or large enterprises, you will eventually be asked for a VPAT. The Voluntary Product Accessibility Template is a standardized document that describes how your product conforms to accessibility standards. Without one, your product is excluded from procurement processes that require Section 508 compliance documentation.

The current version is VPAT 2.4 Rev, published by the Information Technology Industry Council (ITI) in 2020. This guide covers what a VPAT contains, how to create one manually, and how to generate one automatically from structured test data.

What is a VPAT?

A VPAT (Voluntary Product Accessibility Template) is a document format created and maintained by ITI. It produces an Accessibility Conformance Report (ACR) when completed. The terms are related but distinct: the VPAT is the blank template, and the ACR is the filled-in result.

Federal agencies use ACRs during procurement to evaluate whether a product meets Section 508 requirements. The General Services Administration (GSA) maintains the Accessibility Requirements Tool (ART) that references VPAT-based documentation for all ICT purchases above the micro-purchase threshold (currently $10,000 per the Federal Acquisition Regulation).

Key fact: According to a 2023 survey by the International Association of Accessibility Professionals (IAAP), 78% of enterprise software buyers now request VPATs during procurement evaluation, up from 52% in 2019.

VPAT editions: which one do you need?

ITI publishes four editions of the VPAT 2.4 template. Each maps to different standards:

| Edition | Standards Covered | Use Case | |---------|-------------------|----------| | WCAG | WCAG 2.x Level A and AA | Products sold internationally without US/EU regulatory requirements | | Section 508 | Revised Section 508 standards + WCAG 2.0 Level A and AA | Products sold to US federal agencies | | EU | EN 301 549 + WCAG 2.1 Level A and AA | Products sold in EU public sector markets | | INT (International) | All three: Section 508 + EN 301 549 + WCAG 2.x | Products sold to both US and EU government buyers |

Recommendation: If you sell to both US and EU public sector customers, use the INT edition. It covers all three standards in one document and saves you from maintaining separate reports.

VPAT 2.4 structure: what each section covers

The VPAT template has a defined structure. Each section addresses a different standard or product category:

| Section | Title | What It Covers | |---------|-------|----------------| | Preamble | Product Information | Product name, version, date, contact info, description, evaluation methods | | Table 1 | WCAG 2.x Report | All WCAG Level A and AA success criteria (50 criteria for WCAG 2.1) | | Table 2 | Section 508 Chapter 3 | Functional performance criteria for users with disabilities | | Table 3 | Section 508 Chapter 4 | Hardware requirements (not applicable for most software products) | | Table 4 | Section 508 Chapter 5 | Software requirements and interoperability | | Table 5 | Section 508 Chapter 6 | Support documentation and services | | Table 6 | EN 301 549 Report | European accessibility standard requirements |

For a typical web application, Tables 1 and 2 contain the bulk of the work. Table 3 (hardware) is usually marked Not Applicable. Tables 4-6 apply depending on your edition choice.

The four conformance levels

Every WCAG criterion in the VPAT must be assigned one of four conformance levels:

| Conformance Level | Definition | When to Use | |-------------------|------------|-------------| | Supports | The product fully meets the criterion | All tested scenarios conform with no exceptions | | Partially Supports | Some functionality meets the criterion | Most features conform, but specific exceptions exist | | Does Not Support | The product does not meet the criterion | Known failures with no current workaround | | Not Applicable | The criterion does not apply to the product | The product has no content or functionality related to this criterion |

Each entry also requires a "Remarks and Explanations" column. This is where you describe how the product meets or fails the criterion, and what exceptions exist for partial support.

Common mistake: Marking criteria as "Not Applicable" when they actually apply. Auditors and procurement reviewers check N/A claims carefully. For example, if your product contains any images, WCAG 1.1.1 (Non-text Content) applies. Incorrectly marking it N/A undermines the credibility of the entire report.

Manual VPAT creation: the traditional process

Time and cost estimates

Manual VPAT creation by an accessibility consultant typically requires:

For organizations maintaining multiple products, costs compound quickly. A company with five products updating VPATs annually faces $15,000-$40,000 in ongoing documentation costs.

Step-by-step manual process

Step 1: Define the evaluation scope

Step 2: Conduct accessibility testing

Step 3: Map findings to VPAT criteria

Step 4: Write the remarks and explanations

Good remarks are specific. Compare these examples for WCAG 1.4.3 (Contrast - Minimum):

Weak remark: "The product supports this criterion."

Strong remark: "All text elements in the application meet the 4.5:1 contrast ratio for normal text and 3:1 for large text. Body text uses #333333 on #FFFFFF (12.63:1). Navigation links use #1A5276 on #FFFFFF (8.19:1). One exception: placeholder text in the search field uses #999999 on #FFFFFF (2.85:1), which is being remediated in release 4.2, scheduled for Q3 2026."

Step 5: Complete the preamble

Fill in the standard product information fields: product name, version, report date, contact information, evaluation methods used, and any general notes about the scope of the evaluation.

Step 6: Internal review and sign-off

Automated VPAT generation: the modern approach

Manual VPAT creation has two fundamental problems: it is expensive and it goes stale quickly. Every product release can invalidate conformance claims, requiring re-evaluation and updates.

Auditi solves both problems by generating VPAT documentation directly from structured test data.

How Auditi generates VPATs

Auditi uses a journey-based testing model where test results map directly to VPAT conformance statements:

What the automated output includes

| Component | Manual Process | Auditi Output | |-----------|---------------|---------------| | Conformance levels | Manually determined per criterion | Calculated from aggregated test results | | Remarks | Written from scratch each time | Generated from test evidence with specific pass/fail examples | | Test methodology | Described in general terms | Linked to actual journey steps and test data | | Update process | Re-evaluate everything manually | Re-run affected journeys, regenerate report | | Multi-standard mapping | Separate analysis per standard | WCAG, Section 508, and EN 301 549 mapped simultaneously | | Time to generate | 40-80 hours | Available after testing is complete (test data is the input) |

Auditi's multi-standard support

A single set of journey test results in Auditi can generate documentation for multiple standards simultaneously:

This matters because the same underlying test data maps to criteria across standards. Testing a form's error handling covers WCAG 3.3.1, FDA Part 11.10(f), and EN 301 549 clause 11.3.3.1 simultaneously.

Manual vs automated VPAT generation: a direct comparison

| Factor | Manual VPAT | Automated (Auditi) | |--------|-------------|-------------------| | Initial creation cost | $3,000-$8,000 | Included in subscription | | Time to first report | 2-4 weeks | Available after testing cycle | | Annual update cost | $2,000-$5,000 | Re-run tests, regenerate | | Multi-product cost | Multiplied per product | Same subscription | | Consistency | Varies by author | Standardized output | | Traceability | Depends on documentation | Every claim linked to test evidence | | Audit defensibility | Based on consultant reputation | Based on systematic test data |

Common VPAT mistakes that procurement reviewers catch

Based on reviewing hundreds of VPATs during procurement evaluations, these are the most frequent problems:

Tips for VPAT credibility

Procurement reviewers evaluate VPATs critically. These practices improve credibility:

Frequently asked questions

How long does it take to generate a VPAT report? Manual VPAT creation by a consultant takes 40-80 hours over 2-4 weeks. Automated generation through a platform like Auditi produces the report immediately after testing is complete. The testing itself is the time investment: plan for 1-3 weeks depending on product complexity and the number of user journeys tested.

Is a VPAT legally required? VPATs are not legally mandated by any statute. However, Section 508 of the Rehabilitation Act requires federal agencies to procure accessible ICT, and agencies use VPATs as the standard evidence format during procurement evaluation. Without a VPAT, your product may be excluded from consideration. State governments and universities often follow the same practice.

How often should a VPAT be updated? ITI recommends updating your VPAT with each major product release and at minimum once per year. Procurement reviewers treat VPATs older than 18 months with skepticism. If your product has a continuous deployment cycle, quarterly updates are ideal.

What is the difference between a VPAT and an ACR? The VPAT is the blank template published by ITI. An ACR (Accessibility Conformance Report) is what you get when you fill in the template with your product's conformance information. In practice, people use "VPAT" to refer to both the template and the completed report.

Can automated tools generate a complete VPAT? Automated scanning tools alone cannot generate a complete VPAT because they only detect 30-40% of WCAG issues. A complete VPAT requires manual testing data covering keyboard navigation, screen reader compatibility, and workflow-level accessibility. Auditi combines automated and manual test results into a single dataset that feeds VPAT generation.

Do I need separate VPATs for web and mobile versions of my product? If the web and mobile versions share the same underlying functionality and codebase, one VPAT with separate notes for each platform is acceptable. If the mobile app is a distinct product with different functionality, it should have its own VPAT. The ITI template supports documenting multiple platforms within a single report.

Getting started with VPAT generation

If you need a VPAT for procurement, start by identifying which edition applies to your market. US federal sales require the Section 508 or INT edition. EU public sector sales require the EU or INT edition.

Then choose your approach: hire a consultant for a one-time manual evaluation, or invest in structured testing that generates VPATs on demand.

Auditi offers journey-based accessibility testing with built-in VPAT 2.4 generation. Define your critical user flows, test against WCAG criteria, and generate procurement-ready documentation from your test data. Import results from axe, WAVE, Lighthouse, or pa11y to build on existing automated testing.

For organizations that need expert-led accessibility auditing with VPAT documentation, BetterQA provides comprehensive testing services with certified accessibility specialists. BetterQA's team holds ISO 9001, ISO 13485, and ISO 27001 certifications and has produced VPATs for government, healthcare, and financial services clients.

Sources and references:
  • ITI VPAT 2.4 Rev template: itic.org/policy/accessibility/vpat
  • Section 508 standards: section508.gov
  • EN 301 549 standard: ETSI EN 301 549 V3.2.1
  • GSA Accessibility Requirements Tool: buyaccessible.gov
  • IAAP 2023 procurement survey: accessibilityassociation.org
  • W3C WCAG 2.1 specification: w3.org/TR/WCAG21/
    • Built by BetterQA, a software testing company with ISO 9001, ISO 13485, and ISO 27001 certifications. 50+ engineers, Clutch-rated 4.9/5 from 63 verified reviews.

    © 2026 Auditi. A BetterQA project. | auditi.ro