Technology has the power to include or exclude, either reducing barriers or creating them. The tools we choose have far-reaching implications for our campus community and the level of accommodations we need to make.

Requirements for Purchasing Technology/Procurement

Colorado and federal laws, as well as CSU’s Accessibility of EIT Policy, require us to consider accessibility as part of the technology purchasing process. EIT (Electronic and Information Technology) and ICT (Information and Communication Technology) are generally used interchangeably.

All EIT (or potential EIT) software and hardware must be evaluated before purchase. Ideally, this will take place before a final decision has been made in case an accessible alternative is required.

EIT purchases include university systems required for use by students or employees, such as:

  • registration,
  • electronic textbooks,
  • adaptive courseware, software or apps used in instruction or evaluation,
  • databases,
  • proctoring tools,
  • clickers,
  • etc.
CSU System logo

Sample RFP and Contract Language

Visit the CSU System's Procurement IT Accessibility Requirements webpage for sample Request for Proposal (RFP) and contract language.

Procurement Process

Beta testing:  Engage with the ICT Procurement Doc Requirements AI Agent.

  • Provide the agent with product details from the vendor’s website, or from the agreement or Scope of Work document, or with the answers to the questions found in CSU Software Acquisition form.
  • The AI Agent knows which product ACRs are on file with CSU, which products are managed by IT enterprise software, who the data stewards are, how to complete a VPAT®, and what the various data levels are. It can provide examples of each, and more.
  • You can ask the AI agent questions related to accessibility, security, data governance, or IT governance.
  1. Check the Accessibility Conformance Report (ACR) Summary database for the product and vendor. Review the ACR Database section below for more information on this step.
  2. Request an internal accessibility review from the Division of IT using the ICT request form.
  3. Once approved, attach the ICT accessibility approval to the requisition.
  4. Accessibility language will be included in all contracts.

For assistance with evaluating a product, email CSU IT Accessibility.

Procurement Guidelines

Below are guidelines for how to successfully incorporate accessibility in the purchasing process. 

  • Accessibility must be an explicit criterion in all EIT Request for Proposals (RFPs), and should be evaluated and taken into consideration early in the process, before the preferred product is chosen.
  • When an RFP is not required, accessibility must also be considered before adopting technology tools which students or employees will be required to use, whether purchased or free.
  • The recommended contract language should be included for all EIT contracts.
  • Products with accessibility issues may be adopted if the vendor provides a roadmap for improvements.
  • If an inaccessible product is adopted, individuals with disabilities must be accommodated by offering an equitable alternative.

Accessibility Conformance Reports (ACR) and VPAT®

An Accessibility Conformance Report (ACR) details how a vendor’s ICT product complies with accessibility standards. The blank template for an ACR is called a Voluntary Product Accessibility Template (VPAT)®. At CSU, the acronyms VPAT and ACR are often used interchangeably to reference a completed report. 

“The VPAT name and report form are ITI registered service marks, and should not be altered without the express written permission of ITI.” —ITI

ACR Database

An ACR is required for most technology purchases at CSU, with few exceptions. A new ACR summary database has been created to streamline this aspect of the procurement process. When product purchases are approved in any department, a summary of the approved ACR is added to the database. When your department is purchasing technology, follow these steps: 

  1. Before requesting an ACR from the vendor, check the existing ACR summary database.
    • If an ACR summary exists for the specific product you are purchasing, download and attach the ACR summary to your procurement request. 
    • If an ACR summary does not exist for the specific product you are purchasing, request an ACR from the vendor. Attach the full ACR to your procurement request. 

If the ACR did not previously exist in the database, Procurement Services will summarize the complete ACR and add the summary to the database. 

For questions regarding ACRs, email CSU IT Accessibility.

Evaluating Product Accessibility — Advanced

Prospective vendors should be able to demonstrate their knowledge of and commitment to electronic accessibility during the purchasing process by:

  • Maintaining a current Accessibility Conformance Report (ACR) from VPAT® version 2.4 or higher describing the accessibility of their products and services. Vendors may also submit an independent third party accessibility evaluation from a certified accessibility consultant.
  • Disclosing any existing accessibility issues that they are aware of in their product, and a roadmap or other such plan for addressing existing issues. (Note that all products have accessibility issues, since accessibility is a continuum.)
  • Providing accommodation options for areas in which their product isn’t yet fully accessible.

Having a completed ACR does not mean that a product is accessible.

  • A good ACR should acknowledge specific areas of concern and detail plans for improvement.
  • A flawless ACR is not realistic, and raises questions about the vendor’s understanding of accessibility.
  • If a vendor does not have a ACR readily available, it could be a sign that accessibility is not an active concern of theirs.

All University contracts for EIT should contain appropriate provisions concerning accessibility. See IT Accessibility Requirements on the Procurement Website for sample contract language. Vendors can demonstrate a commitment to making accessibility a priority by:

  • Assigning a specific support contact to work on accessibility issues as they arise.
  • Offering workarounds for issues that currently exist.
  • Adopting WCAG 2.1 AA guidelines as a standard for development.
  • Adopting a development process that includes accessibility testing throughout, with a variety of assistive technologies (not just screen readers).
  • Developing a roadmap for accessibility improvements, including a timeline for development.

If the adoption of a product does not include a contract, the adopter should still advocate with the vendor or publisher for making accessibility a priority in their business.

These additional questions can help provide a more complete picture of a vendor’s understanding of and commitment to accessibility as part of their product development:

  • Is your product developed using accessibility standards? If so, which?
  • Which assistive technologies have been tested with your product?
  • Has your product been tested with assistive technologies beyond screen readers, such as keyboard, magnification, text-to-speech, voice recognition, etc.? If not, do you have plans to include these in future testing?
  • Have you had users with disabilities do any testing for you?
  • What existing accessibility issues are you aware of in your product?
  • Do you have a roadmap for addressing existing issues?
  • Do you have a plan for resolving any accessibility issues that come up during the period of a contract?
  • Does your company have an accessibility policy?
  • Do you have anyone assigned to addressing accessibility issues in your company?
  • Exceptions may be determined during the evaluation if appropriate.
  • Products with accessibility issues may be adopted if the vendor provides a roadmap for improvements.
  • If an inaccessible product is adopted, individuals with disabilities must be accommodated by offering an equitable alternative.