Vendors can demonstrate a commitment to accessibility in several ways, including: 

• Creating, adhering to, and maintaining an accessibility statement. A statement that includes a commitment to equal access, information about accessibility features and barriers, and a way for users to provide feedback 

• Creating, adhering to, and maintaining an accessibility policy. A policy that includes language about application, maintenance, and definitions, and that clarifies the vendor's commitment and responsibilities. 

• Completing, updating, and maintaining a current Accessibility Conformance Report (ACR) for each product. Also known as a completed Voluntary Product Accessibility Template (VPAT), this report is available to all vendors to document product accessibility with specific data. 

• Ensure digital EIR comply with keyboard, and screen reader accessibility. A vendor can demonstrate the product's key features using only a keyboard and screen reader.

• Third-party assessment. Vendors may conduct an accessibility assessment of the product or service by a qualified accessibility personnel at UHS or a third-party assessor.

It is important to document accessible Electronic and Information Resources (EIR) to support several functions, including:

• Accessibility: Accessible EIR allows people with disabilities to use and understand the information, which provides access to people with visual, hearing, cognitive, or moto-related conditions.

• Usability: Accessible EIR can increase the visibility and usability of resources, making them user-friendly to a wider audience.

• Compliance: Accessible EIR complies with legal requirements, reducing risk for organizations to face internal complaints and other legal action.

• Procurement: Accessible EIR meets state and federal rules that expect public institutions of higher education to spend public dollars on accessible products to meet their business needs and serve the public good.

When researching the accessibility of a product or service, you can:

• Search for the vendor's completed VPAT on their website.
• Request a completed VPAT from the vendor if it is not available online.
• Compare completed VPATs of various products or services.
• Ask the vendor how they test for accessibility and request test results from the vendor.
• Ask for a product demonstration so someone familiar with accessibility from your department can experience product performance firsthand.

When engaging with a vendor for a technology product or service, it is important to assess their experience with accessibility so that you can determine their ability to comply with UHS’ EIR Accessibility Policy. These questions can help you start a conversation with the vendor about their commitment to accessibility in their work. 

Overall approach to accessibility

• What is the name, title, and contact information for the most appropriate accessibility contact for the product or service under consideration?
• What is your approach to ensuring accessibility in your product or service? Please provide examples of how you have done so in the past.

Product/Service documentation

• What accessibility documentation exists for this product or service, such as a completed Voluntary Product Accessibility Template ("VPAT") (otherwise known as an Accessibility Conformance Report or "ACR")? When was that documentation last updated?
  • Check to see if the documentation matches the current version of the product.
• The UH System EIR Accessibility Policy cites technical standards which UHS procured an developed products and services must comply are found in TAC 213.38, and website standards are found in TAC 206.70. What technical or legal accessibility standard of conformance do you adhere to for the product or service in question? 
• If there are any identified accessibility issues: Can you provide a current, detailed plan for accessibility improvements (roadmap) to be made on your product or service, with dates of intended delivery?

Testing and user experience

• How do you assess your product or service for accessibility? Do you have accessibility testers in-house, for example, in the quality assurance department, or do you hire an outside accessibility consultant?
• Can you provide a live or recorded demo of the product or service being used with assistive technology (i.e., screen reader and/or non-mouse input)?
• Does your product or service rely on activating a special "accessibility mode," a "lite version," or accessing an alternate interface for accessibility purposes?
• Describe the process of a user reporting an accessibility issue. What would they experience? Can you give examples of how you have used that feedback to improve your product or service.

Credible evidence is a term used in the UH System EIR Accessibility Policy to cover a range of materials a vendor can supply to demonstrate the accessibility of a product. 

Credible evidence is required for procurement of EIR, or the institution must use an exemption under law (with very limited application) or an exception process as defined in state law.

Accessibility Conformance Report (ACR)

The ACR is a completed Voluntary Product Accessibility Template (VPAT), a detailed report which the vendor uses to self-assess areas of compliance for digital products. While the current VPAT/ACR is the preferred form to document credible evidence as the industry standard, UHS policy does allow vendors to use other forms of documentation for credible evidence.

