Beta This is new guidance. Complete our quick 5-question survey to help us improve it.
Testing for accessibility
You must test and audit your service to make sure it can be used by everyone who needs it. If it isn’t accessible, you may be in breach of the Equality Act 2010.
Learn more about making your service accessible.
Meeting the Digital Service Standard
You must build an accessible service as part of meeting these points:
- point 1 (understand user needs)
- point 2 (do ongoing user research)
- point 12 (make sure users succeed first time)
You’ll have to explain how you did this in your service assessments.
You’ll also have to explain how your service meets government accessibility requirements.
What to test
To meet technical government accessibility requirements, your service must:
- meet level AA of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0) as a minimum
- work on the most commonly used assistive technologies - like screen readers and speech recognition tools
You’ll also need to do user research to make sure your service is fully accessible.
When to test
You should start thinking about accessibility during alpha.
As your team begins to discuss ideas and develop concepts, consider whether what you’re designing meets WCAG’s design principles. You also need to understand how people with impairments to their sight, hearing, movement, memory and thinking might use your service.
This will reduce the risk of introducing accessibility problems that might be difficult or expensive to fix at a later stage. You may also become aware of issues when doing user research with people who have disabilities.
Regular testing throughout beta will help build your knowledge of common problems and best practice. It should also help you pass your accessibility audit, which is something you must get before your beta assessment.
Getting an accessibility audit
Your service owner should start planning for an accessibility audit in alpha.
You must get this audit towards the end of beta to provide evidence at assessment that your service works with assistive technologies and meets level AA of WCAG 2.0.
If you don’t have anyone in your department with specialist accessibility auditing skills, you’ll need to have your audit done by an external supplier. This usually costs between £5,000 and £7,000.
You’ll also need to get a retest to check you’ve fixed any problems found by the audit, so make sure you leave enough time for this.
What to audit
You don’t need to get your whole service audited. Choose a sample that includes all the different types of content and interactions in your service.
Your auditor can help you decide what to include. If you start working with them at the beginning of beta, they can also do an early audit to check that your styles, components, templates and patterns are accessible before you start using them across your service.
Using audit results to fix problems
Audit results usually include:
- a spreadsheet of WCAG success criteria, with a ‘pass’ or ‘fail’ against all that were tested
- a report describing the problems found and why they’re important
- ways to fix problems (including code examples) - content and design issues might need to be fixed by someone else on the team
When you receive the report, your auditor should help you prioritise any problems. If you use a bug-tracking system, you can ask them to use this.
Make sure the report includes a summary that’s written in language that a non-technical audience can understand. The summary should mainly cover the effect of any problems on users.
Testing code yourself
You should regularly check that your code and content meet WCAG 2.0 level AA requirements. This should help reduce the number of problems the audit finds.
Use a combination of automated tools and manual testing. Automated testing tools identify basic accessibility issues quickly and cheaply but only find about 20% of problems.
Using automated testing tools
Automated tools can help you identify accessibility issues as they’re created. You can integrate them into your code or run them in your browser - both will give you immediate feedback when they find an accessibility issue.
For example, the Government Digital Service (GDS) Accessibility team uses a range of tools to identify issues, including:
- aXe, an in-browser testing tool
- Wave, an in-browser testing tool
- Tenon, an API you can integrate with other tools
- SiteImprove, an in-browser testing tool
Read a blog post about choosing automated testing tools from the GDS Accessibility team.
Doing manual accessibility tests
You should also test your code manually. Use the accessibility checklist created by 18F (the US government’s digital agency) to help you work through issues that users might have.
Testing with different browsers and devices
Your service needs to work on every browser or device that somebody might use to access it.
Not all browsers will render web pages in the same way, which means they might not always look perfect. However, users must be able to access the information they need or be able to complete their task without layout issues causing any problems.
Find out about designing for different browsers and devices, including which browsers to test in.
Testing with assistive technologies
You must also test that your service works with the most commonly used combinations of browsers and assistive technologies.
If you don’t have access to all the technologies you need to test, you can:
- get your service owner to ask for assistive technology testing to be included in your audit
- use the devices at GDS with assistive technologies installed - to arrange this, email firstname.lastname@example.org
Examples and case studies
Read some blog posts on:
- dos and don’ts on designing for accessibility
- how the Government Digital Service did accessibility testing on GOV.UK
You may also find these guides useful:
- Published by:
- Accessibility community
- Last update:
Guidance first published