Accessibility and SLS

The content of this page is based upon the SUNY Procurement Accessibility Conformance Standards (PACS).

Consistent with expectations of the field and requirements from emerging case law, PACS was created to proactively address EIT accessibility within SUNY purchasing policies and procedures. This Standard serves as a baseline for EIT compliance and inclusion. It is intended for anyone involved in purchasing electronic and information technologies. The Standard is also applicable to free and open source software, including but not limited to publisher materials and Open Educational Resources.

The following recommendations are intended to guide a smooth development of a process, to achieve the benchmarks within this set of standards.

Planning:
Key campus stakeholders should meet and discuss incorporating accessibility in the solicitation process.

• Determine classification of product purchase/adoption type (e.g., centralized, decentralized, open source)
• Create impact assessment (e.g., high, medium, low) and prioritization framework (e.g., new, renewal, public facing) for accessibility evaluation. Include a protocol for existing contracts.
• Establish a workflow that covers intake, review, exceptions, and monitoring compliance. Consider establishing a committee for determining approvals and denials.
• Designate roles and responsibilities for every step in the process.
• Identify a mechanism for documentation, to track progress and status for each product/service.

Awareness:
Educate vendors and all campus personnel involved in purchasing electronic and information technologies regarding the importance of accessible design.

• Develop training programs (e.g., engaging vendors about accessibility, reviewing and interpreting documentation, and generating Equally Effective Alternate Access Plans).
• Communicate accessible purchasing protocols across divisions, colleges, and departments. Consider creating an accessibility liaison system.
• Create an EIT Accessibility Inventory for campus community members to check if accessibility has already been evaluated and approved, to reduce the duplication of effort.
• Join SUNY and national communities of practice to share information and strategies for ensuring compliance (e.g., SUNY EIT Accessibility list-serv, SUNY Facebook Workplace Web Accessibility Group, ITACCESS EDUCAUSE list-serv, ATHEN).

Gauge the potential impact on the University of a particular product or service's accessibility.
Required

How to implement:
The following are common examples of rationale for determining accessibility impact level:
Low Impact

• EIT is not part of an essential program, service or activity
• Low number of users
• Single instance, intended for individual use

Medium Impact

• Limits access to a program/service, but not essential
• Moderate amount of users
• Use by an individual department or school, but not used across the entire campus
• Use by an entire college (one college within a larger campus)

High Impact

• EIT is part of an essential program, service or activity
• Great amount of users
• Public-facing or publicly available EIT
• Enterprise-wide EIT

Additional inaccessibility impact considerations include assessing disability subcategories who may be most affected by inaccessibility, such as those with color blindness, cognitive disabilities, manual impairments, hearing impairments, persons who are blind or have low vision, persons who are deaf or hard of hearing, and more.

To streamline impact assessment, consider creating a form to generate impact level. Human review by an accessibility professional is strongly advised, as persons who submit information on these forms may not realize the potential risk and impact of the product/services.
 

1. Include accessibility in pre-purchase documents/questionnaires
Required

How to implement:
Add an accessibility section in pre-purchase forms and questionnaires.
Sample questions for vendors:

• Do you have clients who require accessibility? If so, would you be willing to provide reference information for clients who can speak to the accessibility of your product?
• What experience do developers on your team have coding for accessibility?
• What standards are followed for coding of interfaces (if 508, what parts, if WCAG 2.0, which level)?
• Do you do testing with users with disabilities? If so, can you explain the process and identify, roughly, the range of disabilities and access technologies used?
• Does your company have a road map for accessibility going forward? If so, can you give us a general outline (goals, milestones)?
• Have you tested and/or developed your mobile apps with accessibility in mind?
• If we find that there are changes that need to be made to web/mobile interfaces/apps, what guarantee can we have that these will be implemented to our satisfaction prior to go-live/going forward?
• Would your company indemnify [Campus] against legal action related to accessibility?

Source: Procurement - Accessibility at University at Buffalo

2. Commitment to accessibility is reflected in RFP language
Required

