WCAG: Web Content Accessibility Guidelines erklärt

Was sind die Web Content Accessibility Guidelines (WCAG)?

Die Web Content Accessibility Guidelines (WCAG) sind der technische Standard des W3C, damit Webinhalte auch von Menschen mit Behinderungen genutzt werden können. Sie gliedern sich in vier Prinzipien, prüfbare Erfolgskriterien und drei Konformitätsstufen (A, AA, AAA). Aktuell ist WCAG 2.2, auf die sich die meisten Barrierefreiheitsregeln und Ausschreibungen beziehen.

Die WCAG entstehen in der Accessibility Guidelines Working Group des W3C als Teil der Web Accessibility Initiative. Sie gelten für Websites und Web-Apps und beschreiben die Inhalte, die Nutzer erhalten, nicht ein bestimmtes Framework oder Tool.

Die vier Prinzipien: POUR

Jedes Erfolgskriterium gehört zu einem von vier Prinzipien, die als POUR bekannt sind:

• Wahrnehmbar: Informationen müssen so dargestellt werden, dass Nutzer sie wahrnehmen können, etwa mit Textalternativen für Bilder, Untertiteln für Videos und ausreichendem Farbkontrast.
• Bedienbar: Jede Funktion ist per Tastatur nutzbar, Nutzer haben genug Zeit, nichts löst Anfälle aus und die Navigation ist klar.
• Verständlich: Texte sind lesbar, Seiten verhalten sich vorhersehbar und Formulare helfen, Fehler zu vermeiden und zu beheben.
• Robust: Inhalte funktionieren mit aktuellen und künftigen Browsern und assistiven Technologien, Name, Rolle und Wert werden korrekt bereitgestellt.

Konformitätsstufen A, AA und AAA

• Stufe A ist das Minimum: Bilder haben Textalternativen, Videos Untertitel, alles ist per Tastatur erreichbar.
• Stufe AA ist das übliche Ziel. Dazu gehören ein Kontrast von 4,5:1 für normalen Text (3:1 für großen Text), 3:1 für Bedienelemente und Grafiken und, neu in 2.2, Zielflächen von mindestens 24 mal 24 CSS-Pixeln (oder genug Abstand um kleinere).
• Stufe AAA fügt strengere Kriterien hinzu. Das W3C empfiehlt nicht, sie für ganze Websites vorzuschreiben, weil sich manche Kriterien nicht für alle Inhalte erfüllen lassen.

Konformität wird pro Seite bewertet. Eine Seite erfüllt eine Stufe nur, wenn sie alle Kriterien dieser und der darunterliegenden Stufen erfüllt.

WCAG-Versionen: 2.0, 2.1, 2.2 und 3.0

• WCAG 2.0 erschien im Dezember 2008.
• WCAG 2.1 (Juni 2018) ergänzte 17 Erfolgskriterien, vor allem für mobile Nutzung, Sehbehinderung und kognitive Bedürfnisse.
• WCAG 2.2 ist eine W3C-Empfehlung (aktualisiert im Dezember 2024). Sie ergänzt 9 Erfolgskriterien, darunter Fokus nicht verdeckt, Ziehbewegungen, Mindestgröße von Zielflächen, einheitliche Hilfe, redundante Eingaben und barrierefreie Authentifizierung, und entfernt 4.1.1 Parsing als überholt.
• WCAG 3.0 ist weiterhin ein Arbeitsentwurf (Stand 10. September 2026). Laut W3C ersetzt es WCAG 2 nicht, Teams sollten also weiter 2.2 anstreben.

Das W3C hat 2.0, 2.1 und 2.2 abwärtskompatibel angelegt: Inhalte, die 2.2 erfüllen, erfüllen auch 2.1 und 2.0. Den vollständigen Text finden Sie in der WCAG-2.2-Empfehlung.

Ein praktisches Beispiel

