Follow the Web-Based Tool or Mobile App Review Process

Summary

The Office for Digital Accessibility can review web- and mobile-based software to uncover potential accessibility issues. 

To begin the process of an ODA web tool accessibility review, follow these steps:

  1. Decide if the policy applies: Determine if a web-based tool review is needed for this software. The ODA only reviews software that is web based and/or mobile based. We do not evaluate standalone software applications that are installed on a Windows, MacOS, or Linux operating system. Examples of web-based tools include Google Gemini or Personify Health. Examples of installed software tools include Microsoft Word or Zoom Workplace.
  2. Submit an ODA Review of a Web-Based Tool or Mobile App form: If the software runs in a browser or mobile application, submit this form: ODA Review of a Web-Based Tool or Mobile App - Google Forms
    1. Understanding priority based on user base criticality takes priority: Keep in mind that due to the volume of tools that need to be reviewed, tools that are used by a larger user base, are critical to essential University activities, or are public facing will be prioritized first. If the software is used by a small number of people at the University (under 25 people), the review will not be prioritized.
      1. Specialized tools with a small number of users: If the tool is highly-specialized and has a small user base, accessibility testing will not be necessary in most cases. We do, however, want to gather accessibility documentation and review contract language.
  3. Send a vendor letter: Once the form is sent, we encourage you to contact a representative for the vendor using the Vendor Letter - Request for Accessibility Information as a template. This will request some standard accessibility documentation and ask that they fill out a questionnaire.
  4. Check for accessibility language in existing contracts: If you have an existing contract with the vendor, please check the current contract for any accessibility language. This will help us determine if an addendum to the contract is needed. Any new contracts should include updated accessibility contract language.
  5. Review of VPAT and questionnaire responses: Once the vendor has sent a Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report (ACR) and submitted the vendor questionnaire, the ODA will begin the review process and determine if testing is needed based on those responses. 
  6. Perform accessibility testing: In some cases, especially when significant accessibility issues are described in documentation, ODA staff will perform accessibility testing on the tool. Testing requires access to the tool, and we may ask for your assistance to set up testing access.
  7. Review results delivered: Once the review is complete, we will provide a report based on the documentation review, accessibility testing, or both. 
    1. Our reviews provide analysis and inform technology owners on the accessibility of web- and mobile-based tools. We will only recommend contacting the vendor to request that they fix accessibility issues. We do not make recommendations on risk, legal requirements, or contracts.

This site is produced by the Office of Information Technology (OIT) with guidance from the Office for Equity and Diversity (OED) and the Accessible U Committee. We use a mix of person- and identity-first language (access our Style Guide).

Send site feedback to [email protected]

Open the ODA Site Map