How to implement:
Include the following language (approved by the Office of General Counsel) for the procurement solicitation that underscores accessibility commitment. Note that this language can be revised, provided any revisions meet the minimum requirements of ADA/504 accessibility conformance standards, as applicable.
1. Electronic and Information Technology (“EIT”) Accessibility

a. SUNY is committed to providing an accessible, usable, and integrated experience for all its students, staff and community. Electronic and information technology (“EIT”) consists of information technology and any equipment or interconnected system or subsystem of equipment that is used in the creation, conversion, or duplication of data or information that will be deployed in connection with such technology, equipment or systems. Further, EIT includes, but is not limited to, telecommunications products, information kiosks and transaction machines, Internet and Intranet websites, web-delivered content, software, electronic books and electronic book reading systems, search engines and databases, multimedia, classroom technology, and office equipment.
b. By submitting a Proposal, Proposer warrants that (i) Web-based EIT products included in the Proposal shall conform to Web Content Accessibility Guidelines (“WCAG”) 2.0 AA and (ii) non-web-based EIT products included in this Proposal shall meet or exceed the applicable accessibility requirements of section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. § 794d), and its implementing regulations set forth at Title 36, Code of Federal Regulations, Part 1194. If selected for award, selected Proposer agrees to provide evidence of compliance with these requirements before an Agreement becomes effective and any other time upon reasonable request of University.

3. Collect documentation verifying EIT accessibility conformance (e.g., Voluntary Product Accessibility Template).

Required

What it Means
The most universally recognized accessibility conformance documentation for EIT is called a Voluntary Product Accessibility Template (VPAT). A VPAT is a blank template. When a VPAT is completed, it is called an Accessible Conformance Report (ACR).

Characteristics of a reliable ACR:

• The salesperson knows what a VPAT is
• The vendor is using the most recent VPAT version (2.0+)
• VPAT was completed by a qualified 3rd party rather than self-completing
• Every Conformance Level is not “Supports”
• It is dated within the last year or two
• There are comprehensive Remarks and Explanations
• Real examples are provided
• Testing methodologies are referenced and described
• Reference to a roadmap plan and/or specific remediation dates
• The vendor has a reputation/history of dedicating resources to accessibility

Note: Please see Vendor Management for sample emails to request VPATs and response when a VPAT is not available.

4. Obtain an Accessibility Roadmap - document which addresses all [application] interface accessibility gaps, describes the timelines by which these accessibility gaps will be remediated, and recommendations regarding interim workarounds.
Required

How to implement:

• Create or adopt an Accessibility Roadmap Template that allows vendors to document accessibility gaps associated with their products and their plans to remediate these gaps in the future.
• Include a statement regarding the Accessibility Roadmap for all solicitations and contract documents.
• Request the vendor to complete the Accessibility Roadmap.
• Sample language for Accessibility Roadmap clause:

  - Within a reasonable time of the Effective Date of the Agreement, Vendor shall complete and return an Accessibility Roadmap document which addresses all accessibility gaps. Each criterion on the Accessibility Conformance Document (ACR) that has a Conformance Level response of “Partially Supports” or “Does not Support” must be included on the Accessibility Roadmap. The roadmap will identify gaps, describe the timelines by which these accessibility gaps will be remediated, as well as recommendations regarding interim workarounds. Vendor will provide revised Accessibility Roadmaps whenever revised VPATs are submitted.

1. High impact EIT products and services should be evaluated by an appropriately qualified individual or entity. This evaluation should be documented and can be performed by campus personnel or through third-party vendors. Cost for an external evaluation can be deferred to the prospective vendor(s).
Required

How to implement:

1. Add the following procurement solicitation requirement:
   • A comprehensive accessibility evaluation is required from an objective, independent, third party verifying the claims made on the product Accessibility Conformance Report (VPAT 2.X), or equivalent. Bidders may use a third party accessibility evaluation service of their choice.
