WCAG einfach erklärt: Die vier Prinzipien im Überblick

Stell dir vor, du bekommst im Team eine neue Aufgabe: „Bitte prüf mal, ob unser Kontaktformular WCAG-konform ist.“ Du öffnest die offizielle Richtlinie des W3C und landest in einem langen englischen Dokument voller Nummern wie 1.4.3, 2.4.7 oder 3.3.2. Dazu Begriffe wie „Erfolgskriterium“, „Konformitätsstufe AA“ und „programmatisch ermittelbar“. Nach zehn Minuten weißt du vor allem eins: Hier braucht es erst einmal einen Überblick.

Genau diesen Überblick bekommst du in diesem Artikel. Du erfährst, was die WCAG sind, wie sie aufgebaut sind, was hinter den vier Prinzipien steckt und wie du ein einzelnes Kriterium liest, ohne dich zu verlaufen. Vorwissen brauchst du keins. Wenn du danach wissen willst, warum Barrierefreiheit weit über Kontrast hinausgeht oder was das Gesetz verlangt, findest du am Ende Wege zum Weiterlesen.

Was die WCAG überhaupt sind

WCAG steht für Web Content Accessibility Guidelines, auf Deutsch etwa „Richtlinien für barrierefreie Webinhalte“. Herausgeber ist das World Wide Web Consortium, kurz W3C. Das ist das Gremium, das auch Standards wie HTML und CSS pflegt. Eine kurze Definition findest du auch im Glossar unter WCAG.

Barrierefreiheit bedeutet im Web: Menschen können eine Website nutzen, egal ob sie blind sind, schlecht hören, nur die Tastatur bedienen können oder Schwierigkeiten haben, komplizierte Texte zu verstehen. Die WCAG übersetzen dieses Ziel in konkrete, überprüfbare Anforderungen. Statt „mach es irgendwie zugänglich“ steht dort zum Beispiel: Normaler Text braucht ein Kontrastverhältnis von mindestens 4,5:1 zu seinem Hintergrund.

Wichtig für den Einstieg: Die WCAG schreiben dir nicht vor, wie deine Website aussehen soll. Sie legen fest, welches Ergebnis erreicht werden muss. Wie du dorthin kommst, bleibt deine Entscheidung. Deshalb funktionieren sie für einen kleinen Blog genauso wie für einen großen Onlineshop.

Welche Version gerade aktuell ist

Die WCAG gibt es in mehreren Versionen. WCAG 2.0 erschien 2008, WCAG 2.1 im Jahr 2018. Die aktuelle Version ist WCAG 2.2. Sie wurde im Oktober 2023 veröffentlicht, die heute gültige Fassung stammt vom 12. Dezember 2024. Im Oktober 2025 hat das W3C bekanntgegeben, dass WCAG 2.2 auch als internationale Norm ISO/IEC 40500:2025 anerkannt ist.

Die Versionen bauen aufeinander auf. Das W3C formuliert es so: Inhalte, die WCAG 2.2 erfüllen, erfüllen auch WCAG 2.0 und 2.1. Neue Versionen ergänzen also vor allem Kriterien. Gestrichen wurde in WCAG 2.2 nur ein einziges Kriterium (4.1.1 Parsing), weil es technisch überholt ist. Für dich heißt das: Wenn du heute anfängst, orientierst du dich direkt an WCAG 2.2.

Vielleicht stößt du auch auf WCAG 3. Das ist ein Nachfolger, an dem das W3C arbeitet. Er ist laut W3C noch ein unvollständiger Entwurf und wird erst in einigen Jahren fertig. Das W3C empfiehlt ausdrücklich, bis dahin WCAG 2.2 zu nutzen. Du musst also nicht warten.

Der Aufbau: vom Prinzip bis zum Kriterium

Das Dokument wirkt anfangs unübersichtlich, folgt aber einer klaren Hierarchie mit vier Ebenen. Wer diese Ebenen kennt, findet sich schnell zurecht.

1. Prinzipien: Ganz oben stehen vier Grundsätze. Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein.
2. Richtlinien: Unter den Prinzipien stehen insgesamt 13 Richtlinien. Sie beschreiben Ziele, zum Beispiel „Alles muss per Tastatur nutzbar sein“. Richtlinien selbst sind nicht prüfbar, sie geben die Richtung vor.
3. Erfolgskriterien: Unter jeder Richtlinie stehen die eigentlichen Prüfpunkte. Ein Erfolgskriterium (englisch Success Criterion) ist eine Aussage, die entweder zutrifft oder nicht. WCAG 2.2 enthält 86 davon.
4. Techniken und Erläuterungen: Zu jedem Kriterium gibt es ergänzende Dokumente, die erklären, warum es existiert und wie du es umsetzen kannst. Sie sind hilfreich, aber selbst keine Pflicht.

