From VPAT to ACR: The Complete Product Accessibility Documentation Guide

VPATs and ACRs may seem complex and overly technical, but in this 15 minute guide 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.

Overview

What Are VPATs and ACRs?

• VPAT: A Voluntary Product Accessibility Template is used to document how accessible a product is according to accessibility standards.
• ACR: An Accessibility Conformance Report is the resulting documentation after a VPAT is filled in. The ACR details the product’s accessibility features and conformance with standards.

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. This helps buyers, especially federal agencies, determine the accessibility of information technology products and services.

Key Components of VPATs

• Product Information: Name, version, date, and contact details.
• Standards and Guidelines: Specific accessibility standards such as WCAG 2.1 or Section 508.
• Conformance Levels: Categories indicating how well the product meets each criterion (Supports, Partially Supports, Does Not Support, Not Applicable).
• Remarks and Explanations: Detailed explanations providing context and additional information about the conformance levels.

Creating 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. Ensure accurate contact details for the person responsible for preparing the VPAT.
2. Choose Relevant Standards: Identify the accessibility standards your product needs to comply with. Common standards include WCAG 2.1 and Section 508.
3. Conduct an Accessibility Audit: Perform a thorough accessibility audit of your product by:
   • Testing with assistive technologies like screen readers and keyboard navigation.
   • Checking for compliance with WCAG 2.1 success criteria.
   • Identifying any accessibility issues that need remediation.
4. Document Conformance Levels: For each criterion 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.
6. Review and Validate: Review the completed VPAT for accuracy and completeness. Validate findings through additional testing and feedback from users, especially those with disabilities.

Practical Example of a VPAT Entry

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.

Preparing to Write the Accessibility Conformance Report (ACR)

This section covers:

• 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, the ACR should be authored right before the product release to ensure it provides the most relevant and accurate information about the product.

Who Should Write the ACR

The ACR should be written by individuals involved in product development who have access to accessibility testing results and a thorough understanding of accessibility. The ACR is a technical document, not a marketing document, and must be fact-based.

Sections of the ACR

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 Requirements

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

• Product Information: Name, version number, date of completion, product description, and 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

Standards Included

The ACR should specify the applicable standards and guidelines, such as WCAG 2.x, Section 508, and EN 301 549. Optional sections may include branding headers, change dates, additional notes, evaluation methods, remarks and explanations, and a legal disclaimer.

Answering Technical Criteria

Technical Criteria Tables

The ACR should include tables for WCAG, Section 508, and EN 301 549 criteria. Each criterion should 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.

Remarks and Explanations

Include detailed information about the testing performed, dependencies such as OS and browsers, methods for finding more accessibility information, and known workarounds for accessibility issues.

Understanding WCAG and Its Application

In this section, we’ll cover:

• The basics of WCAG, including its development and purpose.
• Overview of WCAG criteria and their organization.
• How WCAG applies to various products, including hardware, software, documentation, and support services.

What Is WCAG?

Definition and Development

WCAG stands for the Web Content Accessibility Guidelines. It is produced by the World Wide Web Consortium (W3C). The guidelines are developed by a consortium of members well-versed in accessibility, including people with disabilities, accessibility consultants, and industry members like companies that also develop the VPAT.

Purpose and Application

WCAG is a global standard used in policies and regulations as technical requirements for anything displayed on a screen, from web and non-web user interfaces and content to electronic documentation.

WCAG Versions

There are several versions of WCAG:

• WCAG 1.0: Released in 1999.
• WCAG 2.0: Released in 2008.
• WCAG 2.1: The latest version, completed in June 2018. Most regulations worldwide use WCAG 2.0 or 2.1. WCAG 2.1 builds on WCAG 2.0, adding requirements for mobile and touchscreen devices and addressing the needs of people with low vision and cognitive and learning disabilities.

WCAG Levels

WCAG criteria are divided into three levels:

• Level A: Basic web accessibility features.
• Level AA: Deals with the biggest and most common barriers for disabled users.
• Level AAA: The highest and most complex level of web accessibility. When regulations require compliance with WCAG Level AA, it means that the product must meet both Level A and Level AA requirements.

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

