University of Arizona · Digital Accessibility

Accessible Procurement Process

Ensuring technology purchases meet accessibility requirements before contract signing.

Why Accessible Procurement Matters

The best time to ensure accessibility is before you buy. Once a contract is signed, you have limited leverage to request accessibility improvements.

The Cost of Inaccessible Purchases

Applies To

Accessibility review is required for:

The Procurement Process

Step 1: Identify Accessibility Requirements

At the start of your procurement:

Step 2: Include Accessibility in RFP/RFQ

Your request for proposals should include:

Step 3: Request VPAT from Vendor

Ask vendors to provide:

Red flags: Vendors who don’t have a VPAT, provide outdated VPATs, or claim “full compliance” without documentation.

Step 4: Submit for Accessibility Review

  1. Submit the VPAT/ACR to the Digital Accessibility team via the ServiceNow Accessibility Review Request form
  2. Include product name, version, and intended use (e.g., student-facing, faculty-only, or public)
  3. Provide vendor contact information for follow-up technical questions
  4. Allow 5–7 business days for an initial risk assessment report

Step 5: Review Results and Decide

After review, you’ll receive:

Step 6: Include Accessibility in Contract

For approved purchases, contracts should include:

Process Flowchart

  1. Need identified — Involves technology?
  2. Yes → Request VPAT from vendor
  3. Submit VPAT to Digital Accessibility team
  4. Review completed — Risk assessment
  5. Low risk → Proceed with standard terms
  6. Medium risk → Proceed with conditions (remediation plan)
  7. High risk → Seek alternatives or document exception
  8. Contract executed with accessibility terms

Vendor Accessibility Evaluation Questions

Use these questions during the RFP/RFQ process to evaluate a vendor’s commitment to accessibility. They align with DOJ Title II web accessibility requirements and the April 2026 compliance deadline.

How to use: Include relevant questions in your RFP/RFQ. Use the “What to look for” guidance to score vendor responses.

1. Accessibility in the Development Lifecycle

Ask the vendor:

What to look for:

2. Alignment with DOJ Guidelines

Ask the vendor:

What to look for:

3. Ongoing Accessibility Maintenance

Ask the vendor:

What to look for:

4. Response to Accessibility Issues

Ask the vendor:

What to look for:

5. Partnership and Collaboration

Ask the vendor:

What to look for:

6. Transparency and Reporting

Ask the vendor:

What to look for:

7. Training and Certifications

Ask the vendor:

What to look for:

8. User-Centric Testing

Ask the vendor:

What to look for:

9. Accountability and Continuous Improvement

Ask the vendor:

What to look for:

10. Contingency Plans and Risk Management

Ask the vendor:

What to look for:

Understanding VPATs

The Voluntary Product Accessibility Template (VPAT) is the standard format for vendors to report product accessibility.

What’s in a VPAT

Conformance Level Meanings

Level Meaning
Supports Functionality meets the criterion without known defects
Partially Supports Some functionality meets the criterion; some gaps exist
Does Not Support Majority of functionality does not meet the criterion
Not Applicable Criterion does not apply to the product
Not Evaluated Not tested (concerning if used frequently)

Red Flags in VPATs

See Detailed VPAT Review Guide for more.

Accessibility Contract Language

Standard accessibility language for technology contracts:

Requirements Clause

“Vendor agrees that the Product shall conform to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA success criteria, as published by the World Wide Web Consortium (W3C). Vendor shall provide an updated Voluntary Product Accessibility Template (VPAT) upon request, and at minimum with each major product release.”

Remediation Clause

“If accessibility defects are identified, Vendor shall develop a remediation plan within 30 days and complete remediation within a mutually agreed timeline. Critical accessibility barriers that prevent users with disabilities from accessing core functionality shall be remediated within 90 days or an interim accommodation shall be provided.”

Audit Rights Clause

“University reserves the right to conduct or commission accessibility testing of the Product at any time. Vendor shall cooperate with such testing and provide access to test environments as reasonably requested.”

Termination Clause

“Material failure to meet accessibility requirements that renders the Product unusable for users with disabilities, if not remediated within 90 days of written notice, shall constitute grounds for termination without penalty.”

Handling Exceptions

Sometimes a product with accessibility gaps may still be needed. The exception process ensures informed decisions.

When Exceptions May Apply

Exception Requirements

To approve an exception, document:

  1. Business justification: Why this product is necessary
  2. Alternatives considered: What other products were evaluated
  3. Risk assessment: Who is affected and how
  4. Mitigation plan: How users with disabilities will be accommodated
  5. Remediation timeline: Vendor’s plan to improve accessibility
  6. Review date: When the exception will be reconsidered

Exception Approval

Procurement Checklist

The Three-Step Framework

Accessibility should be considered at each step of the procurement process. This framework, adapted from the University of Washington’s Accessible Technology procurement model, provides a structured approach.

