Meeting accessibility requirements

To meet government accessibility requirements, digital services must:

• meet level AA of the Web Content Accessibility Guidelines (WCAG 2.1) as a minimum.
• have an accessibility statement that explains how accessible the service is – you need to publish this when the service is made available to the public.
• work with the commonly used assistive technologies. This includes screen magnifiers, screen readers and speech recognition tools.

If your service meets government accessibility requirements, then you’ll also be meeting the accessibility regulations that apply to public sector websites and mobile applications.

We want as many people as possible to be able to use this website. That means that users need to be able to:

• zoom in up to 300% without the text spilling off the screen
• navigate most of the website using just a keyboard
• navigate most of the website using speech recognition software
• listen to most of the website using a screen reader (including the most recent versions of JAWS, NVDA and VoiceOver)

WCAG 2.1 design principles

WCAG 2.1 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 or all of a screen
• use voice commands to navigate a website

The principles apply to all aspects of your service including code, content and interactions.

Meeting WCAG 2.1 standards

The WCAG 2.1 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.

You need to do 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 the to identify potential problems.

Principle 1: Perceivable

To meet WCAG 2.1 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 know they’re important

Principle 2: Operable

To meet WCAG 2.1 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
• 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 pinching) 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

Principle 3: Understandable

To meet WCAG 2.1 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:

• use plain English
• keep sentences short
• not use words and phrases that people won’t recognise – or provide an explanation if you can’t avoid it
• explain all abbreviations and acronyms, unless they are well known and in common use – for example, UK, EU, VAT
• 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
• make sure all form fields have visible and meaningful labels – and that they are marked up properly
• make it easy for people to identify and correct errors in forms – you can find best practices for form design on our interactions design page

Principle 4: Robust

To meet WCAG 2.1 Principle 4: Robust, you must make sure your content can be interpreted reliably by a wide variety of user agents (including reasonably outdated, current and anticipated browsers and assistive technologies).

This means you need to do things like:

• use valid HTML so user agents, including assistive technologies, can accurately interpret and parse content
• make sure your code lets assistive technologies know what every user interface component is for, what state it is currently in and if it changes
• make sure important status messages or modal dialogues are marked up in a way that informs users of their presence and purpose and lets them interact with them using their assistive technology
• lets the user return to what they were doing after they’ve interacted with the status message or modal input

Accessible documents

It is important that all PDFs and documents that are on a website are meaningful and useful. GOV.UK has provided guidance on how to publish accessible documents that meet the needs of all users under the accessibility regulations.

Accessibility statement

You need to publish an accessibility statement to explain how accessible your website or mobile app is.

Most people looking at your statement will not be accessibility experts, so it needs to be written in plain English that everyone can understand. This will also make it easier for users with a disability (who might have a cognitive impairment or learning disability) to understand how they can best use your website or mobile app.

Your statement needs to cover:

• whether your website or mobile app is ‘fully’, ‘partially’ or ‘not’ compliant with accessibility standards
• if it’s not fully compliant, which parts of your website or mobile app do not currently meet accessibility standards and why (for example, because they are exempt or it would be a disproportionate burden to fix things)
• how people can get alternatives to content that’s not accessible to them
• how to contact you to report accessibility problems – and a link to the website that they can use if they’re not happy with your response.

GOV.UK has provided a sample accessibility statement that meets the needs of all users under the accessibility regulations.