Skip to Main Content
MIT Libraries Staff Web

Accessibility Resources: Web Accessibility

Web Content Accessibility Guidelines (WCAG)

The benchmark for web accessibility is the Web Content Accessibility Guidelines, or WCAG. WCAG is published by the World Wide Web Consortium (W3C) and updated periodically. The current version is 2.2, and version 3.0 is in draft form.

WCAG provides three levels of compliance: A (lowest), AA, and AAA (highest). At minimum, all web content should meet WCAG AA. It should also meet as many AAA guidelines as possible.

The WCAG recommendation is expansive, so we suggest using automated tools to validate your content. See Making content accessible for tips and tools to improve content accessibility.

Title II and Title III of the Americans with Disabilities Act (ADA)

Titles II and III of the ADA regulate web accessibility for content available to the public. Title II applies to public institutions, and Title III to private institutions.

Changes to Title II, finalized in April 2024, will take effect on April 24, 2026. While they affect public institutions only, it’s useful to understand the changes, as vendors and systems providers will need to adhere to these standards.

The Title II changes will require all publicly available content to be WCAG 2.1 AA compliant. This includes the following content types:

  • Vendor content
  • Public content controlled by the institution (websites, archival content, instructional content, etc.)
  • Virtual services such as online chat, virtual reference, and digital ILL
  • Internal content and tools for staff with disabilities

Accessibility for Vended Systems and Content

To ensure that vendors understand it is a requirement, accessibility should be discussed early in vendor negotiations. If you’re not sure what questions to ask, MIT’s procurement office includes the following in web application RFPs:

  • Are user and author interfaces (where applicable) of your product compliant with WCAG 2.1 AA?
  • What internal processes do you employ for evaluating and remediating accessibility issues?  What assistive technology applications do you use?
  • Do you have a VPAT (Voluntary Product Accessibility Template) or other documentation detailing the accessibility of your product?  Please attach.
  • Please provide the name and contact information for the individual designated to address accessibility compliance at your company.
  • If your product is not fully accessible, please attach a roadmap with details on your plans to make your product fully accessible.
  • Are you willing to commit to cover the cost of remediating any necessary accessibility fixes after purchase, if the product does not meet accessibility standards?
  • What accessibility tools is your developer using to ensure your product is compliant?

The “IT Accessibility” section of the Higher Education Community Vendor Assessment Toolkit (HECVAT). The HECVAT is a questionnaire created by the Higher Education Information Security Council (HEISC) to help with risk assessment. While it is largely focused on security, the toolkit does provide some useful prompts to evaluate accessibility. Please note that when a DLC is making a purchase, they should connect with Strategic Sourcing.

Vendor claims about accessibility should be confirmed. The User Experience and Web Services (UXWS) team can consult on how best to achieve this. Beyond the Libraries, Disability and Access Services (DAS) provides accessibility reviews for websites and digital products. To have DAS review your website, please request UXWS services through Jira.

Accessibility for Locally Developed Applications

Our developer documentation includes information on how to prioritize accessibility for local software engineering projects.