Accessibility and assisted digital
Making your service accessible: an introduction
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 isn’t the responsibility of just one person. Everyone on your team is responsible for making sure your service is accessible.
Meeting government accessibility requirements
To meet government accessibility requirements, digital services must:
- meet level AA of the Web Content Accessibility Guidelines (WCAG 2.0) as a minimum
- work on the most commonly used assistive technologies - including screen magnifiers, screen readers and speech recognition tools
- include people with disabilities in user research
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
Accessibility is different from assisted digital support, which means helping users with low digital skills or limited access to the web.
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 trying to understand the range of abilities that users can have.
What to do in alpha
During alpha, you should be thinking about whether what you’re designing meets the WCAG 2.0 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. 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.0 level AA. This can take time to arrange, so start planning for it during alpha.
Your team should use the audit results to fix problems. You’ll also need a retest to check you’ve fixed everything, so make sure you leave enough time for this.
Appointing an auditor
If you don’t have anyone in your department with experience of doing accessibility audits, you can use the Digital Marketplace to find an external supplier. Audits by external suppliers usually cost between £5,000 and £7,000.
Your brief should explain that your service needs to be tested with assistive technologies and checked against WCAG 2.0 level AA.
You should also include:
- your service name and a description of what it’s for
- the scale of your service - including the types of content and interactions you have, as well as common user journeys
- how you want your audit results presented - you can ask for examples so you can work out what will be most useful to your team
- the type of support you need - this might include help choosing what to audit, and help fixing any problems that are found
When appointing an auditor, make sure they:
- have extensive auditing experience
- have in-depth knowledge of WCAG 2.0
- are experienced at testing with assistive technologies
- will help you prioritise problems and suggest ways to fix them
If you can, use someone with previous experience of auditing government services. You can also ask suppliers for references and example accessibility reports.
Anyone carrying out an accessibility audit might find the following WC3 resources useful:
Learn more about working with contractors or third parties.
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:
- a series of interviews with people with disabilities 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
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: