Purpose and Intended Audience
Students with sensory, physical, and learning disabilities are at risk of falling behind in educational progress when the learning materials provided in schools are not accessible to them. To ensure access to the general education curriculum for students with disabilities, state and local educational agencies can take specific actions when reviewing instructional material and adopting educational tech (edtech) products. This guide informs all state and local procurement teams on best practices for using Accessibility Conformance Reports (ACRs) to determine how accessible an edtech product or digital curriculum material is for students with disabilities.
A more basic introduction to the ACR, Understanding the Voluntary Product Accessibility Template (VPAT®) and ACRs, is available separately. And a broader resource, Including Accessibility in All Components of Procurement, describes a range of strategies to include accessibility when adopting edtech and digital educational materials.
Representatives from administration, general education, special education, and technology, as well as other staff engaged in instructional materials and edtech adoption, will find this information important to their roles and responsibilities.
How To Use This Resource
What follows will help you to better understand and leverage ACRs in edtech purchasing and use decisions by describing the structure of ACRs and providing guidance on how to interpret and vet one. The following sections also suggest ways to engage potential vendors, using ACRs as part of a broader conversation about accessibility support in third-party products. Use this as a reference as you integrate ACRs into formal and informal procurement processes to be better equipped to engage in accessibility.
Characteristics of a Strong ACR
We recommend approaches to vetting ACRs based on four characteristics. You need an ACR to be current, complete, accurate, and thorough.
- Current: An ACR isn’t helpful if the information in it is out of date. Emphasize the need for a current ACR in the initial request.
- Complete: Be sure all sections of an ACR are filled in, from the general information requested near the beginning (product/version, report date, contacts, notes, and evaluation methods) to the details found in the technical compliance table. Throughout the compliance table, it’s ideal if entries are under “Remarks and Explanations” for each row.
- Accurate: Vendors need to provide correct information throughout an ACR. A helpful way to check for accuracy is to ask the vendor questions about the information they provide.
- Thorough: Check for details throughout an ACR that provide enough information to feel comfortable comparing products to one another.
The Importance of an ACR’s Product and Vendor Information
Don’t skip the less technical details. Focus on the information vendors provide at the beginning of an ACR before diving into the technical compliance tables.
- Product Name/Version: If the product being purchased is version 3.1 and its ACR applies to version 2.6, this suggests these versions have significant differences since the primary version of the product (the number before the period) has changed. If the primary version numbers are different, request an updated ACR. For products without a version number, you may need to rely on their date. If an ACR is more than one year old, make the same request. A lot can change over the course of one year. If a vendor won’t provide an updated ACR, ask them to provide a list of everything that has changed from the ACR date, or from the version listed on the ACR, to the current version available.
- Report Date: Make sure an ACR has a report date within the last 12 months (cloud apps) and/or includes a version number closely matching the current version of the product.
- Contact Information: Ideally, this will be the contact information for an individual person designated over product accessibility. Contact information should include the individual’s role, such as accessibility specialist, web designer, or web developer. Some reports may provide a generic email address such as accessibility@company.com. Some vendors, however, will provide a sales contact here. When that happens, ask how any of your questions about accessibility will be passed along and who specifically they will go to. Set your expectations clearly for a turnaround of information and for follow‑ups during your ACR evaluation (and after the award).
- Notes: The instructions vendors use to complete the VPAT (the source template for ACRs) don’t require specific information in this section. However, it can be a helpful source of additional information. If the Notes section is empty, you may ask vendors to describe in the notes how they ensure accessibility is part of their internal processes and policies. This request goes above what’s required, but it is helpful to know. If a vendor states they have accessibility experts on multiple teams, an accessibility policy, and/or consistent testing for accessibility at regular intervals, they are more likely to maintain accessibility in future versions of a product. Ask vendors to provide any documented policies or roadmaps related to accessibility as evidence of their claims for their own accessibility.
- Evaluation Methods Used: Look for a combination of manual and automated testing, not just “general product knowledge” or automated scans. Vendors with more experience in accessibility are likely to provide the specific accessibility tools they use to test their product such as WAVE from WebAIM or other reputable tools. Vendors should also detail assistive technologies they test with, including screen readers, speech to text and voice control, and keyboard-only navigation and use. Indicating a third party performed technical evaluation and consultation is reassuring, and engaging a product with people who have disabilities indicates a more robust evaluation.
Deciphering Technical Conformance
It’s always important to decipher the technical details of ACRs. Vendors self‑report on each Web Content Accessibility Guideline (WCAG) requirement, or success criterion, in one of four status categories:
- “Supports”
- “Partially Supports”
- “Does Not Support”
- “Not Applicable”
Vendors should also include information under the ”Remarks and Explanations” section detailing each reported status.
- If “Supports” is marked, look for implementation details. These can be technical, which may require partnering with someone with a technical background in your organization to interpret the information. You may also want to reach out to the vendor with questions such as, “How are text alternatives provided? Can you show example code for image buttons and charts?”
- If “Partially Supports” is marked, look for information on where support fails (for example, in workflows or interactive components) and when fixes will be available. Ask for a vendor’s accessibility roadmap with dates for specific fixes.
- If “Does Not Support” is marked, look for the scope of impact and when the vendor will have a fix available. Ideally, the vendor will have an accessibility roadmap including this information.
Regardless of a product’s reported status, be prepared to ask questions to get more information. Some reports will provide enough detail while others may only provide a brief sentence or nothing at all. An accessibility expert can help interpret a report’s information and formulate clarifying questions to ask the vendor to fill any gaps. If your team is new to accessibility, put the burden on the vendor to explain what they are doing with accessibility in a way you can understand. Use the World Wide Web Consortium (W3C) WCAG 2.2 Quick Reference to keep your team informed and coordinated. (Meeting WCAG 2.1 AA satisfies ADA Title II. If this is your goal, use the Filter tab in the upper left of the webpage to select that standard set.)
Summary
This guide helps education agencies use ACRs to make better edtech decisions by embedding accessibility requirements from the start of procurement. It emphasizes that a strong ACR must be current, complete, accurate, and thorough, and that clear expectations should be set with vendors early and throughout the process. An available ACR does not guarantee a product meets accessibility requirements. Teams without deep technical expertise should focus on non-technical sections to identify gaps and vendor maturity. Ultimately, procurement teams should place responsibility on vendors to clearly explain and demonstrate how their products support accessibility.