Procuring accessible systems

There is extensive guidance under the Web Content Accessibility Guidelines (WCAG) 2.2 (w3.org) that spells out accessibility requirements for digital systems – particularly in their How to Meet WCAG (Quick Reference) guidance (w3.org).

For context, here is a list of some of the most common accessibility issues to avoid:

• Content is not accessible by screen reader.
• Captions are not provided for all pre-recorded content, such as video. An example alternative could be a downloadable transcript.
• Poorly embedded materials.
• Issues with contrast.
• Inflexible layouts eg no reflow on mobile devices.
• Missing or inappropriate alt text on images and diagrams. Informative images require descriptive alt text that conveys the information they contain, especially when that information is not given elsewhere in the text. Decorative images should have an empty alt attribute so screen readers can ignore them.

To learn more or refresh your knowledge, read the University's digital accessibility guide.

All contracts should include clauses requiring suppliers to carry out remedial accessibility work at no extra cost if problems are identified.

The entirety of the product that is being purchased and delivered should be fully accessible. If fundamental accessibility issues are identified with a system, then it should be deemed incomplete.

If the supplier falls short or cannot meet full compliance, discuss it with them. Ask for a clear accessibility roadmap that explains:

• How they will identify and resolve accessibility issues
• How they will carry out remedial work.
• What steps they will take to mitigate any current barriers.

All actions should have clear and comprehensive deadlines.

Be pragmatic but firm. In some cases, such as niche applications with few alternatives, full WCAG compliance may not be possible. Even so, suppliers should identify known issues, offer mitigation plans and commit to improvements.

For advice and support, contact:

• Procurement Office (procurement@york.ac.uk) 
• Legal Team (legal@york.ac.uk)

The only reliable way to check if a digital product is accessible is to test it – both automated testing and with real users. Do this before purchasing it. 

Recommended approach:

• Ask the supplier to run automated tests during development to catch early issues and report them back to you.
• Review the VPAT critically. Review, scrutinise and verify any claims using automated and human user-testing. 
• Involve a diverse group of testers during selection and evaluation.
• Invite testers to demos to flag issues and concerns early.
• Set up a process to test future software updates for accessibility impact.

Getting help with testing:

• Contact the E-Accessibility Working Group (equality@york.ac.uk) for advice on undertaking testing and help finding participants with digital access needs.
• Join the University’s #Digital-Accessibility slack channel to share knowledge
• Complete the Creating Accessibility Statement training resources.
• After completing the training, request access to the Accessibility Statements slack group by emailing digacc-support@york.ac.uk.  
• Example of an UoY user-testing protocol (slides 10-15)

An accessibility statement is a user-facing accessibility statement that explains in clear language how a digital system meets accessible standards and where it does not. Its purpose is to help users with accessibility needs.

The person procuring the product is responsible for creating a clear, user-facing statement.

The statement should include:

• Accessibility features
• Known issues/non-compliances
• Planned improvements (and associated timescales)
• Support contact
• How to make a complaint 

Statements must be reviewed when there is a substantial change to the product or service. 

Once your product or service goes live, you should register it and its accessibility statement in the University’s catalogue of tools, software and services.

Example accessibility statements for University systems:

• University of York website accessibility statement
• YorSearch accessibility statement
• MyUoY accessibility statement
• Jobs portal accessibility statement
• Canvas LMS accessibility statement
• Planon accessibility statement

Accessibility compliance is primarily governed by:

• The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 (PSBAR) (legislation.gov.uk) 
   Requires public institutions to ensure digital systems and services are accessible.
  • Ensure that their website content and mobile applications meet the standards laid out in the Web Content Accessibility Guidelines (WCAG) 2.2 AA (w3.org).
  • Publish a compliant accessibility statement in line with the Central Digital & Data Office (CDDO) model statement.

• The 2025 EU Accessibility Act (abilitynet.org.uk)
   Requires companies operating in the EU to meet accessibility standards.

The University follows WCAG 2.2 AA standards as its benchmark. These guidelines define how to make content usable for all, including those with disabilities.

WCAG 2.2 AA principles:

• Perceivable: eg alt text, captions, screen reader compatibility, resizable text
• Operable: eg keyboard navigation, meaningful headings, clear link text
• Understandable: eg plain English, explained abbreviations, clear instructions
• Robust: eg valid HTML to support assistive technologies.

Failing to build in accessibility from the start can lead to:

• Legal non-compliance: Breaching WCAG.2.2 standards, which the University is legally required to meet, can result in financial penalties and reputational damage.
• User exclusion: Inaccessible products can block people with diverse needs from using services effectively.
• Bias in decision making: Relying on personal experience may overlook issues faced by others, leading to unexpected accessibility barriers.
• Costly retrofits: Fixing accessibility later is more expensive and can disrupt services.
• Staff burden: Maintaining inaccessible systems increases workload and reduces efficiency.

• Accessibility regulations – what you need to know (jisc.ac.uk)
• Understanding accessibility requirements for public sector bodies (gov.uk)
• 10 tips for accessible procurement (abilitynet.org.uk)
• University College London’s Procurement of digital products, services, and platforms policy (ucl.ac.uk)
• University of California Guidelines for Purchasing Accessible IT Products or Services (ucop.edu)
• Digital accessibility: a practical guide