We are legally required to ensure third-party products are accessible​  

Vendors are not accountable under the new law – public entities are.​ This means we need to validate whether third-party products meet Web Content Accessibility Guidelines 2.1 A and AA. This includes any third-party products used by students, employees, or the public.​ We need to try our best to meet the new requirements by April 2026, which means we need to streamline third-party product testing going forward. ​

Why can’t we rely on a vendor’s word?​

Most vendors currently do not have a full understanding of accessibility or a designated accessibility team. ​

Vendors often rely on a third-party to do their testing and that testing is often limited due to the overall cost of outsourcing accessibility testing, so several types of assistive technology testing are often left out, including speech recognition software and display modes.​

In addition, the testing does not happen on a regular basis (some vendors only get their products tested every five years even though significant changes have happened in the meantime). ​

Finally, the Voluntary Product Accessibility Template (VPAT) that vendors often provide is voluntary and not legally binding. The VPAT is completed differently by every vendor making it significantly unreliable. 

Internal Product Owners  

• Engages the accessibility team in the overall procurement process, ensures any products being reviewed are tested, and leverages the team’s findings to make a procurement decision.​
• Supports the accessibility team in meetings with the vendor.​
• Engages the accessibility team in any upgrades and roll outs of new features.
• Ensures the escalation process is upheld with vendors that refuse to comply with digital accessibility laws and standards.
• Communicates any critical issues to campus governance and support teams so they are aware of the issues and how they are being addressed. Brings in the accessibility specialist when a demo of the issue is needed for more clarity.
• Emphasizes the importance of digital accessibility to campuses and governance. ​
• Advocates for a product replacement when all avenues have been exhausted. Note that most vendors work with us to resolve issues as we are willing to partner with and educate them on the issues, so we have only taken this route once (Adobe Sign). ​

Product Owners can become stronger advocates for accessibility by completing Digital Accessibility Training, so they are aware of common accessibility issues and the barriers those issues create.

President’s Office Digital Accessibility Team

The Digital Accessibility team reviews all third-party products owned and managed by the President’s Office to ensure they meet Web Content Accessibility Guidelines (WCAG) 2.1. 

The Digital Accessibility Team's testing responsibilities include:

• Reviews an Accessibility Conformance Report from the vendor (if one is available) along with any additional accessibility materials the vendor sends over.
• Reviews a completed Accessible Procurement questionnaire from the vendor.  
• Engages campus accessibility teams in testing process when a product will be used by the President’s Office and other campuses.  
• Tests the product through a demo environment to identify any critical accessibility barriers.  
• Provides accessibility compliance scores during the RFP process.  
• Works with Procurement and the General Counsel to update a vendor contract with an accessibility remediation timeline.  
• When a vendor introduces a new issue during an upgrade or feature roll out, the accessibility team documents the issue and works with the vendor to fix it.
• Escalates critical issues to legal following the accessibility issue escalation process when a vendor refuses to address the issue and is in violation of their contract. 

Important: The President’s Office Digital Accessibility Team does not review third-party products that are owned and managed by a campus. The testing of these products is a campus responsibility currently as we do not have a centralized Accessibility office.  

Procurement

Procurement ensures the Digital Accessibility team is engaged in both the procurement of products and the contract renewal process. 

• Ensures the Digital Accessibility team is part of the technical team for reviewing any President’s Office RFPs related to digital products or software that will be used by employees, students, or the public.  
• Ensures the Digital Accessibility team is alerted of a contract renewal underway for any digital product or software that is used by employees, students, or the public. This allows the Digital Accessibility team to work with the General Counsel to build in an accessibility remediation timeline for any products that are not compliant with the Web Content Accessibility Guidelines (WCAG) 2.1.  

General Counsel

The General Counsel provides legal guidance around vendor digital accessibility compliance. 

• Maintains the standard RFP and Contract language around accessibility compliance.
• Works with the UPST, the Product Owner, and the Digtal Accessibility Team to provide an accessibility remediation timeline in new or updated contract, when needed.
• Reviews any changes vendors have to the accessibility compliance language in Contracts.  
• Keeps informed of where we stand from a compliance perspective.
• Provides legal advice when the Digital Accessibility team and Product Owner are unable to get an existing vendor to comply with WCAG.  
• Engages the Digital Accessibility Team, Product Owner, and Executive Leadership of any accessibility issues that have been escalated to the General Counsel by a campus when the product is owned by the President's Office. 

When should the Accessibility Team be engaged?

The Digital Accessibility Team should be involved in every phase of a product’s lifecycle.

How to request testing

Submit a case as early as possible for the UITS - Digital Experience team with the following information:

