WCAG einfach erklärt

Wer sich mit digitaler Barrierefreiheit beschäftigt, stößt früher oder später auf vier Buchstaben: WCAG. Eine Webdesignerin sagt, die Website „erfüllt WCAG 2.1 AA“, ein Gesetz verweist darauf, eine Ausschreibung verlangt es, ein Prüfbericht listet Verstöße auf. Die WCAG klingen nach einem dicken technischen Regelwerk für Fachleute. In der Praxis beschreiben sie alltägliche Dinge: Bilder mit Beschreibung, lesbaren Text, Formulare, die sich mit der Tastatur ausfüllen lassen, Seiten, die sich so verhalten, wie man es erwartet. Dieser Artikel erklärt, was die WCAG sind, welche Version und Stufe zählen, was sich zuletzt geändert hat und wie Sie damit arbeiten, ohne das ganze Dokument zu lesen.

Was die WCAG sind

WCAG steht für Web Content Accessibility Guidelines, auf Deutsch Richtlinien für barrierefreie Webinhalte. Herausgegeben werden sie vom W3C, der internationalen Organisation, die Standards für das Web entwickelt, über ihre Web Accessibility Initiative (Überblick des W3C). Sie dürfen sie kostenlos lesen und nutzen.

Die WCAG sind in Ebenen aufgebaut:

Vier Prinzipien an der Spitze: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein. Dazu weiter unten mehr.
Richtlinien unter jedem Prinzip, etwa „Text lesbar machen“ oder „ausreichend Zeit geben“.
Erfolgskriterien unter jeder Richtlinie. Das sind die eigentlichen Anforderungen, so formuliert, dass man sie prüfen kann: Eine Seite erfüllt sie oder nicht. Jedes hat eine Nummer wie 1.1.1 und einen kurzen Namen wie „Nicht-Text-Inhalt“.

Die WCAG sind an keine bestimmte Technik gebunden. Sie beschreiben Ergebnisse, etwa „jedes Formularfeld hat eine Beschriftung, die sagt, wofür es da ist“, nicht den Weg dorthin. Deshalb passen sie zu einer selbst programmierten Website ebenso wie zu einem WordPress-Theme oder einer Seite aus einem KI-Baukasten. Version 2.2 ist zudem eine internationale Norm, ISO/IEC 40500:2025 (Ankündigung des W3C).

Die Versionen 2.0, 2.1 und 2.2

Die WCAG sind Schritt für Schritt gewachsen, und jede Version baut auf der vorherigen auf.

WCAG 2.0 (2008) legte das Fundament.
WCAG 2.1 (2018) ergänzte Anforderungen für Mobilgeräte, für Menschen mit Sehbehinderung und für Menschen mit kognitiven Beeinträchtigungen oder Lernschwierigkeiten. Beispiele sind Inhalte, die im Hoch- und Querformat funktionieren, und Text, der lesbar bleibt, wenn man Zeilen- und Buchstabenabstände vergrößert.
WCAG 2.2 (Oktober 2023) brachte neun neue Erfolgskriterien, vor allem zum Tastaturfokus, zu Klick- und Tippflächen, zur Anmeldung und zur Hilfe. Ein altes Kriterium zur Code-Syntax, „Syntaxanalyse“ (Parsing), fiel weg, weil moderne Browser es überflüssig gemacht haben (Neu in WCAG 2.2).

Weil die Versionen aufeinander aufbauen, hat das W3C sie so angelegt, dass eine Website, die WCAG 2.2 erfüllt, auch 2.1 und 2.0 erfüllt. Wenn Sie jetzt beginnen, orientieren Sie sich an 2.2.

Vielleicht hören Sie auch von WCAG 3. Das ist ein völlig neuer Entwurf, an dem das W3C noch schreibt. Es handelt sich um einen Arbeitsentwurf, keinen fertigen Standard, und es wird Jahre dauern, bis Gesetze darauf verweisen (Einführung in WCAG 3). Vorerst zählt WCAG 2.

Die Stufen A, AA und AAA

Jedes Erfolgskriterium hat eine Stufe.

