Skip to main content

This manual is a community effort. Email your feedback to help us to improve it.

Skip past section navigation

Service features

There are some things you need to consider about your service to meet the Web Content Accessibility Guidelines AA standard.

The guidance on this page doesn’t cover fundamentals such 1.4.1 Use of Color as 1.4.3 Contrast. This guidance is more to highlight things you need to consider about your entire service.

2.2.1 Timing Adjustable (Level A)

There are several ways you can meet this criterion.

You can use the Manage a session time out pattern to allow the user to extend the time limit. This balances security with usability.

You can also meet this criterion by making your session longer than 20 hours. This may not be appropriate in the context of your service, though.

There may be cases where using real-time events mean time limits are appropriate. For example, when using two-factor authentication.

Read W3’s guidance on success criterion 2.2.1 Timing Adjustable

You should be validating user input page by page and giving feedback to the user on how to correct any issues. We recommend using the Error messages component from the GOV.UK Design System. This component includes guidance on how to write good error messages.

Data can pass validation and still not be correct though, so you need to give the user the option to check it.

We recommend using the Check answers pattern from the GOV.UK Design System. Using this pattern gives the user the opportunity to review and correct what they have inputted.

When designing a very large transaction with lots of sections, it may help to include a check answers page at the end of each section.

Read W3’s guidance on success criterion 3.3.4 Error Prevention (Legal, Financial, Data)

3.2.6 Consistent Help (Level A)

Services may offer help mechanisms to help users with the service. Help mechanisms could include:

  • contact details,
  • help pages (including accessibility statement pages and support pages),
  • and chat bots.

When you include these help mechanisms on multiple pages on a service, they must be in the same place on each of those pages. For example, a link to a help page in a list of links in the footer should also be in the footer on any other pages it is featured. It should also be in the same order in that list of links.

People who need to rely on help the most will be able to find that help more easily if it’s featured in the same way across different pages.

Sometimes you may need to design services that integrate with other micro-services. Here, particular care and consideration should be given to providing consistent help.

Read W3’s guidance on success criterion 3.2.6 Consistent Help

3.3.7 Redundant Entry (Level A)

Services should not ask for information from users and then require the user to input that same information again in the same process.

Sometimes asking for the same information again is unavoidable. If that’s the case, then the information must be either auto-populated or available to the user to select.

Designers need to ensure that the interfaces they design don’t ask the same questions over and over again. This requires consideration of how the whole service works from start to finish.

We recommend reading the guidance on Question Pages from the GOV.UK Design System to ensure that you’re asking user questions in the right way.

Read W3’s guidance on success criterion 3.3.7 Redundant Entry

3.3.8 Accessible Authentication (Minimum) (Level AA)

This success criterion applies if your service requires authentication (logging in). Authentication must not include a cognitive function test (such as remembering a password or solving a puzzle). This success criterion applies to all authentication processes on your service. That means you also need to consider things like forgotten password journeys.

We recommend:

This will help to ensure that authentication processes are accessible.

Read W3’s guidance on success criterion 3.3.8 Accessible Authentication (Minimum).

Back to top