Skip to main content

A guide to WCAG

This guide was previously known as the WCAG Primer.

This guide will help you make websites, documents and apps that are accessible to everyone. This includes disabled people, and those with health conditions or impairments to their:

  • vision - such as blind, partially sighted or colour blind people
  • hearing - such as people who are deaf or hard of hearing
  • movement - such as motor skills which make it hard to use a mouse or keyboard
  • thinking and understanding - including people with dyslexia, autism or learning difficulties

This guide gives you an overview of the Web Content Accessibility Guidelines (WCAG), also known as the WCAG standard. It does not replace the official WCAG standard.

It’s updated by volunteers from across the UK public sector.

Who this guide is for

This guide has been created for the UK cross government accessibility community.

Anyone can use it, but it will be most useful if you work in content, design or code.

About WCAG

WCAG is a set of guidelines to help you to make sure websites and apps work for all users, including people who:

  • change the way a website looks in their browser
  • use a keyboard instead of a mouse
  • use a screen reader to navigate and present website content as speech
  • use an an electronic braille display
  • use a screen magnifier to increase the size of everything on-screen
  • use speech recognition to use the web with voice commands and dictation

WCAG is written by accessibility specialists, volunteers and disabled people at the World Wide Web Consortium W3C.

WCAG guidelines and levels

There are 13 guidelines, grouped into 4 themes (‘principles’):

  • Perceivable: people need to know that content or functionality is there
  • Operable: people need to be able to use things
  • Understandable: people need to understand things easily
  • Robust: things need to be compatible with different technology

The things you need to do (‘success criteria’) are grouped under these guidelines. There are 3 levels of success criteria:

  • A: basic, essential - this covers vital areas such as images having text alternatives and functionality working with a keyboard.
  • AA: important. Meeting level AA will mean most people can use the website.
  • AAA: complex or specialist. For example, a sign language interpretation of a video.

This guide focuses on A and AA success criteria to help you meet the minimum legal standard. Find out more about AAA success criteria.

Rules for public sector websites and apps

Public sector websites and apps in the UK must meet WCAG 2.2 level AA.

This means you must pass the success criteria for both level A and level AA. You may be breaking the law if your website or app does not.

Find out more about the accessibility regulations for public sector websites and apps.

What’s new in WCAG 2.2

WCAG 2.2 extends previous versions of WCAG by adding 6 new criteria you need to meet to reach the legal level for accessible websites and apps.

It also includes all the criteria from previous versions of WCAG, apart from 4.1.1 Parsing (A) - because this is covered by other criteria.

The new A or AA criteria for WCAG 2.2 are:

  • 2.4.11 Focus Not Obscured (Minimum) (AA)
  • 2.5.7 Dragging Movements (AA)
  • 2.5.8 Target Size (Minimum) (AA)
  • 3.2.6 Consistent Help (A)
  • 3.3.7 Redundant Entry (A)
  • 3.3.8 Accessible Authentication (Minimum) (AA)

If your website or app meets WCAG 2.2, it also meets versions 2.1 and 2.0.

Find out more about what’s new in WCAG 2.2.

WCAG overview

Here is a short description of the principles, guidelines and success criteria you must meet.

Principle 1: Perceivable

Your service must present information in ways people can recognise and use, no matter how they consume content (by touch, sound or sight for example)

Guideline 1.1: Provide text alternatives

  • 1.1.1 Provide a text description for images, and make sure the description serves the same purpose as the image. More about 1.1.1

Guideline 1.2: Provide alternatives for time-based media

  • 1.2.1 Provide a text description for video content that has no audio, or a transcript for audio content that has no video, and make sure the description and transcript serve the same purpose as the original content. More about 1.2.1
  • 1.2.2 Provide real-time captions for video content that has audio, and make sure the captions include all dialogue and important sound-effects. More about 1.2.2
  • 1.2.3 Provide a text description or a transcript for video content that has audio, and make sure the description or transcript serves the same purpose as the original content. More about 1.2.3
  • 1.2.4 Provide real-time captions for live video content that has audio, and make sure the captions include all dialogue and important sound-effects. More about 1.2.4
  • 1.2.5 Provide audio description for video content, and make sure the description includes all important activity that takes place on-screen. More about 1.2.5

Guideline 1.3: Create content that can be presented in different ways

  • 1.3.1 Use elements like headings, lists and tables to properly convey the structure of content. More about 1.3.1
  • 1.3.2 Make sure content can always be read in a logical order even when stylesheets are disabled. More about 1.3.2
  • 1.3.3 Do not use colour, size, shape, sound or location as the only way to convey instructions. More about 1.3.3
  • 1.3.4 Make sure a page view is not locked to either horizontal or vertical views only, unless this is essential. More about 1.3.4
  • 1.3.5 In forms that collect information about the user add HTML autocomplete attributes to identify the purpose of the input. More about 1.3.5