WCAG is applied to non-web technologies through standards and regulations such as:

• U.S. Section 508: Applies WCAG 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 criteria to various technologies with some exceptions and replacements for specific criteria.

WCAG Exceptions in U.S. Section 508 Non-Web

For non-web documents and software, U.S. Section 508 does not require conformance to certain WCAG criteria such as:

• 2.1.4 Bypass Blocks
• 2.4.5 Multiple Ways
• 3.2.3 Consistent Navigation
• 3.2.4 Consistent Identification

Support Services

Support services must also be accessible. For example:

• U.S. Section 508: Requires ICT support services to accommodate the communication needs of individuals with disabilities.
• EN 301 549: Requires support services documentation to be available in accessible formats.

WCAG 2.x Report Section of VPAT

The VPAT includes sections for reporting WCAG conformance:

• Levels A and AA: Each criterion has a conformance level and remarks/explanations section.
• Level AAA: Optional, as no regulations currently require meeting Level AAA criteria.

Understanding Section 508 VPAT and ACR

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 EN 301 549 VPAT and ACR

In this section, we’ll cover:

• Understanding the EN 301 549 criteria.
• Learning how to apply these criteria to various technologies.
• Identifying the sections of the VPAT that cover EN 301 549 criteria.

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)?

In this section, we will cover:

• The elements that make a good ACR.
• Examples of well-crafted and poorly constructed ACRs.

What Makes a Good ACR?

Truthful Statements

A good ACR provides accurate and truthful statements about the product’s current accessibility status. It is not a projection of future improvements or a wish list but a factual report of the product’s present state.

Legal Considerations

ACRs can become legal documents if included in bids or contracts. Therefore, it is crucial that they are accurate and reliable as they may be introduced in court during disputes.

Management Review

Once an ACR is written and reviewed for accuracy, it should be reviewed by the management responsible for the product, especially for sections indicating “Partially Supports” or “Does Not Support.”

Minimum/Required Sections of an ACR

An ACR should include the following minimum sections:

• Basic Product Information: Product name, version number, completion date, product description, contact information, and evaluation methods.
• Standards and Guidelines: Indicate the accessibility standards and guidelines the product was evaluated against.
• Definition of Terms
• Tables: WCAG 2.x (2.0 or 2.1), Section 508, and EN 301549.

Evaluation Methods Used

Evaluation methods can vary but should include:

• General Product Knowledge: Reference to similar products evaluated.
• Assistive Technologies Used: Screen readers, switches, keyboards, etc.
• Published vs. Proprietary Test Methods
• Manual audits including keyboard and screen reader testing
• Testing by Individuals with Disabilities

Application Standards and Guidelines Tables

At the top of the ACR, indicate the standards and guidelines being tested, including:

• WCAG 2.0 and 2.1: Each with levels A, AA, and AAA.
• Section 508
• EN 301549

Conformance Levels

There are five conformance levels:

• Supports
• Partially Supports
• Does Not Support
• Not Applicable
• Not Evaluated

Remarks – Best Practices

Remarks should:

• Explain Non-Support: Detail what doesn’t work, its impact, and any accessible alternatives.
• Include Bug Reporting: Provide bug IDs and any known workarounds.
• Detail Testing Approach: Specify operating systems, frameworks, browsers, etc.

Bug Reporting – Best Practice

Including workarounds in bug reporting is essential. For instance, if a navigation issue exists, provide a workaround and bug ID for reference.

Additional Sections

Additional sections can include:

• Branding Header
• Report Changes
• Notes
• Legal Disclaimer

Tips for Making the File Shorter

To make the ACR file shorter:

• Remove Instruction Sections: Instructions for completing the ACR should be deleted.
• Consolidate Notes Sections: Either use the notes section at the top or within chapters, not both.
• Use Applicable Reports: Choose between the WCAG, 508, EN 301549, or International editions based on requirements.

Combining WCAG Tables

Combining tables for WCAG levels A and AA can make the ACR easier to read by maintaining consecutive numbering and reducing redundancy.

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.

Handling the Completed Accessibility Conformance Report (ACR)

Now we will discuss:

• Understanding the steps to take after completing the ACR.
• Learning about upcoming changes to the VPAT by ITI.

