From VPAT to ACR: The Complete Product Accessibility Documentation Guide

VPATs and ACRs may seem complex and overly technical, but in this 10 minute guide (updated for 2025) we’ll take you from start to finish on exactly what you need to understand about this documentation. From how to fill out a VPAT to what to look for in an ACR during the procurement process, it’s all here.

The key acronyms are Voluntary Product Accessibility Template (VPAT) and Accessibility Conformance Report (ACR).

The demand for accessible products and services has skyrocketed – both for physical and digital accessibility – because of an advancing private marketplace and regulatory updates that include the new ADA Title II web accessibility rule and the updated HHS Section 504 regulation that includes a section on digital accessibility that mirrors ADA Title II requirements.

This accessibility demand represents a huge growth opportunity for product vendors as buyers must purchase only WCAG 2.1 AA conformant products to ensure access to people with disabilities and for compliance and legal risk mitigation reasons. But both buyers and sellers must understand how VPATs and ACRs work because glossing over the details can cause serious damage.

Let’s now learn the ins and outs to documenting product accessibility.

Note: VPATs can be filled out for products or services, but we’ll use products throughout this guide for simplicity.

Overview

What Are VPATs and ACRs?

• VPAT: A Voluntary Product Accessibility Template is a standardized document used to provide an accounting of a product or services’s accessibility against a technical standard.
• ACR: An Accessibility Conformance Report is the resulting documentation after a VPAT is filled in and completed. The ACR consists of two sections: important details (think of administrative stuff like the product name and version) and an accessibility table (where we find out how the digital asset grades against the criteria for a standard).

Purpose of VPATs and ACRs

The primary purpose of VPATs and ACRs is to assist in the procurement process by providing a standardized format for reporting product accessibility. Buyers can easily:

• determine the accessibility of a product or service
• easily compare the accessibility of digital assets against one another

Completing a VPAT: Step-by-Step Guide

1. Gather Product Information: Compile all relevant information about the product, including its name, version, and the date of the report. Add a method of contact for the person responsible for questions regarding the report.
2. Choose Relevant Standards: Identify the accessibility standards your product needs to conform with. Common standards include WCAG 2.1 AA and Section 508. Whatever standard(s) you choose will match the VPAT edition.
3. Conduct an Accessibility Audit: Conduct a thorough and meticulous accessibility audit of your digital asset. At Accessible.org, our evaluation includes the following methodologies:
   • Screen reader testing
   • Keyboard-only interaction
   • Code inspection
   • Visual inspection
   • Browser zoom 200% and 400%
   • Color contrast analyzer tool
   • Automated accessibility scan (AXE)
4. Document Conformance Levels: For each criteria in the chosen standard, document the conformance level using categories such as Supports, Partially Supports, Does Not Support, and Not Applicable.
5. Provide Detailed Explanations: Include remarks and explanations for each conformance level to provide context and clarity about how the product meets or does not meet each criterion. A comment is required only when partially supports or does not support is entered, but it is best practice to add in supporting comments where they help add context.
6. Review and Validate: Review the completed VPAT for accuracy and completeness.

Practical Example of a VPAT Criterion Entry

Here is a hypothetical example where a product only partially supports a criterion.

1.2.1 Audio-only and Video-only (Prerecorded)

• Conformance Level: Partially Supports
• Remarks and Explanations: The application provides transcripts for prerecorded audio content but lacks captions for video content. Plans are in place to implement captions in the next update.

VPAT Editions

There are four different VPAT editions. You will select one to fill out and create an ACR.

Our clients usually select the WCAG edition.

Preparing to Create the Accessibility Conformance Report (ACR)

We’ve already covered how to fill out the VPAT. In this section we’ll talk about:

• When the ACR enters the design, development, and procurement process.
• Who should write the ACR.
• What sections to fill out in the ACR.

Integration of Accessibility into the Product Development Lifecycle

Timing of ACR Creation

Accessibility needs to be considered throughout the product development lifecycle. The ACR should be completed after the design, development, testing, and documentation phases are finished. Ideally, you will have an accessibility audit and remediation take place before the VPAT is filled in.

The reason for this is you want as clean of an ACR as possible (as few accessibility issues as possible). This means you are more likely to win the contract or have your product or service purchased.

Optimally, the ACR should be completed right before the product release to ensure it provides the most relevant and accurate information about the latest version of the product.

Who Should Write the ACR

Because most organizations do not have a technical accessibility expert on staff, it’s highly recommended (though not required) to source the audit to a digital accessibility company known for providing high quality services. This is because the accuracy of the ACR is based upon the accuracy of the audit.

After the audit is conducted, then the material portion of the VPAT, the accessibility table, can be filled in using the audit report.

