Accessibility overview

What are our accessibility requirements?

To meet Government accessibility requirements, digital services must:

• meet level AA of the Web Content Accessibility Guidelines (WCAG) 2.2 as a minimum
• publish an accessibility statement that explains how accessible the service is – the website will need to be thoroughly audited for WCAG compliance, the Digital Transformation can help you with this.
• work for people using assistive technologies, including screen magnifiers, screen readers and speech recognition tools

If your service meets government accessibility requirements, then you will 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 our websites. That means customers are able to:

• change colours, contrast levels and fonts
• zoom in up to 400% 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.2 design principles

WCAG 2.2 is based on 4 design principles:

• Perceivable – the customer can see or hear a description of every element on the website
• Operable – the customer can interact with links and buttons to follow their task through to completion
• Understandable – the content is not too hard to understand, using plain English, and instructions to complete tasks are clear
• Robust – the website code is stable, and the customer will not experience unexpected failures

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 need to:

• use a keyboard instead of a mouse
• change browser settings to make content easier to read
• use a screen reader to speak content aloud
• 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 the content, code and interactions like forms or third party tools.

Meeting WCAG 2.2 standards

The WCAG  2.2 accessibility rules are organised into themes called “guidelines”. Each guideline then has a set of specific checkpoints, called “success criteria”, that your website or service needs to meet. There is often more than one way to meet a success criterion, so it is important to choose the approach that works best for your service and the type of people who will be using it.

To make sure your website meets all the WCAG 2.2 Level AA requirements, it needs to pass all Level A and Level AA success criteria. Some accessibility issues are easy to spot, but many are hidden in the code and can only be found through proper testing. This is why accessibility checks need a mix of automated tools and manual testing by specialists.

WCAG 2.2 also includes Level AAA requirements. These go even further and are designed to make websites as easy to use as possible, especially for people with disabilities or those using assistive technologies. You are not legally required to meet all of these, but it is good practice to meet as many as you reasonably can to give every customer the best possible experience.

Principle 1: Perceivable

To meet WCAG 2.2 Principle 1: Perceivable everyone must be able to take in information on a website using at least one of their senses. In simple terms, everyone should be able to perceive what is on a page, whether through sight, hearing, or assistive tools like screen readers, braille displays, or captions. When information is not perceivable, users are excluded before they even get a chance to interact with the site.

Content should never rely on a single sense like sight or sound – there must always be an accessible alternative, like a transcript or the ability for assistive technology to read it.

This principle focuses on making sure information is not “hidden” from anyone. For example, blind users need descriptions of images, deaf users need captions for audio, and people with low vision need text that can be enlarged or uses high‑contrast colours.

Below are some actions to consider when creating a website or web content to make sure it is perceivable:

• provide text alternatives (known as “alt text“) for non-text content
• provide a transcript for audio and video elements
• provide captions for video elements
• 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 code markup for every element (for example, forms, buttons and tables), so that they function correctly and can be read out correctly by assistive technology
• do not use colour as the only way to explain or distinguish something – for example by using flat colours in charts with no labels or textures to help the customer connect the segment to its meaning
• choose text colours that show up clearly against the background colour
• when the zoom is increased up to 400% make sure every element still functions correctly and the content wraps to the width of the screen or browser window
• do not use images of text
• make sure your service is responsive to screen size and page orientation, as well as custom user settings like zoom or font size – this means nothing goes off-screen, and the customer does not have to scroll sideways to see anything
• make sure your service works well with assistive technologies – meaning customers who rely on these technologies can access all the information and transactions on your website

Principle 2: Operable

To meet WCAG 2.2 Principle 2: Operable your customers must be able to use and interact with your website, no matter how they navigate.
Some people use a mouse, but others rely on a keyboard, voice commands, switch devices, or assistive technology. A website should never require actions that some users physically cannot perform.

In simple terms, people need to be able to move around the site, select things, fill in forms, and control features in ways that work for them. This includes being able to use a keyboard and no mouse, having enough time to read and complete tasks, avoiding flashing content that could trigger seizures, and providing clear ways to move through pages.