Other Forms of Credible Evidence

The UHS policy gives the vendor several types of credible evidence which are each explained below. Forms of credible evidence that departments may use to consider vendor products include:

• Internal Accessibility Policy Documents
• Contractual Warranties for Accessibility
• UHS Checklist to Select Accessible Technology Form
• Accessibility Testing Documents
• Examples of Prior Work Results
• Vendor Accessibility Development Services Information Request (VADSIR)
• Higher Education Community Vendor Assessment Toolkit (HECVAT)

It is important to note that by state law and UHS policy, vendors who cannot or will not provide some form of credible evidence are considered non-compliant. 

Accessibility Warranty Clause

Make sure the Accessibility Warranty Clause is included in the vendor contract. By signing it, a vendor commits to upholding UHS’ accessibility standards. This will help address accessibility issues promptly if they arise after the product is in use.

For more information, Download the Accessibility Warranty Clause (Standard Contract Addendum, Clause 28) from the Office of Contract Administration (OCA) website. If a warranty clause is not provided in your contract, use the UHS Checklist in the next section below.

UHS Checklist to Select Accessible Technology

When a vendor will not sign the UHS accessibility warranty clause included in UHS procurement contracts, it becomes necessary to assess a product’s accessibility based on credible evidence provided by the vendor or apply applicable exemptions.

Departments should begin their assessment using the UHS Checklist to Select Accessibility Technology form. Contact your campus EIRAC if you have questions about the form.

VADSIR 

The Department of Information Resources (DIR) created the Vendor Accessibility Development Services Information Request (VADSIR) to assist in evaluating a company's ability to deliver compliant services. The VADSIR survey allows a purchaser to gain insight into a vendor's commitment to accessibility by asking questions that probe into the organization's policies, procedures, and service delivery strategies. The survey is comprised of six questions that enable the vendor to document their commitment to creating compliant deliverables.

HECVAT 

The Higher Education Community Vendor Assessment Toolkit (HECVAT) is a questionnaire-based framework from Educause that helps higher education institutions assess the risk of vendors and ensure the security and privacy of cloud services. HECVATs are used to:

• Measure vendor risk - Before purchasing a third-party solution, institutions can ask the provider to complete a HECVAT assessment to confirm that they have policies in place to protect sensitive information.
• Ensure cloud service security - HECVAT helps institutions ensure that cloud services are appropriately assessed for security and privacy needs.
• Standardize information security and data protection - HECVAT aims to standardize information security and data protection requirements for cloud service providers.

The HECVAT looks at a vendor's information, data, and cybersecurity policies to protect the University's sensitive information. The IT Accessibility section of the HECVAT addresses accessibility competency and can serve the same purpose as the VADSIR.

Exception Process 

If the vendor does not supply UHS with sufficient evidence and does not qualify for an exemption under law, the procuring department must go through an exception request process.

Under state law, an exception may only be approved by the University President when all of the following are provided by the department:

1. Date of expiration or duration of the exception,
2. Plan for alternate means of access for persons with disabilities,
3. Justification for exception (including technical barriers, cost of remediation, fiscal impact to bring into compliance and other identified risks), and
4. Documentation of how the University considered alternative solutions and all institutional resources available to the applicable program or program component.

Created by the Information Technology Industry Council (ITIC), the Voluntary Product Accessibility Template (VPAT) is a document that explains how a product conforms to accessibility standards such as the Web Content Accessibility Guidelines (WCAG).

Once the VPAT is completed, it is sometimes referred to as an Accessibility Conformance Report (ACR).

A VPAT has two parts, a Product Information Page, and the Success Criteria Table. Extensive knowledge of accessibility standards is not needed for a quick assessment of product compliance.

Product Information Page

The VPAT requires the vendor to list details about the product, including the name of the product, the date of the report’s creation and the evaluation methods used. A quick assessment of the information here can give you a sense of the quality of the vendor’s approach to accessibility.