Ultimately, the VPAT can be completed by the service provider or someone in-house who was involved in product development, knowledgeable of accessibility, and has access to the audit results. Practically, it’s advantageous to have the service provider issue the ACR because buyers and procurement agents may discount an ACR that was created by the product team. ACRs created in-house are subject to bias and a tendency to underreport accessibility issues.

Keep in mind that the ACR is a sterile, technical document, not a marketing document, and must be fact-based.

Sections of the ACR

The final ACR will consist of two parts: details and accessibility. The leading 10 pages of instructions found in the VPAT are to be discarded for the final report.

When it comes to the accessibility table, it’s important to account for all product components.

Determining Product Components

Identify and document all components of the product, including documentation, support services, hardware, software, and third-party products. If users cannot distinguish the third-party product, include its accessibility information in the ACR. If it is a separate product, note this and, if possible, provide a URL for its accessibility information.

Minimum Details Requirements

The ACR must include the following basic information about the product:

• Product Information: Name of the product and version number (if applicable).
• Product Description: A description of what the product is.
• Date of Completion: Date the ACR was issued or completed.
• Contact Information: The contact information is crucial for follow-up questions or additional information.
• Evaluation Methods: Description of the methods used to evaluate the product’s accessibility.

Applicable Standards and Guidelines

One very important detail is the standard used when evaluating the product or service. For Section 508 and EN 301 549 editions, this is obvious based on the VPAT edition. For the WCAG edition, it’s important to name the version and conformance level.

The INT edition of the VPAT will include all standards.

Standards Included

The ACR should specify the applicable standards and guidelines, such as WCAG 2.x, Section 508, and EN 301 549.

Answering Technical Criteria

Technical Criteria Tables

When the VPAT is completed, the resulting ACR can include tables for WCAG, Section 508, and EN 301 549 criteria. Each criterion will have a conformance level and a remarks and explanations section.

Conformance Levels

There are five conformance levels:

• Supports: The functionality of the product meets the criterion without known defects or with equivalent facilitation.
• Partially Supports: Some functionality of the product does not meet the criterion.
• Does Not Support: The majority of the product’s functionality does not meet the criterion.
• Not Applicable: The criterion is not relevant to the product.
• Not Evaluated: This can only be used for WCAG 2.x Level AAA criteria. For all other criteria, use Supports, Partially Supports, Does Not Support, or Not Applicable.

You will choose one conformance level for each criterion.

Remarks and Explanations

The remarks and explanations column requires an entry only if the term used for conformance is partially supports or does not support. Otherwise this column is optional. However, it’s encouraged to add supporting context where it would be helpful for at least some criteria. Not only can this be practically useful information, but it shows attention to detail and is evidence of genuine evaluation.

This column can include detailed information such as the evaluation methodology, dependencies such as OS and browsers, methods for finding more accessibility information, and known workarounds for accessibility issues.

Understanding WCAG and Its Application

What Is WCAG?

WCAG stands for the Web Content Accessibility Guidelines. These are technical standards for web accessibility developed by the World Wide Web Consortium (W3C).

WCAG Versions

There are several versions of WCAG:

• WCAG 1.0: Released in 1999.
• WCAG 2.0: Released in 2008.
• WCAG 2.1: Released in 2018.
• WCAG 2.2: Released in 2023.

WCAG Conformance Levels

WCAG success criteria are divided into three conformance levels:

• Level A: Provides for foundational accessibility.
• Level AA: Provides for a comprehensive level of accessibility.
• Level AAA: An extreme level of accessibility that is often practically difficult to fully conform with (this is why you rarely see AAA referenced).

WCAG POUR Principles

WCAG criteria are divided into four main principles represented by the acronym POUR:

• Perceivable: Information and user interface components must be presentable to users in ways they can perceive. This includes providing text alternatives for images and captions for multimedia content.
• Operable: User interface components and navigation must be operable. This includes making all functionality available from a keyboard and providing users enough time to read and use content.
• Understandable: Information and the operation of the user interface must be understandable. This involves making text readable and predictable and helping users avoid and correct mistakes.
• Robust: Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.

Application of WCAG to Non-Web Technologies

Although WCAG does not fully apply to non-web assets such as software, the principles still generally apply so that is why you will see adopted or incorporated as a technical standard even for non-web technologies:

• U.S. Section 508: Applies WCAG 2.0 Level A and AA criteria to web-based documentation and authoring tools. It has exceptions for certain criteria in non-web software and documentation.
• European EN 301 549: Applies WCAG 2.1 AA criteria to various technologies with some exceptions and replacements for specific criteria.

Understanding The Section 508 VPAT Edition

In this section we will cover:

• Reviewing Section 508 criteria and their application.
• Understanding how Section 508 applies to hardware, software, documentation, and support services.
• Identifying which sections of the VPAT cover specific criteria.

What Is Section 508?

