The University of Chicago

Procurement

The University is committed to procuring accessible products. We are responsible for the accessibility of the digital assets we offer, including those we procure or acquire from vendors. For websites and applications, accessibility must be considered throughout the procurement process. For more information about whether this applies to your website or app, please refer to our FAQs. The following are recommendations for integrating accessibility into IT procurement.

To contact the Center for Digital Accessibility (CDA) for help during the procurement process, email the CDA. Consult Procurement Services for specific procurement guidance.

Procurement process recommendations

Consider accessibility throughout the procurement process in each of the following steps:

Impact assessment

Before beginning the procurement process, evaluate accessibility risk by considering its potential impact upon users. Visit the intranet for information about classifying accessibility impact (requires CNet login). If the product or website is higher impact, contact the CDA to participate throughout the procurement process. If the product or website is lower impact, follow all recommended guidance below and reach out to the CDA or IT Procurement with questions.

Requirements phase

Include conformance with UChicago’s digital accessibility standards in requirements documentation.

For products

  • Request a completed UChicago Vendor Accessibility Questionnaire or Educause HECVAT.
  • Request a completed VPAT (Voluntary Product Accessibility Template). The University’s preferred version is WCAG or INT. The VPAT is a template developed by the ITI (Information Technology Industry Council) for vendors to self-report on the accessibility of their digital products. An Accessibility Conformance Report (ACR) is a completed VPAT. The terms VPAT and ACR are often used interchangeably. If the vendor doesn’t have a VPAT, this is a red flag. Ask them how they plan to report on the accessibility of their product.

For websites

Vendor and product selection

Analyze the vendor’s commitment to accessibility

  • Do they have an accessibility page or statement on their website?
  • Search “accessibility” on their website to get a quick sense of their attention to the topic.
  • Is their VPAT readily available on their site?

Analyze vendor documentation

  • Contact the CDA to request a review of vendor accessibility documentation received during the Requirements phase. Use information gained from this analysis to evaluate vendor options.

Conduct accessibility testing

  • For products, request a vendor demo. For higher impact products, also request access to the product for evaluation. A vendor demo or product accessibility test should include running an automated checker, performing manual keyboard testing, and, if possible, screen reader testing.
  • For websites, request a sample accessible website to conduct an accessibility test.

Address known accessibility concerns

  • Request a vendor roadmap for remediation of accessibility issues.

Contract negotiation

Product onboarding

  • Request information from the vendor on how to configure their product in the most accessible way. Configure with those guidelines in mind prior to implementation and testing.
  • Add content to the product in conformance with accessibility guidelines.
  • For known barriers to user access, create an Equally Effective Alternate Access Plan (EEAAP) (requires CNet login) and store it for future reference. In the EEAAP, describe workarounds to known issues in advance, so that users with disabilities who encounter barriers can be afforded an equal opportunity to receive the same information, obtain the same result, to gain the same benefit, or to reach the same level of achievement.

Contract renewal and upgrades

  • Request updated VPAT and analyze it against the previous version.
  • Request an updated product accessibility roadmap.
  • Analyze status of previous roadmap commitments.
  • Update accessibility language if standards have changed.

Assessing the VPAT (Voluntary Product Accessibility Template)

After you receive a completed VPAT, contact the CDA to request a VPAT assessment. We will review it to make a preliminary assessment of product conformance. The VPAT should be used in conjunction with hands-on product testing or a product demo.

A strong VPAT should include:

Introductory section:

  • Product name and version
  • Report date—best case is to be less than one year old with no major releases after the report was created
  • An accurate product description
  • Contact information
  • Evaluation methodology, including testing tools and assistive technology used
  • A single product, not multiple products
  • Creation by a third-party vendor (preferred)

WCAG success criteria table

  • The Conformance Level column should include proper terminology, such as: Supports, Partially Supports, Does Not Support, N/A (Note: Not Evaluated should be used for Level AAA only).
  • Passes, Fails, Conformant, Compliant, Meets, Doesn’t Meet, etc. are examples of incorrect terminology.
  • A variety of conformance levels should be included.
  • A VPAT with Supports in all columns would be something to discuss with the vendor because it would be unusual for there to be no exceptions.
  • There should be very few instances of N/A.
  • When the conformance level is Partially Supports or Does Not Support, the Remarks and Explanations column should identify which functionality or features have issues.