• Overview of what will need to be tested.  
• Information about who will or does use the product.  
• Estimated timeline for testing.  

Step by Step Testing Process Completed by Accessibility Team​

• Engages campus digital accessibility teams in the testing process when a product will be used by the President’s Office and multiple campuses.
• Reviews Accessibility Conformance Report from the vendor or relevant accessibility documentation. ​
• Reviews completed Accessible Procurement Questionnaire. ​
• Participates in Vendor demos of product used assistive technology. ​
• Completes internal manual testing of product with various types of assistive technology.  
• Documents all accessibility issue findings in the Accessibility Tracker, records videos so vendor can recreate issues, and submit issues with recordings to vendor. ​
• Works with the General Counsel and Procurement to update a new or up-for-renewal contract with an accessibility remediation timeline as needed.​
• Provides ongoing updates to the product owner and any identified leadership on vendor's accessibility efforts.
• Works directly with the vendor to fix and re-test issues.  
• Follows the critical issue escalation process when a vendor refuses to fix or does not respond when a critical issue is submitted.
• Engages in ongoing testing of the product during upgrades and when new features are released. 

Types of Manual Testing Conducted by the Digital Accessibility Team​

What the team needs for successful testing and vendor fixes​

• A list of business processes to test within the product. ​
• Access to a staging or test environment with proper security access. ​
• Test scripts to follow, such as functional test scripts or user job aids.
• Once testing is complete, access to the vendor’s accessibility or development testing team to work on identified issues. ​
• Escalation to leadership and then legal when the vendor refuses to fix critical barriers. ​

How We Prioritize and Manage Third-Party Product Testing​

All third-party product testing is managed through the Accessibility Tracker. The Accessibility Tracker allows us to capture the following:​

• Key information about a product, such as the product contract language, Accessibility Conformance Report, both the internal and external product owner, and an overall history of accessibility testing in relation to that product.​
• Issues associated with each product. Issues are entered individually so we can track the status of each issue along with the issue impact information (who is impacted, what types of assistive technology, and whether the impact will block the user from completing a process). ​

Compliance review priority statuses

• Critical - Vendor is using an overlay   
• Critical - Barriers submitted by impacted end user​
• Critical - High Usage and Known Compliance Issues​
• Critical - High Usage and Compliance Status Unknown​
• Medium - Targeted Audience and Known Compliance Issues​
• Medium - Targeted Audience and Compliance Status Unknown​
• Low - Usage Varies but No Barriers​ 

The Digital Experience team uses a standard form to input all accessibility issues. The form content is added to the accessibility tracker. 

Here are the fields captured:

• Product or Service: A dropdown value with all the products currently owned by the President's Office. This field in the form is used behind the scenes to display the issue on the related Product page.
• Interface Tested: A lookup field with only two values - Back End/Administrative Interface and Front End/Customer-Facing Interface.
• Issue Title: A text field to provide a short description of the issue.
• Detailed Description of Issue: A long text field with formatting options (bullets, headings, etc.) that provides ample room for providing as much detail as possible around the issue.
• Video Recording: A link field that provides a link to a video recording of the issue. We store all video recordings on Dropbox, not directly in the database so that we can provide captions and a transcript for the video.
• Page or Location of Issue: A text field to provide either the exact page name or a navigation path to the content depending the product.
• Impact: A text field that provides how a disabled person would be impacted if the issue is not resolved.
• Impacted Disabilities: A multi-select list with the following values.
  • Blind
  • Colorblind
  • Deaf
  • Deafblind
  • Epilepsy, Vestibular Disorder, or Motion Sensitivity
  • Hard of Hearing
  • Low Vision
  • Mobility
  • Neurodivergent
• Associated WCAG Success Criteria: A multi-select list with all the WCAG success criteria listed as selection options and a not applicable option for issues that do not align with a specific WCAG criteria but create usability issues for the disability community.
• Manual Testing Used: A multi-select list with the following values.
  • Browser Zoom
  • Dark Mode
  • Dragon Naturally Speaking
  • High Contrast Mode
  • JAWS
  • Keyboard Only
  • Manual Video Review
  • NVDA
  • Reduced Motion Mode
  • Text-to-Speech Software
  • Voice Control
  • VoiceOver
• Automated Testing Used (If Applicable): A dropdown field with the following values.
  • Adobe Accessibility Checker
  • axe Dev Tools
  • Color Contrast Analyzer
  • DubBot