Stufe A deckt die Grundlagen ab. Ohne sie können manche Menschen die Seite gar nicht nutzen. Beispiele: Bilder haben eine Textalternative, alles funktioniert mit der Tastatur, es gibt keine Tastaturfalle (eine Stelle, die man mit der Tastatur nicht mehr verlassen kann), und Videos haben Untertitel.
Stufe AA ergänzt, was eine Website für viel mehr Menschen angenehm nutzbar macht. Beispiele: Text hat genug Kontrast zum Hintergrund, Seiten funktionieren auch bei 200 % Zoom, der Tastaturfokus ist sichtbar, und Überschriften und Beschriftungen beschreiben ihr Thema.
Stufe AAA ist die strengste. Beispiele: noch höherer Kontrast, Gebärdensprache für Videos und Texte, die mit dem Leseniveau der unteren Sekundarstufe verständlich sind.

Die Stufen bauen aufeinander auf. Um AA zu erfüllen, muss eine Seite jedes A- und jedes AA-Kriterium erfüllen. In WCAG 2.2 sind das 55 Erfolgskriterien. AAA ist eine gute Quelle für zusätzliche Ideen, doch das W3C selbst rät davon ab, sie für ganze Websites zu verlangen, weil manche Inhalte schlicht nicht jedes AAA-Kriterium erfüllen können.

Wer „WCAG AA“ sagt, meint die Stufen A und AA zusammen. Das ist die Stufe, die fast jedes Gesetz und jeder Vertrag verlangt.

Die vier Prinzipien mit Beispielen aus dem Alltag

Jedes der vier Prinzipien beantwortet eine einfache Frage über Ihre Besucherinnen und Besucher.

Wahrnehmbar: Können Menschen die Inhalte aufnehmen?

Informationen müssen Menschen über mindestens einen Sinn erreichen, den sie nutzen können. Ein blinder Besucher hört einen Screenreader (Software, die den Bildschirm vorliest), deshalb brauchen Fotos eine kurze Beschreibung, den Alternativtext. Eine gehörlose Besucherin braucht Untertitel für Ihr Video. Wer schlecht sieht, braucht Text mit gutem Kontrast zum Hintergrund und eine Seite, die nicht zerfällt, wenn die Schrift größer wird. Und Farbe allein reicht nicht: Ein Formular, das Fehler nur mit einem roten Rahmen markiert, sagt einem farbenblinden Menschen nichts.

Bedienbar: Können Menschen es benutzen?

Jede Funktion muss auf mehr als eine Weise funktionieren. Wer keine Maus nutzen kann, bewegt sich mit der Tabulatortaste durch Ihre Website, also muss jeder Link, jeder Knopf und jedes Menü erreichbar sein und zeigen, wo die Tastatur gerade steht. Wer langsam liest, braucht genug Zeit, also darf eine Sitzung nicht ohne Warnung ablaufen. Inhalte dürfen nicht öfter als dreimal pro Sekunde blitzen, weil Blitze Anfälle auslösen können. Und klare Überschriften und Seitentitel helfen allen, sich zurechtzufinden.

Verständlich: Finden sich Menschen zurecht?

Die Seite sollte die Sprache der Besucher sprechen, wörtlich (die Seitensprache ist angegeben, damit ein Screenreader die Wörter richtig ausspricht) und im übertragenen Sinn (klare Wörter, kurze Sätze). Seiten verhalten sich vorhersehbar: Ein Menü bleibt an derselben Stelle, eine Auswahl schickt Sie nicht plötzlich auf eine andere Seite. Formulare sagen, was sie brauchen, und erklären bei einem Fehler, was falsch ist und wie man es behebt: „Geben Sie ein Datum wie 14.03.2026 ein“ hilft, „Ungültige Eingabe“ nicht.

Robust: Funktioniert es mit den Hilfsmitteln der Menschen?

Ihre Website muss mit Browsern und assistiven Technologien funktionieren, heute und morgen. Praktisch heißt das: echte Knöpfe, Links und Formularfelder verwenden, mit Namen, die Software lesen kann. Ein „Knopf“, der nur ein farbiges Feld ist und auf Mausklicks reagiert, sieht gut aus, aber ein Screenreader kündigt ihn nicht an, und die Tastatur erreicht ihn nicht.

Welche Stufe das Gesetz verlangt

In der Europäischen Union zählen für Websites vor allem zwei Regelwerke. Die Web-Zugänglichkeits-Richtlinie gilt für Websites und Apps öffentlicher Stellen. Der European Accessibility Act, der seit dem 28. Juni 2025 gilt, umfasst viele private Dienstleistungen wie Onlineshops, Bankdienstleistungen, Personenverkehr und E-Books. Beide wirken über eine europäische Norm, die EN 301 549. Für Websites übernimmt diese Norm die Erfolgskriterien der WCAG auf den Stufen A und AA.

