You need to make sure your service meets level AA of the Web Content Accessibility Guidelines 2.1 (WCAG 2.1) as a minimum.
If the service does not meet WCAG 2.1 AA, you may be breaking the law.
If you’re working to meet the Service Standard, you’ll also need to:
- make sure the service works with the most common assistive technologies - screen readers or speech recognition software, for example
- test the service with disabled users and with older users
The best way to meet accessibility requirements 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. You might find these accessibility user profiles useful.
Start thinking about technical accessibility from alpha. When you’re discussing ideas and developing concepts, consider:
- whether what you’re thinking about meets the WCAG design principles
- 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 do not 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.
There are a range of tools for automated testing including:
See the GDS accessibility team’s audit of the most used accessibility tools if you’re not sure which tools to use.
Use the accessibility checklist created by 18F (the US government’s digital agency) to help you test for common accessibility problems, including:
- lack of keyboard accessibility (important because some people rely on using a keyboard to navigate websites)
- link text that’s not descriptive (for example,‘click here’ links)
- lack of colour contrast for text and important graphics and controls
- images not having meaningful alt text (where alt text is needed)
- online forms not being marked up correctly, so the right control is associated with the right label
Some browsers have tools that make it easier to find accessibility problems in the Document Object Model (DOM). For example, the Accessibility Inspector for Mozilla Firefox and the accessibility features in Chrome DevTools.
There are also tools like Microsoft’s Accessibility Insights which help going through manual checks.
Testing with assistive technologies
Your service needs to work on the most common browsers and devices people will use to access your service.
You must also make sure your service works with common assistive technologies.
- where possible, doing some testing with assistive technology yourself
- finding user research participants who use assistive technology
- asking for assistive technology testing to be included in your accessibility audit
Getting an accessibility audit
You must get an accessibility audit - and fix any issues - before your service moves into public beta.
You can start some simple tests with:
- Doing a basic accessibility test if you cannot do a detailed one
- W3C Easy Checks - a few quick things to help you start to assess how accessible a web page is
- Basic screen reader commands for accessibility testing, from TPGi
- WCAG report generator
You can also read some blog posts on:
- Assistive technology tools you can test with at no cost
- Why accessibility testing with real users is so important
- Using persona profiles to test accessibility
- Remote accessibility persona testing
- What we found when we tested tools on the world’s least-accessible webpage
You may also find these guides useful:
Page reviewed and updated.
Guidance first published