Like web and instructional materials, purchased software must also be reviewed and vetted for WCAG compliance and Accessibility. Follow the guided steps below to ensure risk mitigation in the procurement process. This process should be repeated at each contract renewal, or every three years, whichever comes first.
The graphic below demonstrates the recommended workflow for assessing risk and addressing the accessibility of your requested product.
Assess Use Case
Depending on your particular use case, different products will pose different levels of risk. While it is not a perfect system, we can mitigate risk via the number of users:
- Tier 1: 1,000+ users
- Tier 2: 100+ =users
- Tier 3: 100 or fewer users
- Tier 4: Single user
Note: All public-facing content, including web apps and digital marketing platforms are assumed to reach over 1,000 users and identified as "High Risk." All Tier 1 procurement requests should include a VPAT review by the Digital Accessibility office.
Any use case that includes users utilizing assistive technology should be considered Tier 1.
Accessibility Conformance Reports
For High Risk assessments, Accessibility Conformance Reports (ACRs) must be evaluated before the procurement process can proceed. In cases where products prove to be partially or fully noncompliant, an Equally Effective Alternative Access Plan (EEAAP) must be developed, signed and documented.
ACRs may be identified in any of the following ways:
- Voluntary Product Accessibility Template (VPAT)
The most common form of ACR, VPATs evaluate products for each WCAG indicator and provide a summary of potential barriers based on a user's disability. - Higher Education Community Vendor Assessment Toolkit (HECVAT)
Created by leaders in higher education in collaboration with EDUCAUSE, the HECVAT is a comprehensive questionnaire that companies can complete to provide a detailed picture of their cybersecurity, privacy, IT accessibility, and compliance standards in one place. - UC Procurement Accessibility Questionnaire
If no VPAT or HECVAT exists, UCOP recommends sending a UC Procurement Accessibility Questionnaire as an abbreviated ACR that provides essential conformance information.
For Medium Risk assessments, ACRs must be evaluated before the procurement process can proceed. In cases where products prove to be partially or fully noncompliant, EEAAPs or simple workarounds may be required on a case-by-case basis.
For Low Risk or No Risk assessments, ACRs should still be collected and reviewed, however a full evaluation may not be necessary for the particular use case, unless they are known to directly affect a population of Dis/abled users.
- Finding ACRs
- UC Davis maintains an ACR Library (opens in new window) from common software vendors. We recommend checking this library for existing documentation before reaching out to vendors.
Important: A vendor providing an ACR does not mean the product is accessible. Reviewing and assessing documentation is crucial for assessment.
When working with a vendor on a potential purchase, the first step is finding or requesting an Accessibility Conformance Report (ACR). ACRs usually take one of two forms: (1) Voluntary Product Accessibility Template (VPAT), or (2) Higher Education Community Vendor Assessment Toolkit (HECVAT).
While neither is a perfect one-size-fits all solution, either will provide important documentation and context for making procurement decisions. Some vendors make documentation openly available to the public (see: Microsoft ACRs). Others make it a little harder. If you are unable to easily find an ACR, contact your vendor representative for assistance.
Please submit ACRs obtained from vendors to the UC Davis library. - Hidden ACRs
- Some vendors make it very difficult to get ahold of their documents, or don’t have them at all. It is not recommended that you sign a Non-disclosure agreement or any other limiting document as a prerequisite to receiving a VPAT or ACR. Accessibility conformance is not proprietary information, and can be independently tested by end users, and therefore should not require an NDA. Push back on any such request and insist on receiving documentation. A vendor who will not, or cannot produce a VPAT or ACR should be treated as though they have not completed any Accessibility assessment, and therefore pose potential risk to the campus.
- Incomplete ACRs
- Not all Accessibility documentation is created equal. VPATs and ACRs are usually made up of a few key components:
(1) Accessibility compliance standard, assessment date(s), and product versions
(2) Compliance status with WCAG or Section 508 success indicators
(3) Support explanation or context for each indicator’s compliance or non-compliance status
For UC Davis’s purposes, documentation should be evaluated against WCAG 2.1 AA standards. If AA evaluation is incomplete, or lacks narrative context, that may be a sign that the product is inaccessible, or the assessment was not thorough, and should be treated as noncompliant.
ACRs that evaluate against WCAG 2.2 and/or AAA standards are not currently necessary to ADA Title II requirements, however they may be indicative of above and beyond compliance. WCAG 2.2 is backward-compatible with 2.1. - Missing ACRs
- Not all vendors have completed Accessibility documentation. In these cases, requestors should send the UC Procurement Accessibility Questionnaire to be completed by the vendor. This questionnaire is a briefer assessment that provides a quick overview of some of the vendor’s known compliance or non-compliance issues.
Don’t be fooled: Some vendors have Accessibility statements or compliance goals available publicly. However, these do not stand in for a proper ACR. - Evaluating ACRs
For each WCAG indicator, your ACR should list a compliance status of “Supports,” “Mostly/Partially Supports,” “Does Not Support,” “Not Applicable,” or “Not Evaluated.” To be fully compliant, a product’s ACR must list all WCAG 2.1 AA indicators as “Supports.”
Note: most ACRs will not be fully compliant.
Any/all ACRs that do not meet a full compliance standard should be further reviewed for risk mitigation.
In addition to compliance level status, each non-compliant indicator should include some narrative or context as to how or why it doesn’t meet the standard. This context could be as simple as “in one limited instance, text clipped when zoomed in past 200%.” This issue, while important to visually impaired users, may not rise to the level of high risk.
By comparison, the context could also say something like “Most form elements lack description and are therefore not accessible to screen reader users,” which demonstrates complete inaccessibility for some users.
The difference in these contextual descriptions provide a basis for whether or not it rises to a level of risk that would require development of an EEAAP (see below), or that UC Davis is unable to accept.NotebookLM, a supported product at UC Davis, can be very effective at analyzing individual ACRs for conformance. If you receive a VPAT or Accessibility questionnaire, consider uploading it to
NotebookLM and enter the following prompt:
"Act as an accessibility procurement specialist. Review this conformance report and provide me with a list of WCAG indicators listed as Does Not Support, Mostly Supports, or Partially Supports. Please also provide a brief narrative to the general accessibility of this product, and any functional barriers it may pose to users with disabilities."
Note: Quality control is always necessary when using AI, and you may need to check responses for accuracy.
Equally Effective Alternative Access Plans
EEAAPs are documentation of alternative plans or workarounds in cases where software proves to be inaccessible or noncompliant with WCAG 2.1 AA. In most cases EEAAPs will be developed as an effort between the requestor, Digital Accessibility Program Manager, and potentially the vendor.
- Starting an EEAAP
- To pursue an EEAAP solution, the requestor will be asked to provide:
(1) The use case and assessed level of risk,
(2) Any ACR documentation provided by the vendor
(3) A specific description of how the application is intended to be used, including any support available for users (i.e. faculty office hours, computer lab staff, or online software instructions provided to users).
Once the Digital Accessibility Program Manager has the necessary information, they may begin a dialogue between the parties to find a solution that limits the amount of functional risk to UC Davis, and does not pose an “undue burden” on Dis/abled users. - Drafting an EEAAP
- The Digital Accessibility Program Manager may ask requestors to draft a proposed solution for moving forward with the product, providing any notes or guidance on what they perceive as functional risks or barriers to user access. Ultimately it will be up to departmental leadership what workload they are able to take on to make the product work.
EEAAPs can range in complexity. Some will be as simple as identifying open lab hours or staff to assist users navigate software, where others may provide very specific instances and ways the product can and cannot be used. In all cases, EEAAP stipulations will be reviewed for efficacy at the time of contract renewal, or biannually. - Finalizing an EEAAP
- Once an EEAAP solution is agreed to, it will be signed and filed along with other procurement documentation. EEAAP agreements will be made available in a central ACR repository as precedent for other programs seeking to purchase the same product(s).
If you have any questions or would like to request training on the procurement review process listed above, please contact the Digital Accessibility Program Manager. You may also attend Access Q&A to ask questions, Wednesdays at 10:00 AM.