2. For campuses that have knowledgeable staff in EIT accessibility evaluation:
   • Minimally, conduct an ACR or equivalent conformance documentation evaluation. Establish a process to comprehensively review the ACR conformance levels (Supports, Partially Supports, Does not Support, or Not Applicable) for each prospective and renewed product or service. Each review should be documented, with explanations and comments regarding the accessibility of all functions, and agreed upon time frames for improving conformance of inaccessible functions.
   • Ideally, conduct a comprehensive evaluation through automated, manual, and functional testing.
     • Automated Testing comprises of free or fee-based tools that crawl and scan websites for accessibility. Automated tools typically address only 30% of a websites accessibility and can create false positives. There are numerous free platform agnostic browser accessibility tools (e.g., Accessibility Insights, aXe)
     • Manual Testing requires human review to check for accessibility issues because automated tools cannot currently check for certain criterion. Check for captions on videos (e.g., automatically versus manually captioned, intelligibility of captions).
     • Functional Testing utilizes various assistive technology (e.g., screen reader, voice control) to check accessibility and usability of electronic and information technologies. Ideally, a native assistive technology user would test for accessibility at this step.

The following is an example of an approach to accessibility testing:

1. Automated: Siteimprove and WAVE
2. Manual: Keyboard-only navigation, checking for captions, alt text, links, color contrast
3. Functional: NVDA, JAWS Inspect, Voiceover

For manual and functional testing, consider using a Strategic Web Accessibility Technique (SWAT) approach. The following four concepts cover most accessibility issues (>60%)

• Keyboard-only navigation
• Images & colors
• Document structure
• Form interactions

Basic keyboard navigation of web pages include use of the following keys:

• Tab
• Shift + Tab
• Arrow keys
• Escape keys
• Space bar
• Enter key

For keyboard-only navigation, check the following:

• Skip repetitive navigationAll links and interactive elements are available using keyboard alone
• Tabbing order is logical
• Keyboard focus is visible
• No keyboard traps

 

2. Conduct Exceptions on a case-by-case basis.
Required

In rare circumstances, the following factors may qualify as exceptions:

1. Where an accessible alternative does not exist commercially.
2. Where compliance is not technically possible or may require extraordinary measures due to the nature or intent of the information resource, application or service, a request for exception must be made. Lack of sufficient funding for any particular college, department, program, or unit of the University would not be considered for an exception.
3. Where compliance would result in a fundamental alteration of the information resource, application, or service, and not satisfy the original intent.
4. Where, in the case that information resources, applications and services that are procured through third party vendors or contractors; and that no alternative accessible products are available from other third party vendors or contractors, procurement can be made of a non-compliant product.
5. Where the product is not currently in compliance, but efforts are underway to fix the defects by a defined date.

Please note: When an institution asserts an undue burden or fundamental alteration defense, such an assertion may be made only by an individual designated by the institution’s President or designee who has budgetary authority after considering all resources available for use in the funding and operation of the service, program, or activity, and must be accompanied by a written statement of the reasons for reaching that conclusion, including the cost of meeting the technical standard and the available funding and other resources. The written statement will be certified by the determining official. If such a determination is made, the certifying official will describe in the written statement how it will provide equally effective alternate access, i.e., other action that would not result in such an alteration or such burdens but would nevertheless ensure that, to the maximum extent possible, individuals with disabilities receive the same benefits or services provided by the institution as their nondisabled peers.

How to implement:
Consider establishing a process for requesting, receiving, and reviewing Exceptions for EIT.
The process should document an explanation as to how or why the product or resource meets the rationale for an exception, and describe the reasonable accommodations which could be made to provide equal and equitable access to individuals with disabilities affected.
Each review should be documented, with a signature from the determining official authorizing a full approval, conditional approval, or a denial.

 

3. Prepare an Equally Effective Alternate Access Plan for non-conforming EIT.
Required

How to implement:
Campuses should create an Equally Effective Alternate Access Plan (EEAAP) to address accessibility issues for non-conforming EIT. Purchase Requestors, who understand the essential components of the EIT they seek to procure and maintain, should consult a qualified individual(s) or entity to assist with creating a plan to ensure comparable access to individuals with disabilities.

 

