Third-Party Digital Accessibility Review Guidelines

These guidelines help university staff evaluate, document, and manage the accessibility of third-party digital solutions that are used by students, employees, or the public but are owned, hosted, or controlled by an external vendor.  

Because the university cannot directly modify these systems, compliance focuses on due diligence, testing, documentation, mitigation, and accommodation planning, as required under Title II of the ADA.

What Title II Requires for Third-Party Tools

Vendor ownership does not transfer responsibility away from the university. Even when a product is vendor-controlled, the university remains responsible for ensuring that:

• Individuals with disabilities can access required functionality
• Barriers are identified and documented
• Reasonable accommodations or alternatives are provided when needed
• Accessibility is considered throughout the lifecycle of the tool

1. Determine Impact and Risk

   Before reviewing accessibility, answer the following:

   • Is the tool required for coursework, employment, or services?
   • Is it public-facing or student-facing?
   • Is there a deadline or time-sensitive use?
   • How frequently is the tool used?
   • Are there accessible alternatives already in place?

   Higher-impact and required systems require deeper review and stronger mitigation planning.

2. Collect Vendor Accessibility Information 

   Required Vendor Documentation

   Request and review:

   • A current VPAT (WCAG 2.1 Level AA preferred)
   • An accessibility or conformance statement
   • Documentation of known accessibility issues
   • Roadmaps or timelines for remediation

   Red flags

   • Missing VPAT
   • VPAT older than two years
   • “Supports with exceptions” without explanations
   • Claims of compliance without evidence

   Vendor documentation alone is not sufficient.

3. Perform Practical Accessibility Testing 

   Conduct basic functional testing focused on real user tasks, not exhaustive audits.

   Keyboard Access

   Check whether users can:

   • Navigate menus using only a keyboard
   • Activate buttons, links, and form controls
   • Complete core workflows without a mouse

   If key tasks cannot be completed by keyboard, the tool presents a significant barrier.

   Screen Reader Compatibility(High-Level)

   Using a screen reader such as JAWS, NVDA, or Voiceover, verify whether:

   • Page titles and headings are announced
   • Form fields have meaningful labels
   • Error messages are announced
   • Navigation order makes sense

   You do not need to fix issues, but you must identify and document them.

   Visual and Interaction Barriers 

   Check for:

   • Low color contrast
   • Text that cannot be resized
   • Instructions that rely only on color or shape
   • Time limits without extensions
   • Pop-ups or modals that trap focus
   Multimedia Accessibility 

   If the tool includes audio or video:

   • Are captions available and accurate?
   • Are transcripts provided?
   • Are video controls accessible by keyboard and screen reader?

4. Document Known Limitations

   Create a known accessibility limitations record that includes:

   • Identified barriers
   • Impacted user groups
   • Affected workflows or features
   • Whether the issue is vendor-acknowledged
   • Any available workarounds

   This documentation is critical for compliance and accommodation planning.

5. Evaluate Vendor Responsiveness

   Assess whether the vendor:

   • Acknowledges accessibility issues
   • Provides realistic remediation timelines
   • Responds to accessibility inquiries
   • Demonstrates ongoing accessibility investment

   Vendor unwillingness or silence increases institutional risk.

6. Mitigation and Accommodation Planning 

   If the tool is not fully accessible, the university must ensure access through one or more of the following:

   • An accessible alternative tool
   • A parallel accessible workflow
   • Individual accommodations coordinated through ADA services
   • Vendor-supported accessibility features or modes

   Mitigations must be timely, effective, and equivalent for required use cases.

7. Decision Outcomes

   Based on review and documentation, a third-party tool may be:

   Approved

   • Meets accessibility requirements or has minimal, non-blocking issues

   Conditionally Approved

   • Has known issues with documented mitigations and monitoring

   Approved with Accommodation Plan

   • Requires case-by-case accommodations coordinated with ADA services

   Not Approved for Required Use

   • Presents significant barriers with no viable mitigation

8. Ongoing Monitoring

   Accessibility review is not one-time.

   • Re-review tools periodically
   • Reassess after major updates
   • Track vendor remediation progress
   • Update documentation as issues change

    

   For procurement and contract considerations, when possible, ensure contracts include:
   • Accessibility representations and warranties
   • Remediation commitments
   • Notification of accessibility changes
   • Cooperation with accommodation efforts

   Important Reminders

   • “Vendor-hosted” does not mean “university-exempt”
   • A VPAT is a starting point, not a guarantee
   • Documentation protects both users and the institution
   • Accessibility issues must be addressed proactively