Accessibility is a critical consideration in higher education, and many instructors rely on documentation like Accessibility Conformance Reports (ACRs) or Voluntary Product Accessibility Templates (VPATs)  to evaluate the accessibility of course materials and platforms. While these documents are essential tools, they can be challenging to interpret, especially for those unfamiliar with accessibility standards.

In this blog post, we’ll break down how to read and evaluate an ACR or VPAT, explain the differences between the two, and offer guidance on how to use these documents effectively to assess the accessibility of educational resources.

What Are ACRs and VPATs?

Both ACRs and VPATs are documents designed to demonstrate how a product or platform adheres to accessibility standards, such as the Web Content Accessibility Guidelines (WCAG) or Section 508 of the Rehabilitation Act.

At McGraw Hill, we provide ACRs for our platforms and tools, and we also partner with a third party to complete them—ensuring transparency and reliability in our accessibility claims.

How to Read an ACR

ACRs are structured into sections that correspond to specific accessibility standards. Here’s a breakdown of what you’ll find:

1. Notes on Testing

All ACRs include information about how the product was tested for accessibility.

What to Look For:

  • Whether testing was conducted by a third-party accessibility expert or internally by the content or product provider.
  • The scope of testing: what was included, what was left out (if anything). It’s important to note whether the testing was fully comprehensive of all content.
  • Testing methods used (e.g., automated accessibility testing tools, manual accessibility testing, and native user testing).

Interpretation:

  • Testing and reporting by a third-party adds credibility to the report.  (Think of it this way: is it as credible if your student grades their own exam as it is if you grade it? That’s why we partner with a third party.)
  • If testing was limited to automated accessibility testing tools, consult with the content provider and require them to provide information about manual accessibility testing and native user testing.

2. Summary Table

This section provides an overview of the product’s compliance with major accessibility guidelines, such as WCAG 2.1 or Section 508.

What to Look For:

  • Supports: Indicates the product meets the criteria without exceptions.[FM7]
  • Partially Supports: Some aspects of the criteria are met, but there are exceptions.
  • Does Not Support: The product does not meet the criteria.
  • Not Applicable: The criteria do not apply to the product’s functionality.

Interpretation:

  • “Supports” is ideal, but “Partially Supports” is not uncommon and doesn’t mean the product is unusable. Review the details in subsequent sections to understand the scope of limitations.

3. Detailed Criteria Table

This section lists specific accessibility criteria and provides detailed responses for each.

What to Look For:

  • Criteria: The specific accessibility standard being evaluated (e.g., WCAG 2.1 Success Criterion 1.1.1: Non-text Content).
  • Conformance Level: The product’s level of compliance against the success criterion (e.g., Supports, Partially Supports).
  • Remarks and Explanations: Additional context explaining how the product meets or fails to meet the success criteria.

Interpretation:

  • Pay close attention to the “Remarks and Explanations” column. A “Partially Supports” response may indicate minor issues that do not block users from accessing the product, while “Does Not Support” indicates there are impacts to the user’s experience that may prevent them from using the product.
  • Look for explanations that clarify whether the issue is technical (e.g., missing alt text) or contextual (e.g., a feature that isn’t relevant to the product’s purpose).

4. Remarks and Explanations

This section outlines known accessibility gaps or areas where the product does not fully meet success criteria.

What to Look For:

  • Specific limitations that may affect access for individuals with disabilities.
  • An explanation of these limitations and their impact.

Interpretation:

Using ACRs Effectively

Having an ACR does not imply "100% conformance". It also does not imply "100% accessibility" as accessibility is combination of conformance and usability. Here’s how to use them effectively:

  1. Understand the Context: Accessibility is about more than technical compliance—it’s about usability. A product with some conformance violations may still be highly usable and effective for your learners.
  2. Identify Red Flags: Look for “Does Not Support” conformance levels. These may indicate significant barriers for users with disabilities.
  3. Evaluate Minor Limitations: “Partially Supports” responses indicate issues where additional paths to access are available. Review the provided remarks and explanations to determine whether the limitations are acceptable for your use case.
  4. Leverage Companion Documents: Some vendors, including McGraw Hill, provide companion documents that explain how accessibility features are implemented and offer guidance on using the product effectively. These documents can fill in gaps and provide practical insights as well as providing a roadmap for ongoing remediation.
  5. Conduct Additional Reviews: Use the ACR or VPAT as a starting point but consider conducting manual reviews or user testing of the product to ensure the product meets the needs of your learners and reflects the conformance reflected in the ACR (always validate the accuracy of an ACR before signing a contract).

ACRs are valuable tools for evaluating the conformance of educational platforms and resources, but they require careful interpretation. By understanding the structure of these documents and focusing on the context behind the responses, educators can make informed decisions about the accessibility of their course materials.

At McGraw Hill, we are committed to transparency and accessibility, providing third-party ACRs for our platforms and tools. By combining these reports with manual reviews and native user feedback, we can work together to create inclusive learning environments that meet the needs of all students.