Language for RFPs, Contracts and Statements of Work
Recommended language to include in Requests for Proposal and vendor contracts for software with a user interface, including websites, web applications, and mobile or desktop applications, as well as the acquisition or creation of electronic documents.
This page contains recommended language regarding accessibility for people with disabilities, appropriate for inclusion in Requests for Proposal (RFP) and vendor contracts. The language is appropriate for any software project with a user interface, including content sites like Yale.edu, or a highly complex web application. It is also appropriate for projects involving the creation or acquisition of electronic documents. Please see Working with Vendors for more information on how to make effective use of this language.
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.
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.
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. Below are some items to consider including depending on the phase of the project.
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 and Siteimprove Accessibility Checker 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 at https://usability.yale.edu/web-accessibility/accessibility-yale
Deliverables to include completion of an Accessibility Conformance Report (utilizing a VPAT®) at launch as final documentation of conformance to the WCAG 2.1 AA standard.