Beta This is new guidance. Complete our quick 5-question survey to help us improve it.

  1. Service manual
  2. Technology
  3. 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:

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 government accessibility requirements, your service must:

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.

During beta, you should test each time you build a new feature (even if you’re using the GOV.UK template, frontend toolkit, elements or design patterns).

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 test that you’re meeting WCAG 2.0 level AA requirements.

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, make sure your service owner asks for assistive technology testing to be included in your accessibility audit.

Examples and case studies

Read some blog posts on:

You may also find these guides useful:

Published by:
Accessibility community
Last update:

Guidance first published