Guideline 1.4: Make content easy for people to see and hear

  • 1.4.1 Do not use colour as the only way to convey information of any kind. More about 1.4.1
  • 1.4.2 Give people a way to stop audio content if it plays automatically and lasts longer than three seconds, or give them a way to change the volume without changing their system settings. More about 1.4.2
  • 1.4.3 Make sure that the colour of text contrasts clearly against its background colour. More about 1.4.3
  • 1.4.4 Make sure it is possible to complete all tasks when text is resized up to 200% in the browser. More about 1.4.4
  • 1.4.5 Do not use images that contain text. More about 1.4.5
  • 1.4.10 Make sure content will reflow to a single column when zoomed and not produce scrolling in both directions. More about 1.4.10
  • 1.4.11 Make sure sight impaired users can see important controls and understand graphics. More about 1.4.11
  • 1.4.12 Make sure users can modify text line height, letter or word spacing. More about 1.4.12
  • 1.4.13 Provide a way to control how people can interact with or dismiss any ‘extra’ content that becomes visible. More about 1.4.13

Principle 2: Operable

Your service must be navigable and usable no matter how someone uses it (without a mouse, with voice commands, or with a screen magnifier for example).

Guideline 2.1: Make functionality work with a keyboard

  • 2.1.1 Make sure every task can be completed using just a keyboard. More about 2.1.1
  • 2.1.2 Make sure that keyboard users do not get stuck when navigating through content. More about 2.1.2
  • 2.1.4 Provide a way to switch off or remap keyboard shortcuts. More about 2.1.4

Guideline 2.2: Give people enough time to read and use content

  • 2.2.1 Give people a way to turn off or extend time limits. More about 2.2.1
  • 2.2.2 Give people a way to stop content that updates frequently, blinks or scrolls automatically. More about 2.2.2

Guideline 2.3: Do not cause seizures

  • 2.3.1 Do not use content that flashes more than three times a second. More about 2.3.1

Guideline 2.4: Provide ways to help people navigate and find content

  • 2.4.1 Give people who do not use a mouse a way to move to the start of the main content. More about 2.4.1
  • 2.4.2 Give every page a unique and helpful title that indicates the purpose of the page. More about 2.4.2
  • 2.4.3 Make sure that things receive focus in an order that makes sense. More about 2.4.3
  • 2.4.4 Make sure the purpose of a link is obvious from its link text, or its link text in association with nearby content. More about 2.4.4
  • 2.4.5 Unless a page is a step in a process, give people different ways of finding content (like searching or browsing links). More about 2.4.5
  • 2.4.6 Provide headings and form labels that will help people find content and complete tasks. More about 2.4.6
  • 2.4.7 Make sure that people using a keyboard to navigate can always see where they are on a page. More about 2.4.7
  • 2.4.11 [New] Make sure that people can always see any components that have keyboard focus. More about 2.4.11

Guideline 2.5: Make functionality easy to use through various inputs beyond keyboard

  • 2.5.1 Do not require complex gestures to do things. More about 2.5.1
  • 2.5.2 Do not have controls or user interface components that fire as soon as they are touched. More about 2.5.2
  • 2.5.3 Make sure that for user interface components with a visible label the accessible name matches. More about 2.5.3
  • 2.5.4 Make sure functionality can not only be activated by shaking or tilting the device. More about 2.5.4
  • 2.5.8 [New] Make sure controls, like buttons or links, are big enough or spaced far enough apart. More about 2.5.8

Principle 3: Understandable

Your service must make information understandable, and make it easy for people to understand how to complete tasks.

Guideline 3.1: Make text readable and understandable

  • 3.1.1 Identify the language that the content is written in. More about 3.1.1
  • 3.1.2 Identify any changes in the default written language of the content. More about 3.1.2

Guideline 3.2: Make things appear and behave in consistent ways

  • 3.2.1 Do not cause surprising things to happen (like opening a new page), when someone focuses on something. More about 3.2.1
  • 3.2.2 Do not cause surprising things to happen when someone interacts with content (like scrolling through a set of options). More about 3.2.2
  • 3.2.3 Make sure that ways to find and navigate content (like search) look and behave the same way when they are used in multiple places. More about 3.2.3
  • 3.2.4 Make sure that features look and behave the same way when they are used in multiple places. More about 3.2.4

Guideline 3.3: Help people avoid and correct mistakes

  • 3.3.1 When someone makes a mistake, provide an error message and make it obvious where the mistake was made. More about 3.3.1
  • 3.3.2 Provide form labels to make it clear what information is expected, and optionally provide extra hints to help people avoid mistakes. More about 3.3.2
  • 3.3.3 When someone makes a mistake give them suggestions on how to correct it, but do not offer suggestions that will have a negative impact on security. More about 3.3.3
  • 3.3.4 Give people a way to review and check the information they have entered, and to correct any mistakes they have made. More about 3.3.4
  • 3.3.8 [New] Make it as easy as possible to sign in - don’t make people remember, solve or transcribe something. More about 3.3.8

Principle 4: Robust

Your service must work with different browsers and assistive technologies in use now, and use technologies in ways that will make your service usable with the browsers and assistive technologies of the future.

Guideline 4.1: Make content compatible with different browsers and assistive technologies

  • 4.1.1 Make sure the code of each page does not contain errors that will have a negative impact on the way browsers and assistive technologies work together. More about 4.1.1
  • 4.1.2 Make sure the code of each page enables assistive technologies to discover the purpose of every feature, the way that feature is identified, and the state it is currently in. More about 4.1.2
  • 4.1.3 Make sure status messages are shown in a way that assistive technologies understand without receiving focus. More about 4.1.3

How to meet WCAG

Use this guide to find out more about the things you need to do to meet WCAG.

View all success criteria, or those that are related to content, design or code.

How to give feedback

Use the “Report problem” link at the end of each page if you spot any issues with this guide.