WCAG explained: principles, levels and what’s new

Spend any time around digital accessibility and you’ll soon run into four letters: WCAG. The Web Content Accessibility Guidelines are the international benchmark for when web content counts as accessible. Laws reference them, audit methods are built on them, and procurement requirements quote them.

Open the actual specification for the first time, though, and it can feel dense: nested numbers, precise technical wording, exceptions within exceptions. The underlying idea is surprisingly clear. Once you understand how the system fits together, you’ll find your way around quickly and be able to use the requirements in your day-to-day work.

This article gives you the big picture: how WCAG is structured, what the four principles are about, what levels A, AA and AAA mean, what’s new in WCAG 2.2 and what to expect from WCAG 3.

What WCAG is and where it comes from

WCAG is developed by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) – the same organization behind the HTML and CSS standards. The first version appeared in 1999. WCAG 2.0 followed in 2008 and laid the foundation everything still builds on today. WCAG 2.1 arrived in 2018, adding requirements focused on mobile use, low vision and cognitive disabilities. The current version, WCAG 2.2, became an official W3C Recommendation on October 5, 2023.

Two qualities make WCAG so influential. First, it’s technology-agnostic: it doesn’t tell you which framework or language to use, it describes outcomes you need to achieve. Second, its success criteria are testable. For each requirement, you can determine whether a page meets it or not. That’s exactly why lawmakers and standards bodies can build on it.

This matters a lot in Europe. The harmonized standard EN 301 549 points to WCAG 2.1 Level AA for web content. Both the EU Web Accessibility Directive for the public sector and the European Accessibility Act (EAA), which has applied to many consumer-facing products and services since June 28, 2025, rely on that standard. Outside the EU, many national laws and policies reference WCAG as well. For the bigger picture, read What digital accessibility means.

The structure: from principle to success criterion

Think of WCAG as a tree with three levels:

• Four principles sit at the top: perceivable, operable, understandable and robust.
• 13 guidelines sit underneath and describe goals such as “Keyboard Accessible” or “Input Assistance”. They aren’t testable themselves, but they set the direction.
• 86 success criteria form the concrete, testable layer. Each one is assigned a conformance level: A, AA or AAA.

The numbering mirrors this structure. Take 1.4.3 Contrast (Minimum): the 1 stands for the first principle (perceivable), the 4 for the fourth guideline under it (distinguishable) and the 3 for the third success criterion within that guideline. Once you know the number, you instantly know which area you’re in.

Alongside the standard itself, the W3C publishes two essential companion resources. “Understanding WCAG” explains the intent behind each criterion, who it helps and how it’s meant to be read. “Techniques” shows concrete ways to meet the criteria and documents common failures. Neither is normative, but in practice you can’t do without them when you need to know how a criterion is interpreted. Our WCAG guide walks through every criterion in plain language.

The four principles (POUR)

The principles are easy to remember with the acronym POUR: Perceivable, Operable, Understandable, Robust. Each one answers a simple question.

1. Perceivable: can everyone perceive the content?

Information can’t depend on a single sense. An image needs a text alternative, a video needs captions, a chart needs a description. Text has to be resizable, colors need enough contrast, and structure such as headings and lists must be expressed in the code, not just visually. The textbook example is 1.1.1 Non-text Content: for a blind user, a product photo without alt text simply doesn’t exist.

The guidelines under this principle are Text Alternatives (1.1), Time-based Media (1.2), Adaptable (1.3) and Distinguishable (1.4).

2. Operable: can everyone use the interface?

Not everyone uses a mouse or a touchscreen. Some people navigate with a keyboard only, with voice commands or with a single switch. That’s why 2.1.1 Keyboard requires every function to be available from a keyboard. Other topics include giving people enough time, preventing content that flashes dangerously, helping people navigate and find their way, and supporting input methods beyond the keyboard, such as gestures and pointers.

The guidelines: Keyboard Accessible (2.1), Enough Time (2.2), Seizures and Physical Reactions (2.3), Navigable (2.4) and Input Modalities (2.5).

3. Understandable: can everyone understand the content and how it works?

A page can be perfectly perceivable and operable and still fail if nobody understands what to do. This principle covers readable text, correct language markup, predictable behavior and help with input. A typical example is 3.3.2 Labels or Instructions: form fields need labels that make it clear what to enter – before anyone makes a mistake.

The guidelines: Readable (3.1), Predictable (3.2) and Input Assistance (3.3).

4. Robust: does it work across technologies?

Content has to be interpreted reliably by browsers and assistive technologies such as screen readers – now and in the future. The core criterion here is 4.1.2 Name, Role, Value: every control has to expose what it’s called, what it is and what state it’s in. A custom dropdown built from div elements doesn’t do that without extra work. A native button element with the right attributes does.

There’s only one guideline under this principle: Compatible (4.1).

Levels A, AA and AAA

Every success criterion belongs to one of three conformance levels. The levels are cumulative: to reach AA, you need to meet all Level A and Level AA criteria.

• Level A covers the essentials. When these fail, content is often completely unusable for some people – for example, when a button can’t be reached with the keyboard at all.
• Level AA adds further important requirements such as sufficient contrast and visible focus. AA is the level laws and standards typically reference, including EN 301 549.
• Level AAA is the highest level, with requirements like enhanced 7:1 contrast or sign language interpretation for video. The W3C explicitly doesn’t recommend AAA as a general requirement for entire sites, because not every criterion can be met for every kind of content.

In practice, aim for Level AA and adopt individual AAA criteria where they make sense for your audience and are feasible. A government service used by many older people, for example, benefits a lot from plain language or larger targets, even if it isn’t required to provide them.