• Report Title – In the heading format of “[Company Name] Accessibility Conformance Report”
• VPAT Heading Information – Template version. Check the ITIC website for the current version of the VPAT template.
• Name of Product/Version – Name of Product being reported, including product version identifier if necessary. Make sure the VPAT you are evaluating is for the correct product version.
• Report Date – Date of report publication. If the VPAT is more than a year old, it may be out-of-date. Check to see if the product or VPAT template as a new update.
• Contact Information – Contact Information for follow-up questions. Ideally this is the person that performed the assessment, like a third-party expert or in-house accessibility subject matter expert.
• Evaluation Methods Used – A detailed description of evaluation methods used to complete the VPAT for the product. Specificity and robustness are good signs here. For example, “Assessed with a screen reader” does not tell us much. Instead, a statement such as, “Tested the X user workflow using NVDA screen reader, keyboard and [website monitoring tool],” is much better.
• Applicable Standards/Guidelines – UH System’s policy indicate adherence to standards included in TAC 213.38 and TAC 206.70 for websites.  VPATs that are still listing WCAG 2.0 or Section 508 as the applicable standard are out-of-date.

Success Criteria Table

This is the section that documents product compliance with WCAG criteria. Products should conform to current Web Content Accessibility Guidelines (WCAG) standards. Conformance with the WCAG standards ensure products are inclusive to all UHS university community members and members of the public with disabilities. Please note standards are subject to periodic change based on federal and state requirements. Contact your campus EIRAC to verify current applicable standards.

Levels of WCAG compliance are divided into separate tables (A, AA, and AAA). Each table has three columns:

Column 1: WCAG Success Criteria

Each row lists a WCAG Success Criteria. Table 1 includes “A Level” success criteria, followed by "AA Level" in Table 2.

Source: Web Content Accessibility Guidelines (WCAG) 2.1

Column 2: Conformance Level

The vendor indicates the conformance level in the second column with one of the following:

• Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
• Partially Supports: Some functionality of the product does not meet the criterion.
• Does Not Support: The majority of product functionality does not meet the criterion.
• Not Applicable: The criterion is not relevant to the product.

Note that if the vendor is marking most rows as “Supports” or “Not applicable,” it could be an indication of a lack of critical assessment. You may find more assurance working with a vendor who identifies their flaws—and plans for improvement—versus those who claim perfection with little to no evidence.

Column 3: Remarks and Explanations

There is a third column that allows the vendor to include notes specific to that criterion and their compliance. Ideally each cell in this column is populated with notes, regardless of whether the product supports the Success Criteria or not. An empty Column 3 should be considered a red flag.

Potential VPAT Follow Up

Having a VPAT is a good sign, but it does not mean that the “accessibility” box is fully checked. Vendors should be prepared to answer questions about their VPAT.

• What tools or methods were used to complete the VPAT? (If the “Evaluation Methods Used” section was not satisfactory)
• Can your company provide a copy of the accessibility test plan and testing results that were used to complete the VPAT?
• Is there an accessibility roadmap in place to deploy updates to resolve accessibility issues found in the VPAT?

Further questions about VPATs can be directed to your campus EIRAC.

UH System university websites built or redesigned after April 18, 2020,  including those designed and built by third-party vendors, are expected to be accessible in accordance with the UHS EIR Accessibility Policy (SAM 01.D.13). This means they should conform to current Web Content Accessibility Guidelines (WCAG) standards,  which is currently WCAG 2.1 AA.  It is recommended to check with your EIRAC for questions on the current WCAG standard as standards are subject to periodic change based on federal and state requirements. Conformance with WCAG standards ensure products are inclusive to all UHS university community members and members of the public with disabilities.

One of the first steps in selecting a vendor to build or design a UHS university website is to determine if they will be able to adhere to UHS’ accessibility policy guidelines in their work. Assessing the vendor’s competence and experience with digital accessibility is important early in the vendor selection process so that site owners may weigh multiple vendors who are able to deliver accessible sites, and then make a selection based on other important criteria. 

