Making your service accessible: an introduction
Your service must be accessible to everyone who needs it, including services only used by public servants. You may be breaking the law if you do not make your service accessible.
You need to think about how users might access and use your service before you design or build anything.
Accessibility is different from assisted digital support, which means helping users with low digital skills or limited access to the web.
Meeting government accessibility requirements
To meet government accessibility requirements, digital services must:
- meet level AA of the Web Content Accessibility Guidelines (WCAG 2.2) as a minimum
- work on the most commonly used assistive technologies - including screen magnifiers, screen readers and speech recognition tools
- include disabled people in user research
- have an accessibility statement that explains how accessible the service is - you need to publish this when the service moves into public beta
If your service meets government accessibility requirements, then you’ll also be meeting the accessibility regulations that apply to public sector websites and mobile applications.
The full name of the regulations is the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.
You can find out more about the regulations by reading the latest guidance.
Think about accessibility from the start
In the UK, 1 in 5 people have a disability - this could be visual, hearing, motor (affecting fine movement) or cognitive (affecting memory and thinking).
The concept of accessibility does not just apply to disabled people - all users will have different needs at different times and in different circumstances. Someone’s ability to use a service could be affected by their:
- location - they could be in a noisy cafe, sunny park or area with slow wifi
- health - they may be tired, recovering from a stroke or have a broken arm
- equipment - they could be on a mobile phone or using an older browser
Accessibility is about making sure your service can be used by as many people as possible. Thinking about this from the beginning will help you:
- make sure that nobody is excluded
- find out earlier if any parts of your service are not accessible - problems usually cost less to fix if you find them early
Budget for accessibility
Include the cost of making your service accessible in your budget. For example, your team might need training or time to learn about accessibility and you’ll need to pay for an accessibility audit.
If you have accessibility specialists in your team you can avoid the costs of an audit if they can do this.
Accessibility is the whole team’s job
Accessibility is not the responsibility of one person. Everyone on your team is responsible for making your service accessible.
It’s important that each person on your team understands how to avoid accidentally making things inaccessible. This includes developers, content designers and interaction designers.
User researchers and testers can help find accessibility problems so the rest of the team can remove them.
Product and delivery managers should understand accessibility too so they can ensure it’s considered from the start and built into the service efficiently.
Read more about how each discipline can help build an accessible service in DWP’s guidance for specific job roles.
Researching with disabled users
When doing research, you need to include disabled people and people who use assistive technologies.
You may need to pay:
- a recruitment agency to help you find participants
- expenses to help participants take part in research - this might include a helper, taxis, or someone to help with communication like a sign language interpreter
Learn more about recruiting participants for user research.
What to do about accessibility in discovery
During discovery you should be learning how people with visual, hearing, motor and cognitive impairments might use your service, as well as the problems they could experience.
You can do this even before you do any user research by:
- developing a clear understanding of what accessibility means as you explore the problem you’re trying to solve
- trying to understand the range of abilities users can have
- reading profiles of disabled users to understand how accessibility affects individual users
You should also join the accessibility community.
What to do about accessibility in alpha
During alpha, you should be thinking about whether what you’re designing meets the WCAG 2.2 design principles - this will help you meet the needs of all your users.
You should also start thinking about your accessibility audit. Even though you will not need this until beta, it can take time to arrange. You may have someone in your department with the necessary skills and auditing experience to do this. If not, you will need to use an external accessibility specialist.
You can ask your auditor to spend a couple of days during alpha reviewing your designs and prototypes for potential accessibility problems.
You can also improve what you’re designing by running research sessions with disabled users.
What to do about accessibility in beta
During beta, you need to start testing for accessibility and get an accessibility audit.
Running a combination of manual and automated tests each time you develop a new feature means you can sort out issues that could be costly to fix later.
Check what testing tools and software your team has access to in case you need to buy some.
Running research sessions with disabled users will help you check that what you’re building is accessible.
You need to publish an accessibility statement when you move to public beta.
Getting an accessibility audit
You must get an accessibility audit before you move into public beta, which will provide evidence at assessment that your service works with assistive technologies and meets WCAG 2.2 level AA. It will give you the information you need to publish your accessibility statement.
Audits can take time to arrange, so start planning for it during alpha.
Find out how to get an accessibility audit including how to find a supplier.
Publish an accessibility statement
Once you’ve got your audit results, you should be ready to draft and publish your accessibility statement.
The accessibility statement must explain:
- how accessible your service is
- what accessibility issues the service has, if any
- how you’re planning to fix the issues
There is a sample accessibility statement you can use to help you write yours.
Your accessibility statement should be easy to find for the user. This means it should be available on every page.
For mobile applications the accessibility statement should be available from either:
- your website
- the information available when downloading the mobile application
- within the mobile application
What to do about accessibility in live
It’s important to carry on testing and researching your service once it’s live.
Check that new features you add meet accessibility requirements, and continue doing research with disabled users.
If you make substantial changes to your service, you can get another audit to check you still meet accessibility requirements.
Your accessibility statement should be reviewed at least once a year and updated if you have made changes that affect the accessibility of your site.
Make non-digital parts of your service accessible
You should make sure the non-digital parts of your service are accessible. For example, you should make sure that users who are deaf or have a speech impairment are offered a way to contact you (by text, email or in person with a British Sign Language translator or lip reader).
If you have to send out letters as part of your service, make sure you can also provide these in alternative formats that are accessible (for example large print, braille or audio CD).
Further reading
You might find the following resources useful:
- a series of interviews with disabled people to learn about the technology they use
- a set of user profiles which highlight the common barriers users face when accessing digital service
- a blog post about the dos and don’ts on designing for accessibility
- Home Office posters about designing inclusive services
- DWP Accessibility Manual
- the accessibility in government blog
You can also watch a series of videos produced by WCAG about how accessible design can benefit disabled people.
Related guides
You might also find these guides useful:
- Last update:
-
Section about when GDS is monitoring the new success criteria in WCAG 2.2 has been removed.
-
Added information about WCAG 2.2 and what GDS is doing as a result of the new success criteria in WCAG 2.2.
-
Added link to accessibility tools.
-
Changes to links to updated content and minor changes to clarity of content
-
Added information on publishing an accessibility page for your service.
-
Moved accessibility audit content to a different guide and added more links to accessibility resources.
-
Guidance rewritten to clarify government accessibility requirements and what to do in each project phase.
-
Guidance first published