---
title: "WCAG Explained Simply: The Four Principles at a Glance"
url: "https://insideuxdesign.com/en/blog/wcag-explained-simply-the-four-principles-at-a-glance"
language: "en"
description: "WCAG explained simply: structure, the four principles, levels A to AAA and everyday examples. Learn how to read a success criterion and get started today."
published: "2025-11-12T09:00:00+01:00"
updated: "2026-10-15T00:39:21+02:00"
---

# WCAG Explained Simply: The Four Principles at a Glance

What the WCAG are, how the guidelines are structured and what perceivable, operable, understandable and robust mean in practice. A clear introduction with everyday examples, no prior knowledge needed.

Picture this: your team hands you a new task. “Could you check whether our contact form is WCAG compliant?” You open the official W3C guidelines and land in a long document full of numbers like 1.4.3, 2.4.7 or 3.3.2, plus terms such as “success criterion”, “conformance level AA” and “programmatically determined”. Ten minutes later, you know one thing for sure: you need an overview first.

That overview is exactly what this article gives you. You’ll learn what the WCAG are, how they’re structured, what the four principles mean and how to read a single criterion without getting lost. No prior knowledge required. If you then want to know why accessibility goes far beyond contrast, or what the law requires, you’ll find pointers for further reading along the way.

## What the WCAG actually are