Include accessibility in your Request for Proposal (RFP)

When submitting an RFP to vendors, be sure to include language that communicates accessibility as a priority for the new website. 

For example, in the RFP for a website redesign, specific language should be included in the request advising vendors the new website must meet UH System’s accessibility requirements (WCAG 2.1 Level AA), and that UHS expects the website to conform to accessibility requirements and serve as a model of web accessibility.

Things to look for in website vendors:

• Is the vendor’s own website accessible? 
• Are Request for Proposal (RFP) responses or other materials provided by the vendor accessible? 
• Does the vendor have other content, such as blog posts or presentations mentioning accessibility?

Be cautious when the vendor’s primary mentions of accessibility are for delivering “ADA compliant” websites — this might be a sign that expertise and understanding of web accessibility are lacking.

Also, be warry of vendors who confuse website accessibility questions with questions about other general website features (such as visual appeal).

Questions to ask a potential vendor:

Some questions to ask you may want to start with for website vendors include:

• Have you built accessible websites in the past that adhere to WCAG 2.1 AA standards?
  If yes, ask to view recent projects that have met WCAG guidelines. Use an automated tool like Siteimprove or the Wave browser plugin to check the accessibility of the vendor’s project websites.
  • Learn more about how to review website accessibility by requesting a campus workshop or reviewing the resource materials on this website.
• Do you have accessibility experts in your design / development team, or do you hire outside accessibility consultants? 
• If the vendor has no internal accessibility experts and does not collaborate with consultants for expertise, it may be an indication that they do not prioritize accessibility as a regular part of their work. 
• How and when do you test for accessibility? 
  A preferred response might be that they use a combination of methods, including automated tools, manual testing, expert review, and tests with assistive technology like screen readers throughout the lifecycle of the project — not only at the very end of the site design and development. 
• How do you document and report to the client that the finished product is accessible?
  A preferred vendor should have an established process of documenting and communicating accessibility of the features and functionality it builds. 

Check with other UH System clients.

• Browse contracts in the procurement database to see if previous UHS university departments have worked with the vendor or if the vendor previously signed UHS’ EIR Accessibility Warranty. 
• If you find that the vendor has worked in the UHS, check with those UHS contacts about the vendor’s ability to deliver on the contractual requirements, and about the process they used. Ask to sample deliverables or generally how the vendor approached and verified accessibility.

Vendors who have worked with UH System universities 

We are interested to hear your experiences working with vendors who have signed the EIR Accessibility Warranty Clause and created deliverables at UHS universities. Contact your campus EIRAC or SEIRAC and let us know about your experience! 

1. Save any key accessibility documentation along with the contract.
2. Retain a signed copy of any exception documentation and other relevant credible evidence for monitoring and management purposes. Create calendar events for promised milestones and check on progress.
3. Forward a copy of all documentation to the procurement manager for your department record-keeping.

When renewing a contract, the Accessibility Warranty Clause should be re-offered, regardless of whether it was signed previously. Accessibility documentation should also be reviewed for renewal, including:

• VPAT/ACR reports;
• Past Temporary Exception Forms (check to see if milestones were completed in timely manner); and/or
• Other applicable vendor documentation as listed above.

Contact your campus EIRAC for assistance with document review when contracts are renewed.

UHS campus EIRACs would like to learn about good or poor experiences with vendors regarding accessibility. 

For updates about your experience, questions related to accessible EIR procurement or for other questions about digital accessibility in general, contact your campus EIRAC.

"Building Accessibility into Your Procurement Process," U.S. General Services Administration.

"Accessibility In Procurement I: Pre-Soliciation," U.S. General Services Administration. Other topics in this resource include:

• Request Accessibility Information from Vendors & Contractors
• Understanding Vendor Claims in Accessibility Conformance Reports for Section 508 Conformance
• Accessibility In Procurement II: Solicitation & Post-Solicitation