Your service must be accessible to everyone who needs it. If it isn’t, you may be in breach of the Equality Act 2010.
This means you need to start thinking 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:
If you think that your service (or any part of it) can’t be made accessible, contact the Government Digital Service (GDS) accessibility team for advice at email@example.com.
Think about accessibility from the start
In the UK, 1 in 5 people have a disability - this could be visual, hearing, motor or cognitive (affecting memory and thinking).
But the concept of accessibility doesn’t just apply to people with disabilities - 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 aren’t accessible - problems usually cost less to fix if you find them early
Budget for accessibility
Make sure you 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 it’s likely you’ll need to pay for an accessibility audit, which can cost between between £3,000 and £7,000.
Accessibility is the whole team’s job
Accessibility isn’t the responsibility of just one person. Everyone on your team is responsible for making sure your service is accessible.
It’s important that each person on your team - especially content designers, interaction designers and developers - understands how they might accidentally make something inaccessible and can avoid doing so.
User researchers and testers can help spot accessibility problems so the rest of the team can remove them.
Product and delivery managers should also understand accessibility so they can ensure it’s considered from the start and built in to the service efficiently.
Read more about how each discipline can help build an accessible service in the US government’s Accessibility for Teams guide.
Researching with users with disabilities
When doing research, you have to include users who have disabilities or use assistive technologies.
You may need to pay for:
- 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 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 barriers they face.
You can do this even before you do any user research by:
You should also join the accessibility community.
What to do in alpha
During alpha, you should be thinking about whether what you’re designing meets the WCAG 2.1 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 won’t 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 appoint 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 users with disabilities.
What to do 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 at a later stage.
Check what testing tools and software your team has access to in case you need to pay for some.
Running research sessions with users who have disabilities will also help you check that what you’re building is accessible.
Getting an accessibility audit
You must get an accessibility audit towards the end of beta, which will provide evidence at assessment that your service works with assistive technologies and meets WCAG 2.1 level AA. This 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.
What to do in live
It’s important to carry on testing and researching your service once it’s live.
Check that any new features you add meet government accessibility requirements, and continue doing research with users with disabilities.
If you make substantial changes to your service, you can get another audit to check you still meet government accessibility requirements.
Make non-digital parts of your service accessible
You should also 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).
You might find the following resources useful:
You can also watch a series of videos produced by WCAG about how accessible design can benefit people with disabilities.
You might also find these guides useful: