Accessible Software/Web Service Procurement
Accessibility must be considered from the earliest stages of the software and/or web service procurement process. The information below outlines the process by which IT evaluates accessibility during the procurement process, and the methods used to ensure accessibility barriers are identified and planned for, before they affect a member of our student population, staff, or campus community member’s ability to be successful.
Procurement Process
When you submit a Technology Purchase Review (TPR) Form (Seawolf ID required), IT staff will review the selected software for information security and accessibility, before it can be approved for procurement. This process is necessary regardless of the cost, and may differ depending on how it is intended to be used. Software installed on a single computer, for use by one staff member, poses different potential risks than an application used by hundreds of students, or web development that can be accessed by members of the public.
VPATs and ACRs
A Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report (ACR) is the first tool we use to identify potential accessibility barriers in software and web services. These documents, usually completed by third party auditors, list Web Content Accessibility Guideline (WCAG 2.1) compliance criteria, and whether or not the application or service meets these guidelines. VPATs and ACRs can often be found on a vendor’s website, in their help materials, or by contacting a representative. Providing these documents when you submit your TPR form can help minimize the time needed to complete an accessibility review. For more information and instruction, please visit IT FAQ: How Do I Interpret a VPAT?
For information on specific products, IT keeps a running list of Software Accessibility Resources for software with a recently completed TPR.
Low-Risk Procurements
Some procurements are identified as having low accessibility risk, usually based on how many users will have access to the product or services, and do not require any additional review or documentation to move forward. There is no hard number of users that qualify as higher risk, and we usually err on the side of caution when determining whether or not to document an accessibility plan for inaccessible products.
Equally Effective Alternative Access Plans (EEAAPs)
An EEAAP outlines a plan, and establishes an agreement between the software requestor and IT, for how software or services that pose accessibility barriers, or lack accessibility documentation, will be utilized to minimize accessibility risk and ensure each member of the campus community has the opportunity to be successful, without unnecessarily disclosing any disability status.
An EEAAP is usually drafted by the Accessibility Services Analyst after some discussion with the requestor, and may require manual review, verbiage added to a syllabus or webpage, or one-on-one assistance to users of the product in question. Whenever possible, previously approved EEAAPs will be referenced as a working precedent, but solutions will ultimately depend on how the unique procurement is intended to be utilized, and for whom.
Time Expectations
Accessibility reviews can take hours, days, or weeks, depending on the variables listed above. Low-risk procurements with few users can usually be approved very quickly, while procurements that reach more users, and pose accessibility barriers, may take several days to identify all potential issues, agree on solutions, and route a completed EEAAP document for signatures from the requestor, Accessibility Services Analyst, and IT Leadership.
Each step of the TPR process can take up to 7 days for the requestor to receive an initial response from IT staff; for a low-risk procurement, with no cloud-based software, a requestor can expect the TPR process to take a minimum of 14 days to complete, before they may send it to Procurement.
Contact
For additional information on the software or web service procurement process, or to suggest information or resources for this page, please contact the Accessibility Services Analyst.