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.
Overview
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.
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 | (yes/no) | Describe how product addresses this requirement |
|---|---|---|---|
| 1 | Does the product conform to the WCAG 2.1 Level AA standard? | ||
| 2 | Can you 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 | Can your product be used using only a keyboard? In other words, are there any functions of the product that require use of a mouse to operate? When using a keyboard to operate the product, is there always a visual indication to know what control is being focused by the keyboard? | ||
| 5 | Is the product compatible with commonly used assistive technology products (e.g., JAWS, NVDA, VoiceOver, ZoomText, MAGic, Dragon Naturally Speaking)? Describe the process you use to evaluate such compatibility, including any manual testing that is done with assistive technology devices. | ||
| 6 | If your product does not fully conform with WCAG 2.1 AA, do you have a roadmap for achieving conformance? Does the roadmap include projected dates for achieving conformance? Please describe your timeline for achieving conformance. | ||
| 7 | Do you conduct regular QA testing and audits for accessibility conformance (utilizing automated and manual testing as applicable)? Please describe how you ensure compliance with WCAG 2.1 AA standards in your QA process. | ||
| 8 | Do you provide training to your developers/designers/BAs/QA analysts, or other roles as applicable, to understand accessibility requirements? | ||
| 9 | 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? Describe your process and timeline for addressing accessibility defects reported to you. | ||
| 10 | Are your online product documentation and support resources accessible (documents and websites conform to accessibility standards, such as WCAG 2.1 AA or PDF/UA)? |
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 https://usability.yale.edu/web-accessibility/accessibility-yale
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.