Die Nummern verraten dir die Position in dieser Hierarchie. Nimm das Kriterium 1.4.3: Die erste Ziffer steht für das Prinzip (1 = wahrnehmbar), die zweite für die Richtlinie (1.4 = unterscheidbar), die dritte für das Kriterium selbst (1.4.3 = Kontrast, Minimum). Wenn dir jemand „2.1.1“ zuruft, weißt du also sofort: Prinzip bedienbar, Richtlinie Tastatur, erstes Kriterium.

Die drei Stufen: A, AA und AAA

Jedes Erfolgskriterium ist einer von drei Konformitätsstufen zugeordnet. Konformität bedeutet einfach: Die Website erfüllt die Anforderungen einer Stufe.

• Stufe A ist das Minimum. Hier stehen Dinge, ohne die bestimmte Menschen eine Website gar nicht nutzen können, etwa eine Tastaturfalle, aus der man nicht mehr herauskommt. WCAG 2.2 enthält 31 Kriterien der Stufe A.
• Stufe AA ist der übliche Zielstandard. Wer AA erreichen will, muss alle Kriterien der Stufen A und AA erfüllen. Dazu kommen 24 weitere Kriterien, etwa der Mindestkontrast oder ein sichtbarer Tastaturfokus.
• Stufe AAA ist die höchste Stufe mit nochmals 31 Kriterien. Sie ist für ganze Websites oft nicht vollständig erreichbar, und das W3C empfiehlt sie nicht als allgemeines Ziel. Einzelne AAA-Kriterien lassen sich aber gut zusätzlich umsetzen.

In der Praxis bedeutet „WCAG-konform“ fast immer: WCAG 2.1 oder 2.2 auf Stufe AA. Auch Gesetze in Europa beziehen sich auf diese Stufe. Was das in Deutschland konkret heißt, erklärt der Artikel BFSG in der Praxis.

Noch ein Detail, das Einsteigende oft übersehen: Konformität gilt immer für ganze Seiten und vollständige Abläufe. Ein Checkout ist nur dann konform, wenn jeder Schritt vom Warenkorb bis zur Bestätigung die Anforderungen erfüllt. Ein barrierefreier erster Schritt hilft wenig, wenn der dritte mit der Tastatur nicht erreichbar ist.

Prinzip 1: Wahrnehmbar

Das W3C formuliert das erste Prinzip so: Informationen und Bedienelemente müssen so dargestellt werden, dass Menschen sie wahrnehmen können. Die Kernidee dahinter: Kein Inhalt darf nur über einen einzigen Sinn erreichbar sein. Was man sieht, muss sich auch hören oder ertasten lassen, und was man hört, muss sich auch lesen lassen.

Unter diesem Prinzip stehen vier Richtlinien:

• 1.1 Textalternativen: Bilder, Icons und Grafiken brauchen eine Beschreibung in Textform, einen sogenannten Alternativtext. Ein Screenreader, also ein Programm, das Bildschirminhalte vorliest, kann diesen Text ausgeben.
• 1.2 Zeitbasierte Medien: Videos brauchen Untertitel, Audio-Inhalte eine Textfassung. Untertitel für aufgezeichnete Videos gehören schon zur Stufe A (Kriterium 1.2.2).
• 1.3 Anpassbar: Die Struktur einer Seite muss auch für Technik erkennbar sein. Eine Überschrift muss technisch als Überschrift ausgezeichnet sein, nicht nur fett und groß aussehen.
• 1.4 Unterscheidbar: Inhalte müssen sich gut vom Hintergrund abheben. Hier stehen der Mindestkontrast, die Regel, dass Farbe nicht das einzige Unterscheidungsmerkmal sein darf, und Vorgaben zum Vergrößern von Text.

Ein Beispiel aus dem Alltag

Ein Beispiel: Ein Online-Reiseportal zeigt Angebote als Bild mit eingebranntem Preis. Für sehende Menschen ist alles klar. Ein Screenreader liest aber nur „Bild“ vor, weil kein Alternativtext hinterlegt ist. Der Preis, die wichtigste Information, fehlt komplett.

Vorher: <img src="angebot-mallorca.jpg">
Nachher: Der Preis steht als echter Text neben dem Bild, und das Bild bekommt einen kurzen Alternativtext wie „Hotelanlage mit Pool am Meer“.

