Testing for accessibility
You must test and audit your service to make sure it can be used by all your users. You’ll need to make sure your service:
- meets level AA of the Web Content Accessibility Guidelines 2.1 (WCAG 2.1) as a minimum
- works on the most common assistive technologies - screen readers or speech recognition software, for example
You’ll also need to test your service with users who have disabilities and with older users.
If your service isn’t accessible to anyone who needs it, you may be in breach of the Equality Act 2010.
The best way to meet these criteria is to:
- think about accessibility from the start
- run your own accessibility tests regularly throughout development
- get a formal accessibility audit before you go into public beta
Think about accessibility from the start
Consider accessibility at every stage. During discovery, this might mean making sure you’re not making decisions that might exclude people. You might find the Government Digital Service’s (GDS) accessibility user profiles useful at this stage.
Start thinking about technical accessibility from alpha. Even when you’re only discussing ideas and developing concepts, consider whether what you’re thinking about meets the WCAG design principles and how people with impairments to their sight, hearing, movement, memory or thinking might use it.
You should run regular tests as soon as you start writing production code. Once your service moves into public beta, run tests every time you add a new feature.
When you’re working on rough prototypes, you don’t need to worry about your code being accessible. But it’s useful to check that things like the colour contrasts you’re using are accessible.
Working in this way helps you identify and fix issues early. It’s much more expensive to unpick and fix them at a later stage.
Testing your code
Test your code regularly, using both automated testing and manual testing. These tests will also uncover issues with design and content.
It’s important to do both types of testing - you’ll miss some issues if you only do automated testing.
Use the accessibility checklist created by 18F (the US government’s digital agency) to help you with your manual testing.
For automated tests, GDS uses a range of tools, including:
See the GDS accessibility team’s audit of the most used accessibility tools if you’re not sure which tools to use.
Testing with different browsers and devices
Your service needs to work on the most common browsers and devices people use.
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 ask to use the GDS empathy lab instead.
You should ask for assistive technology testing to be included in your audit, even if you’ve done testing yourself.
Getting an accessibility audit
You must get an accessibility audit - and fix any issues - before your service moves into public beta.
Don’t leave your audit until the last minute - make sure there’s time to act on the recommendations.
Work out what you need from your audit
Before you start searching for someone to carry out your audit, you’ll need to work out which elements of your service you want the audit to focus on.
It’s not feasible to audit the whole service. You should usually focus on:
- getting a representative sample of your page templates tested
- any key interactive features
- your most common or important user journeys
- any particularly problematic areas you’ve seen in testing
If you build a reusable components library, get all of the components tested. Using a library makes things easier in the long run: if you hard-code all of your pages you’ll need to fix each instance of a problem manually, rather than just updating the library.
There are a number of different types of test you could ask for, including:
- conformance testing - this is an assessment of your service against WCAG 2.1
- assistive technology compatibility testing - this shows how well your service performs with things like screen magnification software and speech recognition tools
- a usability review - this involves experienced testers with a range of disabilities going through your service and finding accessibility issues
How to get an audit
- ask a specialist from your department to do the audit - they’ll need good accessibility and assistive tech knowledge, and experience of evaulating services against WCAG 2.1
- find a third party auditor, which usually costs between £3,000 and £7,000 depending on the size and scope of your service - you can use the Digital Marketplace to help you find a supplier
Arrange a follow-up audit when you book your initial audit, so you can check you’ve fixed any issues.
If you’re using a third party auditor, there are a couple of extra steps you’ll need to take.
Write an accessibility audit brief
You’ll need to write a brief so potential suppliers know what you need from them. In your brief, include:
- the name of your service and a description of what it is - it’s helpful to include some screenshots and URLs
- who your users are and what their impairments might be
- what your priorities are for the audit and why
- which user journeys, tasks, patterns or page types you’d like the auditor to look at - it’s helpful to provide a list of components in your pattern library
- your timescale for the audit - allow enough time for bug fixes before you move on to the next stage of user testing
- whether you’re aiming for WCAG 2.1 level AA or level AAA compliance
- who will read the audit report - for example, product managers or developers
- how much support you want - it’s a good idea to get support from the start and ongoing support after the audit
- whether you’ll need help fixing any issues identified in the audit
You should also tell potential suppliers:
- where you are in your development cycle
- if you want to attend any of the testing and the dates you could attend
- if any part of your service was built by a third party
Check that you’ll get to discuss things face-to-face with your auditors and make sure they don’t rely exclusively on automated tools.
Check W3C’s evaluation methodology if you’re not sure which pages to get tested or how the evaluation process works.
Pick a supplier
Don’t automatically go for the cheapest supplier - they often won’t represent the most valuable choice. Look for suppliers that:
- have extensive experience of doing audits, preferably of government services
- where possible, are familiar with the service standard and GOV.UK design patterns
- provide clear and actionable reports - it’s okay to ask to see examples
- are involved in the wider accessibility community - for example through publishing blog posts, running training and contributing to standards
- can help you prioritise issues and provide support in fixing them - it’s worth paying more for a supplier that can help with this
- meet your needs - for example if you need support tickets raised in a specific project management tool
What happens after the audit
You’ll need to prioritise and fix the issues raised in your audit report. Your supplier should be able to help you with this - it’s worth choosing a supplier that offers this service, and paying a bit extra if necessary.
Use your follow-up audit to check you’ve fixed all the issues.
If you need extra help, start with the cross-government accessibility community google group or accessibility community slack channel.
You could also use the:
You can start some simple tests with:
- W3C Easy Checks - a few quick things to help you start to assess how accessible a webpage is
- Basic screen reader commands for accessibility testing, from the Paciello Group
- WCAG report generator
You can also 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: