ICT Accessibility Exceptions – Draft

In these situations, the university must be able to demonstrate that reasonable efforts were made to procure an accessible ICT and an equally effective alternative method of access must be provided. As such, a request to use an inaccessible ICT or to use an ICT in an inaccessible context must be reviewed and approved.

The exception process is intended to support procurement and the university’s mission to create an inclusive environment. It is in place to ensure that the university is maintaining an inclusive and welcoming educational and workplace environment and to demonstrate due diligence under accessibility law.

To fulfill its obligations under federal and state accessibility law, the university must do two things:

1. Procure and utilize only the most accessible products available on the market, if no fully accessible product is available, that best meets the business need.
2. Document a plan for providing equally effective alternative access to those who encounter access barriers due to the accessibility flaws in an ICT product.

The exception process is utilized to ensure that the above conditions are met. It is only in cases where it is clear that due diligence was not performed when procuring a product and no meaningful alternative access can be provided that an exception request may be denied, and a product may not be used.

If it seems likely that an exception will not be approved by the Digital Accessibility Steering Committee (DASC), then it may be prudent to pause the procurement process until the exception process has been completed and the outcome is known. While an approved exception is required for an inaccessible product to be used for the mission of the university, it is left to individual units to determine when in the procurement process they wish to seek an exception and if procurement will be suspended until the outcome of an accessibility exception request is determined.

Accessibility exceptions are reviewed and approved by the Digital Accessibility Steering Committee (DASC). Below is an general overview of theException Process steps.

1. Complete Vendor’s Commitment to Accessibility Evaluation.
2. College/Vice Chancellor Unit internal review by subject matter experts/IT staff who may verify or gather additional information.
3. Submission to the Exception Request Process and Review by ICT Accessibility Exception Review Committee who may verify or gather additional information.
4. Approved or denied by the Chief Information Officer or designee
5. The request will be logged into a centrally managed database of exception requests and the requestor will be notified of the decision.
6. The requester can appeal the decision to CIO, upon whose decision is final. Prior to the exception expiration, the responsible unit must complete remediation or request a renewal of the exception

Before requesting an ICT accessibility exception, the Requesting Individual must have the following information:

1. An accessibility evaluation report for the ICT product that will receive the exception. The evaluation must have been performed by an employee of the university or by an approved third-party.
   • If the request is to renew an expiring exception, the evaluation must be a follow-up evaluation conducted on the most recent version of the ICT product; ie., the evaluation report that was submitted with the expiring request may not be resubmitted for the renewal. This helps ensure that any updates to the ICT product are evaluated and addressed as needed by updates to the alternative access plan.
2. Documentation of the product comparison research demonstrating that the ICT to be excepted is the most accessible product available product on the market that meets business need.
   
   • If no product research was performed or the ICT to be excepted is not the most accessible, document rationale for why this product was chosen.
3. A completed Alternative Access Plan template which documents the equally effective alternative access that will be provided by the requestor, the requestor’s unit, or the product service management team.

• The first is because all issues found negatively impact those with disabilities, resulting in anywhere from an outright inability to use a product to wasting valuable time and effort as an individual grapples with access barriers in the product.
• The second reason is that accessibility law does not make mention of issue priority and all accessibility issues found in a product, regardless of the priority assigned in an evaluation report, constitute violations of legal requirements.

You can use the Digital Accessibility Decision Tree to help you determine the most appropriate course of action.

• Access Decision Tree

• The ICT product has no human-facing interface
• The ICT product is special-purpose software that will be used by few individuals, none of whom have an identified disability that will be adversely affected by product accessibility issues
• The ICT product is for use internally by a research team where no members of the team have an identified disability that will be adversely affected by product accessibility issues

In the latter two situations, it is be prudent to create an alternative access plan in case someone who must use the product develops a disability or a new team member is introduced who has a disability that will be adversely affected.

• Access Exception Guide

The accessibility of products changes as they are updated, and new, more accessible products that meet the business need often become available over time. As such, approved exceptions are not permanent, typically expiring in one to two years after approval. Exceptions may be renewed (See Exception Renewals below).

Process Timeline

• 60 days prior to expiration: DASC notifies requestor and requestor’s unit via email that an exception is expiring in 60 days.
  • Requestor should notify DASC if they intend to renew the exception or if the exception is no longer required.
• 30 days prior to expiration: If no response received from the requestor, DASC sends an expiration reminder via email.
  • Requestor may notify DASC of need for an extension if needed.
• Date of Expiration: If no response from requestor, ADA IT Coordinator is notified. ADA IT Coordinator will contact the requestor and the requesting unit to discuss next steps.
• 90 days post expiration: If no progress is made toward renewal, requesting unit must discontinue use of the product.

About Expiration Dates

Exception expiration dates are set by the DASC. When setting the date, the DASC takes into account:

• The contract renewal date, if that is known
• Vendor activity to remediate accessibility issues in the product
• The context of use for a product. As an example, expiration for a classroom technology will not occur during the semester where the technology is in active use by students.