The Web Content Accessibility Guidelines (WCAG) help you make websites and apps accessible. The requirements can be applied using different technologies.
The full standard is technical and includes conditions and exceptions. This page provides a simplified explanation of WCAG 2.2 at Levels A and AA. Always use the full standard for an assessment.
This explanation is deliberately brief and straightforward. An assessment must always consider the full success criterion, its conditions and any exceptions.
What is WCAG?
WCAG is an international standard from the World Wide Web Consortium (W3C). People with disabilities and other specialists contribute to its development.
WCAG considers the different ways people use information. Someone might use a screen reader, braille display, screen magnification, speech input or a keyboard alone. People with hearing or cognitive disabilities may also need different ways to understand information and complete tasks.
WCAG 2.2 builds on WCAG 2.1. It adds new criteria and removes criterion 4.1.1 from WCAG 2.2. Meeting WCAG helps many people, but does not automatically meet every accessibility need.
How WCAG is organised
WCAG 2.2 has thirteen guidelines organised under four principles: content must be perceivable, operable, understandable and robust.
Each guideline contains testable success criteria. Every criterion has a level: A, AA or AAA. To meet Level AA, you must meet all applicable Level A and Level AA criteria. A criterion’s level is not a simple measure of a problem’s severity.
Below are plain-language summaries of all 55 Level A and AA criteria in WCAG 2.2. These summaries do not replace the full criteria and their exceptions. See the official WCAG 2.2 standard and W3C’s Understanding documents for the full requirements.
WCAG and legislation
The legal accessibility requirements depend on your organisation, product or service and the applicable legislation. For Dutch public sector websites and apps, the European standard EN 301 549 is the basis, including WCAG 2.1 at Levels A and AA.
The following sections explain the four principles, thirteen guidelines and the Level A and AA criteria. WCAG 2.2 adds requirements covering obscured keyboard focus, dragging, target size, help, repeated entry and authentication.
Principle 1: Perceivable
Present information in ways people can perceive. Do not make important information depend on sight or hearing alone.
Guideline 1.1: Provide text alternatives
1.1.1: Provide suitable text alternatives for non-text content. Exceptions apply to decorative images and other specific situations.
Guideline 1.2: Provide alternatives for time-based media
1.2.1: Provide an alternative for prerecorded audio-only and video-only content.
1.2.2: Caption prerecorded video with audio, including important sounds.
1.2.3: Provide audio description or a full media alternative for prerecorded video, as specified by the criterion.
1.2.4: Caption live video with audio.
1.2.5: Provide audio description for prerecorded video when important visual information would otherwise be missing.
Guideline 1.3: Create content that can be presented in different ways
1.3.1: Make structure and relationships, such as headings, lists and table associations, programmatically determinable or available in text.
1.3.2: Provide a programmatically determinable reading order when the order affects meaning.
1.3.3: Do not make instructions depend only on characteristics such as shape, colour, size, sound or position.
1.3.4: Support both landscape and portrait orientation unless a particular orientation is essential.
1.3.5: Make the purpose of relevant personal-information fields programmatically determinable, for example using appropriate autocomplete attributes.
Guideline 1.4: Make content easier to see and hear
1.4.1: Do not use colour alone to communicate information, actions or differences.
1.4.2: Let people pause or stop audio that plays automatically for more than three seconds, or control its volume independently.
1.4.3: Provide at least 4.5:1 contrast for normal text and 3:1 for large text, subject to the standard’s exceptions.
1.4.4: Allow text to be resized to 200% without losing content or functionality.
1.4.5: Use real text instead of images of text unless the image is essential or can be customised.
1.4.10: Keep content usable when enlarged without requiring scrolling in two directions, except where a two-dimensional layout is necessary.
1.4.11: Provide sufficient contrast, generally at least 3:1, for necessary visual information in controls and graphics.
1.4.12: Let people increase line, paragraph, letter and word spacing without losing content or functionality.
1.4.13: Make additional hover or focus content dismissible, hoverable and persistent where the criterion requires it.
Principle 2: Operable
People must be able to operate the interface and find their way around, for example using a keyboard, touchscreen or speech input.
Guideline 2.1: Make functionality available from a keyboard
2.1.1: Make functionality operable with a keyboard, except input that inherently depends on a movement path.
2.1.2: Do not trap keyboard users inside a component.
2.1.4: Let users turn off or remap single-character shortcuts, or activate them only while the relevant component has focus.
Guideline 2.2: Give people enough time
2.2.1: Let users turn off, adjust or extend time limits where required.
2.2.2: Provide control over moving, blinking, scrolling or automatically updating information where the criterion requires it.
Guideline 2.3: Avoid content that can cause seizures
2.3.1: Avoid flashes that exceed the thresholds for photosensitive seizures.
Guideline 2.4: Help people navigate and find content
2.4.1: Provide a way to bypass repeated blocks of content.
2.4.2: Give pages titles that describe their topic or purpose.
2.4.3: Provide a focus order that preserves meaning and operability.
2.4.4: Make a link’s purpose clear from its text or its programmatically determined context.
2.4.5: Provide more than one way to find pages within a set, except steps in a process.
2.4.6: Use headings and labels that describe the topic or purpose.
2.4.7: Make keyboard focus visible.
2.4.11: Do not let author-created content completely obscure a component that has keyboard focus.
Guideline 2.5: Make pointer input easier to use
2.5.1: Provide a simple single-pointer alternative to multipoint or path-based gestures unless the gesture is essential.
2.5.2: Prevent unintended activation by completing actions on release or providing a suitable way to cancel or undo them.
2.5.3: Include a control’s visible label text in its accessible name.
2.5.4: Provide an alternative to device-motion controls and let users disable unintended motion activation.
2.5.7: Provide a single-pointer alternative that does not require dragging unless dragging is essential.
2.5.8: Make pointer targets at least 24 by 24 CSS pixels or meet an allowed exception, such as sufficient spacing between smaller targets.
Principle 3: Understandable
Make information understandable. Keep interactions predictable and help people enter and correct information.
Guideline 3.1: Make text readable and understandable
3.1.1: Programmatically identify the page’s language.
3.1.2: Programmatically identify language changes in passages, subject to the standard’s exceptions.
Guideline 3.2: Make pages predictable
3.2.1: Do not trigger a change of context merely when an element receives focus.
3.2.2: Do not let changing a setting cause an unexpected change of context.
3.2.3: Keep the relative order of repeated navigation consistent.
3.2.4: Identify components with the same functionality consistently.
3.2.6: Keep repeated help mechanisms in the same relative order across pages.
Guideline 3.3: Help people avoid and correct mistakes
3.3.1: Describe input errors in text and identify the item with the error.
3.3.2: Provide labels or instructions when people need to enter information.
3.3.3: Offer useful suggestions for correcting input errors where possible, unless doing so would compromise security or the purpose of the content.
3.3.4: Let users reverse, check or confirm important legal, financial or data changes as required by the criterion.
3.3.7: Let users reuse or select information already entered in the same process, except where an allowed exception applies.
3.3.8: Do not require a cognitive function test for authentication without an alternative, assistance or an allowed exception. For example, support password managers and paste.
Principle 4: Robust
Use technologies in ways that let browsers and assistive technologies interpret the content and controls correctly.
Guideline 4.1: Support browsers and assistive technologies
4.1.2: Make controls’ names, roles, values and changing states programmatically available to assistive technologies.
4.1.3: Make status messages available to assistive technologies without requiring a change of focus.