• Priority: A dropdown field with the following two values.
  • Blocker: User can not complete the process or is significantly hindered from completing the process. When to fix: Must be fixed prior to go live. However, if an application wasn't reviewed prior to go live, issues should be fixed within three to six months.
  • Weakness: A weakness is considered an issue with the content or functionality that is still considered an issue by accessibility standards, but the user can complete the process. Deemed frustrating or annoying. When to fix: If the issue is complex to address, the recommendation would be to wait until all blockers are fixed. If it's a quick change, as soon as possible to reduce overall frustration.
• Expected Outcome: A text field for entering in detailed information about the expected outcome.
• Recommended Fix: A long text field with formatting for entering in either a high level recommended fix or detailed code fix recommendations.
• Status: A dropdown field with the following values.
  • Identified
  • Submitted to Vendor
  • Submitted to Internal Team
  • Vendor Working on Fix
  • Internal Team Working on a Fix
  • Vendor Declined to Fix
  • Vendor to review for future remediation project
  • Internal Workaround in Place until Vendor Fix
  • Escalated to Legal
  • Fix Applied
  • Fix Validated
  • Canceled - Functionality Being Retired
• Reporter: A dropdown field with the following values.
  • Accessibility Specialist
  • Developer
  • DubBot Report
  • End User
  • Vendor
• Associated Case Number (if applicable): This is a text field that we use for capturing case numbers provided by vendors that have case management systems.
• Comments: This field is available for anyone with access to the tracker to submit a comment on an issue.

General Escalation Process

When critical issues are found, we alert the vendor of those issues and work with them to resolve the issues. This often includes educating the vendor on how disabled people navigate their site with assistive technology and best practices on coding for digital accessibility. However, on occasion, some vendors may refuse to address critical issues. In that case, we need to follow a formal issue escalation process. The digital accessibility team: 

1. Identifies a critical accessibility issue through testing or is alerted of an critical accessibility issue by a campus.
2. Documents the accessibility issue in the accessibility tracker and alerts the Product Owner of the issue.
3. Works with the internal Product Owner to engage the vendor via email or submits a case to the vendor if the vendor uses case management.
4. If a vendor refuses to fix a critical issue or does not respond (identified as a blocker in the tracker), the digital accessibility team changes the status of the issue to Vendor declined to fix and alerts the Product Owner of the vendor's response.
   1. In addition, if a vendor gives a deadline and goes past that deadline, we would need to escalate issue.
5. Alerts Executive Leadership that the vendor is refusing to fix a critical issue with the product - Executive Leadership to inform the team of the best way to alert them - either via Slack or Email.
   1. Leadership requests a follow up meeting if needed or confirms scheduling an urgent meeting with the vendor.
6. Works with the Product Owner and the vendor to schedule a discussion between our team and the vendor's team with identified President's Office department leadership present.
7. Presents critical issue overview at Digital Accessibility Governance to keep all governance members aware of the critical issue and the vendor's current stance.
8. If the vendor continues to refuse to fix the issue, the Digital Accessibility team escalates the issue to legal with detailed information on the steps taken and both the user and legal impact of the issue. The Digital Accessibility team will also ask legal to keep designated leadership in the loop on the legal case.
9. Legal reviews the legal advice request and provides a recommended path forward. 

Specific Critical Issues that Need Legal Engagement in the Background from the Beginning

Accessibility Overlays

If a vendor installs an accessibility overlay on their product, legal should be aware that we are entering into discussions with the vendor to remove the overlay. Overlay discussions can be hard to navigate as the vendor's that implement them do not engage with the accessibility community on a regular basis and have spent money on a product they believe will fix accessibility issues with their product. Some vendors are easy to educate and will remove the overlay. However, legal should be prepared to step in if a vendor refuses to remove the overlay as each day the overlay exists on a product increases our overall legal risk. 

User Reported Barrier

When a member of the general public, employee or student reports an issue with one of our products, legal should be aware in the background and be kept up to date on how we are working with the vendor to address the issue. 

Issues Escalated by Legal

In some cases, legal may become aware of a critical accessibility issue due to a campus raising the issue to the legal office. In that case, legal will loop in the Digital Accessibility team, who will keep them updated on the issue until it has been fixed. 

The Digital Accessibility team is responsible for developing any communications to end users around critical digital accessibility issues. The process is as follows:

• The Digital Accessibility team develops a communication that covers what the issue is and which disability communities the issue would impact.
• The communication is reviewed by leadership and by legal prior to being communicated to either all employees or all students.
• Any recommended changes to the communication should be reviewed and confirmed by the Digital Accessibility team. We have encountered issues in the past where the rewording of the content by a product owner would have an inaccurate and negative impact.
• Once the communication is approved, the product owner should send it to campus product owners to communicate at the campus level. The digital accessibility team should be copied so they can document when the communication was sent out.
• A follow up communication should be sent out when the critical issue is resolved.