WCAG stands for *Web Content Accessibility Guidelines*. They’re published by the World Wide Web Consortium, or W3C for short, the body that also maintains standards such as HTML and CSS. You’ll find a short definition in the glossary under [WCAG](https://insideuxdesign.com/en/glossar/wcag).

On the web, [accessibility](https://insideuxdesign.com/en/glossar/accessibility) means that people can use a website whether they’re blind, hard of hearing, can only use a keyboard or struggle with complicated text. The WCAG turn that goal into concrete, testable requirements. Instead of “make it accessible somehow”, they say things like: normal text needs a contrast ratio of at least 4.5:1 against its background.

An important point for beginners: the WCAG don’t tell you what your website should look like. They define the outcome you need to achieve. How you get there is up to you. That’s why they work for a small blog just as well as for a large online store.

### Which version is current

There are several versions of the WCAG. WCAG 2.0 was published in 2008 and WCAG 2.1 in 2018. The current version is WCAG 2.2. It was first published in October 2023, and the version in force today dates from 12 December 2024. In October 2025, the W3C announced that WCAG 2.2 had also been approved as the international standard ISO/IEC 40500:2025.

The versions build on each other. In the W3C’s words, content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and 2.1. New versions mostly add criteria. WCAG 2.2 removed only one criterion (4.1.1 Parsing) because it had become technically obsolete. For you, that means: if you’re starting today, go straight for WCAG 2.2.

You may also come across WCAG 3. That’s a successor the W3C is working on. According to the W3C, it’s still an incomplete draft and won’t be finished for a few more years. The W3C explicitly recommends using WCAG 2.2 until then. So there’s no need to wait.

## The structure: from principle to criterion

The document looks overwhelming at first, but it follows a clear hierarchy with four levels. Once you know these levels, you’ll find your way around quickly.

1. **Principles:** At the top are four core principles. Content must be perceivable, operable, understandable and robust.
2. **Guidelines:** Below the principles sit 13 guidelines in total. They describe goals, for example “make all functionality available from a keyboard”. Guidelines themselves aren’t testable; they set the direction.
3. **Success criteria:** Under each guideline are the actual checkpoints. A success criterion is a statement that is either true or false for your content. WCAG 2.2 contains 86 of them.
4. **Techniques and explanations:** Each criterion comes with supporting documents that explain why it exists and how you can meet it. They’re helpful but not mandatory in themselves.

The numbers tell you where you are in this hierarchy. Take criterion 1.4.3: the first digit stands for the principle (1 = perceivable), the second for the guideline (1.4 = distinguishable) and the third for the criterion itself (1.4.3 = contrast, minimum). So when someone mentions “2.1.1”, you immediately know: principle operable, guideline keyboard, first criterion.

## The three levels: A, AA and AAA

Every success criterion is assigned to one of three conformance levels. Conformance simply means that a website meets the requirements of a given level.

- **Level A** is the minimum. It covers things without which some people can’t use a website at all, such as a keyboard trap you can’t escape from. WCAG 2.2 contains 31 Level A criteria.
- **Level AA** is the usual target. To reach AA, you must meet all Level A and Level AA criteria. That adds 24 more criteria, such as minimum contrast or a visible keyboard focus.
- **Level AAA** is the highest level, with another 31 criteria. Whole websites often can’t meet it completely, and the W3C doesn’t recommend it as a general policy. Individual AAA criteria can still be worth adding.

In practice, “WCAG compliant” almost always means WCAG 2.1 or 2.2 at Level AA. Laws in Europe refer to this level too. What that means in Germany is explained in the article [The BFSG in Practice](https://insideuxdesign.com/en/blog/bfsg-in-practice-german-accessibility-act-websites-apps), which covers the German Accessibility Strengthening Act (Barrierefreiheitsstärkungsgesetz).

One more detail beginners often miss: conformance always applies to full pages and complete processes. A checkout only conforms if every step, from the cart to the confirmation, meets the requirements. An accessible first step doesn’t help much if the third one can’t be reached with a keyboard.

## Principle 1: Perceivable

The W3C phrases the first principle like this: information and user interface components must be presentable to users in ways they can perceive. The core idea: no content should be available through only one sense. What you can see must also be available to hear or touch, and what you can hear must also be available to read.

This principle has four guidelines:

- **1.1 Text Alternatives:** Images, icons and graphics need a text description, known as [alt text](https://insideuxdesign.com/en/glossar/alt-text). A [screen reader](https://insideuxdesign.com/en/glossar/screen-reader), a program that reads screen content aloud, can then announce that text.
- **1.2 Time-based Media:** Videos need captions, and audio content needs a text version. Captions for prerecorded video are already required at Level A (criterion 1.2.2).
- **1.3 Adaptable:** The structure of a page must be recognizable to technology as well. A heading must be marked up as a heading, not just look big and bold.
- **1.4 Distinguishable:** Content must stand out clearly from its background. This is where you’ll find minimum contrast, the rule that color must not be the only way to convey information, and requirements for resizing text.

### An everyday example

For example: a travel portal shows its deals as images with the price baked in. For sighted users, everything is clear. A screen reader, however, only announces “image” because there’s no alt text. The price, the most important piece of information, is missing entirely.

Before: `<img src="deal-mallorca.jpg">`
After: the price appears as real text next to the image, and the image gets short alt text such as “Hotel complex with a pool by the sea”.

A second classic is light gray text on a white background. It looks elegant but often misses the [contrast ratio](https://insideuxdesign.com/en/glossar/contrast-ratio) of 4.5:1 that criterion 1.4.3 requires for normal text. Large text needs 3:1.

## Principle 2: Operable

The second principle states that user interface components and navigation must be operable. In other words, people must be able to control a website through very different input methods: a mouse, a finger, a keyboard only, voice control or special switches.

This principle has five guidelines:

- **2.1 Keyboard Accessible:** All functionality must be available without a mouse. Find out more in the glossary under [keyboard accessibility](https://insideuxdesign.com/en/glossar/keyboard-accessibility).
- **2.2 Enough Time:** People need enough time to read and act. If there’s a time limit, it generally has to be possible to turn it off, adjust it or extend it.
- **2.3 Seizures and Physical Reactions:** Nothing may flash more than three times per second unless the flashing stays below certain thresholds. Rapid flashing can trigger seizures in some people.
- **2.4 Navigable:** People need to be able to find their way. That includes descriptive page titles, a logical order when tabbing through the page and a visible focus, meaning a marker that shows which element is currently active.
- **2.5 Input Modalities:** Touch and other input methods must work well. For example, targets should be at least 24 by 24 CSS pixels or have enough spacing around them (criterion 2.5.8, new in WCAG 2.2).

### An everyday example

For example: on a sports club’s website, clicking “Newsletter” opens a pop-up. Mouse users simply click the small X. Keyboard users tab through the dialog but can’t get out, because the X isn’t a real button and the Escape key does nothing. That’s a keyboard trap, and criterion 2.1.2 explicitly rules it out, already at Level A.

The fix is manageable: the X becomes a `<button>`, the Escape key closes the dialog, and focus then returns to the link that opened the pop-up.

How to check your own website for problems like this is covered in the article [Accessibility Testing: Tools and Methods for UX Designers](https://insideuxdesign.com/en/blog/accessibility-testing-tools-and-methods-for-ux-designers).

## Principle 3: Understandable

The third principle requires that information and the operation of the interface are understandable. It’s not enough for someone to perceive a text and reach a button. They also need to understand what it says and what will happen when they click.

Three guidelines belong here:

- **3.1 Readable:** The language of the page must be specified in the code (criterion 3.1.1). Only then will a screen reader pronounce an English text with English pronunciation rather than, say, German.
- **3.2 Predictable:** Websites should behave as expected. When an element merely receives focus, the whole page must not suddenly change (criterion 3.2.1). Navigation should be consistent across pages.
- **3.3 Input Assistance:** Forms need clear labels and helpful error messages. New in WCAG 2.2, for instance, is that people shouldn’t have to enter the same information twice in one process (criterion 3.3.7), and that logging in must not rely solely on remembering or transcribing something (criterion 3.3.8).

### An everyday example

For example: an appointment booking form only says “Invalid input” after submission and turns one field red. Which field is meant and what went wrong remains unclear. People with color vision deficiency may not notice the red marker at all, and a screen reader announces nothing useful.

Before: “Invalid input.”
After: “Phone number: please enter digits only, for example 02071234567.” The message appears right next to the field and is programmatically linked to it.

That covers two criteria at once: 3.3.1 requires that an error is identified and described in text, and 3.3.2 requires labels or instructions for input. How to design forms well from the ground up is covered in the article [Forms Nobody Abandons](https://insideuxdesign.com/en/blog/forms-nobody-abandons-12-rules-for-better-form-ux).

## Principle 4: Robust

The fourth principle is the most technical: content must be robust enough to be interpreted reliably by a wide range of browsers and assistive technologies, including future ones. For designers, that sounds like pure development work at first, but it also affects how components are designed.

This principle has only one guideline, **4.1 Compatible**, with two criteria:

- **4.1.2 Name, Role, Value:** Every interactive element must tell assistive technology what it’s called (name), what it is (role, such as button or checkbox) and what state it’s in (value, such as “selected”).
- **4.1.3 Status Messages:** Messages such as “Item added to cart” must also reach people using a screen reader, without moving the focus.

### An everyday example

For example: a team builds a custom toggle for “Dark mode on/off”. Visually it’s perfect, but technically it’s just a styled `<div>`. A screen reader can’t tell that it’s interactive or whether it’s currently on or off.

The robust solution uses a native element, such as a checkbox or a button with the right state, and styles it however you like. If you build custom components, [ARIA](https://insideuxdesign.com/en/glossar/aria) can help: a set of HTML attributes that describe roles and states. The rule of thumb, though: native HTML first, ARIA only where HTML falls short.

## How to read a single success criterion

Now you know the map. That leaves the question of how to work with a single criterion when someone says, “Can you check 2.4.7?” A proven approach in three steps:

### 1. Read the criterion text carefully

The actual text is usually just one to three sentences long. For 2.4.7 Focus Visible, it says in essence: any keyboard operable interface has a mode in which the keyboard focus indicator is visible. Look out for exceptions, which are often listed below, and for terms defined in the document’s glossary. They’re linked in the original.

### 2. Open the “Understanding” document

For every criterion, the W3C provides an explanation titled “Understanding Success Criterion …”. It describes who benefits from the criterion and why it exists, and it includes examples. For beginners, this is the most valuable part, because it translates the terse standard into everyday language.

### 3. Look at techniques and failures

At the end of each Understanding document, you’ll find “Sufficient Techniques” (ways to meet the criterion) and “Failures” (common mistakes). For 2.4.7, one documented failure is removing the focus outline with CSS without providing a replacement. That gives you concrete starting points for your design and your code.

If the full document feels like too much, the W3C’s filterable quick reference helps. You’ll find it in our resources under [WCAG 2.2 Quick Reference](https://insideuxdesign.com/en/ressourcen/wcag-22-quick-reference). There you can, for example, show only Level A and AA criteria or filter by topics such as forms.

## Common misconceptions at the start

**“Accessible means high contrast and large text.”** Contrast is just one criterion out of 86. Most requirements concern structure, operation and understandability. Why that is, is explained in the article [Why Accessibility Is More Than Contrast and Font Size](https://insideuxdesign.com/en/blog/why-accessibility-is-more-than-contrast-and-font-size).

**“An automated test tells me whether I’m WCAG compliant.”** Testing tools quickly find many technical issues, such as missing alt text or insufficient contrast. But whether alt text makes sense or an error message is understandable can only be judged by a person. A complete check always combines tools with manual testing.

**“WCAG are a developer thing.”** Many criteria are decided in design: contrast, focus styles, target sizes, error messages, labels and reading order. Thinking about them during design saves costly fixes later.

**“Level AAA is the real goal.”** For most websites, AA is the realistic and legally relevant target. You can add AAA criteria selectively where they make a real difference for your audience.

## Getting started in practice

You don’t need to understand all 86 criteria at once. A sensible path for your first few weeks looks like this:

Start with the four principles and ask yourself with every design: is this perceivable, operable, understandable and robust? These four questions alone catch many problems before they happen.

Then pick a handful of criteria that come up in almost every project: text alternatives (1.1.1), contrast (1.4.3), keyboard (2.1.1), no keyboard trap (2.1.2), focus visible (2.4.7), labels or instructions (3.3.2) and error identification (3.3.1). Read the Understanding document for each one and check a page of your project against it.

After that, work your way through guideline by guideline. With every criterion you’ve understood, the document feels less foreign, and the numbers become a shared language with your team.

## Conclusion

At first glance, the WCAG look like an impenetrable rulebook. In fact, they follow a clear logic: four principles, 13 guidelines, 86 testable success criteria and three levels, of which AA is the usual target. Once you know this structure, you can place any number and look it up with purpose.

The four principles are more than a table of contents. They’re a thinking tool for every design: can someone perceive it, operate it, understand it, and does it work with different technologies? If you ask these questions early, accessibility becomes a natural part of your work rather than a test at the end.

## Checklist

- You use WCAG 2.2 Level AA as your reference.
- You know the four principles: perceivable, operable, understandable, robust.
- You can read a criterion number: principle, guideline, criterion.
- You check full pages and complete processes, not just individual elements.
- You read the matching Understanding document for each criterion.
- You combine automated tools with manual testing.
- You consider contrast, focus, target size, labels and error messages during design.

## Sources

- [W3C: Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 12 December 2024](https://www.w3.org/TR/WCAG22/)
- [W3C Web Accessibility Initiative: What’s New in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- [W3C Web Accessibility Initiative: WCAG 2.2 Approved as an ISO Standard, 21 October 2025](https://www.w3.org/WAI/news/2025-10-21/wcag22-iso)
- [W3C Web Accessibility Initiative: WCAG 3 Introduction](https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/)
- [W3C: Understanding WCAG 2.2](https://www.w3.org/WAI/WCAG22/Understanding/)
- [W3C: How to Meet WCAG 2.2 (Quick Reference)](https://www.w3.org/WAI/WCAG22/quickref/)