This page provides resources about digital accessibility when working with content providers, which happens most frequently for electronic resource management. Sections are organized by the e-resource management lifecycle, which tends to be a cyclical process for most e-resources–especially the renewal process. Portions of the lifecycle used in this context include investigation, evaluation, acquisition, and review.
Investigate: Sample Questions to Ask Content Providers
Responses to the following questions can help reveal the depth and breadth of a content provider’s commitment to inclusive design and accessibility.
- What accessibility documentation is available for this product (for example, a VPAT, ACR, or accessibility information on the content provider’s website such as an accessibility statement)?
- Does the product rely on an accessibility mode or alternate interface for accessibility purposes?
- Can users perform all functions without a mouse?
- If the product supports video and/or audio, does it support captions, transcripts, and audio descriptions?
- What are common accessibility-related issues with the products?
- Can you provide an accessibility roadmap or a current plan for accessibility improvements with a timeline?
- Who is the designated accessibility contact and how are accessibility concerns addressed when they are submitted by customers or users of the product?
- Can you provide a product demonstration focused on accessibility?
Sources and Additional Resources on Questions to Ask Content Providers
- Digital Accessibility Services, Harvard University: Accessibility Questions for Vendors
- ADA Digital Accessibility Center, The Ohio State University: Purchasing Questions and Contract Language
- Office of Information Technology, State of Colorado: Vendor Accessibility Checklist
- Information Technology, University of Illinois Chicago: Accessibility Questions for Vendors
Investigate and Evaluation: Vetting Accessibility for Electronic Resources
Voluntary Disclosures
Content providers may disclose the accessibility status of their products proactively or by request through a variety of formats. Voluntary disclosure documentation provides helpful context for more in-depth research and conversations about a product’s accessibility prior to purchase or renewal.
Voluntary Disclosure Terminology
The following list includes common terminology used to describe voluntary disclosure of a product’s accessibility.
- VPAT (Voluntary Product Accessibility Template): “The ITI Voluntary Product Accessibility Template (ITI VPAT®) is a free template that translates accessibility requirements and standards (e.g., in Section 508 and other legal frameworks) into actionable testing criteria for products and services” (Information Technology Industry Council (ITI), VPAT).
- ACR (Accessibility Conformance Report): “Accessibility Conformance Reports are product-specific reports derived from a VPAT” (WebAIM, Making VPATs and ACRs More Effective in Procurement).
- The acronyms VPAT and ACR are sometimes used interchangeably to refer to a completed product accessibility template.
- Accessibility Statement: Accessibility statements on websites may include: “information about an organization’s commitment towards providing equal access to information;” the accessibility standard used (such as Web Content Accessibility Guidelines 2.1 AA) and links to standards or policies; contact information for questions and support; a mechanism for reporting an accessibility barrier; date of statement or subsequent updates (Section 508.gov, Developing a Website Accessibility Statement).
- Accessibility Roadmap: An accessibility roadmap outlines accessibility goals, includes remediation plans or changes needed to meet the accessibility goals, and provides a timeline for managing changes (Section 508.gov, Play 3: Develop a Section 508 Accessibility Roadmap).
Evaluating Voluntary Disclosure Documentation
Voluntary disclosures provide a starting point for a conversation about a product’s accessibility.
Questions to consider when evaluating documentation include:
- Does the product have its own specific report or documentation?
- How old is the documentation?
- Does the documentation include a methods section explaining how the product was evaluated and who evaluated the product?
- Does the documentation reflect current Web Content Accessibility (WCAG) standards and account for recent product updates?
- Does the documentation include details about whether and how the product meets the WCAG standards?
- Does the content provider clearly communicate plans with specific timelines for addressing accessibility concerns and known issues?
Sources and Additional Resources on Voluntary Disclosures
- Information Technology Industry Council (ITI): VPAT
- WebAIM (Web Accessibility in Mind): Making VPATs and ACRs More Effective in Procurement
- Section 508.gov, General Services Administration: Developing a Website Accessibility Statement
- Office of Management and Budget, The White House (December 21, 2023): M-24-08 Strengthening Digital Accessibility and the Management of Section 508 of the Rehabilitation Act, section III. A, bullet point 6
- Section 508.gov, General Services Administration: Play 3: Develop a Section 508 Accessibility Roadmap
- Rob Carr, Orbis Cascade Alliance Accessibility Speaker Series (February 17, 2026): Finding the Balance: Vetting Accessibility During Technology Purchasing and Use Decisions
- Kevin Corcoran and Rebecca McNulty, Northwest Higher Education Accessibility Technology Group webinars (February 17, 2026): Using AI to Evaluate VPATs
- Terrill Thompson and Lynn Magill, University of Washington Accessible Technology Webinar Series (June 12, 2024): Accessibility in Procurement, June 2024
Doing Your Own Tests
Evaluators can conduct functional accessibility testing to ensure people with disabilities can successfully complete tasks and workflows while using electronic resources. While there are many types of accessibility tests available, this guide provides primary guidance for automated tests and manual tests. Automated tests involve using tools to quickly identify common, repeatable issues while manual tests involve human tester(s) using assistive technologies (like screen readers or keyboard-only navigation) to evaluate whether electronic resources can actually work in practice. Combining both test methods ensures that efficiency is covered through automation while manual testing ensures true functional usability.
See Getting Started with Accessibility Testing section for additional guidance on automated or manual testing, as well as a list of resources for performing checks on internally-developed and external resources.
Selected Third-Party Tests
The following organizations have created publicly available accessibility evaluations for select content providers.
- The Library Accessibility Alliance (LAA), formally a multi-consortial organization, has funded third-party accessibility evaluations for select electronic resources
- Library E-Resource Accessibility Testing: UW Libraries perform in-house accessibility evaluations of library resources to create an Accessibility Conformance Report (ACR) using keyboard navigation testing and content providers’ Voluntary Product Accessibility Templates (VPATs). The testing is not as in-depth as the Library Accessibility Alliance (LAA) but the project does cross-check testing performed by the LAA.
Acquire: Legal Language
Ideally, your contract will include language specifying accessibility capabilities of a product, which is especially important as higher education institutions respond to the federal web content accessibility regulations: ADA Title II and Health & Human Services (HHS) Section 504, both of which selected the Web Content and Accessibility Guidelines (WCAG) version 2.1AA as the technical standard.
The Orbis Cascade Alliance includes accessibility in access and platform expectations for the agreements we facilitate, and we share that information with our community.
- Licensing Best Practices (PDF): This set of best practices provides member libraries with a framework of standardized language for their individual or consortial licensing needs. Please note that the model language is a starting point for negotiations, and the final language will change.
- Alliance Electronic Resource License agreements (Google Drive): This folder collects license agreements for each content provider, which includes the final language. The folders also include voluntary disclosures for accessibility (e.g., VPATs, ACRs, and/or accessibility roadmaps).
- Alliance ERP: ADA Title II Compliance Statement: This compliance statement outlines several aspects of content accessibility addressed by the Alliance Electronic Resources Program when they facilitate e-agreements on behalf of Alliance members for commercially-published electronic resources.
For other examples of legal language for accessibility requirements in licensing agreements, please see the Big Ten Academic Alliance (BTAA)’s standard accessibility license language and the Library Accessibility Alliance’s (LAA) page on library accessibility resources.
Review: Renewal Cycle
Most commercially published electronic resources renew on a one- or three-year renewal cycle. Acute accessibility issues should be addressed in a timely manner via the appropriate accessibility contact at the respective content provider. However, larger issues (e.g., unresolved technical issues, ambiguous roadmap benchmarks, etc.) may require a different approach.
If ongoing accessibility issues aren’t receiving adequate attention by the content provider or if technical changes don’t fully resolve identified accessibility issues, renewals can be made contingent on the resolution of these issues. For example, a renewal can be postponed (or ultimately cancelled) if part of the resource remains inaccessible without a clear fix and a reasonable timeline for implementing the fix isn’t provided.
It might also be necessary to update the license and other order documentation, either through an amendment to an existing document or even an entirely new license. Updated documentation can ensure that all parties have a shared expectation around necessary changes to improve accessibility. Documentation should clearly identify who ultimately has the responsibility for making any such changes, and have a detailed and realistic timeline for implementing those changes.