Die heute verwendete Fassung, EN 301 549 V3.2.1, verweist auf WCAG 2.1 Stufe AA. Eine neue Fassung, V4.1.1, wurde im September 2026 veröffentlicht. Sie ist auf WCAG 2.2 Stufe AA abgestimmt und enthält einen eigenen Teil für den European Accessibility Act. Sie wird zur rechtlichen Referenz, sobald die Europäische Kommission sie im Amtsblatt der EU veröffentlicht, was gegen Ende 2026 erwartet wird (Level Access).

Die nationalen Gesetze bauen darauf auf. In Deutschland setzt das Barrierefreiheitsstärkungsgesetz (BFSG) den European Accessibility Act für Unternehmen um, und für Bundesbehörden gilt die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0). Beide verweisen auf die EN 301 549 und damit auf die WCAG.

Woran sollten sich also ein kleines Unternehmen oder eine Behörde orientieren? WCAG 2.1 AA ist das, was das Gesetz heute verlangt. WCAG 2.2 AA enthält alles aus 2.1 AA (bis auf das gestrichene Kriterium zur Syntaxanalyse) und dazu sechs neue Kriterien, und dorthin bewegt sich das Recht. Wenn Sie eine Website neu bauen oder überarbeiten, orientieren Sie sich an 2.2 AA, damit Sie nicht bald erneut ranmüssen.

Was sich mit WCAG 2.2 für kleine Websites ändert

Sechs der neuen Kriterien liegen auf Stufe A oder AA. Jedes löst etwas, auf das Menschen täglich stoßen.

Fokus nicht verdeckt. Wenn Sie sich mit der Tastatur durch eine Seite bewegen, darf das Element, auf dem Sie stehen, nicht vollständig hinter einer fixierten Kopfzeile, einem Chat-Knopf oder einem Cookie-Banner verschwinden.
Zielgröße. Knöpfe und Links, die man antippt, sind mindestens 24 mal 24 Pixel groß oder haben genug Abstand ringsum, damit Menschen mit zitternden Händen nicht das falsche treffen. Links mitten im Satz sind ausgenommen.
Ziehbewegungen. Alles, wofür man ziehen muss, etwa ein Schieberegler, eine Karte oder das Umsortieren von Einträgen, muss auch mit einfachen Klicks oder Tippen funktionieren.
Einheitliche Hilfe. Wenn Sie Hilfe anbieten, etwa eine Telefonnummer, einen Kontaktlink oder einen Chat, platzieren Sie sie auf jeder Seite an derselben Stelle.
Redundante Eingaben. Lassen Sie Menschen in einem Vorgang nicht zweimal dasselbe eintippen. Hat eine Kundin ihre Adresse in Schritt eins eingegeben, füllen Sie sie in Schritt drei aus oder bieten Sie sie zur Auswahl an, etwa mit einem Kästchen „Gleich wie Lieferadresse“.
Barrierefreie Authentifizierung. Die Anmeldung darf nicht davon abhängen, sich etwas ohne Hilfe zu merken oder abzutippen oder ein Rätsel zu lösen. Erlauben Sie Kopieren und Einfügen sowie Passwortmanager, oder bieten Sie einen Anmeldelink per E-Mail an. Bilderkennungsrätsel und persönliche Inhalte sind auf Stufe AA erlaubte Ausnahmen, aber einfachere Wege sind freundlicher.

Zwei davon lassen sich oft mit wenigen Zeilen CSS lösen (dem Code, der das Aussehen einer Website bestimmt):

/* Element mit Fokus unter einer 80px hohen fixierten Kopfzeile sichtbar halten */
html {
  scroll-padding-top: 80px;
}

/* Kleinen Symbolknöpfen eine angenehme Tippfläche geben */
.icon-button {
  min-width: 44px;
  min-height: 44px;
}

Und das häufigste Anmeldeproblem ist ein Passwortfeld, das Einfügen blockiert:

<!-- Vermeiden: blockiert Passwortmanager und Einfügen -->
<input type="password" onpaste="return false" />

<!-- Besser: lässt Passwortmanager das Feld ausfüllen -->
<input type="password" autocomplete="current-password" />

Mit den WCAG arbeiten, ohne alles zu lesen