ACR Format

While ITI provides the VPAT in a Word document format, you are not restricted to this format for your final ACR. It can be published in HTML, Microsoft Word, or PDF formats, depending on how your company typically handles such reports.

Key Considerations

• Accessibility of the Final Document: Ensure that the final ACR is accessible. It is counterproductive to create an accessibility report that is not itself accessible.
• Customization: If your company customizes the ITI template, make sure the custom template is accessible. This includes adhering to style guides, appropriately tagging images and tables, and following accessibility guidelines in all examples.
• Testing: Always test the final ACR to ensure accessibility.

Publishing Your ACR

Once the ACR is accessible, decide how to publish it:

• Website: Make it viewable or downloadable from your website.
• Email Requests: Allow customers to request a copy via email.
• Customer Support or Sales Team: Provide the ACR through customer support or sales channels. Ensure the method you choose is consistent and accessible.

Upcoming Changes to the VPAT

ITI aims to minimize changes to the VPAT, but updates are sometimes necessary:

• WCAG 2.2: Expected later this year (2021), requiring an update to the VPAT.
• EN 301 549: Regular updates necessitate corresponding VPAT updates.
• Other International Standards: ITI monitors for new standards and may update the VPAT accordingly.

VPAT Versions

Different versions of the VPAT are available on the ITI website. Each version includes a change file detailing updates and changes:

• Initial Version (2.0): Included all standards in one file.
• Version 2.2 and Later: Separated into four different versions (WCAG, 508, EN 301 549, and International). It is essential to determine which version to use and understand the differences between them. Staying updated with the latest version is recommended, but you may need to explain to customers why a particular version is appropriate.

Summary

In summary, once your ACR is complete:

• Ensure it is accessible.
• Choose an appropriate publication method.
• Stay informed about upcoming changes to the VPAT.
• Understand the different VPAT versions and their applicability.

Guide for ACR Readers and Evaluators

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: Determine the Standard Needed

Identify the standard required for the ACR:

• WCAG (Web Content Accessibility Guidelines): Often referred to as WCAG, WoAG, or spelled out as W-C-A-G. It is measured by both version (e.g., 2.0, 2.1) and level (A, AA, AAA).
• Section 508: U.S. federal standard.
• EN 301 549: European standard.

Step 2: Verify the Correct VPAT Template Used

Ensure that the appropriate VPAT template was used:

• WCAG Only: Contains only WCAG criteria.
• 508 Version: Contains Section 508 and WCAG 2.0 AA criteria.
• EU Version: Contains EN 301 549 criteria.
• International Version: Contains all the above criteria.

Step 3: Confirm the Product Version

Check the product version included in the ACR. Ensure the ACR corresponds to the current or relevant version of the product. If necessary, request an updated ACR for newer product versions or significant updates.

Step 4: Review Testing Performed

Examine the “Evaluation Methods Used” section in the ACR to understand the testing conducted:

• 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 actual users with disabilities.
• Kinds of Testing Performed: Manual, automated, tool-assisted, visual inspection, code inspection, etc.

Step 5: Assess the Types of Testing

Understand the different types of testing performed:

• Automated scans: Software is very limited in what accessibility issues it can flag and scan results are never conclusive – they must always be manually reviewed.
• Manual Evaluation: Essential for any valid assessment and ultimately what all findings must rely upon, must include keyboard testing and assistive technology testing.
• Assistive Technologies Used: Screen readers, magnifiers, voice recognition, switch devices, etc.

Step 6: Ensure All Necessary ACRs Are Included

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 7: Identify the Needed Criteria

Know the specific criteria relevant to your needs and the needs of your department:

• Functional Needs Review: Map WCAG to functional performance criteria to quickly check guidelines for specific disabilities.
• Relevance: Focus on the most relevant criteria for your users.

Step 8: Read the Success Criteria Tables

Review the success criteria tables:

• Conformance Levels: Supports, Partially Supports, Does Not Support, Not Applicable.
• Remarks and Explanations: Provide detailed information on any issues, their impact, and any workarounds.

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. Optimally, the VPAT is filled out by a digital accessibility company or otherwise qualified expert.

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 product scope. 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.