Accessibility guidance for:
-
Product and delivery
What product and delivery managers need to do to make digital services accessible.
Make sure your service meets WCAG 2.2
For: Design, Development, Product and delivery, Testing
WCAG 2.2
The Web Content Accessibility Guidelines (WCAG) 2.2 add 9 new "success criteria" for improving web accessibility. 6 of the new criteria are graded at the A and AA level, which means they're a requirement for websites and mobile apps in the NHS. Learn more about the WCAG 2.2 new accessibility requirements and criteria.
See the full list of design system changes to meet the requirements.
Make sure everyone knows their responsibilities
For: Product and delivery
Make sure everyone in the team knows what they need to do and is checking their work, using the guidance for different activities.
If a team member doesn't have a basic understanding already, help them get started with accessibility.
Ask questions at the start of the project
For: Product and delivery
Ask yourself:
- how your project will affect people with access needs
- how much work you will need to do to make it accessible
- whether your team has the capacity and expertise to do it
More questions to ask yourself
If the answer to any of the following questions is 'yes', it's a sign that the project will need a higher level of accessibility expertise or support.
Does the project affect people with access needs differently?
For example, does the user's journey include physical access to a GP surgery? If so, include people who might find this difficult in your user research - for example, people with hearing, visual or mobility impairments. Read more about involving people with access needs in user research.
Will the project use any technologies you haven't already tested for accessibility?
You will need to test them, and the team working on them will need a higher level of accessibility knowledge or support.
Is the project about a complex subject with lots of jargon?
You'll need to allow time to write content that's easy to understand.
Will the interface need new components?
You should show that you've tested existing components and demonstrated a clear need for new ones. You must also make sure new components are accessible and you must test and maintain them.
Will there be a different colour scheme?
You'll need to check colour contrast, both for text and graphical elements.
Will the project use multimedia, PDFs, infographics, large data tables or other less common content?
Check the capabilities of the systems and the people creating them so that you can be sure that they will be accessible.
Is there a reason to include 'Easy Read' documents or translations?
If there is some key information that everyone must understand (such as a guide to a new national service), then consider including an Easy Read version for people with low-literacy or learning disabilities. Or you could link to Easy Read content from other organisations.
Check that accessibility is "done"
For: Product and delivery
It's the product or delivery manager's responsibility to make sure that the product or service is accessible. In most cases it's a matter of making sure that the team is checking their work as they go along.
If in doubt, ask questions early. The sooner you consider accessibility requirements, the easier it is.
4 questions to check it's "done"
- Is it easy to understand?
- Can you use it without a mouse?
- Does it provide good contrast and allow zooming?
- Does it give screen readers appropriate information?
Monitor and record your work
For: Product and delivery
You must show that your team:
- has carried out accessibility tests at each stage of the project
- has user tested the product or service, including with people with access needs
- has acted on the results
The kind of tests and checks you need depend on the scale of your project, the kind of changes you're making, and the stage it's at.
Examples of tests for different products or services
Large projects
For a large project, such as a new or replaced product or service or new functionality, you should record and be able to show that your team has:
- included accessibility requirements in your service design and user research
- tested its own work using the accessibility guidance for different activities
- tested any new technologies or components
- involved people with access needs in usability testing
- completed an independent accessibility audit and allowed time to make changes before your product or service goes live
If you test as you go along, the independent audit should find very little that needs changing. You will need the audit for your accessibility statement.
Small projects
For smaller projects or a small update, you have more discretion. Internal testing may be enough. Your team should follow this accessibility guidance and focus on testing new components and content.
Read more about different types of testing.
Publish an accessibility statement
For: Product and delivery
All websites must have an accessibility statement, in line with with accessibility regulations. Read more about the accessibility requirements for public sector bodies on GOV.UK.
For the statement, you must test every area of your product or service and report on issues that people with access needs might face. You should have as few accessibility issues as possible. Following this accessibility guidance will help you with that.
GOV.UK has published a sample accessibility statement. You can see a live example on the NHS Your data matters service.
Help us improve this guidance
Share insights or feedback and take part in the discussion. We use GitHub as a collaboration space. All the information on it is open to the public.
Read more about how to feedback or share insights.
If you have any questions, get in touch with the service manual team.
Updated: April 2024