Ein zweiter Klassiker ist hellgraue Schrift auf weißem Grund. Sie sieht elegant aus, verfehlt aber oft das Kontrastverhältnis von 4,5:1, das Kriterium 1.4.3 für normalen Text verlangt. Für großen Text reichen 3:1.

Prinzip 2: Bedienbar

Das zweite Prinzip besagt: Bedienelemente und Navigation müssen bedienbar sein. Gemeint ist, dass Menschen eine Website mit ganz unterschiedlichen Eingabewegen steuern können: mit der Maus, mit dem Finger, nur mit der Tastatur, per Sprachsteuerung oder mit speziellen Schaltern.

Dieses Prinzip hat fünf Richtlinien:

• 2.1 Per Tastatur zugänglich: Alle Funktionen müssen ohne Maus erreichbar sein. Mehr dazu im Glossar unter Tastaturbedienung.
• 2.2 Ausreichend Zeit: Menschen brauchen genug Zeit zum Lesen und Handeln. Gibt es ein Zeitlimit, muss es sich in der Regel abschalten, anpassen oder verlängern lassen.
• 2.3 Anfälle und körperliche Reaktionen: Nichts darf mehr als dreimal pro Sekunde aufblitzen, außer das Blitzen bleibt unter bestimmten Grenzwerten. Schnelles Flackern kann bei manchen Menschen epileptische Anfälle auslösen.
• 2.4 Navigierbar: Menschen müssen sich orientieren können. Dazu gehören aussagekräftige Seitentitel, eine logische Reihenfolge beim Durchspringen mit der Tab-Taste und ein sichtbarer Fokus, also eine Markierung, welches Element gerade aktiv ist.
• 2.5 Eingabemodalitäten: Bedienung über Touch und andere Eingaben muss gut funktionieren. Hier steht zum Beispiel, dass Klickziele mindestens 24 mal 24 CSS-Pixel groß sein sollen oder genug Abstand haben müssen (Kriterium 2.5.8, neu in WCAG 2.2).

Ein Beispiel aus dem Alltag

Ein Beispiel: Auf einer Vereinswebsite öffnet sich beim Klick auf „Newsletter“ ein Pop-up. Wer mit der Maus arbeitet, klickt einfach auf das kleine X. Wer nur die Tastatur nutzt, springt mit der Tab-Taste durch das Fenster, findet aber keinen Weg hinaus, weil das X kein echter Button ist und die Escape-Taste nichts bewirkt. Das ist eine sogenannte Tastaturfalle, und Kriterium 2.1.2 verbietet sie ausdrücklich, schon auf Stufe A.

Die Lösung ist überschaubar: Das X wird als <button> umgesetzt, die Escape-Taste schließt das Fenster, und danach springt der Fokus zurück zu dem Link, der das Pop-up geöffnet hat.

Wie du deine eigene Website auf solche Probleme prüfst, zeigt der Artikel Accessibility-Prüfung: Werkzeuge und Methoden für UX-Designer.

Prinzip 3: Verständlich

Das dritte Prinzip verlangt, dass Informationen und die Bedienung der Oberfläche verständlich sind. Es reicht nicht, dass jemand einen Text wahrnehmen und einen Button erreichen kann. Die Person muss auch verstehen, was dort steht und was passiert, wenn sie klickt.

Drei Richtlinien gehören dazu:

• 3.1 Lesbar: Die Sprache der Seite muss technisch angegeben sein (Kriterium 3.1.1). Nur dann spricht ein Screenreader einen deutschen Text mit deutscher Aussprache aus und nicht mit englischer.
• 3.2 Vorhersehbar: Websites sollen sich erwartbar verhalten. Wenn ein Element nur den Fokus bekommt, darf sich nicht plötzlich die ganze Seite ändern (Kriterium 3.2.1). Navigation soll auf allen Seiten gleich aufgebaut sein.
• 3.3 Hilfestellung bei der Eingabe: Formulare brauchen klare Beschriftungen und hilfreiche Fehlermeldungen. Neu in WCAG 2.2 ist zum Beispiel, dass Menschen dieselben Angaben in einem Ablauf nicht mehrfach eintippen müssen (Kriterium 3.3.7) und dass ein Login nicht allein darauf beruhen darf, sich etwas zu merken oder abzutippen (Kriterium 3.3.8).

Ein Beispiel aus dem Alltag

