Accessibility and assisted digital

Testing for accessibility

Give feedback about this page

From:
Accessibility community

You need to make sure your service meets level AA of the Web Content Accessibility Guidelines 2.2 (WCAG 2.2) as a minimum.

If the service does not meet WCAG 2.2 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 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.

Automated testing

There are a range of tools for automated testing including:

Manual testing

Doing a basic accessibility check if you cannot do a detailed one is guidance 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.

This means:

  • 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.

Useful resources

You can start some simple tests with:

You can also read some blog posts on:

You may also find these guides useful:

From:
Accessibility community
Last updated
23 days ago
Last update:

Section about when GDS is monitoring the new success criteria in WCAG 2.2 has been removed.

  1. Added information about WCAG 2.2 and what GDS is doing as a result of the new success criteria in WCAG 2.2.

  2. Page reviewed and updated.

  3. Guidance first published