Procuring accessible systems
When we're buying a new digital tool or service for the University (such as an IT system, mobile app, or online training module) it’s our responsibility to make sure it’s accessible to everyone who will use it, including students, staff and the public.
The University is legally required to meet accessibility standards for all digital products and services. This guidance explains what you need to do if you're involved in a procurement process, and who can help. You don’t need to be an expert, just follow the steps below and ask for support if needed.
Accessibility is a requirement from the start – it's essential not an optional extra. Accessibility applies to the whole product, both front-end and back-end. If fundamental accessibility issues are identified with a system, then it should be deemed incomplete.
Your responsibilities
- Build in accessibility from the start.
Use the checklist to guide your decisions throughout the procurement and development process. - Set clear standards.
Require suppliers to meet WCAG 2.2 AA standards (w3.org). During tendering and scoring exercises, give additional weight to suppliers who can show how they meet these standards. - Write accessibility requirements into the contract.
Most suppliers don’t include full accessibility details by default. Make it explicit and include clauses requiring suppliers to carry out remedial accessibility work at no extra cost if problems are identified. For help and template clauses, read Accessibility in supplier contracts (makethingsaccessible.com). You should also seek advice from the University’s Legal Team (legal@york.ac.uk ) where needed. - Score evidence of accessibility.
During tendering and scoring exercises we recommend you:- Give additional weight to suppliers who can show how they meet these standards.
- Use a scoring matrix (makethingsaccessible.com)
- Read the Reviewing procurement responses for accessibility (makethingsaccessible.com) guidance to help you score effectively.
- Request a Voluntary Product Accessibility Template (VPAT).
Ask suppliers for a VPAT or accessibility roadmap, and review their accessibility statement to assess how their product meets WCAG standards. You can check SearchBOX for supplier statements (textboxdigital.com). - Test the platform.
Don’t rely solely on supplier claims. Use both automated and human testing to identify barriers experienced by a diverse range of users. - Publish an accessibility statement.
Create a clear, user-facing statement to help users understand how accessible the product is, what accommodations are available and how to make a complaint. For help, read University guidance on creating accessibility statements.
Checklist and what to do
Start using the checklist at the very beginning of the procurement process. It includes actions you should take when procuring a new digital product or service, such as:
- What to ask suppliers
- How to assess the accessibility of the product
- How to address any shortfalls
- Publishing an accessibility statement.
The checklist is available through Google Docs – make a copy and use it to guide your procurement and development process.
More details and resources
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:
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
About this guidance
This guidance was created by the Equality and Diversity Office, and was consulted on by the Equality, Diversity Inclusion Committee and the e-Accessibility Working Group.
For general queries about this guidance contact equality
Version 1.0 (February 2025)