Procuring Accessible IT

The University of Colorado Denver and Anschutz Medical Campus strives to ensure that IT products developed at, purchased by, or used at the university are accessible to all faculty, students, and staff, including those with disabilities. To reach this goal, those responsible for making decisions about which products to procure must consider accessibility as one of the criteria for acquisition. This is especially critical for enterprise-level systems and other technologies that affect a large number of students, faculty, and/or staff.

 

Campus Administrative Policy, Section B.3

Faculty and staff responsible for making decisions about which products, services and technologies to procure are responsible for making it accessible should strongly consider accessibility as one of the criteria for acquisition. This will ensure that products, services, and technologies developed at, purchased by, or used at the university are accessible to all faculty, students, and staff, including those with disabilities. This is especially critical for enterprise-level systems and other technologies that affect a large number of students, faculty, and/or staff.  APS 6011, section II.A.2 provides key principles to consider regarding digital accessibility.

In order to facilitate the procurement of accessible information technology, the following three steps should be considered for all products and services that fall within the scope of the above policy. 

Step 1: Solicit accessibility information

CU Denver and CU Anschutz bidders and vendors shall be required to demonstrate that information technology provided to the university conforms to or addresses each of the World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG) 2.0, Level AA success criteria wherever demonstrating such performance is practicable. Vendors may do so by providing any of the following:

  • an independent third party evaluation from an accessibility consultancy (the vendor's responsibility)
  • a Voluntary Product Accessibility Template (VPAT). If a VPAT is used, it must use the VPAT 2.0 template, which is based on WCAG 2.0 Level AA. The VPAT 2.0 template is available from the Information Technology Industry Council at  itic.org/policy/accessibility.

Step 2: Validate accessibility information received

Vendors should provide detailed information about the accessibility of their product or services using both methods listed in the preceding section. The first of these sources is the most likely of the two to be credible, providing it was completed by a credible accessibility consultancy. The second source of information can be informative, but there are limitations since they are self-reports completed by the vendors. Some vendors do not have adequate technical expertise to accurately assess their products’ accessibility. Others skillfully provide information that trivializes the significance of accessibility shortcomings. Therefore, vendors’ claims should be independently verified and not accepted at face value. The information they provide should provide a good starting point for a thorough discussion about accessibility of vendors’ products, particularly for those whose products are selected as finalists.

Step 3: Include accessibility assurances in contracts

If ultimately the best product for meeting a particular need is one that fails to fully meet accessibility requirements, vendors should be asked to make a commitment to improving accessibility over a specified timeline, perhaps working with campus staff.

After a procurer discusses accessibility issues with a vendor, the procurement contract should include language that specifically documents the agreement between vendor and procurer as to how satisfactory progress on accessibility will be measured. For example, the vendor might provide a roadmap as an addendum to the contract with a prioritized list of accessibility issues and a timeline for addressing each issue. Then, contract extensions might be contingent upon satisfactory progress toward resolving the issues identified in the roadmap.

Even if the product is currently accessible, the contract should include language that assures continued accessibility as the product is updated. This is especially important for products that are developed on an ongoing rapid release cycle.

CMS Login