WCAG 2.2 explained in plain terms

WCAG is the global benchmark for accessible websites – and the foundation of what the EAA and Germany's BFSG require. Here is how the standard is structured and what is new in version 2.2.

What is WCAG – and who publishes it?

The Web Content Accessibility Guidelines (WCAG) are the internationally recognised standard for accessible web content. They are published by the World Wide Web Consortium (W3C), specifically by its Web Accessibility Initiative (WAI) – the same organisation that standardises HTML and CSS. The current version, WCAG 2.2, was released in October 2023 and builds on WCAG 2.1: everything that applied before still applies, with new requirements added on top (and one removed – more on that below).

An important point: WCAG itself is not a law but a technical guideline. Its legal weight comes from the fact that laws around the world reference it – in Europe via the standard EN 301 549, which underpins the requirements of the European Accessibility Act (EAA) and Germany's Accessibility Strengthening Act (BFSG).

The four principles: POUR

Every WCAG requirement hangs off four principles, abbreviated as POUR: Perceivable, Operable, Understandable, Robust. Once you understand these four ideas, you understand the logic of the entire standard.

1. Perceivable

All content must be accessible to all senses – with an alternative route if needed. Examples:

• Images need alt text so screen readers can describe them (see our article on how to write good alt text).
• Videos need captions for people who cannot hear, or cannot hear well.
• Text needs sufficient contrast against its background – light grey on white is simply unreadable for many people.

2. Operable

Every function must work without a mouse and must not put anyone under time pressure. Examples:

• The entire website can be used with a keyboard – Tab, Enter and arrow keys.
• The currently focused element is visibly highlighted, so you always know where you are.
• Buttons and links are large enough to hit with trembling hands or on a smartphone.

3. Understandable

Content and controls must be easy to follow. Examples:

• Forms explain errors specifically: "Please enter your date of birth as DD/MM/YYYY" instead of "Invalid input".
• Navigation works the same way on every page and elements behave predictably.
• Copy is written clearly – jargon is explained or avoided.

4. Robust

Content must work with as many browsers and assistive technologies as possible. Examples:

• Clean, semantic HTML: a button is a button, not a clickable div.
• Status messages (such as "Product added to cart") are marked up so screen readers announce them too.

Conformance levels: A, AA and AAA

Each WCAG success criterion is assigned to one of three levels:

• A – the absolute minimum. Failing it makes content completely inaccessible to some groups.
• AA – the established standard. This is the level required by virtually every law worldwide, including the EAA and the BFSG via EN 301 549.
• AAA – the highest level, for example sign-language videos for all audio content. As an overall target for entire websites it is usually unrealistic, and it is not legally required.

New in WCAG 2.2: nine success criteria

WCAG 2.2 adds nine new success criteria. They primarily target people with motor impairments, people with cognitive disabilities, and mobile use:

At the same time, one old criterion was removed: 4.1.1 Parsing (error-free syntax) no longer exists in WCAG 2.2, because modern browsers and assistive technologies have become tolerant enough that the criterion no longer served any purpose of its own.

WCAG, EN 301 549 and the EAA/BFSG: how do they connect?

The chain is simpler than it sounds: the EAA is the EU directive, the BFSG is its German implementation. Both require accessibility according to the harmonised European standard EN 301 549 – and for web content, that standard essentially adopts WCAG at level AA. EN 301 549 currently still references WCAG 2.1; the update to 2.2 is under way. If you aim directly for WCAG 2.2 AA today, you are on the safe side: it covers all 2.1 requirements plus the ones to come.

To find out who is affected by the EAA and BFSG, which deadlines apply and what fines are possible, read our article The European Accessibility Act: who must comply, and by when?

Common misconceptions

• "An overlay widget makes my site compliant." No. Assistive features such as contrast switchers or read-aloud functions are a useful addition, but they cannot fix fundamental problems in the code – missing alt text, broken keyboard operation, unlabelled forms. Accessibility is built into the foundation, not added as a layer on top.
• "Accessibility only concerns blind people." WCAG also covers motor, auditory and cognitive impairments – and helps everyone along the way: better contrast in sunlight, larger buttons on a smartphone, clearer forms for all.
• "An automated test is enough." In practice, automated tools only find a portion of the problems. Whether an alt text makes sense or a keyboard trap exists only becomes clear through manual testing.

How to start pragmatically

You do not have to tackle every criterion at once. A realistic way in:

1. Take stock: check your most important pages and processes (home page, contact, checkout) with an automated tool and with the keyboard. You will find a step-by-step guide in how to test your website for accessibility.
2. Quick wins first: contrast, alt text, form labels and a visible focus can often be fixed with little effort – and cover many AA criteria.
3. Plan for the new 2.2 criteria: review target sizes, drag-and-drop alternatives and your login process.
4. Keep at it: anchor accessibility in your editorial and development processes so new content does not create new barriers.