Digital Accessibility Policy
Adopted: December 8, 2021, Updated: May 29, 2024

1 - Purpose

The Digital Accessibility Policy promotes high-level coordination of digital accessibility efforts throughout the Champaign-Urbana Mass Transit District’s (MTD) operating boundaries as well as throughout its locations. It defines a standard of accessibility compliance and, through a flexible implementation plan, establishes procedures to help ensure that information technology used for the mission of MTD is accessible to all persons, regardless of ability or delivery format.

MTD is committed to ensuring equal access to information, services, and resources through the use of its information technology for all customers and employees. All of MTD’s web pages, applications, and digital content, subject to exceptions enumerated in this policy, must be made accessible to the widest range of users.

This policy establishes the standards for digital accessibility of Information and Communication Technology (ICT) to ensure technologies developed, procured, maintained, used, or provided by MTD for the purpose of accessing information, creating content, and manipulation of data comply with applicable state and federal laws.

2 - Scope

This policy applies to any new, updated, or existing Information and Communication Technologically (ICT) developed, procured, maintained, used, or otherwise provided by MTD for use by its customers, employees, or the public including mtd.org and third-party applications procured by MTD.

ICT that does not utilize a human interface is outside the scope of this policy.

3 - Authority

The Managing Director/CEO designates authority to oversee execution of this policy to the Deputy Managing Director and Technology Services Director.

The Managing Director/CEO shall appoint a Web Accessibility Coordinator to act as a single point of contact for accessibility concerns, feedback, and information submitted by members of the public to MTD.

4 - Accessibility Statement

MTD will ensure that the following accessibility statement is available on MTD.org:

MTD is committed to ensuring that its website and mobile applications are accessible to individuals with disabilities. All pages on our website and all mobile applications must meet Web Content Accessibility Guidelines (WCAG) 2.1 Level AA conformance. Please report accessibility issues to MTD’s Web Accessibility Coordinator at accessibility@mtd.org.

5 - Accessibility Complaints

When web accessibility feedback, comments, or complaints are received, they must be logged into MTD’s customer feedback system by the Customer Support Specialist or qualified Supervisor. Additionally, any web accessibility feedback received by MTD, must immediately be shared with the Web Accessibility Coordinator, Technology Services Director, Customer Service Director, and Deputy Managing Director.

Within seven (7) business days of receiving accessibility feedback, the Web Accessibility Coordinator will organize a meeting with the Technology Services Director, Software Developer, Customer Support Specialist, and Deputy Managing Director to discuss the feedback and formulate a response. At this meeting, MTD Staff will determine what action is required to address the accessibility feedback. These actions may include user training, software fixes, or auditing by internal or external accessibility auditors.

Within ten (10) business days of receiving the accessibility feedback, the Customer Support Specialist will respond to the complainant outlining MTD’s planned response and requesting follow-up information if needed.

The Web Accessibility Coordinator will keep a log of all web accessibility feedback MTD receives, MTD’s response, and resolution to the feedback.

6 - Definitions

Archived is Information and Communication Technology (ICT) or services that are no longer actively linked or circulated but may be subject to records retention plans (e.g. previous MTD Board Meeting Packets and Agendas). If posted publicly on a web page, archived content must be clearly labeled as such.

Legacy refers to ICT that has been procured, maintained, or utilized prior to May 29, 2024 and is still in active circulation or use.

Minimum Digital Accessibility Standards (MDAS) are the legal and technological standards and guidelines that MTD utilizes to determine if its ICT are technically and functionally accessible. See Appendix A.

ICT that is not technically or functionally accessible per the MDAS must receive an approved exception in order to be used or otherwise provided for use by MTD for its customers, employees, or the public. See Appendix B.

ICT for individual or limited team use, where no member of the team has been identified as having a qualified disability, does not require an approved exception.

7 - Implementation Plan

General Requirements

The Implementation Plan shall address Information and Communications Technologies (ICT) as outlined in the Scope of this Digital Accessibility Policy. Per the Minimum Digital Accessibility Standards (defined in Appendix A), ICT shall meet the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, and the Americans with Disabilities Act (ADA), Title II.

