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, 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.

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.

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

The following table 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.

Requirement # requirement/question Available? (yes/no) Describe how product addresses this requirement
1 Should have ability to conform to the WCAG 2.1 Level AA standard.    
2 Should provide an Accessibility Conformance Report (VPAT®), using version 2.x of the ITI VPAT template, detailing your product’s conformance with the WCAG standard. Please describe how the Voluntary Product Accessibility Template (VPAT) was prepared.    
3 Do you contract with an outside expert to help with accessibility auditing, training, and program development? If so, who do you utilize?    
4 Should describe compatibility of product with commonly used assistive technology products (e.g., JAWS, NVDA, VoiceOver, ZoomText, MAGic, Dragon Naturally Speaking) and a description of the process used to evaluate such compatibility.    
5 Should have a roadmap to achieving compliance if product is currently not WCAG 2.1 AA compliant.    
6 Do you conduct regular QA testing and audits for accessibility conformance (utilizing automated and manual testing as applicable)? Does testing include use of assistive technology (screen reader and keyboard-only testing at a minimum)? Please describe how you ensure compliance with WCAG 2.1 AA standards in your QA process.    
7 Should provide training to your developers/designers/BAs/QA analysts, or other roles as applicable, to understand accessibility requirements.    
8 Do you prioritize accessibility problems reported to you, and handle these as high priority bugs with the same level of priority as any equivalent loss of functionality for individuals without disabilities?    
9 Are your online product documentation and support resources accessible (documents and websites conform to accessibility standards)?    

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.

Design 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”.

Build Phase

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

Launch Phase

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.