VPAT & ACR Documentation:
The Complete Guide

What Is a VPAT?

A Voluntary Product Accessibility Template (pronounced "VEE-pat") is a standardized document that describes how a software product, website, or digital service meets (or doesn't meet) accessibility standards. It's created and maintained by the Information Technology Industry Council (ITI), and it's the industry-standard way to communicate accessibility compliance.

The completed VPAT is formally called an Accessibility Conformance Report (ACR). So you'll often hear these terms used interchangeably: you write a VPAT, and the result is an ACR. Think of the VPAT as the template and the ACR as your completed document.

The current edition is VPAT 2.5, released in 2021. It covers three major accessibility standards:

• WCAG 2.x (Web Content Accessibility Guidelines): the global standard for web accessibility
• Section 508 of the Rehabilitation Act: U.S. federal government accessibility requirements
• EN 301 549: European Union accessibility standard for ICT (Information and Communication Technology)

Who Needs a VPAT?

The short answer: if you're selling to government, higher education, or large enterprises, you likely need a VPAT. More precisely:

• Any software sold to the U.S. federal government: Section 508 compliance is required by law
• State government agencies: most states have accessibility requirements equivalent to or stricter than Section 508
• Universities and higher education institutions: typically required as part of ADA Title III compliance
• Large enterprise purchases: procurement teams increasingly require VPATs to evaluate vendor compliance
• Healthcare organizations: especially those receiving federal funding
• Financial services: increasing regulatory requirements around digital accessibility

The common trigger: a government RFP (Request for Proposal) or a procurement team's due diligence checklist. A missing or outdated VPAT can kill a deal before your sales team even gets a chance to pitch the product.

Which VPAT Edition Do I Need?

VPAT 2.5 comes in four different editions. Each covers different standards and serves different markets. Choosing the right edition depends on where you're selling.

Edition	Standards Covered	Best For	Typical Use Case
WCAG Edition	WCAG 2.1 and 2.2 only	Web products, SaaS platforms, digital services	Web-only products, especially private sector or international sales
Section 508 Edition	Section 508 standards (incorporates WCAG 2.0 AA)	U.S. federal government and contractors	Software sold to federal agencies
EU EN 301 549 Edition	European standard (similar to WCAG 2.1 AA)	Products sold in the European Union	SaaS with European customers, EU government contracts
INT Edition (Combination)	WCAG, Section 508, and EN 301 549	Enterprise SaaS serving multiple markets	Products sold to U.S. government and EU customers simultaneously

Quick rule of thumb: If you're selling enterprise SaaS that touches U.S. government, federal contractors, or EU markets, use the INT Edition. If you're only targeting a single market, choose the appropriate edition. Most mature products end up using the INT Edition because it's future-proof. If you're already documenting compliance for three standards, adding more is minimal extra work.

What Are the VPAT Conformance Response Options?

For each accessibility criterion, you mark the product's status with one of five response options. Understanding the difference between these options is critical. Vague responses create legal risk.

Response	What It Means	When to Use It
Supports	The product fully meets the criterion without exceptions. Testing confirms compliance across the product scope.	When you've tested and verified the feature works accessibly
Partially Supports	The product meets the criterion in some areas but not all. You must specify exactly which parts and why in the remarks.	Only when there's a legitimate reason and you explain it clearly
Does Not Support	The product does not meet the criterion. This is a compliance failure.	When a feature is inaccessible and won't be fixed in the near term
Not Applicable	The feature described by this criterion doesn't exist in the product.	Example: If your product has no video, WCAG 1.2 (video captions) is N/A
Not Evaluated	You haven't tested this criterion yet, but you acknowledge it applies to your product.	Rarely appropriate in final VPATs, but acceptable when submitting early drafts

Critical rule: Never leave a criterion blank. If you don't know the status, mark it "Not Evaluated" rather than leaving it empty. Procurement teams view blank fields as red flags.

How Do You Write a VPAT Step by Step?

Writing a VPAT is a methodical process that requires both technical testing and clear communication. Here's the step-by-step approach used by successful accessibility teams:

Step 1: Get the Official Template

Download the VPAT 2.5 template directly from itic.org (the Information Technology Industry Council). Don't use older versions or modified templates. Procurement teams expect the official format.

Step 2: Define Your Product Scope

Start with a clear statement of what you're documenting. Example:

"This ACR covers the web application dashboard of Product X, version 2.5.0, accessed via modern browsers (Chrome, Firefox, Safari, Edge from 2022 onward). Mobile app and legacy browser support are documented separately."

Clear scope prevents misunderstandings about what you've actually tested.

Step 3: Test Each Criterion Systematically

This isn't just visual testing. You need to:

• Test with keyboard navigation only (no mouse)
• Test with at least one screen reader (NVDA or JAWS for Windows, VoiceOver for Mac/iOS)
• Test color contrast using automated tools and manual verification
• Check mobile accessibility and touch interactions
• Review for focus management, ARIA implementations, and semantic HTML

Many teams use a combination of automated tools (Axe, Lighthouse, WAVE) and manual testing. Automated tools catch obvious issues; manual testing finds the subtle ones that break real user workflows.

Step 4: Write Honest, Specific Remarks

This is where VPATs separate good compliance teams from mediocre ones. For every "Partially Supports" response, write remarks that explain:

• Which parts of the product support the criterion
• Which parts don't, and why
• Any workarounds users can employ
• Timeline for fixes, if applicable

Bad example: "Partially Supports: some color contrast issues"
Good example: "Partially Supports. Primary text meets WCAG AA contrast requirements (4.5:1 minimum). Secondary UI elements in the reporting module use a custom gray that measures 3.8:1 against the white background, failing the 4.5:1 requirement. This will be remediated in Q2 2026. Users can enable high-contrast mode in settings as a temporary workaround."

Step 5: Document Workarounds and Accommodations

If a feature is inaccessible but users have a workaround, document it. Examples:

• "Custom data visualization doesn't support keyboard navigation, but the underlying data is available as an accessible CSV export"
• "This legacy module doesn't meet WCAG 2.1 AA, but we provide phone support for users needing assistance"
• "Mobile map interface is not fully keyboard-accessible; desktop version is fully accessible and recommended for users with mobility disabilities"

Workarounds don't replace accessibility fixes, but they demonstrate commitment to accommodating users.

Step 6: Sign and Date Your ACR

The VPAT should include the name and title of the person responsible for its accuracy. This creates accountability. Include a date, and update it whenever you refresh the document.

How Do I Document Special Content Types in a VPAT?

PDFs

PDFs receive special attention in accessibility compliance because they're widely distributed but notoriously difficult to make accessible:

• Must be tagged with proper heading hierarchy, list structure, and table structure
• Must have reading order: the logical flow of content must make sense to screen reader users
• Must pass color contrast: text on colored backgrounds must meet WCAG AA standards (4.5:1 for normal text, 3:1 for large text)
• Images must have alt text: convey the purpose or content of every image
• Forms must be properly structured: form fields must be labeled and properly associated

If your product includes PDFs, test them with a PDF accessibility tool (like PAC or Adobe Acrobat's accessibility checker) and a screen reader. Document the WCAG criteria specific to PDF accessibility in your VPAT.

Video Content

Video accessibility involves multiple layers:

• Captions are required (WCAG 1.2.2 AA): must be accurate, include speaker identification, and cover all dialogue and relevant audio
• Audio descriptions are required (WCAG 1.2.5 AA) for any visual information that isn't conveyed through dialogue, such as actions, expressions, scene changes
• Transcripts recommended (WCAG 1.2.1 A): provide a complete text transcript of all video content
• Video player must be accessible: keyboard controls, screen reader compatibility, caption toggle visibility

If your product has video, note which videos are captioned and which have audio descriptions. If some are missing, mark the criterion "Partially Supports" and commit to remediation.

Pre-Built Component Libraries

If your product uses third-party UI component libraries (like Material Design, Ant Design, React Bootstrap), document their accessibility status separately. Note:

• Which library version you use
• Which components are certified accessible
• Any custom overrides to those components (which might introduce accessibility issues)
• Whether you've tested those components in your actual implementation

Example VPAT remark: "Form inputs use Material-UI v5 components, which are WCAG 2.1 AA certified. Custom color themes apply a primary blue (#0066CC) on white backgrounds, which meets WCAG AA contrast requirements (4.75:1). All form error states include both icon and text labels, supporting users with color blindness."

Government-Specific Features

If your software serves government use cases, you may need to address:

• Government ID verification flows: ensure identity confirmation doesn't rely on visual patterns alone
• Digital signatures: must be keyboard and screen reader accessible
• Multi-factor authentication: WCAG 2.2 has specific criteria around cognitive load and accessibility during authentication
• Accessible PDF generation for official documents: certificates, licenses, notices must be tagged and structured

How Often Should a VPAT Be Updated?

Version Your ACRs

Maintain a document history. When you update your VPAT, include version numbers and dates. Example naming convention:

• ProductX-ACR-v2.5.0-March2026.pdf
• ProductX-ACR-v2.4.0-December2025.pdf (previous version)

This way, procurement teams know exactly which product version the VPAT covers, and you have a record of compliance history.

Review After Major Releases

Accessibility compliance isn't a one-time checklist. When you release significant new features:

• Review any new criteria affected by the feature
• Re-test existing functionality that might have regressed
• Update your VPAT remarks
• Update the version number and date

Address the Audit Reality

Government customers often require independent third-party accessibility audits. When an audit finds issues:

• Fix the actual problem: update your code and re-test thoroughly
• Update your VPAT: change the conformance status and document the fix
• Provide evidence: save testing records that demonstrate the fix works
• Establish a timeline: if fixes aren't immediate, provide a concrete remediation date

Watch the Deadline: 12-18 Months

A VPAT older than 12-18 months raises red flags in procurement. Updated your major version? Released significant new features? Your old VPAT is no longer credible. Create a refresh schedule:

• After every major version release (e.g., 2.0, 3.0)
• After significant feature launches
• Annually, at minimum, if you're selling to government

Implement Automated Regression Testing

Track accessibility compliance over time with automated tests. Tools like Axe, Cypress with accessibility plugins, or Deque's axe-core can be integrated into your CI/CD pipeline. This won't catch everything, but it will alert you to obvious regressions before they reach customers.

External Resources

What Are WCAG Conformance Levels in a VPAT? (A, AA, and AAA)

VPAT conformance responses (Supports, Partially Supports, etc.) describe how your product complies — but WCAG conformance levels describe how much is required. Understanding the difference is essential when completing or reviewing any VPAT.

WCAG organizes its success criteria into three levels:

Level	What It Means	Required By	VPAT Impact
Level A	Minimum baseline. Failures at this level completely block users with disabilities from accessing content.	All serious accessibility standards	Must be addressed — Level A failures are the most critical issues in a VPAT
Level AA	The legal and procurement standard. Covers the most common accessibility barriers for real users in real contexts.	Section 508, EN 301 549, ADA Title II (2024), most government contracts	This is the target level for virtually all VPATs submitted to U.S. federal agencies and enterprise procurement teams
Level AAA	Enhanced accessibility. Addresses edge cases and specific user needs. Not achievable for all content types.	Not legally required anywhere	Optional in a VPAT — document it if you meet it, but it's not expected by procurement

The practical implication: When procurement teams ask for a VPAT that shows "WCAG 2.1 AA compliance," they want documentation proving your product meets all Level A and Level AA success criteria — 50 criteria in total. Your VPAT should explicitly state which level you're targeting (typically AA) in the scope section.

If your product fails any Level AA criteria, mark those as "Partially Supports" or "Does Not Support" with honest, specific remarks. Claiming full AA conformance when Level A failures exist is a legal risk.

What Should a VPAT Legal Disclaimer Say?

Every completed VPAT (ACR) should include a legal disclaimer at the top of the document. This disclaimer protects the vendor by clarifying scope, evaluation methodology, and the date of testing — and it signals professionalism to procurement reviewers.

What to Include in a VPAT Legal Disclaimer

• Product name and version: exactly which release was tested
• Evaluation date: the date testing was completed (not the date the document was written)
• Evaluator identity: the person or firm responsible for the report — internal team or third-party
• VPAT edition: which edition was used (WCAG, Section 508, EU, or INT)
• Evaluation scope: which platforms, browsers, and assistive technologies were tested
• Limitation clause: that the report reflects the product at the time of testing and future releases may differ

VPAT Legal Disclaimer Example

Below is a standard legal disclaimer you can adapt for your own ACR:

Accessibility Conformance Report — Legal Disclaimer

This Accessibility Conformance Report (ACR) was prepared by [Company Name or Evaluator Name] on [Evaluation Date]. It covers [Product Name], version [X.X.X], evaluated via desktop web browsers (Chrome, Firefox, Safari, Edge — 2023 and later releases) and mobile browsers on iOS 17 and Android 14. Screen reader testing was conducted using NVDA 2023.3 with Chrome, JAWS 2024 with Chrome, and VoiceOver with Safari on macOS and iOS.

This report was completed using the [VPAT 2.5 INT / Section 508 / WCAG / EU] edition template, published by the Information Technology Industry Council (ITI).

The information in this report is accurate as of the evaluation date. Subsequent product updates, configuration changes, or third-party integrations may affect the conformance status described herein. This report is not a legal guarantee of accessibility and does not constitute legal advice. Users relying on this report for procurement decisions should verify currency and scope with the vendor.

Where Can I Find Official VPAT Templates?

The only authoritative source for official VPAT templates is the Information Technology Industry Council (ITI) at itic.org. All four VPAT 2.5 editions are available there for free. Do not use modified templates, outdated versions, or templates from unofficial sources — procurement teams expect the standard ITI format, and deviations can flag your submission as non-compliant before it's even read.

The Four Official VPAT 2.5 Templates

• VPAT 2.5 WCAG Edition — for international or web-only contexts not covered by U.S. or EU law
• VPAT 2.5 Section 508 Edition — for U.S. federal government and federal contractor sales
• VPAT 2.5 EU EN 301 549 Edition — for products sold to EU public sector organizations
• VPAT 2.5 INT Edition — combines all three standards; the most common choice for enterprise SaaS vendors

Supplemental Resources for Government VPAT Templates

• Section508.gov: provides procurement guidance, sample language, and testing tools for U.S. federal agencies and contractors. Particularly useful for understanding how agencies evaluate the VPATs they receive.
• GSA's government-wide IT accessibility program: publishes VPAT guidance for vendors participating in federal procurement vehicles like GSA Schedule contracts.
• Existing published ACRs as reference: many large software vendors (Microsoft, Google, Adobe, Salesforce) publish their VPATs publicly. These serve as real-world examples of professional-grade ACRs and are a valuable reference for format and remark quality.

Frequently Asked Questions

What is the difference between a VPAT and an ACR?

A VPAT (Voluntary Product Accessibility Template) is the blank standardized form published by the IT Industry Council (ITI). An ACR (Accessibility Conformance Report) is what you produce when you fill in that form for your specific product. Think of the VPAT as the template and the ACR as your completed document. The terms are used interchangeably in procurement conversations, but strictly speaking the ACR is the deliverable that gets submitted.

Is a VPAT legally required?

A VPAT is not mandated by statute, but it is effectively required for selling software to U.S. federal agencies and federally funded organizations. Section 508 of the Rehabilitation Act requires federal agencies to procure accessible technology, and agencies enforce this by requesting a completed VPAT/ACR during procurement. Without one, vendors are routinely disqualified before pricing is even discussed.

Which VPAT edition should I use: WCAG, 508, EU, or INT?

Use the Section 508 edition for U.S. federal government sales. Use the EU edition for European public sector contracts under EN 301 549. Use the INT edition if you need to cover all three standards (WCAG, Section 508, and EN 301 549) in a single document — which most enterprise SaaS vendors do. The WCAG-only edition is for purely international contexts not covered by either U.S. or EU law.

How long does it take to complete a VPAT?

A first-time VPAT for a mid-size web application typically takes 3–6 weeks when done thoroughly: 1–2 weeks of systematic testing against all relevant WCAG criteria, 1–2 weeks writing specific remarks and documenting workarounds, and at least one week for review and sign-off. Hiring an accessibility consultant can compress this to 2–3 weeks. Enterprise products with complex features, mobile apps, or multiple user roles can take 2–3 months.

What does "Partially Supports" mean on a VPAT?

"Partially Supports" is one of five allowed conformance responses in a VPAT. It means the product meets the accessibility criterion for some functionality or in some circumstances, but not all. The five responses are: Supports, Partially Supports, Does Not Support, Not Applicable, and Not Evaluated. Every "Partially Supports" entry must be accompanied by a specific remark explaining what works, what doesn't, and any available workarounds. Vague remarks are a legal risk.

How often should a VPAT be updated?

A VPAT should be reviewed after every major product release that changes UI, navigation, or interactive features. A VPAT older than 12–18 months raises red flags with government procurement teams and may be rejected. Many organizations review their VPAT quarterly and conduct a full accessibility re-test annually. Always version and date your ACRs so buyers can see how recently it was validated.

Can I write a VPAT myself or do I need a third-party consultant?

You can write a VPAT internally if your team has accessibility testing expertise and understands WCAG criteria. However, many organizations engage an independent accessibility consultant for the first VPAT because a third-party audit carries more credibility with government buyers and consultants typically surface issues that internal teams overlook. For large federal contracts, an independent audit is often expected. Once an initial compliant VPAT is in place, subsequent updates can usually be handled in-house.

Does a VPAT cover mobile apps as well as web products?

Yes. A VPAT can and should document mobile app accessibility separately from the web product. VPAT 2.5 includes criteria for software applications as well as web content. When documenting a product that spans web, iOS, and Android, define the scope clearly at the top of the ACR — typically you document each platform separately in the same document, noting any platform-specific conformance differences.

What is a VPAT legal disclaimer and what should it say?

A VPAT legal disclaimer is a statement placed at the top of an Accessibility Conformance Report (ACR) that clarifies the scope, evaluation methodology, date of testing, and limitations of the report. It should include: the product name and version evaluated, the evaluation date, the evaluator's name or organization, the VPAT 2.5 edition used, the platforms and assistive technologies tested, and a clause stating the report reflects the product at the time of testing and may not cover future releases. See the legal disclaimer section above for a full example you can adapt.

What is the difference between WCAG Level A, AA, and AAA in a VPAT?

WCAG defines three conformance levels. Level A is the minimum — failures here completely block users with disabilities. Level AA is the legal standard required by Section 508, EN 301 549, and most government and enterprise procurement requirements — this is what virtually all VPATs are evaluated against. Level AAA is enhanced accessibility, not legally required, and not achievable for all content types. When a procurement team asks for a VPAT demonstrating "WCAG 2.1 AA" compliance, they want evidence your product meets all 50 Level A and AA success criteria.

Where can I download official VPAT templates for government procurement?

Official VPAT 2.5 templates are published for free by the Information Technology Industry Council (ITI) at itic.org. Four editions are available: WCAG, Section 508, EU EN 301 549, and the INT (combined) edition. For U.S. federal government sales, use the Section 508 or INT edition. Supplemental procurement guidance is available at Section508.gov. Do not use unofficial or modified templates — agencies expect the standard ITI format.

Should I hire a VPAT creation service or write my VPAT in-house?

For your first VPAT — especially ahead of a federal RFP or major enterprise procurement — hiring a professional VPAT creation service or accessibility consultant is strongly recommended. An independent audit carries more credibility with government buyers than a self-assessed report, and experienced consultants surface issues internal teams typically miss. For ongoing updates once your initial VPAT is established, in-house teams with accessibility testing skills can usually take over. Look for IAAP-certified consultants or firms specializing in Section 508 and WCAG auditing.