Key Takeaways
- 1A VPAT is the template; when completed for a specific product, it becomes an ACR (Accessibility Conformance Report) — the document buyers actually evaluate
- 2VPAT Version 2.5Rev (April 2025) comes in four editions: 508, EU, WCAG, and International — choose based on your target market
- 3Section 508 requires an ACR for all ICT sold to the US federal government — a missing ACR means automatic disadvantage in procurement
- 4You must test your product first, then document results — guessing conformance levels is the #1 mistake vendors make
- 5ACRs should be updated at least annually and after every major product release — stale ACRs erode buyer trust
What Is a VPAT? (Voluntary Product Accessibility Template)
A VPAT (Voluntary Product Accessibility Template) is a standardized document that technology vendors use to describe how their product or service conforms to accessibility standards. Created and maintained by the Information Technology Industry Council (ITI), the VPAT provides a consistent format for documenting accessibility across the entire ICT (Information and Communications Technology) industry.
The current version is VPAT 2.5Rev, released in April 2025. "VPAT" is a registered service mark of ITI, but the template itself is free to download and use. Anyone can complete a VPAT for their product — there's no license fee, no certification requirement, and no formal approval process from ITI.
The VPAT matters because it has become the de facto standard for communicating product accessibility in procurement. When a government agency, university, or enterprise buyer asks "Is your product accessible?", they're really asking "Where's your VPAT?" It's the common language of accessibility documentation across industries and borders.
💡 Quick History of the VPAT
The VPAT was originally created in the early 2000s after Section 508 of the Rehabilitation Act was refreshed, requiring federal agencies to procure accessible ICT. ITI developed the template to give vendors a standardized way to communicate their accessibility conformance. Over time, the VPAT evolved through multiple versions — adding support for WCAG 2.0, then WCAG 2.1, and eventually European standard EN 301 549. The current Version 2.5Rev now supports WCAG 2.2, making it the most comprehensive edition yet.
VPAT vs. ACR: Understanding the Difference
This is the single most common source of confusion in accessibility documentation, so let's clear it up: the VPAT is the blank template; the ACR is the completed document.
📄 VPAT (Template)
- •The blank form you download from ITI
- •Contains empty tables for accessibility criteria
- •Includes instructions and column headers
- •Like a blank tax form (1040, W-9)
📊 ACR (Completed Report)
- •The VPAT filled out for your specific product
- •Contains your conformance levels and explanations
- •Tied to a specific product version and date
- •Like the completed tax return you file
In practice, the industry uses "VPAT" loosely to refer to both the template and the completed report. When a procurement officer says "Send me your VPAT," they mean your completed ACR. When Section508.gov says "How to Create an ACR with a VPAT," they're using the terms precisely. For this guide, we'll use the terms correctly — but know that in the real world, "VPAT" often means "ACR."
The Four VPAT 2.5 Editions Explained
VPAT 2.5 comes in four editions, each covering different accessibility standards. Choosing the right edition is your first decision — and it depends entirely on your target market.
VPAT 2.5 508 — US Federal
Covers Revised Section 508 standards and references WCAG 2.0 Level A and AA. This edition is designed specifically for vendors selling to US federal government agencies. It includes Section 508 chapters on functional performance criteria, hardware, software, support documentation, and services — beyond just the WCAG web criteria.
Best for: Vendors selling exclusively to US federal agencies
VPAT 2.5 EU — European
Covers the EN 301 549 European standard, which references WCAG 2.1 Level A and AA. Use this edition when selling to EU public sector buyers or demonstrating compliance with the European Accessibility Act (EAA). EN 301 549 extends beyond web content to cover documents, mobile applications, and hardware.
Best for: Vendors selling to EU public sector organizations
VPAT 2.5 WCAG — W3C Standards
Covers WCAG 2.0, 2.1, and 2.2 — all three versions of the W3C Web Content Accessibility Guidelines. This is the most flexible edition for vendors who want to document general web accessibility conformance without tying it to a specific government procurement standard. It's ideal for commercial products that need to demonstrate ADA compliance or respond to enterprise RFPs.
Best for: Commercial products, enterprise sales, general accessibility documentation
VPAT 2.5 INT — International
The all-in-one edition that combines Revised Section 508, EN 301 549, and WCAG 2.x into a single document. It's the most comprehensive but also the longest — you're documenting conformance against all three standards simultaneously. If you sell to both US and EU government buyers, this saves you from maintaining separate ACRs.
Best for: Global vendors selling to US federal, EU public sector, and commercial markets
💡 Practical advice: If you're unsure which edition to use, go with the VPAT 2.5 INT (International) edition. It covers all standards in one document, and you can mark sections as "Not Applicable" if a particular standard doesn't apply to your market. This gives buyers maximum information and avoids the need to maintain multiple ACRs.
Who Needs a VPAT/ACR?
The short answer: if you sell technology products or services to any organization that cares about accessibility — which is increasingly all of them — you need an ACR. Here's who specifically requires one:
🏛️ US Federal Government Vendors
Section 508 of the Rehabilitation Act requires that all ICT purchased, developed, maintained, or used by federal agencies must be accessible. This applies to every technology procurement — from a $500 software license to a $50 million platform contract. Agencies use ACRs to evaluate and compare vendor accessibility claims as part of the procurement process. No ACR? You're at an automatic disadvantage against competitors who have one.
🇪🇺 EU Public Sector Vendors
Under EN 301 549 and the European Accessibility Act, any vendor selling ICT to EU public sector organizations must demonstrate accessibility conformance. The VPAT EU edition provides the recognized format for this documentation.
🏫 State & Local Government and Education Vendors
With the DOJ's ADA Title II rule requiring WCAG 2.1 AA compliance for state and local government websites by April 2026, government procurement officers increasingly demand ACRs from vendors. Higher education institutions have long required VPATs for learning management systems, student portals, and library databases. K-12 school districts are now following suit.
🏢 Enterprise Procurement
Large enterprises are increasingly adding accessibility requirements to their procurement checklists — even without a legal mandate. Companies like Microsoft, Google, IBM, and Salesforce require ACRs from their vendors. If you're responding to enterprise RFPs, expect an accessibility section that asks for your VPAT/ACR.
🏥 Healthcare and Financial Services
Regulated industries like healthcare and banking use ACRs for compliance documentation. Healthcare organizations purchasing EHR systems, telemedicine platforms, or patient portals typically require a VPAT as part of vendor evaluation. Financial institutions purchasing digital tools need documentation that their technology investments meet accessibility requirements.
VPATs and Government Procurement: How Agencies Use ACRs
Understanding how government agencies use ACRs in procurement helps you create a better one. It's not just a checkbox — it's a competitive evaluation tool.
The "Best Meets" Standard
Section 508 doesn't require agencies to buy only products that are 100% accessible. Instead, it uses a "best meets" standard — agencies must procure the product that best meets their accessibility needs among available options. This means your ACR is being compared side-by-side with your competitors' ACRs.
A product that honestly reports "Partially Supports" for some criteria with clear explanations of workarounds is often preferred over a product with vague claims of "Supports" across the board. Procurement officers know no complex product is perfectly accessible — they're looking for honesty, specificity, and evidence of commitment to improvement.
How Procurement Officers Evaluate ACRs
Currency Check
Is the ACR recent? Does it reference the current product version? ACRs older than 1-2 years raise immediate red flags. Procurement officers check the evaluation date first.
Conformance Level Review
They scan for the overall pattern: How many "Supports" vs. "Partially Supports" vs. "Does Not Support"? An ACR that claims "Supports" for everything is viewed with skepticism — it suggests the vendor didn't actually test.
Remarks Quality
The Remarks/Explanations column is where credibility lives or dies. Specific, detailed remarks (like "Keyboard focus is visible on all interactive elements except the date picker widget, which will be remediated in Q2 2026") show genuine evaluation. Vague remarks (like "Some issues may exist") show the vendor is guessing.
Competitive Comparison
Agencies lay competing ACRs side by side and compare conformance across critical success criteria for their use case. The product with the strongest overall accessibility profile gets the procurement edge.
💡 Missing ACR = Missing opportunity. According to the Section508.gov ACR guide, agencies can and do exclude vendors who fail to provide an ACR during procurement. In competitive government bids, the absence of an ACR isn't neutral — it's a disqualifying factor.
How to Create an ACR: Step-by-Step Process
Creating a quality ACR isn't something you rush through in an afternoon. Here's the complete process, from downloading the template to publishing your final report.
Download the VPAT Template from ITI
Go to the ITI VPAT page and download the edition that matches your market (508, EU, WCAG, or INT). The templates are Word documents that you'll fill in. Make sure you're downloading Version 2.5Rev — using an outdated version is one of the most common mistakes vendors make.
Complete the Title Page Information
The title page sets the context for your entire ACR. Fill in:
- •Product name and version — be specific (e.g., "Acme Cloud Platform v4.2.1," not just "Acme Cloud Platform")
- •Report date — the date the ACR was completed, not the product launch date
- •Contact information — a person or team who can answer questions about the ACR
- •Evaluation methods — describe whether you used automated testing, manual testing, assistive technology testing, or a combination
- •Notes — any additional context about the scope of evaluation (which features were tested, which platforms, etc.)
Understand the Three-Column Structure
Every table in the VPAT uses the same three columns:
Criteria
The specific accessibility requirement (e.g., "1.1.1 Non-text Content" or "Chapter 4: Hardware"). This column is pre-filled — don't modify it.
Conformance Level
Your assessment of how well the product meets each criterion: Supports, Partially Supports, Does Not Support, or Not Applicable.
Remarks and Explanations
Detailed explanations of how the product meets the criterion, or what barriers exist and what workarounds are available. This is the most important column.
Complete the WCAG Level A and AA Tables
This is the core of your ACR. You'll evaluate your product against each WCAG success criterion at Level A and Level AA. For the best results, use a combination of automated testing tools and manual evaluation. Document findings criterion by criterion — this is where the testing you did (or should have done) in advance pays off.
For each criterion, ask: Does the product fully meet this requirement across all features and user flows? If yes, mark "Supports." If partially, describe what works and what doesn't. If not at all, be honest — it's better to report "Does Not Support" with a remediation timeline than to falsely claim compliance.
Complete Section 508 Chapters (If Applicable)
If you're using the 508 or INT edition, you'll also need to address Section 508's additional chapters:
- •Chapter 3: Functional Performance Criteria — alternative approaches when a specific technical standard doesn't apply
- •Chapter 4: Hardware — physical product accessibility (mark N/A for pure software products)
- •Chapter 5: Software — interoperability with assistive technology, platform accessibility services
- •Chapter 6: Support Documentation and Services — accessible user documentation, helpdesk, and training materials
Final Review Checklist
Before publishing your ACR, verify:
- ✓All criteria have a conformance level (no blank cells)
- ✓Every "Partially Supports" and "Does Not Support" has detailed remarks
- ✓The product version matches the version you actually tested
- ✓Evaluation methods are clearly described on the title page
- ✓Contact information is current and reaches someone who can discuss accessibility
- ✓You're using the latest VPAT template (Version 2.5Rev)
Understanding Conformance Levels
The VPAT defines specific conformance levels you must use when completing your ACR. Using the correct terminology is critical — procurement officers know these definitions and will notice if you're using them incorrectly.
✅ Supports
The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation. Use this only when you've tested and confirmed full conformance for the criterion across all relevant product features.
⚠️ Partially Supports
Some functionality of the product does not meet the criterion. This is the most common honest assessment for complex products. In your remarks, describe specifically which features conform and which don't, any workarounds available, and your remediation timeline if applicable.
❌ Does Not Support
The majority of product functionality does not meet the criterion. Don't be afraid to use this level when it's accurate — it demonstrates you've actually evaluated the product. An ACR with a few "Does Not Support" entries and clear remediation plans is more credible than one that claims "Supports" for everything.
➖ Not Applicable
The criterion is not relevant to the product. For example, WCAG criterion 1.2.1 (Audio-only and Video-only) is "Not Applicable" if your product doesn't contain any audio or video content. Use this judiciously — overusing "Not Applicable" to avoid evaluation is a red flag.
⚠️ Avoid "Not Evaluated." While the VPAT allows this level, leaving criteria as "Not Evaluated" signals to procurement officers that you either didn't do the work or are trying to hide something. Agencies may treat "Not Evaluated" the same as "Does Not Support" when comparing ACRs.
VPAT vs. Accessibility Audit: What's the Difference?
Another common point of confusion: a VPAT/ACR is not the same thing as an accessibility audit. They're related but distinct activities, and understanding the difference is essential to producing a credible ACR.
🔍 Accessibility Audit
- •Expert testing of your product's accessibility
- •Identifies specific barriers and issues
- •Includes automated scans + manual testing + assistive technology evaluation
- •Produces a detailed report with screenshots and remediation guidance
- •The input — provides the data you need
📊 VPAT/ACR
- •Standardized documentation of conformance status
- •Summarizes accessibility at the criterion level
- •Uses predefined conformance levels (Supports, Partially Supports, etc.)
- •Designed for procurement evaluation, not remediation
- •The output — the public-facing document
💡 The critical relationship: You need an accessibility audit before you can create a credible ACR. The audit provides the testing data; the ACR translates that data into the standardized VPAT format. Skipping the audit and going straight to the ACR means you're guessing at conformance levels — which is the #1 mistake vendors make. For more on the audit side, see our guide to accessibility testing services.
Common VPAT/ACR Mistakes That Cost Contracts
Having reviewed hundreds of vendor ACRs, procurement officers and accessibility consultants see the same mistakes repeatedly. These errors don't just make your ACR less useful — they can cost you the contract.
Mistake #1: Using an Outdated VPAT Version
Some vendors are still submitting ACRs based on VPAT 2.0 or even older formats. The current version is 2.5Rev (April 2025). Submitting an outdated format signals that you're not paying attention to the accessibility landscape — and if you can't keep your template current, procurement officers wonder how current your testing is.
Mistake #2: Not Testing Before Completing the ACR
This is the biggest and most common mistake. Vendors complete the VPAT by guessing how their product performs against each criterion, rather than actually testing with accessibility tools. The result is an ACR full of "Supports" claims that fall apart under scrutiny. Procurement officers who conduct their own spot-checks will immediately lose trust in your entire document.
Mistake #3: Leaving Criteria as "Not Evaluated"
While "Not Evaluated" is technically a valid status, using it for required criteria tells procurement officers you didn't do the work. It's especially damaging for WCAG Level A criteria — the baseline of web accessibility. If you can't even evaluate the fundamentals, why would an agency trust your product?
Mistake #4: Vague Remarks That Don't Explain Barriers
Remarks like "Some elements may not be fully accessible" or "Product generally supports this criterion" are useless. Procurement officers need specific information: Which features have barriers? What is the nature of the barrier? Are there workarounds? When will it be fixed? Compare: "Some issues may exist" vs. "The data table sorting feature does not announce sort direction changes to screen readers. A keyboard-only workaround exists via the F5 refresh shortcut. Fix targeted for v5.1 (Q3 2026)."
Mistake #5: Not Updating When Products Change
An ACR is a snapshot in time. If you release a major product update that changes the UI, adds new features, or modifies user flows, your old ACR no longer accurately represents your product. Stale ACRs erode trust — especially when the product version on the ACR doesn't match the version being sold. Treat your ACR as a living document that updates with your product.
GSA OpenACR: The Future of Machine-Readable Reports
The General Services Administration (GSA) has been developing OpenACR — an initiative to create machine-readable accessibility conformance reports. While the traditional VPAT is a Word document that humans fill out and other humans read, OpenACR represents ACR data in a structured format that can be programmatically compared, analyzed, and tracked over time.
Why OpenACR Matters
Standardized Machine-Readable Format
Instead of reading through Word documents, procurement officers can use tools to compare ACRs across vendors automatically. This levels the playing field — a small vendor's ACR gets evaluated with the same rigor as a large vendor's.
Version Tracking
OpenACR format allows tracking conformance changes across product versions, making it easy to see whether accessibility is improving or regressing over time.
Public Repository
GSA envisions a public repository of OpenACR reports, allowing any agency (or any buyer) to search and compare vendor accessibility data without having to request ACRs individually.
The GSA OpenACR Editor is already available as a tool to create machine-readable ACRs. While it hasn't fully replaced the traditional VPAT Word document in most procurement workflows, it signals where the industry is heading. Forward-thinking vendors should familiarize themselves with the OpenACR format — it may become the preferred (or required) submission format for federal procurement in the coming years.
Testing Before Your VPAT: Getting Accurate Data
The quality of your ACR is only as good as the testing behind it. Here's a practical approach to getting the accurate conformance data you need before filling out the VPAT template.
Start with Automated Scanning
Run automated accessibility testing tools across your product. Tools like RatedWithAI scan your product against WCAG success criteria — the same criteria documented in your VPAT — giving you a data-driven baseline. Automated testing typically catches 30-40% of WCAG issues but provides an essential starting point and identifies low-hanging fruit for remediation.
Conduct Manual Testing
Have an accessibility expert (internal or contracted testing service) manually test your product. This catches issues that automated tools miss: logical reading order, meaningful sequence, keyboard traps, complex widget interactions, and proper use of ARIA attributes.
Test with Assistive Technology
Test your product with actual assistive technology: screen readers (NVDA, JAWS, VoiceOver), screen magnifiers, voice control software, and switch devices. This is the gold standard for accessibility evaluation and provides the most credible data for your ACR. At minimum, test with NVDA + Chrome and VoiceOver + Safari.
Fix What You Can Before Documenting
Here's where many vendors miss an opportunity: test first, remediate the easy fixes, then document your ACR. A round of automated scanning and quick fixes can upgrade several criteria from "Partially Supports" to "Supports" before you even start the formal ACR process. Use our ADA compliance checklist as a guide for prioritizing fixes.
✅ Pro tip: Document your testing methodology as you go — which tools you used, what browsers and assistive technology combinations you tested, which user flows you evaluated, and which devices you tested on. This becomes the "Evaluation Methods" section of your ACR title page and significantly boosts credibility with procurement officers.
Maintaining Your ACR Over Time
Creating an ACR isn't a one-and-done exercise. Your product changes, standards evolve, and buyers expect current documentation. Here's how to keep your ACR relevant and credible over time.
When to Update Your ACR
Annual Review (Minimum)
Even if your product hasn't changed significantly, review your ACR annually. Confirm that conformance levels still hold, update the evaluation date, and reference the current product version. An ACR with a date more than 12 months old is a procurement red flag.
After Major Product Releases
Any release that changes the UI, adds significant features, or modifies user flows should trigger an ACR update. New features need to be evaluated for accessibility, and UI changes may affect conformance for existing criteria.
When Standards Change
When new WCAG versions are adopted (e.g., WCAG 2.2) or new VPAT template versions are released, update your ACR to reflect the latest standards. This shows you're proactive about accessibility, not just reactive.
After Accessibility Remediation
If you've fixed accessibility issues that were noted in your ACR, update the document to reflect the improvements. This shows progress and demonstrates ongoing commitment to accessibility.
Consider integrating ACR maintenance into your product release cycle. When QA tests a new release, include accessibility testing in the checklist. When the release notes go out, update the ACR. This transforms accessibility documentation from an occasional burden into a routine part of product management.
For organizations with a digital accessibility platform like RatedWithAI running continuous monitoring, much of this data collection becomes automatic — you always have current accessibility data to feed into your next ACR update.
Get Accurate WCAG Data for Your VPAT — In Minutes
RatedWithAI scans your product against WCAG success criteria — the same criteria documented in your VPAT. Get a data-driven baseline of your conformance levels before you start your ACR, identify issues to fix first, and set up continuous monitoring to keep your ACR current.
Free scan includes WCAG 2.1 AA compliance check · No credit card required · Results in under 60 seconds
Frequently Asked Questions
What is a VPAT and what does VPAT stand for?
VPAT stands for Voluntary Product Accessibility Template. It's a standardized document created by the Information Technology Industry Council (ITI) that vendors use to describe how their ICT product or service conforms to accessibility standards like WCAG, Section 508, and EN 301 549. The VPAT itself is the blank template — once completed for a specific product, it becomes an Accessibility Conformance Report (ACR). "VPAT" is a registered service mark of ITI, but the template is free to download and use.
What is the difference between a VPAT and an ACR?
A VPAT is the blank template; an ACR is the completed document for a specific product. Think of it like a tax form: the blank 1040 is the template (VPAT), and the filled-out 1040 you file is the report (ACR). The industry often uses "VPAT" colloquially to mean both, but when a procurement officer says "Send me your VPAT," they want your completed ACR.
Who needs to complete a VPAT?
Any company selling ICT products or services to the US federal government (Section 508), EU public sector (EN 301 549), state/local governments (ADA Title II), higher education, or large enterprises that include accessibility in procurement requirements. Increasingly, healthcare and financial services organizations also require VPATs from vendors.
How long does it take to create a VPAT/ACR?
Creating a thorough ACR typically takes 2-6 weeks. The bulk of the time is spent on accessibility testing — the actual documentation in the VPAT template takes 1-2 weeks for a straightforward product. Complex enterprise applications with many features may require longer. If you haven't done any accessibility testing yet, add time for testing and remediation before documentation.
Which VPAT edition should I use?
Choose based on your market: VPAT 2.5 508 for US federal sales, VPAT 2.5 EU for European public sector, VPAT 2.5 WCAG for general web accessibility, or VPAT 2.5 INT (International) if you sell to multiple markets. When in doubt, use the INT edition — it covers all standards in one document and you can mark irrelevant sections as "Not Applicable."
Does ITI review or certify completed VPATs?
No. ITI creates and maintains the VPAT template, but it does not review, certify, or validate completed ACRs. The vendor is solely responsible for the accuracy of their ACR. There is no official certification body for VPATs, which is why the quality varies significantly. Learn more about accessibility certification options.
How often should I update my ACR?
At minimum, annually. You should also update after every major product release that changes functionality or UI, and when new VPAT template versions are released. An ACR older than 12 months raises questions with procurement officers about whether it reflects the current state of your product.
Can automated tools like RatedWithAI help with VPAT completion?
Yes — automated tools are essential for the testing phase that precedes ACR creation. RatedWithAI scans your product against WCAG success criteria — the same criteria documented in your VPAT — giving you a data-driven baseline of conformance levels. However, a complete ACR should also incorporate manual testing. Use automated tools as your first step: scan, fix what you find, then do deeper manual evaluation before documenting in the VPAT template.
Sources
Related Articles
Government
Government Accessibility Compliance Cost Comparison 2026
What federal, state, and local agencies spend on accessibility compliance and how vendors can compete effectively.
Deadline
ADA Title II April 2026 Deadline Countdown
State and local government websites must meet WCAG 2.1 AA by April 24, 2026 — driving new VPAT requirements for vendors.
Testing
Best Accessibility Testing Tools in 2026
The tools you need for the testing phase before completing your VPAT/ACR — from automated scanners to manual evaluation.