1. All MTD Staff shall be notified of this Policy and the Implementation Plan.
2. Compliance targets must be reviewed annually to ensure substantive, measurable progress toward full IT accessibility compliance throughout MTD’s services and resources.
3. All ICT developed or procured after the effective date of the Digital Accessibility Policy shall be developed or procured in such a manner as to comply with the Policy.
4. ICT existing prior to the effective date of the Digital Accessibility Policy and that is in use is considered "legacy" ICT (see Section 6 Definitions). Legacy ICT is not exempt from the Policy and will be brought into accessible compliance in an ongoing, prioritized process based on impact.
5. When any legacy ICT undergoes a redesign or other substantive change, it is now considered "new" and must be brought into compliance with the Digital Accessibility Policy at the time of the change.
6. MTD must implement an anonymous, accessible, and easily accessed method for reporting accessibility issues. Currently, there is a link to MTD’s “Contact Us” page on each web page. A third-party fraud, waste, and abuse reporting software is in the plan for implementation. Once implemented, this will enable an anonymous and accessible method of reporting issues for employees and members of the public.
7. MTD must establish an accessible and easily identified mechanism for requesting that ICT be made accessible.
8. It is each Department’s responsibility to devise and maintain an appropriate alternative access plan when one is necessary (See Appendix B).
9. Employees are required to work with their Supervisor and Human Resources to ensure that electronic materials they use are accessible.

Recommended Procedures & Guidelines

Web accessibility shall be considered throughout the development process and life cycle for websites, web applications, and their related content such as content created by MTD for posting on social media platforms.

Accessibility evaluation methods for websites and web applications must include manual testing as well as tool-based evaluation. Recommended methods for evaluating websites and web applications for accessibility compliance will be established.

Each web page must clearly provide an anonymous, accessible method for reporting accessibility issues to website owners. Website owners shall bear the primary responsibility for ensuring that their websites, web applications, and related content are accessible. This includes websites developed by a third party for MTD’s use.

Similarly, non-web-based software must also comply with Minimum Digital Accessibility Standards defined in Appendix A and accessibility shall be considered throughout the development process and life cycle of the software.

Non-web-based software, such as Android and iOS apps, deployed by MTD must utilize current accessibility application programming interfaces (APIs) of their target platforms.

Accessibility evaluation methods for non-web-based software must include manual testing as well as tool-based evaluation (where possible). Recommended methods for evaluating non-web-based software for accessibility compliance will be established.

8 - Policy and Accessibility Training

All staff will be trained on this policy within six (6) weeks of their start date. An annual retraining on this policy will also be executed.

All relevant Staff (Figure 1) will be trained on web accessibility within six (6) weeks of their start date. This training shall include training videos outlined in Figure 1 below. All relevant Staff will be retrained annually.

Position	Content Authoring	Accessible Design	Developer Training	Multimedia	Testing for Accessibility
Web Accessibility Coordinator	x	x		x	x
Technology Services Director	x	x	x	x	x
Software Developer	x	x	x	x	x
Marketing Manager	x	x		x
Communication Design Specialist	x	x		x
Customer Service Director	x	x		x
Customer Support Specialist	x				x
Analyst Planner		x
Service Planner		x
Special Services Manager		x
Deputy Managing Director	x	x		x

Figure 2 outlines training needs on this Policy and associated processes.

Position	Alternative Access Plans	Equally Effective Alternative Access Plan Template	Learning Management System	Procurement Process
All Department Directors	x	x	x	x
Deputy Managing Director	x	x		x
Managing Director/CEO				x

9 - Notice and Posting

Any Staff who create, procure, maintain, or modify ICT, including all employees listed in Figures 1 and 2 above, shall receive a copy of this policy upon adoption and be provided a new copy whenever the policy is revised.

A copy of this policy shall also be posted publicly on mtd.org.

10 - Exceptions

Exceptions are granted through a request process and must include:

• A documented Equally Effective Alternative Access Plan (EEAAP) that will provide an alternative means of access for the features of the Information and Communication Technology (ICT) that are not accessible (See Appendix B).
• Alternatively, documentation that describes why an alternative means of access is not possible due to technological constrains or the intended purpose of the technology (e.g. virtual reality goggles) at issue does not call for an EEAAP.

