Procuring Accessible IT

The University of Arkansas strives to ensure that IT products developed, purchased, or used by the U of A 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.

In order to facilitate the procurement of accessible information technology, the following steps should be implemented for all products and services that fall within the scope of the above policy. U of A-IT Accessible Technology Services can assist with any of these steps. 

Step 1: Solicit accessibility information.

U of A bidders and vendors are required to demonstrate that information technology provided to the U of A conforms to or addresses each of the World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG), Level AA criteria wherever demonstrating such performance is practicable. Vendors may do so by providing either of the following:

  • An independent third-party evaluation from an accessibility consultancy
  • A Voluntary Product Accessibility Template (VPAT). If a VPAT is used, it must use the latest VPAT template, which is based on WCAG Level AA. The latest VPAT 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 one or more of the methods listed in the preceding section. The first of these sources is the most likely to be credible, providing it was completed by a credible accessibility consultancy. The second source of information can be informative, but it has limitations, since it is a self-report 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 serve as a good starting point for a thorough discussion about accessibility of vendors’ products, particularly for those whose products are selected as finalists.

Wherever practicable, the U of A IT Services or applicable experts will attempt to validate the information provided by bidders and vendors by:

  • Obtaining additional information from the bidder or vendor to develop a complete and thorough understanding of the accessibility of the product or service,
  • Consulting with independent third parties who have evaluated the product or service for accessibility, or
  • Conducting an internal evaluation of the accessibility of the product or service.

Few IT products are fully accessible. However, vendors should, at a minimum, be willing to make a commitment to address their accessibility problems. Without this commitment, using the product may place the university at risk for discriminating against some of its students and/or employees.

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 requester discusses accessibility issues with a vendor, ITS Services and applicable experts, the procurement contract should include language that specifically documents the agreement between vendor and requester 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.