Key Principle: Those responsible for making decisions about which products to procure must consider accessibility as one of the criteria for acquisition. This is especially critical for enterprise-level systems and other technologies that affect a large number of students, faculty, and/or staff. — Adapted from University of Washington Accessible Technology

Step 1: Solicit Accessibility Information

Suppliers are expected to have available an Accessibility Conformance Report (ACR) for each of their products and services, documenting their current state of accessibility as measured by WCAG 2.1/2.2 Level AA.

Step 2: Validate Accessibility Information Received

When suppliers provide accessibility documentation, these materials must be reviewed and verified. When reviewing a supplier’s ACR, consider:

  1. Does the ACR include all required information? At a minimum: product name and version, report date, contact information for follow-up questions, and description of evaluation methods.
  2. Is the ACR reasonably current? If the report date is more than a few months old, the information may be outdated unless the product hasn’t been updated during that time.
  3. Who completed the report? A report prepared by an independent third-party accessibility consultant is more credible than a self-report.
  4. How accessible is the product? An ACR that declares 100% accessibility (i.e., “Supports” on every criterion) is suspicious—perfectly accessible products are extremely rare. A transparent ACR that accurately acknowledges accessibility problems is preferred.
  5. Do you understand how people with disabilities will use the product? The Remarks/Explanations column should provide sufficient detail to answer “Yes” to this question.
  6. When can you expect the supplier to fix identified problems? Request an accessibility roadmap indicating their plan for resolving issues.

Quick Keyboard Test: One easy test that anyone can perform without specialized tools: Test the product with a keyboard. Anything accessible with a mouse should also be accessible with keyboard alone. If a product fails the keyboard test, this is a strong indicator of other accessibility problems. — University of Washington Accessible Technology

Step 3: Include Accessibility Assurances in Contracts

All technology suppliers are expected to provide assurances that their product is either compliant with accessibility standards, or is working toward compliance within a reasonable timeline.

The Keyboard Accessibility Test

Before finalizing any technology purchase, conduct this simple but revealing test. Based on the UW Accessible Technology keyboard checklist.

How to Test

  1. Set aside your mouse and use only your keyboard
  2. Press Tab to move forward through interactive elements
  3. Press Shift+Tab to move backward
  4. Press Enter or Space to activate buttons and links
  5. Use arrow keys to navigate within menus, tabs, and other widgets
  6. Press Escape to close dialogs and menus

What to Check

Failure Indicator: If the product fails the keyboard test — if you cannot accomplish tasks without a mouse — this is a strong indicator of deeper accessibility problems. Request demonstration of keyboard support from the vendor before proceeding.

Digital Accessibility Checklist Framework

This checklist framework is adapted from the University of Washington’s Digital Accessibility Checklist, which organizes checkpoints by technology type and impact.

For All Digital Content (Web, Documents, LMS)

  1. Headings — Do headings form an outline of the page content?
  2. Lists — Are lists used to identify content that can be described as a list of something?
  3. Images — Do images have alt text that conveys their purpose?
  4. Tables — Are tables used solely for data (not layout), with column and row headers identified?
  5. Color contrast — Does the interface have sufficient contrast between text and background?
  6. Visual characteristics — Have you avoided using color alone to communicate information?
  7. Links and buttons — Are links and buttons labeled correctly with meaningful text?
  8. Forms — Do form fields have appropriately coded labels and helpful error messages?
  9. Time limits — Do pages with time limits include mechanisms for adjustment?
  10. Language — Has the language of the page or document been defined?

For Web Pages Only

  1. Keyboard accessibility — Can all controls be operated by keyboard?
  2. Page regions — Are common regions (header, main, nav, footer) properly identified?
  3. ARIA — Do rich, dynamic interfaces include proper ARIA markup?
  4. Popups — Are dialogs, menus, and tooltips accessible?
  5. Flashing content — Have you avoided content that flashes at seizure-triggering rates?
  6. Auto-updating content — Can users pause carousels and animated graphics?
  7. Enlarged text — Does content scale well when text is enlarged?
  8. Mobile devices — Is content accessible on mobile?
  9. Predictability — Have you avoided controls that trigger unexpected changes?
  10. Navigation — Does the site have consistent navigation and multiple ways to find content?

For Audio and Video

  1. Captions — Does recorded video have captions?
  2. Audio description — Does video include critical visual content that needs description?
  3. Transcripts — Does recorded audio have a transcript?
  4. Live captions — Are captions available for live meetings, classes, and events?

Checklist framework adapted from University of Washington Accessible Technology, used with attribution under their public educational mission. The UW checklist is based on W3C’s Web Content Accessibility Guidelines (WCAG) 2.1.

Sources & Attribution

This procurement guidance incorporates best practices from leading higher education institutions and accessibility organizations.

Primary Sources

Additional Authoritative Sources

About This Guidance: The University of Arizona gratefully acknowledges the University of Washington’s leadership in accessible technology and their generous sharing of procurement resources with the higher education community. Content has been adapted to align with UA policies and Arizona state requirements.

Resources