Comprehensive Guide to ACR and VPAT

Accessibility Conformance Reports (ACR) and the Voluntary Product Accessibility Template (VPAT) documents serve as standardized tools for assessing and reporting the accessibility of digital products and services. In this article, we'll break down what an ACR and a VPAT are, how to create one, and explore the "Supports" levels used in these reports.

What is a VPAT?

The Voluntary Product Accessibility Template (VPAT) is a standardized document that assesses the extent to which a product or service conforms to accessibility standards, most commonly the Web Content Accessibility Guidelines (WCAG), Section 508 of the Rehabilitation Act (for U.S. government agencies), and the European EN 301 549 standard.

The VPAT helps organizations determine how accessible their product is and whether it complies with relevant legal requirements. It is especially vital for businesses looking to provide software, hardware, websites, and other digital products to governments or regulated industries that prioritize accessibility.

What is an ACR?

An Accessibility Conformance Report (ACR) is the finished document created from a VPAT. It provides a detailed view of a product’s accessibility compliance. An ACR essentially serves as a snapshot of the accessibility state of your product, helping potential buyers, developers, or internal teams understand what works, what doesn’t, and what needs improvement.

The ACR is often shared with clients or government agencies to show that the company is committed to making its product accessible.

Steps to Create a VPAT/ACR

Step 1: VPAT Template

Before filling out a VPAT, it’s essential to know which standards your product should conform to. VPAT templates are available for the following key standards:

WCAG 2.1 or 2.2 (AA or AAA) for web content.
Section 508 for U.S. government compliance.
EN 301 549 for European compliance.

Understanding the specific requirements of each of these standards will help guide you in completing the VPAT.

Step 2: Perform an Accessibility Audit

Conduct a thorough audit of your product or website. This includes automated testing (e.g., using tools that scan your website for common WCAG issues) and manual testing (e.g., with screen readers, keyboard navigation, and assistive technologies).

Document your findings for each section and component of the product. This detailed audit will serve as the foundation for completing the VPAT.

Step 3: Complete the VPAT

A VPAT is divided into different criteria based on the chosen standards.

For each criterion, you will need to provide:

A conformance level (using the "Supports" levels, which we'll cover below).
A description of how the product supports or does not support that criterion.
Any remarks or explanations for context or additional information.

Step 4: Use "Supports" Levels Correctly

The "Supports" levels are standard terms used to indicate how well a product meets each accessibility criterion. Here’s a breakdown of these levels:

Supports: The product fully meets the criterion without any exceptions. Use this if the feature or content is accessible to all users, including those with disabilities.
Partially Supports: The product meets the criterion in some areas but not entirely. For example, some content or features are accessible, while others may require more work.
Does Not Support: The product does not meet the criterion. Accessibility issues prevent users with disabilities from fully accessing the content or functionality.
Not Applicable: The criterion does not apply to the product. This could be because the product does not contain the functionality covered by the criterion (e.g., audio description for a website with no videos).

Step 5: Calculate the "Supports" Level

Calculating the "Supports" level is based on the findings of your audit and depends on how many accessibility barriers were discovered and their impact. Here's a simple method for evaluating:

Supports: No significant barriers were found during testing.
Partially Supports: Minor barriers exist that only affect some users or situations but do not block access entirely.
Does Not Support: Major barriers exist that prevent users from accessing core features or content.
Not Applicable: The feature or content is irrelevant to this specific criterion.

Step 6: Compile and Review the ACR

Once you've completed the VPAT, the final ACR should be reviewed to ensure accuracy. Ensure that the language is clear, the descriptions accurately reflect the test findings, and all major issues are documented with a clear plan for remediation where necessary.

Formula Approach for "Supports" Levels:

1. Supports:

Formula: If the criterion is met for at least 95% or more of the pages, components, or features.
Use Case: Minimal issues, and users with disabilities can navigate and use the content with no significant barriers.
Example: You’ve tested 100 pages, and only minor issues (e.g., non-impactful contrast differences) appear on 2 of them, and they do not block functionality for any users.

2. Partially Supports:

Formula: If the criterion is met for 51% to 94% of the pages or components, meaning some accessibility issues exist that impact users but do not block access entirely.
Use Case: Issues are present but are not universal or severe enough to completely prevent access. In this case, you should provide specific details about what works and what needs improvement in the remarks section.
Example: You’ve tested 100 pages, and 20 of them have missing or improperly labeled form fields that make it difficult, but not impossible, for screen reader users to complete tasks.

3. Does Not Support:

Formula: If the criterion is met for 50% or fewer of the pages or components, meaning significant accessibility issues are present that prevent access for many users.
Use Case: The product has major barriers, such as missing alternative text for images on more than half of the pages, or navigation elements that are not keyboard-accessible.
Example: You’ve tested 100 pages, and 55 of them have inaccessible navigation menus, making it difficult or impossible for users relying on keyboard navigation to move through the site.

4. Not Applicable:

Formula: Use this level if the criterion is irrelevant to the product or service being evaluated. For example, if your website has no multimedia content, audio description requirements would not apply.

5. Not Evaluated:

Formula: Use this level if the feature has not been tested yet or is outside the scope of the current evaluation.

Example Calculation Using the Formula

Let’s say you're evaluating the "Text Alternatives for Non-Text Content" (WCAG 2.1, Success Criterion 1.1.1) for a website with 100 pages. During testing, you find that:

30 pages have appropriate alternative text for all non-text elements.
40 pages have missing or insufficient alternative text for some images.
30 pages have no alternative text for any images.

To calculate the "Supports" level for this criterion:

30 pages meet the requirement fully (30%).
40 pages partially meet the requirement (40%).
30 pages do not meet the requirement (30%).

Since 70% of the pages have issues (either partial or complete), and only 30% fully support the criterion, this would likely result in a "Partially Supports" rating. The detailed notes should explain the specific problems (e.g., "30% of the pages lack any alternative text, while 40% have partial coverage").

General Guidelines for Assessing the "Supports" Level

Scope of Impact: Consider how widely the issue impacts users. If the problem appears in critical features or on many high-traffic pages, you may want to lean towards a more conservative rating (e.g., Partially Supports or Does Not Support).
Severity of Impact: Some issues, even if they only affect a few pages, may be critical (e.g., missing focus indicators, lack of keyboard access), and you may choose to rate the criterion more severely.
User Experience: Think about the overall user journey. If one major accessibility barrier on a few pages prevents users from completing key tasks, that could weigh heavily in the rating.

Key Considerations When Creating an ACR

Be transparent: Companies or organizations relying on your ACR need to trust its accuracy. Misrepresenting accessibility levels can lead to legal issues or reputational damage.
Update regularly: Accessibility is an ongoing process. Ensure that your ACR is up to date, especially when new features are added or remediations are implemented.
Consult experts: For thorough testing and compliance, consider hiring accessibility professionals who understand the standards in depth.

Conclusion

Creating a Voluntary Product Accessibility Template (VPAT) and an Accessibility Conformance Report (ACR) involves a thorough evaluation of a product’s compliance with accessibility standards such as the Web Content Accessibility Guidelines (WCAG), Section 508 of the Rehabilitation Act, and EN 301 549. The process typically starts with an in-depth audit to identify accessibility barriers across the product’s features. The VPAT serves as a standardized template to document how a product meets these guidelines, detailing areas where it complies fully, partially, or not at all. Once the VPAT is completed, an ACR is generated as the final report that reflects the accessibility conformance status of the product based on the VPAT findings. Both documents are essential tools for organizations to communicate their product’s accessibility to customers and to fulfill regulatory or procurement requirements.