It also matters what conformance applies to. WCAG requires you to evaluate full pages, and for multi-step processes, every step. An accessible shopping cart doesn’t help much if the payment page that follows can’t be used.

How to read a success criterion

Success criteria are short but precise. It pays to look at three things: the requirement itself, the exceptions and the defined terms. Let’s use 1.4.3 Contrast (Minimum) again.

The requirement says that text and images of text need a contrast ratio of at least 4.5:1. Then come the exceptions: large text only needs 3:1. Text that is pure decoration, text in inactive controls and text in logos are exempt. What exactly counts as “large text” is spelled out in the WCAG glossary. If you only read the first line, you might apply the criterion too strictly or too loosely.

Here’s a realistic scenario: your team is debating whether a grayed-out “Submit” button has to meet the contrast requirement. The exceptions show that inactive controls are exempt. At the same time, the Understanding document makes clear that users still need to know why the button is disabled. So the answer isn’t just “it’s allowed”. It’s “it’s allowed, but tell people what’s missing”.

What’s new in WCAG 2.2?

WCAG 2.2 adds nine new success criteria. Many of them improve things for people with motor or cognitive disabilities and for keyboard users.

• Focus not obscured: 2.4.11 Focus Not Obscured (Minimum) (AA) requires that a focused element isn’t entirely hidden by other content, such as a sticky header or a cookie banner. 2.4.12 (AAA) goes further: no part of it may be hidden.
• Focus appearance: 2.4.13 (AAA) sets minimum requirements for the size and contrast of the focus indicator.
• Dragging movements: 2.5.7 (AA) requires that anything you can do by dragging can also be done with simple clicks or taps, unless dragging is essential.
• Target size: 2.5.8 Target Size (Minimum) (AA) asks for targets of at least 24 by 24 CSS pixels or enough spacing from neighboring targets, with some exceptions – links within running text, for example.
• Consistent help: 3.2.6 (A) requires help options such as contact details or a chat to appear in the same relative place across pages.
• Redundant entry: 3.3.7 (A) means information someone has already entered in the same process doesn’t have to be typed again; it’s either filled in automatically or available to select.
• Accessible authentication: 3.3.8 Accessible Authentication (Minimum) (AA) rules out login steps that depend on a cognitive function test, like remembering a password or solving a puzzle, unless there’s an alternative or a mechanism that helps. Blocking paste from a password manager, for instance, fails this criterion. 3.3.9 (AAA) is the stricter version.

One criterion was removed at the same time: 4.1.1 Parsing is now obsolete. Modern browsers and assistive technologies handle invalid HTML so robustly that the criterion no longer served its original purpose. The real problems it was meant to catch are covered by other criteria such as 4.1.2.

WCAG 2.2 is backward compatible: content that meets 2.2 generally meets 2.1 and 2.0 as well. In Europe, the legal baseline via EN 301 549 is currently WCAG 2.1 AA. It’s still worth working toward 2.2 today. The new criteria solve real everyday problems, and standards are typically updated to follow new versions. This is general information, not legal advice.

Looking ahead: WCAG 3

In parallel, the W3C is working on a fundamentally new generation called the W3C Accessibility Guidelines 3.0 – also abbreviated WCAG 3. As of October 2026, WCAG 3 is still a working draft, not a finished Recommendation. Its content and structure may change significantly before it’s complete.

The drafts so far point in a few directions: a broader scope beyond traditional web content, more attention to cognitive accessibility and a scoring model that’s less of a strict pass-or-fail. How it all ends up is still open.

The takeaway: don’t wait for WCAG 3. WCAG 2.x will remain the legally relevant benchmark for the foreseeable future, and nothing you implement against WCAG 2.2 today is wasted effort. The core ideas – text alternatives, keyboard access, understandable content, robust code – stay the same.

Using WCAG in your daily work

Nobody needs to memorize all 86 success criteria. It’s far more useful to sort them by role. Designers focus on contrast, focus styles, target sizes, color as a carrier of information and consistent navigation. Developers take care of semantics, keyboard support, name, role and value, and status messages. Content teams own alt text, heading structure, link text, captions and plain language.

Be realistic about testing, too. Automated tools reliably check only some of the criteria. Whether alt text is meaningful or a focus order makes sense is something only a human can judge. Our article on accessibility testing explains how to combine methods effectively.

Checklist: WCAG at a glance

• You know the four principles: perceivable, operable, understandable, robust.
• Your target is Level AA, plus AAA criteria where they make sense.
• You work toward WCAG 2.2, even if the legal baseline is currently 2.1 AA.
• When in doubt, you check the exceptions, definitions and the Understanding document.
• You evaluate full pages and complete processes, not isolated components.
• You’ve split responsibility for the criteria across roles in your team.
• You combine automated and manual testing.

Conclusion

WCAG looks complicated at first, but it follows a clear logic: four principles, guidelines beneath them and testable success criteria at three levels beneath those. Once you understand that structure, you can place any requirement in context and look it up when you need it.

In practice: aim for Level AA, use WCAG 2.2 as your reference and treat WCAG 3 as an interesting outlook rather than a reason to wait. Start with the criteria that matter most for your role and build from there.

Sources

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (opens in a new tab)
• W3C WAI: WCAG 2 Overview (opens in a new tab)
• W3C WAI: What’s New in WCAG 2.2 (opens in a new tab)
• W3C WAI: Understanding WCAG 2.2 (opens in a new tab)
• W3C WAI: WCAG 3 Introduction (opens in a new tab)
• EUR-Lex: Directive (EU) 2019/882 (European Accessibility Act) (opens in a new tab)