Sie müssen nicht den ganzen Standard lesen. Ein paar Gewohnheiten bringen Sie schon weit.

Gehen Sie von den wichtigsten Aufgaben Ihrer Besucher aus. Informationen finden, buchen, bezahlen, Kontakt aufnehmen. Prüfen Sie, ob jede Aufgabe gelingt, statt jedes Kriterium abstrakt abzuhaken.
Nutzen Sie die Kurzreferenz des W3C. How to Meet WCAG zeigt jedes Kriterium mit kurzen Erklärungen und Beispielen und lässt sich nach Stufe filtern. Filtern Sie auf A und AA und blenden Sie den Rest aus.
Beheben Sie zuerst die häufigsten Probleme. In der WebAIM-Auswertung von einer Million Startseiten aus dem Jahr 2026 waren die häufigsten Fehler zu kontrastarmer Text, Bilder ohne Beschreibung, Formularfelder ohne Beschriftung, leere Links, leere Knöpfe und eine fehlende Seitensprache (WebAIM Million). Unsere Anleitungen zur Behebung behandeln jedes davon.
Lesen Sie im Zweifel die Seite „Understanding“. Zu jedem Kriterium gibt es eine Seite, die den Zweck erklärt, sagt, wem es hilft, und Beispiele zeigt. Ihre Entwickler finden dort auch die technischen Techniken.
Halten Sie es schriftlich fest. Wenn Sie eine Designerin, einen Entwickler oder eine Agentur beauftragen oder ein Theme wählen, verlangen Sie ausdrücklich „WCAG 2.2 Stufe AA“ und fragen Sie, wie das geprüft wird.
Dokumentieren Sie es in einer Erklärung. Eine Erklärung zur Barrierefreiheit sagt, welchem Standard Sie folgen, was Sie geprüft haben und was noch Arbeit braucht. Unsere Anleitung zur Erklärung zur Barrierefreiheit erklärt, wie das geht.

Wie automatische Prüfungen mit den WCAG zusammenhängen

Automatische Prüfwerkzeuge, auch ibin, testen Seiten auf die WCAG-Erfolgskriterien, die Software zuverlässig beurteilen kann. Gibt es überhaupt eine Textalternative? Hat der Text genug Kontrast? Hat jedes Feld eine Beschriftung? Ist die Seitensprache angegeben? Diese Prüfungen sind schnell und wiederholbar, und sie finden viele der häufigsten Fehler.

Viele Kriterien brauchen aber einen Menschen. Software sieht, dass ein Bild einen Alternativtext hat, aber nicht, ob „foto123“ oder „Bild“ es beschreibt. Sie kann prüfen, ob eine Seite Überschriften hat, aber nicht, ob diese den Inhalt beschreiben. Sie kann nicht sagen, ob Ihre Anleitungen klar sind oder ob ein Menü wirklich mit der Tastatur funktioniert. Automatische Prüfungen finden etwa ein Drittel bis die Hälfte der Probleme; den Rest müssen Menschen prüfen.

Eine gute Routine verbindet beides. Machen Sie eine automatische Prüfung, beheben Sie, was sie findet, machen Sie dann den Tastaturtest in zehn Minuten und lesen Sie Ihre Bildbeschreibungen und Linktexte mit frischem Blick. Der optionale zweite Blick durch KI in ibin bewertet unter anderem Bildbeschreibungen, Linktexte und die Bedienung per Tastatur, damit Sie wissen, wo Sie zuerst hinsehen sollten. Das sind Hinweise, keine Urteile. Und kein Werkzeug kann bescheinigen, dass eine Website die WCAG erfüllt: Dafür braucht es eine vollständige Prüfung durch Menschen.

Prüfen Sie eine Seite auf die Grundlagen

Prüfen Sie eine Seite kostenlos mit ibin und sehen Sie, welche WCAG-Probleme die automatischen Prüfungen finden, in einfacher Sprache erklärt, mit einem Bild der Stelle, an der jedes Problem liegt, und einer Anleitung zur Behebung. Beginnen Sie mit Ihrer Startseite oder Ihrem wichtigsten Formular, beheben Sie zuerst die kritischen Probleme und prüfen Sie dann erneut.

Sehen Sie, wie Ihre Website abschneidet

Prüfen Sie kostenlos eine Seite, ohne Konto. Sie erhalten eine klare Liste, was zuerst zu beheben ist, mit Bildern, wo jedes Problem liegt.