Last updated April 28, 2021
In order to ensure accessibility of digital and information technology used at the University of Wisconsin–Madison, those responsible for making decisions about which vendor products to procure must consider accessibility early and throughout the process as one of the criteria for acquisition. This is especially critical for enterprise-level systems or technologies that affect a large number of students, faculty, and/or staff.
For free digital accessibility assistance, consulting, or training go to the Get help with accessibility guide.
Steps in the process
When creating your Request For Proposal (RFP)
While you are creating your RFP and purchasing contract language, include the following items for accessibility:
- Include accessibility language in your RFP and purchasing contracts.
- In your RFP, ask vendors to provide information about the accessibility of their products.
During the RFP evaluation period
While evaluating the products from the vendors who responded to your RFP, include the following subject matter expert review:
- During the final round of evaluations or when the RFP team has narrowed the selection to 2-3 finalists, allow an accessibility subject matter expert to evaluate the product(s) that the RFP team is interested in purchasing.
- The accessibility subject matter expert provides the RFP team with an accessibility evaluation report which includes the accessibility status of the product and initial recommendations for accommodation and communication planning if the product was purchased.
Accessibility Language for IT RFPs and Purchasing Contracts
The language below is used to incorporate accessibility into RFP Requirements. For access to the formal language which includes tailored Rating Guidance, please submit an accessibility evaluation request and add an accessibility subject matter expert to your RFP evaluation process.
(Ratings of “excellent,” “good,” “fair,” and “unsatisfactory” will be provided with associated guidance details to support the accessibility subject matter expert in providing you with evaluation results and recommendations.)
|The University of Wisconsin–Madison is committed to ensuring that our digital environment is accessible and free from barriers for all members of the campus community. For digital products or services, Contractor shall comply with the Americans with Disabilities Act (ADA) by supporting assistive software or devices such as large print interfaces, text-to-speech output, voice-activated input, screen readers, refreshable braille displays, and alternate keyboard or pointer interfaces, in a manner consistent with the Web Accessibility Initiative Web Content Accessibility Guidelines, version 2.1, at conformance level AA (“WCAG 2.1, AA”).”
|Vendor is able to provide a demo environment for the university to accessibility evaluate. The vendor describes a user-centered accessible design, development, and quality assurance process that is baked into the standard practices for all product and component development. The vendor provides an accurate VPAT with accessibility barriers listed preferably in a way that is public and finable to end-users to show transparency and good faith. The vendor provides at least a projected roadmap of when accessibility barriers will be fixed. The vendor has an in-house team of skilled inclusive design and accessibility professionals who monitor and improve accessibility, with a knowledgeable point person we can interface with on elevating barrier reports.
|Do your products and/or services conform to the W3C Web Content Accessibility Guidelines, version 2.1 (“WCAG 2.1”) at the conformance levels A and AA, and Section 508? Has a VPAT or ACR been created or updated for the product and version under consideration within the past year? Please demonstrate conformance by filling out VPAT 2.4 Rev 508 (March 2022) and VPAT 2.4 Rev WCAG (March 2022). Has a third-party accessibility expert conducted an accessibility audit of the most recent version of your product?
|All functionality is accessible to screen readers, keyboard navigation, magnification reflows smoothly from 200% to 400% magnification, and passes automated testing with no errors.
|Has the product been tested with assistive technologies (AT)? If so, which AT were used? Who did the testing? What was the testing methodology? What were the results? The Center for User Experience will request that the vendor provide a demo instance for the Center to accessibility test during the evaluation period of the RFP process. The Center evaluates vendor products for magnification, keyboard, color contrast, and screen reader accessibility. Can all functions of the application or service be performed using only the keyboard, using a screen reader, magnifying up to 400%? Does your product rely on activating a special “accessibility mode,” a “lite version,” or accessing an alternate interface for accessibility purposes? If so, does this alternative version have full feature parity with the main version? Do you have documentation to support users with disabilities in utilizing the accessibility of your product? Is your product documentation accessible?
|Mac & PC as well as mobile testing with screen readers, keyboard navigation testing, reflow with magnification testing, and automated testing.
|How is accessibility built into your quality assurance workflow? Do you have a documented and implemented process for reporting and tracking accessibility issues? Do you expect your staff to maintain a current skill set in IT accessibility? Do you have documented processes and procedures for implementing accessibility into your development lifecycle? If you roll out upgrades of the product, how do you assure that upgrades will not break accessibility?
|Accessibility is baked into conceptualization, design, development, QA, release messaging, and post-release testing/feedback.
|Do you have a documented and implemented process for verifying accessibility conformance? Have you adopted a technical or legal accessibility standard of conformance for the product in question? Are there known accessibility issues with your products or tools? If so, what are they? What are the workarounds for users of assistive technology? What is the plan to address these issues? How do you communicate those to users? Can you provide a current, detailed accessibility roadmap with delivery timelines?
|Vendor is able to provide a roadmap of known accessibility barriers and schedule of fixes. Those barriers provided have accommodations or workarounds that are clearly and transparently messaged to users in a findable way.
|How should accessibility barriers be communicated to you and how does your company respond to such issues? Please provide the name, title, and contact information for the most appropriate accessibility contact for the product under consideration.
|Vendor has a large accessibility team that is heavily engaged in the company’s strategic involvement all levels including customer user experience feedback and communication. Barriers identified can be surfaced to this group and escalated easily with a transparent means to identify progress on reported tickets.
Below is the accessibility contract language the Center provides for inclusion into RFP signed contracts. To get access to the formal copy and to add an accessibility subject matter expert to your RFP evaluation process or post-procurement planning, please submit an Accessibility Evaluation Request.
“For all products or services, the Vendor shall comply with the Americans with Disabilities Act (ADA) in a manner consistent with the W3C Web Content Accessibility Guidelines (WCAG), version 2.1 (“WCAG 2.1”), at conformance levels A and AA. If the Product does not fully conform to WCAG 2.1 A and AA, the Vendor shall inform the University of non-conformance prior to the execution of this Agreement and shall provide a plan and timeline to achieve conformance. If during the Term of this Agreement, the Vendor fails to maintain compliance with WCAG 2.1 A and AA, or the University identifies an Accessibility Barrier in the Product that renders the Product inaccessible or unusable to people with disabilities, the University shall notify the Vendor of non-compliance. If conformance is not reached within 30 days of the Vendor receiving the notification of non-compliance (“Notice”), the Vendor and the University shall meet and mutually agree upon an appropriate timeline for resolution of the Accessibility Barrier(s). Should Vendor:(i) fail to acknowledge receipt of the notice within 30 days of receipt of the Notice, or(ii) fail to materially resolve the Accessibility Barrier(s) within the agreed-upon timeline, Vendor agrees to indemnify and hold harmless University from any claims arising out of its failure to comply with the aforesaid requirements. Failure to comply with these requirements shall constitute a material breach and may be grounds for termination of this Agreement by the University.”
Requesting Accessibility Information From Vendors
When discussing accessibility with vendors, request specific information about accessibility of their product, such as the following:
- Is your product accessible without a mouse? (ask them to demonstrate)
- Has the product been tested with assistive technologies (AT)? If so, which AT products were tested? Who did the testing? What was their testing methodology? What were the results?
- How is accessibility built into your quality assurance workflow? If you roll out upgrades after we purchase the product, how can you assure us the upgrades will not break accessibility?
Evaluating product accessibility with a VPAT
The Voluntary Product Accessibility Template (VPAT) is a standard form developed to assist federal agencies in fulfilling their Section 508 requirements. Therefore, one way that vendors may be asked to report on the accessibility of their products is to submit a completed VPAT. This is the approach taken by the University of California in the example in the preceding section.
There are limitations to the VPAT since it is a self-report completed by the vendor. Some vendors do not have adequate technical expertise to accurately assess accessibility. Others skillfully complete their VPATs in ways that trivialize the significance of accessibility shortcomings. Also, Section 508 is itself a limiting standard, purposefully developed to be the minimum standard by which federal agencies are to be held legally accountable. Products can technically meet Section 508 standards yet still present significant barriers in usability for people with disabilities. A VPAT will not catch these barriers.
Request an evaluation
The Center for User Experience Digital Accessibility Program provides accessibility evaluation services for vendor products during the RFP process and purchased vendor products to support UW–Madison in providing accessible user experiences to people with disabilities.
Campus technologies should be evaluated for accessibility to identify barriers for people with disabilities, support accommodation planning, and provide communications guidance. If you have procured a technology and realize an accessibility evaluation was never completed, request an evaluation today.
Learn more about working with an Accessibility Subject Matter Expert.