Pillar 1: Procure

We recognize the importance of acquiring accessible ICT when purchasing, developing, maintaining, or using ICT for university business.

Scope

Scope includes all information and communication technology (ICT) purchased, developed, or maintained, and/or used, to conduct university business, where

  • a user interface is present (e.g., website, mobile app, desktop computer) or
  • the ICT is in the form of electronic document(s) (e.g., online subscription database, online textbook, PDF documents).

Scope is not limited by:

  • Cost: Even free (or $0.00) ICT shall be reviewed for accessibility compliance.
  • Number of users: Even if one individual is using the ICT, it shall be reviewed for accessibility compliance.

Compliance Standards for Procurement

To comply with federal and state regulations, TAMU-CC must perform an accessibility review of ICT. Two main results or determinations will occur: compliant or non-compliant.

Compliant

Four general areas are determined compliant:

  1. The ICT's accessibility documentation meets accessibility standards
  2. The ICT is currently covered under a regulatory exemption
  3. The ICT is currently covered under a defined regulatory exception
  4. The product or service requested is not covered under the definition of ICT, so it is not applicable

No additional approvals are required, unless a contract is under review.

Non-Compliant

ICT can become non-compliant for several reasons:

  1. Accessibility documentation does not meet technical accessibility standards
  2. Accessibility documentation is missing or unavailable
  3. The ICT has not been designed or developed yet, so the review is pending in the product's lifecycle

Since the university must procure accessible ICT, non-compliant ICT must be assessed for liability risk before acquisition. The president or their delegate must approve the acquisition of non-compliant ICT. The university may also opt into exceptions approved by the System chancellor or their delegate.

Regulations define the scope of ICT that can be covered under an exception (e.g., best meets, fundamental alteration, undue administrative/financial burden). ICT that cannot be covered under an exception must include similar plans for workarounds and accommodations. If a contract is present, it must also be reviewed.

Accessibility Review

The DAO must be informed of all acquisitions through a work intake process that provides information on the ICT requested.

In order to process the accessibility review of the ICT, the intake process should provide the DAO with (at minimum):

  • Requester’s contact information to clarify information
  • A description of the ICT (i.e., business impact, strategic goals, purpose)
  • The cost of the ICT in total for a project or annual subscription
  • The audience(s) using the ICT who would be at risk if they have a disability now or in the future
  • The operational scope of the ICT, including public/internal access and traffic
  • Vendor’s contact information to request accessibility documentation, program maturity documentation, and clarification on responses (e.g., technical staff, accessibility staff)

This information, including vendor responses, will allow the DAO to assess the liability risk.

Accessibility Documentation

The university must contact the vendor about accessibility documentation. If this is done at acquisition, the requester will submit a software acquisition request or hardware acquisition request in Service Now. The Information Technology Department will then send the request to the vendor contact provided in the form.

Note: TAMU-CC is treated as the vendor for internal development or projects (e.g., website, web application), and the DAO or appropriate designee will provide the accessibility documentation.

Accessibility documentation depends on the type of request:

  • Commercial off-the-shelf (COTS) product: The latest versions of Voluntary Product Accessibility Template (VPAT) (e.g., version 2.3 or higher) must be completed. The International (INT) edition may provide the greatest ease for completing required sections. Areas to complete depend on the ICT type as seen below. Once the VPAT is complete it is called an Accessibility Conformance Report (ACR):
    • WCAG 2.x Report (required)
      • Table 1: Success Criteria, Level A
      • Table 2: Success Criteria, Level AA
    • Revised Section 508 Report (required for EIR that is not a website or is in addition to a website)
      • Functional Performance Criteria (FPC) (required)
      • Chapter 4: Hardware (optional: for kiosks, desktop computers, printers, telephones, and other hardware)
      • Chapter 5: Software (optional: for web, mobile, or desktop apps)
      • Chapter 6: Support Documentation and Services (required)
  • ICT Development Services: A completed questionnaire that may include:
    • processes integrating ICT accessibility activities (e.g., product development, procurement, human resource hiring)
    • skills and training resources used or procured to develop or accessible ICT
    • development and testing tools (e.g., testing scenarios and results)
    • remediation processes (e.g., documenting, tracking, resolving)
    • alternate accommodations for non-compliant products (e.g., 24/7 toll-free support number)
    • examples of websites or other ICT work produced by the vendor that meet accessibility standards

Note on Authoring Tools

Authoring tools are software and services used to create digital content (e.g., electronic documents, audio/video content), including

  • word processors, spreadsheets, and presentation generators
  • content management systems (CMS)
  • what-you-see-is-what-you-get (WYSIWYG) HTML editors
  • websites that let users add content, such as blogs and wikis

ICT that is an authoring tool expands the liability risk due to the audience affected by the resulting products of the authoring tool. Authoring tools may be reviewed within a VPAT (i.e., authoring tool). Electronic documents may be reviewed within a VPAT (i.e., supporting docs).

Exception Filing

Determination

The DAO determines if the ICT or design/development services are non-compliant. Priority review will escalate beyond acquisition timelines based on

  • ADA accommodations requests or complaints
  • noted lawsuits and court rulings
  • requests from System IT governance committees, task forces, etc.

If the requester wants to proceed despite non-compliance, the university must review the liability risk of the ICT. Workarounds and accommodations must be provided for people with disabilities to use the ICT. The president or their delegate must accept or reject the liability risk.

Responsibility

The requester or business owner must acknowledge their responsibilities when acquiring ICT which are listed on the acquisition request form:

Exception Request Requirements

The Accessibility Exception Request is now a part of the IT Policy Exception Request form (Laserfiche) and Software Acquisition Request form (Service Now).

Approval Workflow

The DAO and/or CIO will assist in the review of the exception form. Federal and state regulations do not require any other official approvals except from the president.

A CIO Temporary Approval process is included to address business continuity through IT products and services. This is a rarely performed process to address urgent requests where services may be interrupted.

  • The requester must identify the deadline and consequences.
  • The IT department shares remedies with the requester to prevent similar business continuity issues in the future.
  • There is a guarantee of an accessibility compliance review after the fact to address future use of the product, which may include researching an accessible alternative to transition to if the ICT is rejected.

Delegation

Per 29.01.04, Accessibility of Electronic and Information Resources, each exception must be approved by the president or the president's delegate. The delegate must be informed this "is not a bureaucratic formality but a real decision with some associated risk," and make decisions based on the balance between business impact and liability risk which shall be provided in the request form.

Transition

If the ICT is not approved, a transition plan should be in place to change to another ICT or provide alternative accommodations, like a business continuity plan. Communication plans regarding transitions are the responsibility of the requester or the requester’s department to implement, with guidance as needed from IT or Marketing and Communications.

Contract Review

Where ICT COTS and/or design/development services include a contract, the DAO works with Contract Administration to ensure the university is protected.

EIR Accessibility Coordinator