Your service must be accessible to everyone who needs it. If it isn’t, you may be breaking the law.
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:
- meet level AA of the Web Content Accessibility Guidelines (WCAG 2.1) 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
- have an accompanying accessibility page that explains how accessible the service is – the date you need to publish this depends on the date the service moves into public beta
If your service meets government accessibility requirements, then you’ll also be meeting the new accessibility regulations that apply to public sector websites and apps.
The full name of the new regulations is the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.
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 accessibility@digital.cabinet-office.gov.uk.
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 for a transactional service on GOV.UK can cost 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 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 barriers they face.
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 users with disabilities 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.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 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 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.
You’ll usually need to publish an accessibility page when you move into public beta.
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. It’ll also give you the information you need to publish your accessibility page.
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 page
Once you’ve got your audit results, you should be ready to draft and publish your accessibility page.
The accessibility page must explain:
- how accessible your service is
- what accessibility issues the service has, if any
- what you’re planning to do to fix the issues
If you decide you’re not going to fix something straight away or at all, you should be aware that you’re making a ‘disproportionate burden’ claim. This means that fixing the issue would lead to a burden or cost that is too much for your organisation to reasonably bear.
There’s more guidance on how to weigh up what to fix straight away.
There’s also a sample accessibility page you can use to help you write yours.
When you need to publish the accessibility page depends on when your service moves into public beta. If your service:
- went into public beta before 23 September 2018, you must publish your accessibility page by 23 September 2020
- moved into public beta after 23 September 2018, you must publish your accessibility page by 23 September 2019
- will move into public beta after 23 September 2019, you must publish your accessibility page as soon as you move into public beta
What to do about accessibility 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).