Before requesting an ICT accessibility exception, the requesting project leader must have:

1. An Accessibility Evaluation Report for the ICT product that will receive the exception. The evaluation must be performed by the Technology Services Director or designee, or by an approved third party.
2. Documentation of the product comparison research demonstrating that the ICT to be accepted is the most accessible product available on the market that meets the business need. This could be through a Request for Proposals/Request for Information (RFP/RFI) where proposers are given the Equally Effective Alternative Access Plan (EEAPP) Template (Appendix C) and Procurement Evaluation Template (Appendix E).

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, e.g. 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 EEAAP.

11 - Revisions

This policy shall be reviewed annually by the Web Accessibility Coordinator, Technology Services Director, and Deputy Managing Director. Any substantive change to this policy is subject to MTD Board approval. MTD Staff may make the following categories of changes to this policy without MTD Board approval:

• Spelling, typographical, or grammatical corrections that do not change the meaning of this policy.
• Increase WCAG conformance targets to match current WCAG recommendations (e.g. change target from WCAG 2.1 AA to WCAG 2.2 AA when officially updated).
• Other minor or non-substantive changes that do not fundamentally alter this policy.

Description	Date
Adopted	December 8, 2021
Updated	May 31, 2023
Updated	May 29, 2024

Appendix A: Minimum Digital Accessibility Standards (MDAS)

All information and communication technology (ICT) procured, developed, maintained, utilized, or otherwise provided to MTD employees or to the general public, shall be both functionally and technically accessible. The Minimum Digital Accessibility Standards (MDAS) provide functional requirements supported by technical accessibility standards to help ensure accessibility across a variety of electronic resources and information technology areas of use, including but not limited to:

• Websites, web applications, social media posts created by Staff
• Electronic documents including but not limited to PDFs and Microsoft Office Documents (Word, PowerPoint, Excel, etc.)
• Email, including newsletters and marketing materials
• Multimedia content including but not limited to social media videos such as YouTube, Facebook, and TikTok
• Trainings videos including but not limited to learning management system (LMS) trainings

All ICT that has an interactive user interface is subject to the MDAS requirements.

1 - Technical Requirements

Information and Communication Technology (ICT) that meets technical accessibility requirements is coded or otherwise constructed in a way that conforms with mandated or recommended accessibility standards. Conformance with such standards may be objectively assessed via automated and manual accessibility evaluation.

ICT at MTD must conform to the furthest extent possible with the following technical standards:

1. Commercial-Off-The-Shelf (COTS) software and Software as a Service (SaaS) Products must meet the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA requirements.
2. Software developed internally or jointly with an external entity for utilization by MTD or the public must meet the requirements of the most recent recommended version of WCAG; currently WCAG 2.2 Level AA.
3. Web sites and web applications developed internally or jointly with an external entity must utilize the most current recommended HTML, CSS, and JavaScript standards, as well as the WAI-ARIA 1.2 specification, according to the WAI-ARIA Authoring Practices 1.2.

Non-Web ICT must apply WCAG 2.0 Level AA.

2 - Functional Requirements

ICT that meets functional accessibility requirements provide features and modes of operation that make the ICT usable by individuals with disabilities. To be functionally accessible, individuals with disabilities must be able to use the ICT to achieve the same goals or outcomes, as independently (i.e., without aid or assistance from another individual), in a similar timeframe, and with similar ease of use, as can those without disabilities.

The ICT must be usable by individuals with disabilities in the following modalities:

• Without vision or with limited vision, where a visual mode of operation is provided.
• Without perception of color, where a visual mode of operation is provided.
• Without hearing or with limited hearing, where an audible mode of operation is provided.
• Without speech, where speech is used for input, control, or operation.
• With limited manipulation, reach, and strength, where a manual mode of operation is provided.
• With limited language, cognitive, and learning abilities, making the operation of the ICT easier for individuals with limited cognitive, language, and learning abilities.

3 - Technology Support Requirements

The following software platforms and assistive technologies must be supported by ICT at MTD:

• All commonly utilized web browsers: Microsoft Edge, Chrome, Firefox, and Safari
• Windows and MacOS platforms
• Common iOS and Android mobile devices
• Commonly utilized Screen Readers: JAWS, NVDA, VoiceOver (macOS and iOS), Talkback (Android)
• Commonly utilized text-to-speech applications, such as Kurzweil 3000, Read-Write Gold, ZoomText

Appendix B: Equally Effective Alternative Access Plans (EEAAP)

In compliance with the Americans with Disabilities Act (ADA), Information and Communications Technology (ICT) products and services that MTD buys, creates, uses, and maintains must either conform to the technical and functional requirements of federal and state law, as outlined in Appendix A: Minimum Digital Accessibility Standards (MDAS), or have an approved exception.

When MTD must procure ICT products that cannot be considered accessible, federal and state law requires organizations to document and implement an equally effective alternative method of access that will mitigate the access barriers presented by the inaccessible digital product or service. The alternative access provided must be appropriate for the needs of those with disabilities who might use the ICT and must allow for substantially equivalent efficiency, engagement, and inclusiveness. The documentation of the alternative method of access is referred to as an Alternative Access Plan (AAP) or an Equally Effective Alternative Access Plan (EEAAP).

1 - Three Es of Accessibility

In order to be considered accessible, an ICT product or the alternative method for access must have the following three characteristics:

• Equally Integrated – Providing similarly inclusive experience and access.
• Equally Effective – Providing equal opportunity or outcome.
• Equivalent Ease of Use – Providing access that is not substantially more difficult for users with a disability.

An alternative access plan must incorporate the “Three Es” to be considered to meet the needs of those with disabilities. Individuals must not be made to disclose their disability to utilize the alternative method of access. To maintain the standards of inclusiveness and timeliness, the alternative method of access should be made available in a way that individuals do not need to request the access.

2 - Functional Accessibility Requirements

An effective alternative access plan must mitigate any access barriers in an ICT that would prevent access for or negatively impact the following interaction modalities:

• Without vision or with limited vision, where a visual mode of operation is provided.
• Without perception of color, where a visual mode of operation is provided.
• Without hearing or with limited hearing, where an audible mode of operation is provided.
• Without speech, where speech is used for input, control, or operation.
• With limited manipulation, reach, and strength, where a manual mode of operation is provided.
• With limited language, cognitive, and learning abilities; making the operation of the ICT easier for individuals with limited cognitive, language, and learning abilities.

For each affected modalities, consider what alternative access would be provided for someone who could not use the ICT.

3 - Components of an Alternative Access Plan

An effective AAP will have the following components:

• The name and contact information of the project leader and originating department.
• A brief description of the ICT product.
• The scope and intended use of the ICT product, to loosely quantify the level of potential impact that the accessibility flaws in the product may have.
• A brief overview of the access barriers in the product, including:
  • The common disability types that will be adversely impacted.
  • The extent of the access barrier, i.e. users who are blind cannot utilize the product.
• A description of the alternative method of access that will be provided.
• How the alternative access will be systematically communicated to those who may need it.
• Any notes for special consideration, such as use limitations that those who wish to utilize the ICT product should be aware of.

4 - Important Considerations

• An alternative access plan is required documentation of the method of alternative access that will be provided. The plan itself must not be confused with actually implementing and providing the alternative access.
• In most instances, the department that is procuring an ICT product will be responsible for maintaining the alternative access plan and reviewing it for effectiveness.
• An equally effective method of alternative access will not require an individual to disclose their disability and, where possible, will not require an individual to request the alternative access.
• Remember the “Three Es” of accessibility!

5 - Submitting an Alternative Access Plan

The project leader must work with the Technology Services Director or designee to evaluate the accessibility of any new ITC and the need for alternative access. See Section 6 of this policy.

If alternative access is deemed necessary, the project leader shall complete the Equally Effective Alternative Access Plan (EEAAP) Template in Appendix C. The completed EEAAP template shall be submitted to the Deputy Managing Director for approval.

ICT may not be used until it is deemed to meet the MDAS by the Technology Services Director or designee, or until a EEAAP has been approved by Deputy Managing Director.

 

Appendix C: Equally Effective Alternative Access Plan (EEAAP)Template

1 - Plan Creator Information

• Creator Name
• Title
• Department

2 - Information and Communication Technology (ICT) Description

2.1 - Name of ICT Product or Service:

Provide sufficient details about the product or service to ensure correct identification at a later date. If applicable, supply product version numbers to ensure correct identification of the product.

2.2 - ICT Description:

Include the vendor information and a brief description of the type of application, system, or process.

2.3 - Intended ICT Use:

Indicate how the ICT will be used and determination that lead to completion of this EEAAP.

3 - Description of Accessibility Issue(s)

3.1 - Functional Modalities Impacted

The accessibility issues in this ICT will negatively impact individuals in the following interaction modalities (Check all that apply):

• ☐ Without vision or with limited vision, where a visual mode of operation is provided.
• ☐ Without perception of color, where a visual mode of operation is provided.
• ☐ Without hearing or with limited hearing, where an audible mode of operation is provided.
• ☐ Without speech, where speech is used for input, control, or operation.
• ☐ With limited manipulation, reach, and strength, where a manual mode of operation is provided.
• ☐ With limited language, cognitive, and learning abilities; making the operation of the ICT more difficult for individuals with limited cognitive, language, and learning abilities.

3.2 - Description of the Issue(s)

Briefly describe how access barrier(s) in the product impact the interaction modalities indicated above.

Example: Riders who are blind will be unable to plan trips.

3.3 - Plan Justification

Select at least one:

• ☐ It would cause an undue burden to make this ICT accessible.
• ☐ An accessible version is not available. List other options evaluated.
• ☐ Conformance would result in fundamental alteration.

Explanation:

4 - Alternative Access Plan Details

4.1 - Responsible party(s):

List the name(s) of employee(s) who will be responsible for providing the equally effective alternative access (EEAA) described in this plan. If this plan is for an application add-on, such as add-ons for Microsoft Teams, indicate that the user, such as a member of Staff, who decides to make use of the add-on would be responsible for providing the EEAA.

4.2 - Alternative Access Provision:

Describe in detail how the equally effective alternative access will be provided. Explain how this alternative mitigates the issues described in Section 3 above.

1. What will the project manager need to do to provide the EEAA?
2. What must those who need to use the EEAA do to obtain access?

Communication Plan:

Describe in detail how the existence of and instructions for making use of the EEAA will be communicated.

Important: An effective communication plan will include provision for ongoing communication. This is especially important for application add-ons, where the individuals utilizing the add-ons for a project or course would be responsible for communicating about the EEAA.

1. How will those who need to use EEAA be made aware of it?
2. What will the project manager need to do to communicate how to use the EEAA?

If the project manager is not the originator or part of the originating unit for the EEAAP, how will the existence of the EEAA and how to use it be communicated?

Appendix D: Required Procurement Language

1 - Introduction

The following language (section 2) must be included in all RFP/RFIs issued by MTD, that contain Information and Communication Technology (ICT) elements. If ICT is being procured using other evaluation processes, the project manager is responsible for carrying out an equivalent evaluation before ICT is procured.

This procedure is referenced in the 8 GP1 Procurement Manual in the following locations:

• Section 1: Introduction
• Section 4: Evaluation of Proposals and Contract Award
• Appendix 3.1a: Procurement Threshold Policy

2 - Procurement Language

2.1 - Americans with Disabilities Act (ADA)

The product or service offered must be considered “accessible.” For purposes of this solicitation, the definition of “accessible” is:

A person with a disability is afforded the opportunity to independently acquire the same information, engage in the same interactions, and enjoy the same services within the same timeframe as a person without a disability, with substantially equivalent ease of use.

Title II of the Americans with Disabilities Act (ADA) prohibits discrimination against people with disabilities in all services, programs, and activities of state and local governments. To be compliant, government agencies must meet the Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium (W3C), as referenced by 28 CFR, Part 35 et seq. WCAG 2.1, conformance Level AA (includes all Level A requirements), is the currently referenced standard.

In order to provide greater support for a variety of computing devices and input modalities, MTD requires conformance with the latest version of the WCAG guidelines (currently WCAG 2.2) for products that are developed or substantially customized for the MTD (e.g. off-the-shelf products). Compliance with WCAG 2.2 is backwards compatible with the WCAG 2.1 and WCAG 2.0. As such, a product that is compliant with WCAG 2.2 Level AA requirements will be compliant with Title II of the ADA. If selected as a finalist, the respondent may be required to demonstrate the accessibility of their product or service.