Section 508 is part of the Rehabilitation Act of 1973. It mandates that electronic and information technology procured by federal agencies must be accessible to people with disabilities. The U.S. Access Board is responsible for these standards, which were revised in 2017 and updated in 2018. The revised Section 508 combines aspects of Section 255 of the Telecommunications Act, recognizing the convergence of phones and computers.

Revised Section 508 Standards

The revised Section 508 falls under Section 1194.1 standards and includes seven chapters:

1. Application and Administration
2. Scoping Requirements
3. Functional Performance Criteria
4. Hardware
5. Software
6. Support Documentation and Services
7. Reference Standards

Determine What Your Product Includes

To start, determine all components of your product, including documentation, support services, hardware, and software. This ensures comprehensive accessibility testing and accurate reporting in your ACR. If your product incorporates third-party products, their accessibility must also be documented.

Which Criteria Apply When

Criteria That Apply All the Time

Certain criteria apply universally to products:

• Documentation and Support Services: Must be accessible, covering support documentation (602.2), electronic support documentation (602.3), and alternate formats for non-electronic support documentation (602.4).
• Support Services: Must accommodate communication needs (603.2 and 603.3).

Criteria That Apply to All Hardware

For hardware, specific criteria apply consistently:

• 403 Biometrics
• 404 Preservation of Information Provided for Accessibility
• 405 Privacy
• 406 Standard Connections
• 408 Display Screens
• 410 Color Coding
• 411 Audible Signals

Criteria That Apply to Some Hardware

Some criteria apply depending on the type of hardware:

• 402 Closed Functionality
• 407 Operable Parts
• 409 Status Indicators
• 412 Two-Way Communications
• 413 Closed Captioning Processing Technologies
• 414 Audio Description Processing Technologies
• 415 Controls for Captions and Audio Descriptions

Section 508 Software Criteria Summary

Criteria That Apply to All Software

All software must meet:

• 501 General: Complete the WCAG section regardless of whether the software is web-based or not.

Criteria That Apply to Some Software

Different categories of software have additional criteria:

• Non-Web Software: Must meet 502.2.2 (No Disruption of Accessibility Features) and 502.3 (User Preferences).
• Multimedia: Must meet 503.4.1 (Caching Controls) and 503.4.2 (Audio Description Controls).
• Authoring Tools: Must meet 504.2.1 (Preservation of Information), 504.2.2 (PDF Export), 504.3 (Prompts), and 504.4 (Templates).
• Platform Products: Must meet various criteria under 502.2, 502.3.x, 502.4, and 503.2.
• Assistive Technology: Must meet 503.3 (Alternative User Interfaces).

Understanding The EN 301 549 VPAT Edition

What Is EN 301 549?

EN 301 549 is an accessibility standard for Information and Communication Technology (ICT) products and services. It is adopted by the European Union, Britain, Australia, and other countries. The latest version 3.1.1 can be found on the ETSI website.

EN 301 549 Structure

EN 301 549 contains 13 clauses, with clauses 5 through 13 covering the technical requirements. These clauses detail the specific accessibility criteria for various types of ICT products.

Determine What Your Product Includes

To properly apply EN 301 549, first determine the components and functionality of your product:

• Documentation and Support Services
• Hardware
• Software
• Third-Party Products

Which Criteria Apply When

Criteria That Apply Every Time

Certain criteria apply universally to all products:

• Clause 12: Documentation and support services, including compatibility features and accessibility documentation (completed in the WCAG section of the ACR).
• Clause 5: General requirements for hardware, software, and web products, including closed products, activation of accessibility features, biometrics, and operable parts.

Criteria That Apply to Hardware

Clause 8 specifies criteria for hardware such as:

• General Hardware Requirements
• Speech Output
• Stationary ICT (height, reach)
• Mechanically Operable Parts
• Tactile Indication of Speech Mode

WCAG Exceptions in EN 301 549

EN 301 549 includes exceptions to WCAG criteria:

• 2.4.1 Bypass Blocks
• 2.4.5 Multiple Ways
• 3.1.2 Language of Parts
• 3.2.3 Consistent Navigation
• 3.2.4 Consistent Identification
• 4.1.1 Parsing
• 4.1.2 Name, Role, and Value
• 1.1.3 Status Messages

Criteria for Software

Clause 11 applies to various types of software, including non-web software, command line interfaces, native mobile apps, and closed functionality software. It requires compliance with WCAG 2.1.

Criteria That Apply Sometimes

Certain criteria apply under specific conditions such as:

• Clause 6: ICT with two-way voice communication.
• Clause 7: ICT with video capabilities.
• Clause 13: ICT providing relay or emergency services.

Functional Performance Statements

These criteria (Clause 4) cover different usage scenarios such as:

• Without Vision
• With Limited Vision
• Without Perception of Color
• Without Hearing
• With Limited Hearing
• Without Speech
• With Limited Manipulation or Strength
• With Limited Reach
• Minimizing Photosensitive Seizure Triggers
• With Limited Cognition, Language, or Learning
• Privacy