Ein Button "Jetzt kaufen" nutzt hellgrauen Text (#999999) auf weißem Grund. Das Kontrastverhältnis liegt bei etwa 2,8:1 und verfehlt damit 1.4.3 (Kontrast, Minimum) auf Stufe AA, obwohl es auf einem hellen Monitor gut aussieht. Mit #767676 sind es etwa 4,5:1, das besteht. Derselbe Button braucht außerdem einen sichtbaren Fokusindikator, eine Zielfläche von mindestens 24 mal 24 CSS-Pixeln und einen zugänglichen Namen, der zur sichtbaren Beschriftung passt.

Woran es am häufigsten scheitert

Die Analyse WebAIM Million 2026 fand bei einer Million Startseiten auf 95,9 % erkennbare WCAG-2-Fehler. Am häufigsten waren Text mit zu geringem Kontrast (83,9 % der Seiten), fehlende Alternativtexte (53,1 %), fehlende Formularbeschriftungen (51 %), leere Links (46,3 %), leere Buttons (30,6 %) und fehlende Dokumentsprache (13,5 %). Das lässt sich günstig beheben und eignet sich für einen ersten Sprint.

Häufige Fehler

• Barrierefreiheit als letzte Checkliste. Kontrast, Fokuszustände und semantisches HTML sind von Anfang an im Design-System deutlich günstiger.
• Nur auf automatische Scans setzen. Automatisierte Tests finden nur, was sich per Regel erkennen lässt, etwa fehlende Alt-Attribute. Ob ein Alternativtext sinnvoll ist oder die Lesereihenfolge passt, beurteilen sie nicht. Ergänzen Sie manuelle Tests mit Tastatur und Screenreader.
• ARIA statt natives HTML. Ein echtes <button> bringt Tastatur- und Screenreader-Unterstützung mit. Bei <div role="button"> muss alles nachgebaut werden.
• Bericht mit Konformität verwechseln. Ein VPAT oder ein Accessibility Conformance Report dokumentiert nur, was geprüft wurde. Eine Seite wird dadurch nicht barrierefrei.

WCAG und Ihre Testroutine

Prüfen Sie WCAG zusammen mit der Performance, denn beide Regressionen sollen Sie vor Ihren Nutzern entdecken. Page Speed Monitoring von LoadFocus führt geplante Google-Lighthouse-Audits aus 25 Cloud-Regionen aus, und jedes Audit enthält die Lighthouse-Kategorie Barrierefreiheit. So sehen Sie den Trend für den automatisierbaren Teil der WCAG. Das ist kein vollständiges Barrierefreiheits-Audit und ersetzt keine manuellen Tests. Mehr dazu im Blog (auf Englisch): warum Performance-Tests Accessibility-Metriken einbeziehen sollten.

Häufige Fragen: WCAG

Sind die WCAG gesetzlich vorgeschrieben?

Oft indirekt. Gesetze wie die EU-Richtlinie über den barrierefreien Zugang zu Websites (öffentlicher Sektor) verweisen über die Norm EN 301 549 auf die WCAG, und der European Accessibility Act, der ab dem 28. Juni 2025 gilt, erfasst Dienste wie E-Commerce und Bankwesen. Welche WCAG-Version und -Stufe eine Regel nennt, unterscheidet sich nach Land und Branche. Prüfen Sie die für Sie geltende Vorschrift.

Welche WCAG-Version sollte ich anstreben?

WCAG 2.2 auf Stufe AA. Sie ist die aktuelle Empfehlung und, weil abwärtskompatibel, erfüllt zugleich 2.1 und 2.0. WCAG 3.0 ist ein Entwurf und ersetzt WCAG 2 nicht.

Was ist der Unterschied zwischen A, AA und AAA?

Es sind aufeinander aufbauende Strengegrade. A ist das Minimum, AA ergänzt Kriterien wie 4,5:1 Textkontrast und ist das übliche rechtliche und vertragliche Ziel, AAA ist am strengsten und wird meist nur auf ausgewählte Inhalte angewendet.

Kann ein automatisches Tool bestätigen, dass meine Website WCAG-konform ist?

Nein. Tools wie Lighthouse prüfen die Regeln, die sich im Code erkennen lassen. Sinnvolle Alternativtexte, eine logische Fokusreihenfolge und verständliche Fehlermeldungen muss ein Mensch mit Tastatur und Screenreader beurteilen.

Was hat sich in WCAG 2.2 geändert?

Neun Erfolgskriterien kamen hinzu, darunter eine Mindestgröße von 24 mal 24 Pixeln für Zielflächen, die Regel, dass fokussierte Elemente nicht von fixierten Kopfzeilen verdeckt werden, Alternativen zu Ziehbewegungen und barrierefreie Authentifizierung. Das überholte Kriterium 4.1.1 Parsing entfiel.