Ein Beispiel: Ein Formular zur Terminbuchung meldet nach dem Absenden nur „Ungültige Eingabe“ und färbt ein Feld rot. Welches Feld gemeint ist und was falsch war, bleibt offen. Menschen mit Farbsehschwäche sehen die rote Markierung womöglich gar nicht, und ein Screenreader liest nichts Hilfreiches vor.

Vorher: „Ungültige Eingabe.“
Nachher: „Telefonnummer: Bitte gib nur Ziffern ein, zum Beispiel 0301234567.“ Die Meldung steht direkt am Feld und ist technisch mit ihm verknüpft.

Damit sind gleich zwei Kriterien erfüllt: 3.3.1 verlangt, dass ein Fehler erkannt und in Textform beschrieben wird, und 3.3.2 verlangt Beschriftungen oder Anweisungen für Eingaben. Wie du Formulare von Grund auf gut gestaltest, zeigt der Artikel Formulare, die niemand abbricht.

Prinzip 4: Robust

Das vierte Prinzip ist das technischste: Inhalte müssen so robust sein, dass verschiedene Browser und Hilfsmittel sie zuverlässig verarbeiten können, auch künftige. Für Designerinnen und Designer klingt das zunächst nach reiner Entwicklungsarbeit, betrifft aber auch die Gestaltung von Komponenten.

Unter diesem Prinzip steht nur eine Richtlinie, 4.1 Kompatibel, mit zwei Kriterien:

• 4.1.2 Name, Rolle, Wert: Jedes Bedienelement muss Hilfsmitteln mitteilen, wie es heißt (Name), was es ist (Rolle, zum Beispiel Button oder Checkbox) und in welchem Zustand es sich befindet (Wert, zum Beispiel „ausgewählt“).
• 4.1.3 Statusmeldungen: Meldungen wie „Artikel in den Warenkorb gelegt“ müssen auch bei Menschen ankommen, die einen Screenreader nutzen, ohne dass sich der Fokus verschiebt.

Ein Beispiel aus dem Alltag

Ein Beispiel: Ein Team baut einen eigenen Umschalter für „Dunkler Modus an/aus“. Optisch ist er perfekt, technisch aber nur ein gestaltetes <div>. Ein Screenreader erkennt weder, dass man ihn bedienen kann, noch ob er gerade an oder aus ist.

Die robuste Lösung nutzt ein natives Element, etwa eine Checkbox oder einen Button mit passendem Zustand, und gestaltet es nach Belieben. Wer eigene Komponenten baut, kann mit ARIA nachhelfen, einer Sammlung von HTML-Attributen, die Rollen und Zustände beschreiben. Als Faustregel gilt aber: Natives HTML zuerst, ARIA nur dort, wo HTML nicht ausreicht.

So liest du ein einzelnes Erfolgskriterium

Jetzt kennst du die Landkarte. Bleibt die Frage, wie du mit einem einzelnen Kriterium arbeitest, wenn jemand sagt: „Prüf mal 2.4.7.“ Ein bewährtes Vorgehen in drei Schritten:

1. Den Kriteriumstext genau lesen

Der eigentliche Text ist meist nur ein bis drei Sätze lang. Bei 2.4.7 „Fokus sichtbar“ steht sinngemäß: Jede per Tastatur bedienbare Oberfläche hat einen Modus, in dem der Tastaturfokus sichtbar ist. Achte auf Ausnahmen, die oft in einer Liste darunter stehen, und auf Begriffe, die im Glossar des Dokuments definiert sind. Sie sind in der Originalfassung verlinkt.

2. Das „Understanding“-Dokument öffnen

Zu jedem Kriterium gibt es eine Erläuterung des W3C mit dem Titel „Understanding Success Criterion …“. Dort steht, welche Menschen von dem Kriterium profitieren, warum es existiert, und es gibt Beispiele. Für Einsteigende ist das der wertvollste Teil, weil er den knappen Normtext in Alltagssprache übersetzt.

3. Techniken und Fehlerbeispiele ansehen

Am Ende jedes Understanding-Dokuments findest du „Sufficient Techniques“ (Wege, die das Kriterium erfüllen) und „Failures“ (typische Fehler). Für 2.4.7 ist ein dokumentierter Fehler zum Beispiel, den Fokusrahmen per CSS zu entfernen, ohne einen Ersatz anzubieten. Damit hast du konkrete Ansatzpunkte für dein Design und deinen Code.

Wenn dir das Original zu umfangreich ist, hilft die gefilterte Kurzreferenz des W3C. Du findest sie in unseren Ressourcen unter WCAG 2.2 Quick Reference. Dort kannst du zum Beispiel nur die Kriterien der Stufen A und AA anzeigen lassen oder nach Themen wie „Formulare“ filtern.