Applicable Standards for EU Edition VPAT

When filling out the EU section of the VPAT, ensure you mark “yes” under the included standards at the top of the ACR. The current standard is EN 301 549 version 3.1.1.

WCAG 2.x Report Section of EU VPAT

For the WCAG 2.x report section:

• Report on both 2.0 and 2.1 standards.
• Fill out the conformance level and remarks/explanations for each criterion, including non-text content, web, electronic documents, software, and authoring tools.

What Makes a Good Accessibility Conformance Report (ACR)?

Here are indicators of a good ACR:

• Details section is completed filled out
• Evaluation methods section lists multiple different methodologies with screen reader testing and keyboard navigation testing included
• The conformance level column is completely filled out
• Conformance levels indicated use the right terms
• The remarks and explanations column is filled out for, at the very least, conformance levels that are marked as partially supports or does not support
• Remarks and explanations made provide sufficient information to understand how a product does not or partially supports and any other relevant information including, possibly, known workarounds.
• If reviewed, all conformance level information is accurate

Examples of Good and Bad ACRs

Bad Example ACR: Hardware

Incorrect conformance levels such as “Passes” or “Minor Exceptions” are used instead of the standard five levels.

Good Example ACR: Hardware

Uses correct conformance levels like “Supports,” “Not Applicable,” “Partially Supports” with appropriate remarks.

Bad Example ACR: Software

Incorrect use of “Not Applicable” for criteria that should be marked as “Does Not Support.”

Good Example ACR: Software

Correctly identifies non-applicable criteria and provides clear justifications.

Guide for Buyers

In this section, we will help readers and evaluators understand what to look for in an ACR. This includes ensuring that all components of the ACR are present and accurate, and understanding how to interpret the information provided.

Steps for ACR Readers and Evaluators

Step 1: Identify the standard required for the ACR.

Step 2: Ensure that the appropriate VPAT template was used.

Step 3: Confirm the Product Version Named Is The Current or relevant version.

Step 4: Review the “Evaluation Methods Used” section in the ACR to understand how the product was evaluated:

• Who Conducted the Testing: In-house or external vendor. Obviously, ACRs issued by accessibility experts or digital accessibility companies is much more preferred and favored in the marketplace.
• Inclusion of Users with Disabilities: Whether the testing included users with disabilities.
• Kinds of Evaluation: Manual, automated, tool-assisted, visual inspection, code inspection, etc.

Step 5: Verify that the ACR covers all components of the product:

• Hardware and Software: Ensure ACRs for both if applicable.
• Mobile Apps: Ensure ACR covers mobile app accessibility.
• Third-Party Products: Ensure ACRs for any third-party products included with the main product.

Step 6: Spot Check / Review For Accuracy.

Step 7: Know the specific criteria relevant to your needs and the needs of your organization.

Step 8: Review the conformance levels for essential criteria.

Certification

There is no VPAT certification. Product owners use the VPAT to demonstrate the accessibility of their products, but it is not a certification of any kind. It is merely an accounting of the accessibility of the product. The accounting may show that a product is 100% accessible or various other levels of accessibility below full conformance with the given standards.

Many product owners and procurement agents are under the impression that the mere existence of the ACR equates to an accessible product when all it means is that the accessibility of the product, however good or bad, is documented. So neither a VPAT nor ACR amounts to any sort of official sort certification, but it can serve as very nice documentation to demonstrate product accessibility.

Websites

Although websites do fall under the umbrella of electronic content, VPATs are not typically used for accounting the accessibility of a website. This documentation is best left to provider certification or a conformance statement.

However, an ACR for a website or web pages may be warranted if the website is part of the scope for the product or service. For example, if the product refers back to the website for instructions on how to use the product or for use of the product.

Examples of ACRs

Apple’s ACR page contains literally dozens of ACRs (they use the informal but widely used term of VPAT on their page).

Conclusion

You now have an excellent feel for the ACR creation process and the ACRs practical value. From starting with a blank VPAT template to evaluating the final report offered by a vendor, we have covered all of the essentials.

If you need help with audit, remediation, consultation, or ACR creation services, Accessible.org offers all of the digital accessibility services you need for accessibility and documentation. Contact us to inquire about your project.

VPAT Resources

For more information on VPATs and ACRs, we highly recommend the following resources which we used in the creation of this comprehensive guide.

• Information Technology Industry Council (ITIC) current VPAT editions and information
• VPAT training modules on YouTube
• Section 508 ACR/VPAT FAQ

Accessibility Training

Accessibility training is paramount for all digital teams. We can help your team learn WCAG 2.1 AA and WCAG 2.2 AA. Learn more about our live workshops and on-demand training programs.