4. Evaluate RFP EIT finalists through live accessibility demonstration.
Strongly Recommended

How to implement:

Request the vendor to demonstrate the accessibility of their product or service. The vendor representative needs to be able to demonstrate the actual accessibility functionality of the product. Alternatively, provide the institution access to a demo site.

Sample Vendor Accessibility Demonstration Script:

1. Demonstration of functionality without a mouse, using a keyboard only. For reference, see the no mouse challenge. Install and utilize a Force Focus Bookmarklet such as Paul Adam’s Force Focus Bookmarklet to enhance focus as necessary during the demonstration.
2. Demonstration of user experience navigating and interacting with a variety of product functions using a desktop screen reader such as JAWS and/or NVDA.
3. Demonstration of user options for selection of color contrast and styles. Provide demonstration of the free pre-installed tool Paciello Colour Contrast Analyser during conversation about color contrast.
4. Demonstration of user interface response to screen magnification assistive technologies such as ZoomText. Include a demonstration, as appropriate, of the product’s response to 200% zoom using the browser's zoom function.
5. Install the WebAIM WAVE Browser Tool and walk through the user interface.
6. Provide information about the accessibility of interfaces for system administrators.
7. Source: Five College Consortium, handout by Rob Eveleigh

    

1. Include accessibility assurances in product license agreements; add milestones to remediate accessibility gaps identified in accessibility roadmap.
Required

How to implement:
SUNY’s Office of General Counsel has approved the following Electronic and Information Technology (“EIT”) Accessibility language for contracts:

Electronic and Information Technology (“EIT”) Accessibility.

1. University is committed to providing an accessible, usable, and integrated experience for all its students, staff and community. Electronic and information technology (“EIT”) consists of information technology and any equipment or interconnected system or subsystem of equipment that is used in the creation, conversion, or duplication of data or information that will be deployed in connection with such technology, equipment or systems. Further, EIT includes, but is not limited to, telecommunications products, information kiosks and transaction machines, Internet and Intranet websites, web-delivered content, software, electronic books and electronic book reading systems, search engines and databases, multimedia, classroom technology, and office equipment.
2. Contractor warrants that (i) Web-based EIT products provided under this Agreement shall conform to Web Content Accessibility Guidelines (“WCAG”) 2.0 AA and (ii) non-web-based EIT products provided under this Agreement shall meet or exceed the applicable accessibility requirements of section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. § 794d), and its implementing regulations set forth at Title 36, Code of Federal Regulations, Part 1194.
3. Contractor agrees to provide evidence of compliance with these requirements before this Agreement becomes effective and any other time upon reasonable request of University. Contractor will provide accessibility testing results and written documentation verifying accessibility, and to promptly respond to and resolve accessibility complaints. In the event EIT provided under this Agreement does not fully conform to the standards set forth above, the Contractor will promptly advise University in writing of the non-conformance and provide detailed information regarding the plans to achieve conformance, including but not limited to an intended timeline. Contractor agrees to promptly respond to and resolve any complaint regarding accessibility of its products or services.
4. Failure to comply with these accessibility standards shall constitute a breach of this Agreement. Contractor agrees to indemnify and hold harmless University from any claims arising out of its failure to comply with the foregoing accessibility standards.
   With respect to remediation milestones and accessibility improvements, work with campus counsel to tailor language for the product license agreement rider. The language should reflect the agreement of the Accessibility Roadmap. For example: “Vendor agrees to be WCAG 2.0 compliant by January 30, 20XX”.

 

2. Set a calendar date to check in with vendor regarding accessibility improvements (e.g., annually)
Strongly Recommended

How to implement:
Once the institution concludes when they will follow up with the vendor regarding progress towards accessibility conformance, the designated campus department or individual set a calendar reminder to follow up with the vendor and document progress with the procurement office or EIT Accessibility Officer.