Procure accessible technology

• 3 minutes to read
• Last updated February 11, 2016

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.

Procure accessible IT

Considering accessibility in procurement involves the following steps:

1. Vendors must be asked to provide information about the accessibility of their products.
2. The information provided by vendors must be valid, measured using a method that is reliable and objective.
3. 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

The following are 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 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 web-based, run its pages through an online accessibility checker such as AMP, the University’s free web accessibility testing tool.
• Test the product with assistive technologies. If possible, involve actual users with disabilities in the product testing.

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. See the Get help with accessibility section for additional information.