2.2 - Functional Accessibility Requirements

Respondent must provide a detailed response on how the product or service will meet each of the (13) minimum functional requirements identified in this section (items 2.2.1-2.2.13). A response for each of the thirteen items is required. Blanket statements of compliance will not be considered sufficient. The thirteen requirements in this section represent the minimum functionality necessary to avoid the most common accessibility issues. Meeting these requirements cannot be construed to mean that a product conforms to the WCAG 2.1 requirements.

If a functional requirement is not relevant to the product or service being procured (e.g. A product that has no video content may not have a need for captions or audio description.) a “not applicable” response is required for that section.

2.2.1 - Text Alternatives

To fulfill this requirement, text alternatives must be appropriately descriptive of the non-text content and must be presented in a way that does not require vision to perceive (See Understanding WCAG 2.1 Guideline 1.1).

Describe how the product or service provide text descriptions for images, graphs, charts, etc. as an alternative to visual content.

2.2.2 - Captions and Audio Description

Captions must use correct grammar and punctuation and (where appropriate) identify the speaker and other audio cues (See Understanding WCAG 2.1 Guideline 1.2).

Describe how the product or service make captions, transcripts, and audio description available to the user.

2.2.3 - Adaptable

Users who are blind require the information, structure, and relationships in an application page to be presented in ways that do not require vision to perceive (e.g. programmatically) and is logical without the ability to see the screen. Sighted users with low-mobility (e.g. keyboard-only interaction) require keyboard navigation that makes sense for the application (See Understanding WCAG 2.1 Guideline 1.3).

Describe how the product or service allows users to view and interact with content in a way that they prefer. 

2.2.4 - Distinguishable

Some users will be unable to perceive information that is presented only through a change in color, such as an error state or if color contrast is too low. Others will have difficulty reading page content if there is multimedia content that plays automatically (See Understanding WCAG 2.1 Guideline 1.4).

Describe how the product or service ensure the most important content is obvious to users with varying abilities.

2.2.5 Keyboard Support

Users who are blind and some users with low mobility use only the keyboard to interact with a computer. To fulfill this requirement, keyboard shortcuts and/or mouse keys cannot be the primary way that a user can complete necessary tasks using only the keyboard (See Understanding WCAG 2.1 Guideline 2.1).

Describe how the product or service ensure that the most important tasks can be completed easily with only the keyboard (ex. tab, arrow keys, spacebar/enter). 

2.2.6 - Enough Time

Some users require more time to read content and perform actions than do others. For example, it can take a user who is blind up to three times longer to complete a task than some sighted users. Others require the ability to pause or stop scrolling or auto-updating information (See Understanding WCAG 2.1 Guideline 2.2).

Describe how the product or service provides enough time for users with varying abilities to interact with the content.

2.2.7 - Seizures

Components that flash more than three times per second can induce seizures in some individuals (See Understanding WCAG 2.1 Guideline 2.3).

Describe how the product or service prevents inducing seizures by limiting components that flash more than three times per second.

2.2.8 - Navigable

To fulfill this requirement, navigation via the keyboard (e.g. tab and arrow keys) must be logical. Features such as visual focus indicators for interactive elements, and good heading structure are required. The keyboard interface requirement should not discourage providing mouse input or other input methods in addition to keyboard operation. Any content that does not meet this functionality requirement may interfere with a user's ability to use interact with all content on the web page. This includes all menus, other navigation, and dynamic objects (such as image slideshows), etc. (See Understanding WCAG 2.1 Guideline 2.4).

Describe how the product or service provides ways that help users who cannot use a mouse or have visual impairments to navigate, find content, and determine where they are.

2.2.9 - Input Modalities

Often people use devices that offer several input methods, for example mouse input, touch input, keyboard input, and speech input. These should be supported concurrently as users may at any time switch preferred input methods due to situational circumstances, for example, the availability of a flat support for mouse operation, or situational impediments through motion or changes of ambient light.

