Accessibility requirements apply to every technology purchase.
If you are purchasing, renewing, or contracting for software, a platform, or any technology tool on behalf of UCLA, including free products, low-cost subscriptions, and click-through agreements, then accessibility requirements apply to that purchase.
Under UC IMT-1300 and federal law, UCLA may not acquire technology that creates barriers for people with disabilities. Vendors must meet WCAG 2.1 AA, and it is your responsibility as the requester to verify that before the contract is signed: not after. This includes technology purchased with a PCard, unreviewed renewals, and tools adopted informally by a department. There is no purchasing pathway that bypasses accessibility review.
This applies to:
- Software and SaaS platforms
- Learning tools, LTIs, and Bruin Learn integrations
- Research and administrative applications
- Mobile apps, kiosks, and digital tools
- Any tool UCLA community members are required to use
The UCLA Purchasing Triage Process
Accessibility review is built into UCLA's purchasing triage process alongside security and privacy. All technology purchases must go through the GRC Triage Form before procurement. There is no separate accessibility form: accessibility questions are part of the standard triage submission.
Plan ahead. The review process takes a minimum of 6–8 weeks. Twelve weeks is the recommended lead time. Submitting late is the most common cause of delays and the most common reason departments end up locked into non-compliant tools.
Come prepared. The triage form does not support partial saves. Before you start, collect the following:
- The vendor's website URL
- A link to the vendor's accessibility statement or Accessibility Conformance Report (ACR) / VPAT
- A trial, demo, or testing environment link and credentials (many tools cannot be reviewed without one)
- A vendor contact who can answer accessibility questions
- A clear description of how the tool will be used and who will use it
What to ask a vendor
Before purchasing or renewing, units should:
- Request a current VPAT or Accessibility Conformance Report (ACR)
- Review known accessibility barriers and the vendor's remediation plan
- Use contract language that reinforces accessibility obligations and remediation expectations
- Avoid deploying inaccessible technology unless an approved exception and alternate access plan are in place
Procurement is strongest when VPATs provide visibility and contracts provide enforcement. UCLA's current risk review found that many third-party tools do not yet have both.
No accessibility statement from the vendor? That's a red flag. All digital vendors should have publicly available accessibility documentation. If a vendor can't produce one, treat that as a signal about their compliance posture before you commit.
Security, Privacy, and Accessibility: One Process
The GRC Triage Form handles security, privacy, and accessibility in a single submission. If your purchase already went through TPRM for security review, accessibility was part of that same process; but the accessibility questions are only as useful as the information you provide. A thorough submission gets a faster turnaround.
Security, privacy, and accessibility are handled in a single triage submission. A thorough submission gets a faster turnaround.
Already purchased a non-compliant tool?
If you've contracted for a technology tool that doesn't meet WCAG 2.1 AA, you have two paths forward: work with the vendor on a remediation timeline, or initiate an exception with an Equally Effective Alternate Access Plan (EEAAP) that ensures affected users are not excluded in the meantime.
