1. Service manual
  2. Accessibility and assisted digital
Accessibility and assisted digital

Understanding WCAG 2.2

Give feedback about this page

From:
Accessibility community

This is an overview of WCAG 2.2 level AA. It does not replace the WCAG 2.2 guidelines, which provide a full explanation of all principles and requirements.

The Web Content Accessibility Guidelines (known as WCAG) are an internationally recognised set of recommendations for improving web accessibility.

They explain how to make digital services, websites and apps accessible to everyone, including users with impairments to their:

  • vision - like severely sight impaired (blind), sight impaired (partially sighted) or colour blind people
  • hearing - like people who are deaf or hard of hearing
  • mobility - like those who find it difficult to use a mouse or keyboard
  • thinking and understanding - like people with dyslexia, autism or learning difficulties

Meeting government accessibility requirements

Services must achieve WCAG 2.2 level AA as part of meeting government accessibility requirements.

The Government Digital Service (GDS) is working on how to assess the new success criteria in WCAG 2.2 and will start monitoring for the extra criteria in October 2024. Until October 2024 we will monitor accessibility of websites and apps to WCAG 2.1 level AA.

WCAG 2.2 design principles

WCAG 2.2 is based on 4 design principles:

  • perceivable
  • operable
  • understandable
  • robust

By focusing on principles, not technology, they emphasise the need to think about the different ways that people interact with content. For example, users might:

  • use a keyboard instead of a mouse
  • change browser settings to make content easier to read
  • use a screen reader to ‘read’ (speak) content out loud
  • use a screen magnifier to enlarge part of a screen
  • use voice commands to navigate a website

The principles apply to all aspects of your service (including code, content and interactions), which means all members of your team need to understand and consider them.

Applying WCAG 2.2 guidelines

The WCAG 2.2 design principles are supported by 13 guidelines. Each of these is broken down into specific requirements (or ‘success criteria’) that your service needs to meet.

From beta, you need to do regular accessibility testing to check your design, code and content meet WCAG level AA. To do this, you must meet all A and AA requirements.

You should use a combination of automated tools and manual tests (including those listed in Testing for accessibility) to identify potential problems.

You’ll also need to get an accessibility audit before your beta assessment to provide evidence that your service meets level AA.

Principle 1: Perceivable

To meet WCAG 2.2 Principle 1: Perceivable you need to make sure users can recognise and use your service with the senses that are available to them.

This means you need to do things like:

  • provide text alternatives (‘alt text’) for non-text content
  • provide transcripts for audio and video
  • provide captions for video
  • make sure content is structured logically and can be navigated and read by a screen reader - this also helps if stylesheets are disabled
  • use the proper markup for every feature (for example, forms and data tables), so the relationships between content are defined properly
  • not use colour as the only way to explain or distinguish something
  • use text colours that show up clearly against the background colour
  • make sure every feature can be used when text size is increased by 200% and that content reflows to a single column when it’s increased by 400%
  • not use images of text
  • make sure your service is responsive - for example to the user’s device, page orientation and font size they like to use
  • make sure your service works well with assistive technologies - for example, important messages are marked up in a way that the screen readers knows they’re important

Principle 2: Operable

To meet WCAG 2.2 Principle 2: Operable, you have to make sure users can find and use your content, regardless of how they choose to access it (for example, using a keyboard or voice commands).

This means you need to do things like:

  • make sure everything works for keyboard-only users
  • let people play, pause and stop any moving content
  • not use blinking or flashing content - or let the user disable animations
  • provide a ‘skip to content’ link or equivalent
  • use descriptive titles for pages and frames
  • make sure users can move through content in a way that makes sense
  • use descriptive links so users know where a link will take them, or what downloadable linked content is
  • use meaningful headings and labels, making sure that any accessible labels match or closely resemble the label you’re using in the interface
  • make it easy for keyboard users to see the item their keyboard or assistive technology is currently focused on - this is known as ‘active focus’
  • only use things like mouse events or dynamic interactions (like swiping or dragging) when they’re strictly necessary - or let the user disable them and interact with the interface in a different way
  • make it easy for users to disable and change shortcut keys
  • make sure interactive elements such as buttons are big enough or spaced far enough apart to make it easy to select the right one

Principle 3: Understandable

To meet WCAG 2.2 Principle 3: Understandable, you have to make sure people can understand your content and how the service works.

This means you need to do things like:

  • make it clear what language the content is written in, and indicate if this changes
  • make sure features look consistent and behave in predictable ways, including help mechanisms
  • make sure all form fields have visible and meaningful labels - and that they’re marked up properly
  • make it easy for people to identify and correct errors in forms - you can find best practice for form design in the GOV.UK Design System
  • make it easy for people to re-enter information they’ve previously entered into a form
  • make it easy for people to log in without having to remember information or solve a problem

Principle 4: Robust

To meet WCAG 2.2 Principle 4: Robust, you must make sure your content can be interpreted reliably by a wide variety of user agents (including assistive technologies).

This means you need to do things like:

  • make sure your code lets assistive technologies know what every user interface component is for, what state it’s currently in and if it changes
  • make sure important status messages or modal dialogs are marked up in a way that informs users of their presence and purpose, and lets them interact with them using their assistive technology

Further reading

Read the following resources for more information about meeting the WCAG guidelines:

You might also find these guides useful:

From:
Accessibility community
Last updated
7 months ago
Last update:

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

  1. Page reviewed and updated.

  2. Guidance first published