A common requirement for pointer interaction is the ability of users to position the pointer over the target. With touch input, the pointer (the finger) is larger and less precise than a mouse cursor. For people with motor impairments, a larger target makes it easier to successfully position the pointer and activate the target. People operating pointer input devices may not be able to carry out timed or complex gestures. Examples are drag-and-drop gestures and on touch screens, swiping gestures, split taps, or long presses (See Understanding WCAG 2.1 Guideline 2.5).

Describe how the product or service supports multiple input modalities.

2.2.10 - Readable (Web-based Applicaitons Only)

In order to read text properly on the web, screen reader software needs the language of a webpage, or part of a webpage for multi-language applications to be specified in the HTML code (See Understanding WCAG 2.1 Guideline 3.1).

Describe how the product or service ensures that text content can be read by people and by assistive technologies.

2.2.11 - Predictable

Predictability is essential for users with cognitive disabilities and those who are blind (See Understanding WCAG 2.1 Guideline 3.2).

Describe how the product or service appears and operates in predictable and consistent ways.

2.2.12 - Input Assistance

To fulfill this requirement, sufficient instructional cues, unambiguous error messages and other mechanisms that alert users to mistakes or help them avoid mistakes are present. Such mechanisms must be perceivable to users who have visual and/or hearing impairments (See Understanding WCAG 2.1 Guideline 3.3).

Describe how the product or service assists users to understand required tasks and to avoid, identify and correct mistakes. 

2.2.13 - Robustness and Compatibility

Users must not be required to use a particular operating system (if applicable), web browser (with reasonable limitations on version compatibility), or assistive technology. The product must utilize programming standards and ensure that the name, role and value of each interface element can be programmatically determined (See Understanding WCAG 2.1 Guideline 4.1).

Describe how the product or service works with commonly used operating systems, web browsers, and assistive technologies.

2.3 - Vendor Accessibility Practices

1. Describe the steps that will be taken when MTD submits a request to address an accessibility concern including how a mutually agreeable timeline to address the concern will be obtained.
2. Describe your process for on-going testing, maintenance, and remediation of the accessibility of the product or service.
3. Desired: Describe the role and qualifications of the individual(s) in your organization who will be dedicated to addressing accessibility issues. The representative(s) should be knowledgeable of the technical standards adopted by MTD and required by the ADA. They should be able to coordinate accessibility support for the product or service. The representative(s) should not be the same individual as a sales representative.
4. Desired: Provide a copy of a thorough and accurate Voluntary Product Accessibility Template (VPAT 2.1 Preferred) created based on the Technical Standards for the product or service proposed. The VPAT should describe the proposed version of the product. An updated VPAT must be provided for the product or service in its final status if the Respondent is awarded.

Desired: Provide a copy of accessibility reviews completed on the product or service and identify whether future accessibility reviews will be shared with MTD throughout the contract term.

2.4 - Non-Conformance

If the proposed solution does not fully conform to the WCAG 2.1 Level AA requirements as outlined in 2.2.1-2.2.13, Respondent must explain the nonconformance and provide a detailed implementation plan as to how they will achieve conformance and when. This requirement includes but is not limited to an intended timeline in order to meet any compliance issues. An updated VPAT must be provided for the product or service in its final status if the Respondent is awarded. 

2.5 - Responsiveness

Respondent is required to provide a detailed explanation as to how they will respond and resolve any conflicts, complaints, or other questions in a timely manner, regarding accessibility of its product or service. Respondent must include a timeline to indicate when resolution will be made.

 

Appendix E: Procurement Evaluation Template

Written Evaluation	Maximum Points	Points Awarded	COMMENTS: This Section MUST be completed, and notes written as to why the score was given.
Functional Accessibility Requirements
Text Alternatives	10
Captions and Audio Description	10
Adaptable	20
Distinguishable	20
Keyboard Support	20
Enough Time	10
Seizures	5
Navigable	20
Input Modalities	15
Readable	5
Predictable	10
Input Assistance	10
Robustness and Compatibility	20
Vendor Accessibility Practices (40 pts.)
Steps taken to respond to identified issues	10
Process for testing and maintenance	10
Identify accessibility representatives	10
Thorough and accurate VPAT	5
Accessibility reviews performed on product	5
Written Responses Total Score	215