Typische Missverständnisse am Anfang

„Barrierefrei heißt: hoher Kontrast und große Schrift.“ Kontrast ist nur ein Kriterium von 86. Die meisten Anforderungen betreffen Struktur, Bedienung und Verständlichkeit. Warum das so ist, erklärt der Artikel Warum Barrierefreiheit mehr als Kontrast und Größe ist.

„Ein automatischer Test zeigt mir, ob ich WCAG-konform bin.“ Prüftools finden viele technische Fehler schnell, etwa fehlende Alternativtexte oder zu geringen Kontrast. Ob ein Alternativtext aber sinnvoll ist oder eine Fehlermeldung verständlich, kann nur ein Mensch beurteilen. Ein vollständiger Check kombiniert immer Tools und manuelle Prüfung.

„WCAG sind etwas für die Entwicklung.“ Viele Kriterien entscheiden sich schon im Design: Kontraste, Fokusdarstellung, Größe von Klickzielen, Fehlermeldungen, Beschriftungen und Reihenfolge. Wer im Design daran denkt, spart später aufwendige Korrekturen.

„Stufe AAA ist das eigentliche Ziel.“ Für die meisten Websites ist AA das realistische und auch rechtlich relevante Ziel. AAA-Kriterien kannst du gezielt dort ergänzen, wo sie für deine Zielgruppe besonders viel bringen.

Dein Einstieg in der Praxis

Du musst nicht alle 86 Kriterien auf einmal verstehen. Ein sinnvoller Weg für die ersten Wochen sieht so aus:

Fang mit den vier Prinzipien an und frag dich bei jedem Entwurf: Ist das wahrnehmbar, bedienbar, verständlich und robust? Allein diese vier Fragen fangen viele Probleme ab, bevor sie entstehen.

Nimm dir danach eine Handvoll Kriterien vor, die in fast jedem Projekt vorkommen: Textalternativen (1.1.1), Kontrast (1.4.3), Tastaturbedienung (2.1.1), keine Tastaturfalle (2.1.2), sichtbarer Fokus (2.4.7), Beschriftungen (3.3.2) und Fehlererkennung (3.3.1). Lies zu jedem das Understanding-Dokument und prüf eine Seite deines Projekts damit.

Arbeite dich anschließend Richtlinie für Richtlinie weiter vor. Mit jedem Kriterium, das du einmal verstanden hast, wird das Dokument weniger fremd, und die Nummern werden zu einer gemeinsamen Sprache mit deinem Team.

Fazit

Die WCAG wirken auf den ersten Blick wie ein undurchdringliches Regelwerk. Tatsächlich folgen sie einer klaren Logik: vier Prinzipien, 13 Richtlinien, 86 prüfbare Erfolgskriterien und drei Stufen, von denen AA der übliche Zielstandard ist. Wer diese Struktur kennt, kann jede Nummer einordnen und gezielt nachlesen.

Die vier Prinzipien sind dabei mehr als eine Gliederung. Sie sind eine Denkhilfe für jeden Entwurf: Kann jemand das wahrnehmen, bedienen, verstehen, und funktioniert es mit unterschiedlicher Technik? Wenn du diese Fragen früh stellst, wird Barrierefreiheit zu einem selbstverständlichen Teil deiner Arbeit statt zu einer Prüfung am Ende.

Checkliste

• Du orientierst dich an WCAG 2.2, Stufe AA.
• Du kennst die vier Prinzipien: wahrnehmbar, bedienbar, verständlich, robust.
• Du kannst eine Kriteriumsnummer lesen: Prinzip, Richtlinie, Kriterium.
• Du prüfst ganze Seiten und vollständige Abläufe, nicht nur einzelne Elemente.
• Du liest zu jedem Kriterium das passende Understanding-Dokument.
• Du kombinierst automatische Tools mit manueller Prüfung.
• Du denkst Kontrast, Fokus, Klickziele, Beschriftungen und Fehlermeldungen schon im Design mit.

Quellen

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation vom 12. Dezember 2024
• W3C Web Accessibility Initiative: What’s New in WCAG 2.2
• W3C Web Accessibility Initiative: WCAG 2.2 Approved as an ISO Standard, 21. Oktober 2025
• W3C Web Accessibility Initiative: WCAG 3 Introduction
• W3C: Understanding WCAG 2.2
• W3C: How to Meet WCAG 2.2 (Quick Reference)