6 minutes to read | Last updated January 6, 2021
In order to ensure accessibility of IT products used at the University of Wisconsin-Madison, those responsible for making decisions about which 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
- Vendors must be asked to provide information about the accessibility of their products.
- The information provided by vendors must be valid, measured using a method that is reliable and objective.
- Those making procurement decision must be able to objectively evaluate the accessibility of products, and to scrutinize the information provided by vendors.
Requesting accessibility information from vendors
Examples of accessibility language that could be used in requests for proposals (RFP’s) and purchasing contracts:
- Samples of Procurement Language
This page on accessibility policy from the National Center on Disability and Access to Education includes sample accessibility language for requests for proposals, purchasing contracts of specific products, and purchasing procedures used for general purchasing. - University of California Procurement and Product Accessibility
This page describes UC requirements, and includes a link to sample text for inclusion in RFP’s. - California State University Accessible Electronic and Information Technology Procurement
As part of its system-wide Accessible Technology Initiative, CSU provides procedures, checklists, and other resources to support vendors and institutions in meeting accessibility requirements in procurement. - MIT Web and software Accessibility Policies and Guidelines
Most notable among MIT’s accessibility resources are checklists to assist in evaluating accessibility when purchasing web based products or software.
In the second example, UC has followed the lead of the federal government and is requiring that vendors provide supporting documentation of their products’ compliance with Section 508 of the Rehabilitation Act. Since many vendors who sell products to higher education also sell products to the federal government, these vendors may already have a mechanism for reporting on their products’ compliance with Section 508 standards.
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 in to 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
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.
Evaluating product accessibility through testing
Vendors should be engaged in discussion about accessibility of their products as described in the preceding sections, but they should not be the only source for this information. Products should be tested for accessibility, using methods such as the following:
- Check the product with keyboard; not a mouse. Can you access all features? Can you operate all controls?
- If the product is a web-based application, run its pages through an online accessibility checker. See the Accessibility Checker section below for a recommended list of tools.
- Test the product with assistive technologies. If possible, involve actual users with disabilities in the product testing.
Request an accessibility evaluation
If you are in the process of considering a major IT purchase (i.e., one that will impact large numbers of UW students, faculty, or staff) the Division of Information Technology (DoIT) might be able to assist with product testing.
Accessibility Checkers for web applications
This is an accordion element with a series of buttons that open and close related content panels.
WAVE Web Accessibility Tool
Axe: The Accessibility Engine for Developers
Accessibility testing for local software
Software testing methods for accessibility require nuance based on the type of software being procured. For advice and assistance in how best to test offline or local software, contact the Center for User Experience.
Policies and Guidelines
Credit: Much of the content in this and other guides in this series was provided by the University of Washington’s terrific Accessible Technology website.