Language for RFPs, Contracts and SOWs

This page contains recommended accessibility language for inclusion in Requests for Proposal (RFP) and vendor contracts. The language applies to any software project with a user interface, including content sites such as Yale.edu, complex web applications, and projects involving the creation or acquisition of electronic documents.

Language to include in RFPs

Please confirm in your proposal that your product/service conforms to the guidelines for accessibility as set forth in Web Content Accessibility Guidelines (WCAG) 2.1 (minimum Level AA conformance), or more recent version, and describe how this compliance has been verified. In addition, if applicable, provide an Accessibility Conformance Report, using the latest version of the Voluntary Product Accessibility Template (VPAT®) published by the Information Technology Industry Council, documenting compliance with the WCAG guidelines. The document should include a written description of the compatibility of the product/service with commonly used assistive technology products (e.g., JAWS, NVDA, ZoomText, MAGic, Dragon NaturallySpeaking) and a description of the process used to evaluate such compatibility.

Detailed RFP Requirements

This RFP Requirements document includes more specific requirements to consider including in your RFP/RFI. Requiring responses to these requirements will help you better assess a vendor’s capabilities.

Include accessibility requirements early in vendor discussions to promote accessible, compliant products.

Download Accessible Digital Purchasing Checklist

Accessibility Addendum

The Accessibility Addendum should be added as an addendum to any contract for the acquisition or development of websites, web applications, software with a user interface, or electronic documents.

accessibility icon

Statements of Work

Although Yale’s Accessibility Addendum outlines minimum requirements, it is helpful to include some of the same information in the Statement of Work, to help ensure the requirements are clear. The statement of work is also an opportunity to provide more specific recommendations that might be helpful to clarify with vendors. Refer to the accordion on the right for guidance on what to include at each project phase.

Designs will include accessibility recommendations to guide developers in the build phase (for example, ARIA landmarks, heading hierarchy, controls to start or stop motion on a page, expected keyboard interactions, screen reader announcements, and colors that meet contrast requirements). For more information, see Yale’s visual design article.

Designs will include a link to a statement in the footer of the site communicating the University’s commitment to accessibility, preferably labeled “Accessibility at Yale”.

Comprehensive accessibility testing will be conducted ensuring full compliance with Web Content Accessibility Guidelines (“WCAG”) 2.1 Level AA. Testing to include:

  • Automated review passing WAVE(link is external) and Siteimprove Accessibility Checker(link is external) scans with no errors (Yale has an enterprise instance of Siteimprove that vendors are welcome to use)
  • Manual review conducted continuously throughout the development process, utilizing a complete WCAG 2.1 checklist for all applicable AA success criteria
  • Manual review to include testing with assistive technology, including but not limited to keyboard-only testing and screen reader testing (preferably using NVDA/Firefox, but potentially also including JAWS/Chrome and VoiceOver/Safari)

Deliverables will include a statement or link to a statement in the footer of the site communicating the University’s commitment to accessibility, such as the Accessibility at Yale page found on the Usability & Web Accessibility website.

Deliverables to include completion of an Accessibility Conformance Report (utilizing a VPAT®(link is external)) at launch as final documentation of conformance to the WCAG 2.1 AA standard.