If a website is not operable, users may get stuck on parts of the page and not be able to complete their task, run out of time before finishing something, or be unable to access key functions at all – which means they cannot use the site.

Below are some actions to consider when creating a website or web content to make sure it is operable:

• make sure all elements can be reached and used by keyboard-only users
• make sure there is the option to play, pause and stop any moving content
• not use blinking or flashing content – and let the user pause or disable animations
• provide a “skip to content” link – this is an invisible link at the top of the site that assistive technology users can use to skip past things like the header and menu items
• use descriptive titles for pages and frames – a good way to check is if someone were to say just those words out of context, would it be obvious what they mean
• make sure keyboard and assistive technology users can move through content in a logical order
• use descriptive links, so users know exactly what page, document or website a link will take them to (never use “click here”)
• use meaningful headings and labels, making sure that any accessible labels match or closely resemble the label you are 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”, and is usually a border in a strongly contrasting colour
• only use things like mouse events or dynamic interactions (like swiping or pinching) when they are strictly necessary – or provide a way for 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.2 Principle 3: Understandable, people should be able to easily understand both the content of your website and how to use your service. If information is confusing or anything on the website behaves unpredictably, your customers, especially those with cognitive or learning disabilities, will struggle to use the website.

In simple terms, a website should be written clearly, behave in expected ways, and guide people when they need help, so that everyone, including people with cognitive disabilities, non‑native speakers, or people new to technology, can use it.

At its core, the principle focuses on making things clear, predictable, and supportive. That means using plain language, keeping layouts and navigation consistent, and giving helpful error messages when something goes wrong. Without this, users can get lost, make mistakes, or simply give up on the task.

Below are some actions to consider when creating a website or web content to make sure it is understandable:

• use plain English
• keep sentences short
• not use words and phrases that people will not recognise, or provide an explanation if you cannot 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 elements on your website look consistent and behave in predictable ways
• make sure all form fields have visible and meaningful labels – and that they are marked up properly in the code
• make it easy for people to identify and correct errors in forms – you can find best practices for form design on our structuring our forms page

Principle 4: Robust

To meet WCAG 2.1 Principle 4: Robust, websites must work well with different technologies, both now and in the future.

This includes browsers, phones, tablets, screen readers, voice control tools, and other assistive technologies. The content must be built in a way that these tools can correctly read, interpret, and interact with it.

In simple terms, your website should not “break” when someone uses assistive technology or a different browser, and it should not rely on code that only works in one place or for one specific tool. Good structure, valid HTML, and proper use of labels, roles, and states help assistive technology to understand what things are and how they work.

If a site is not robust, assistive technology may misread content or fail entirely, leaving people who depend on them unable to use the website. Robust code makes websites more “future‑proof”, meaning they are more likely to continue to be accessible as technology evolves.

Below are some actions to consider when creating a website or web content to make sure it is robust:

• use valid HTML, so user 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 pop-ups are marked up in a way that informs users of their presence and purpose and lets them interact with them using their assistive technology
• make sure the user can return to what they were doing after they have interacted with the status message or pop-up

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.

Where possible adding documents to your website should be avoided in favour of providing the information directly in your web content. All our web pages are printer friendly, so the user can choose to save or print the information themselves.

Please be aware that charts and tables can often be particularly inaccessible within documents, often being ignored by assistive technology completely. The data should be described in text underneath so that all users can understand what is on the page.

Please also avoid using images of text within documents, and again provide a description below if it cannot be avoided.

Publishing an 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, but it also needs to follow the correct format set out in the government template. Users with a disability may come to this page first to understand which areas of the site will be inaccessible to them, so it should always have a summary at the top briefly describing any known issues. This saves disabled users time and frustration, allowing them to know right away whether to proceed online or stop and contact us for help.

The accessibility 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, it must list which parts of your website or mobile app do not currently meet accessibility standards and how
• how people can get access to alternatives to content that’s not accessible to them
• how to contact your service 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, and this is the template the Digital Transformation Team uses when we create new websites.