Complete our quick 5-question survey to help us improve our content.

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 doesn’t 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:

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 the Government Digital Service’s (GDS) 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 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.

Manual testing

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 have a disability which means they 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, accessibility Inspector for Mozilla Firefox and the accessibility features in Chrome DevTools.

Automated testing

For automated testing 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 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.

This means:

Getting an accessibility audit

You must get an accessibility audit - and fix any issues - before your service moves into public beta.

Useful resources

You can start some simple tests with:

You can also read some blog posts on:

You may also find these guides useful:

Published by:
Accessibility community
Last update:

Guidance first published