Wer sich mit barrierefreien Websites beschäftigt, stößt schnell auf vier Buchstaben: WCAG. Die Richtlinien gelten als Maßstab dafür, ob Menschen mit Einschränkungen eine Website nutzen können. Auf den ersten Blick wirken sie mit Prinzipien, Richtlinien, Erfolgskriterien und Stufen allerdings sperrig. Verständlicher werden sie, wenn man weiß, woher die WCAG kommen und wie sie aufgebaut sind. Danach geht es um die Neuerungen in Version 2.2 und darum, wie Sie Ihre Website mit Tools und von Hand prüfen.
Was sind die WCAG?
WCAG steht für Web Content Accessibility Guidelines, auf Deutsch Richtlinien für barrierefreie Webinhalte. Sie sind ein internationaler Standard und beschreiben, wie Inhalte im Web für Menschen mit Behinderungen zugänglich werden. Mit Inhalten ist alles gemeint, was eine Webseite oder Webanwendung ausmacht: Text, Bilder, Töne und Videos ebenso wie der Code, der Struktur und Darstellung festlegt.
Herausgeber ist das World Wide Web Consortium (W3C), das Gremium, das auch Standards wie HTML und CSS verantwortet. Innerhalb des W3C erarbeitet die Web Accessibility Initiative (WAI) die Richtlinien, genauer deren Accessibility Guidelines Working Group. Die WCAG richten sich an alle, die Websites gestalten, programmieren oder mit Inhalten füllen, und an Hersteller von Autoren- und Prüfwerkzeugen. Als technischer Standard sind sie ausdrücklich keine Einführung in das Thema.
Die Richtlinien sind technikneutral formuliert. Sie schreiben nicht vor, welches CMS oder Framework Sie verwenden, sondern welches Ergebnis erreicht werden muss. Wie das mit HTML, CSS oder JavaScript konkret gelingt, beschreiben begleitende Dokumente des W3C, darunter die Erläuterungen „Understanding WCAG“, eine Sammlung von Techniken und eine Kurzreferenz zum Nachschlagen.
Die Versionen von WCAG 1.0 bis WCAG 2.2
Seit 1999 wurden die WCAG mehrfach weiterentwickelt. Für die Praxis wichtig ist, dass die Versionen der Reihe 2 aufeinander aufbauen: Neue Versionen ergänzen Erfolgskriterien, ändern bestehende aber nicht. Laut W3C erfüllt eine Website, die WCAG 2.2 einhält, damit auch WCAG 2.1 und 2.0.
| Version | Veröffentlicht | Was sich geändert hat |
|---|---|---|
| WCAG 1.0 | Mai 1999 | erste Fassung, stark auf HTML und CSS ausgerichtet |
| WCAG 2.0 | 11. Dezember 2008 | technikneutrale Neufassung mit vier Prinzipien, zwölf Richtlinien und testbaren Erfolgskriterien |
| WCAG 2.1 | 5. Juni 2018 | eine neue Richtlinie und 17 neue Erfolgskriterien, vor allem für Mobilgeräte, Sehbehinderung und Kognition |
| WCAG 2.2 | 5. Oktober 2023, aktualisiert im Dezember 2024 | neun neue Erfolgskriterien, das Kriterium 4.1.1 Syntaxanalyse entfällt |
| WCAG 3 | Entwurf | grundlegend neu aufgebaute Nachfolgegeneration, noch kein gültiger Standard |
WCAG 2.2 ist inzwischen auch als internationale ISO-Norm verabschiedet: Laut W3C entspricht ISO/IEC 40500:2025 genau der Fassung von Oktober 2023. Das W3C empfiehlt, immer die neueste Version zu verwenden. Auch wir setzen bei Projekten auf WCAG 2.2 in Stufe AA.
Die vier Prinzipien und 13 Richtlinien
Die WCAG sind in Ebenen aufgebaut. Ganz oben stehen vier Prinzipien. Darunter folgen in WCAG 2.2 insgesamt 13 Richtlinien, die beschreiben, worauf hingearbeitet werden soll. Zu jeder Richtlinie gehören testbare Erfolgskriterien, die am Ende über die Konformität entscheiden.
| Prinzip | Bedeutung | Richtlinien |
|---|---|---|
| 1. Wahrnehmbar | Informationen lassen sich mit mehr als einem Sinn erfassen. | Textalternativen, zeitbasierte Medien, anpassbar, unterscheidbar |
| 2. Bedienbar | Alle Funktionen sind mit unterschiedlichen Eingabemethoden nutzbar. | per Tastatur zugänglich, ausreichend Zeit, Anfälle und körperliche Reaktionen, navigierbar, Eingabemodalitäten |
| 3. Verständlich | Inhalte und Bedienung sind nachvollziehbar und vorhersehbar. | lesbar, vorhersehbar, Hilfestellung bei der Eingabe |
| 4. Robust | Inhalte funktionieren mit Browsern und Hilfsmitteln wie Screenreadern. | kompatibel |
Hinter dem ersten Prinzip steht der Gedanke, den man auch Zwei-Kanal-Prinzip nennt: Was man sehen kann, soll auch hörbar oder als Text erfassbar sein, und umgekehrt. Deshalb brauchen Bilder Alternativtexte und Videos Untertitel. Das zweite Prinzip sorgt dafür, dass niemand an einer Maus scheitert. Beim dritten geht es um Sprache, Navigation und Formulare, also klassische Aufgaben im UX- und UI-Design. Das vierte verlangt vor allem sauberen, semantischen Code.
Die Konformitätsstufen A, AA und AAA
Jedes Erfolgskriterium ist einer von drei Stufen zugeordnet. Die Stufen bauen aufeinander auf: Wer AA erreichen will, muss alle Kriterien der Stufen A und AA erfüllen.
- Stufe A: grundlegende Anforderungen. Werden sie verletzt, können bestimmte Gruppen eine Seite gar nicht nutzen, etwa wenn ein Formular nur mit der Maus abschickbar ist.
- Stufe AA: das übliche Ziel für Websites. Hier kommen Anforderungen wie Mindestkontraste, sichtbarer Tastaturfokus und Vergrößerbarkeit hinzu. Die europäische Norm EN 301 549 bezieht die Kriterien der Stufen A und AA ein.
- Stufe AAA: die höchste Stufe mit besonders weitgehenden Anforderungen, etwa Gebärdensprache für Videos oder sehr hohe Kontraste. Das W3C rät davon ab, AAA pauschal für ganze Websites vorzuschreiben, weil sich nicht alle Kriterien bei jedem Inhalt erfüllen lassen. Einzelne AAA-Kriterien sind trotzdem oft sinnvoll.
Konformität gilt immer für ganze Seiten und vollständige Abläufe. Ein Bestellprozess ist nur dann konform, wenn jeder Schritt vom Warenkorb bis zur Bestätigung die Kriterien erfüllt. Eine einzelne barrierearme Unterseite reicht nicht.
Wichtige Erfolgskriterien mit Beispielen
WCAG 2.2 enthält 86 Erfolgskriterien. Die folgenden der Stufen A und AA betreffen fast jede Unternehmenswebsite und sind ein guter Einstieg:
| Kriterium | Stufe | Was es in der Praxis bedeutet |
|---|---|---|
| 1.1.1 Nicht-Text-Inhalt | A | Informative Bilder haben einen Alternativtext, dekorative ein leeres alt-Attribut. |
| 1.2.2 Untertitel (aufgezeichnet) | A | Der Imagefilm hat Untertitel, die auch wichtige Geräusche wiedergeben. |
| 1.3.1 Info und Beziehungen | A | Überschriften sind echte Überschriften, Listen echte Listen, Formularfelder mit ihrer Beschriftung verknüpft. |
| 1.4.1 Benutzung von Farbe | A | Pflichtfelder oder Fehler sind nicht nur rot markiert, sondern auch mit Text oder Symbol. |
| 1.4.3 Kontrast (Minimum) | AA | Fließtext hat mindestens 4,5 zu 1 Kontrast zum Hintergrund, große Schrift mindestens 3 zu 1. |
| 1.4.4 Textgröße ändern | AA | Bei 200 Prozent Vergrößerung geht nichts verloren. |
| 1.4.10 Reflow (Umbruch) | AA | Bei 320 CSS-Pixeln Breite ist kein seitliches Scrollen nötig, das entspricht 400 Prozent Zoom. |
| 1.4.11 Nicht-Text-Kontrast | AA | Umrisse von Eingabefeldern und wichtige Icons haben mindestens 3 zu 1 Kontrast. |
| 2.1.1 Tastatur | A | Menü, Formulare und Schieberegler funktionieren mit Tab, Enter und Pfeiltasten. |
| 2.4.4 Linkzweck (im Kontext) | A | „Mehr zur Wartung“ statt dreimal „hier klicken“. |
| 2.4.7 Fokus sichtbar | AA | Beim Navigieren mit der Tab-Taste ist immer erkennbar, wo man sich befindet. |
| 3.1.1 Sprache der Seite | A | Im Code ist Deutsch als Sprache hinterlegt, damit Screenreader richtig aussprechen. |
| 3.3.1 Fehlererkennung | A | Das Formular sagt im Klartext, welches Feld falsch ausgefüllt ist. |
| 4.1.2 Name, Rolle, Wert | A | Ein Menü-Button ist als Button erkennbar und meldet, ob das Menü offen ist. |
Große Schrift bedeutet in den WCAG mindestens 18 Punkt, bei fetter Schrift 14 Punkt, im Web etwa 24 und knapp 19 Pixel. Farbkombinationen aus Ihrem Corporate Design, zum Beispiel starke Komplementärfarben, sollten Sie deshalb immer mit einem Kontrastprüfer testen. Wie Layouts beim Vergrößern stabil bleiben, zeigt der Artikel über responsive Webdesign.
Was ist neu in WCAG 2.2?
WCAG 2.2 ergänzt neun Erfolgskriterien. Die meisten betreffen die Bedienung mit Tastatur und Touchscreen sowie Menschen mit kognitiven Einschränkungen.
| Kriterium | Stufe | Worum es geht |
|---|---|---|
| 2.4.11 Fokus nicht verdeckt (Minimum) | AA | Das fokussierte Element darf nicht vollständig von fixierten Kopfzeilen, Cookie-Bannern oder Chatfenstern verdeckt werden. |
| 2.4.12 Fokus nicht verdeckt (erweitert) | AAA | Das fokussierte Element ist gar nicht verdeckt. |
| 2.4.13 Fokus-Darstellung | AAA | Die Fokusmarkierung hat eine Mindestgröße und einen deutlichen Kontrast. |
| 2.5.7 Ziehbewegungen | AA | Was sich per Ziehen bedienen lässt, etwa ein Schieberegler oder eine sortierbare Liste, geht auch mit einfachen Klicks. |
| 2.5.8 Zielgröße (Minimum) | AA | Klick- und Tippflächen sind mindestens 24 mal 24 CSS-Pixel groß oder haben genug Abstand. |
| 3.2.6 Konsistente Hilfe | A | Hilfsangebote wie Telefonnummer oder Kontaktlink stehen auf allen Seiten in derselben Reihenfolge an vergleichbarer Stelle. |
| 3.3.7 Redundante Eingaben | A | Bereits eingegebene Daten müssen in einem Ablauf nicht erneut eingetippt werden, etwa die Lieferadresse als Rechnungsadresse. |
| 3.3.8 Barrierefreie Authentifizierung (Minimum) | AA | Anmeldungen kommen ohne Gedächtnis- oder Rätselaufgaben aus. Das Einfügen von Passwörtern und Passwort-Manager dürfen nicht blockiert werden. |
| 3.3.9 Barrierefreie Authentifizierung (erweitert) | AAA | Auch das Erkennen von Objekten oder eigenen Bildern wird bei der Anmeldung nicht verlangt. |
Gestrichen wurde das Kriterium 4.1.1 Syntaxanalyse. Es verlangte fehlerfreien HTML-Code im Sinne bestimmter Regeln. Moderne Browser und Hilfsmittel gehen mit solchen Fehlern inzwischen zuverlässig um, deshalb gilt es als überholt. Sauberer Code bleibt trotzdem wichtig, weil andere Kriterien wie 4.1.2 davon abhängen.
Ausblick: WCAG 3
Parallel arbeitet das W3C an einer neuen Generation, den W3C Accessibility Guidelines 3.0, früher unter dem Arbeitstitel „Silver“ bekannt. Die Abkürzung bleibt WCAG. Laut W3C handelt es sich um einen frühen Entwurf. WCAG 3 soll breiter angelegt sein als die bisherigen Versionen und neben Websites auch Apps, Werkzeuge, Dokumente und neue Technologien stärker einbeziehen. Aufbau und Bewertungssystem werden grundlegend überarbeitet.
Ein Termin für die fertige Fassung steht nicht fest. Für Projekte, die heute starten, ist WCAG 2.2 der Maßstab. Wer seine Website jetzt barrierearm nach WCAG 2.2 umsetzt, schafft zudem eine gute Grundlage für spätere Anpassungen.
WCAG-Konformität mit Tools und von Hand prüfen
Eine Prüfung nach WCAG besteht immer aus zwei Teilen: automatisierten Tests und manueller Kontrolle. Automatische Werkzeuge finden nur einen Teil der Probleme. Sie erkennen, ob ein Bild einen Alternativtext hat, aber nicht, ob der Text sinnvoll ist. Kontraste messen sie ebenfalls. Ob eine Fehlermeldung verständlich ist, können sie dagegen nicht beurteilen.
Automatisierte Werkzeuge
- WAVE: Browser-Erweiterung von WebAIM, die Fehler direkt auf der Seite markiert.
- axe DevTools: Erweiterung für die Entwicklertools, gut für Entwicklerinnen und Entwickler.
- Lighthouse: in Chrome eingebaut, liefert einen Barrierefreiheitswert als groben Anhaltspunkt.
- Accessibility Insights: Werkzeug von Microsoft mit geführten manuellen Prüfschritten.
- Kontrastprüfer: etwa der Colour Contrast Analyser, mit dem sich Farben per Pipette prüfen lassen.
Für eine strukturierte Gesamtprüfung gibt es standardisierte Verfahren wie den WCAG-Test, der im Projekt BIK entwickelt wurde.
Manuelle Prüfung in fünf Schritten
Tastatur
Legen Sie die Maus weg. Erreichen Sie mit Tab, Umschalt und Tab, Enter und Leertaste alle Links, Menüs und Formularfelder? Ist der Fokus immer sichtbar und nie verdeckt?
Zoom und Umbruch
Vergrößern Sie auf 200 und 400 Prozent. Bleibt alles lesbar, ohne dass Sie seitlich scrollen müssen?
Screenreader
Hören Sie sich die Seite mit NVDA unter Windows oder VoiceOver auf Mac und iPhone an. Werden Überschriften, Bilder, Buttons und Fehlermeldungen verständlich vorgelesen?
Struktur
Prüfen Sie die Überschriftenhierarchie und ob Listen, Tabellen und Formularbeschriftungen korrekt ausgezeichnet sind.
Medien und Bewegung
Haben Videos Untertitel? Lassen sich automatisch laufende Inhalte anhalten? Blinkt nichts unkontrolliert?
Am aussagekräftigsten sind Tests mit Menschen, die selbst auf Hilfsmittel angewiesen sind. Sie finden Hürden, die weder Tools noch geübte Prüfer bemerken.
Kurzer Hinweis zu WCAG, BFSG und BITV
In Deutschland verweisen das Barrierefreiheitsstärkungsgesetz (BFSG) und die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) für die technischen Anforderungen auf die europäische Norm EN 301 549 und damit auf die WCAG. Welche Pflichten daraus für Ihr Unternehmen folgen und welche Fassung maßgeblich ist, ist eine rechtliche Frage. Die klären Sie mit einer Anwältin oder einem Anwalt, Ihrer IHK oder Ihrem Branchenverband. Technisch deckt eine Umsetzung nach WCAG 2.2 in Stufe AA auch alle Kriterien der Version 2.1 ab, weil die Versionen aufeinander aufbauen.
Unterstützung bei der Umsetzung
Barrierearm nach WCAG 2.2, geprüft von Hand
Wir prüfen Ihre Website nach WCAG 2.2 in Stufe AA, mit Tools, Tastatur und Screenreader, und liefern einen Bericht mit allen gefundenen Barrieren und konkreten Lösungen. Die technische Prüfung finden Sie beim BFSG-Check, die Umsetzung in Design, Code und Inhalten auf unserer Seite zur barrierefreien Website. Eine rechtliche Bewertung geben wir nicht ab. Nach dem kostenlosen Erstgespräch erhalten Sie innerhalb von drei Werktagen ein Festpreisangebot.
Häufige Fragen
Was bedeutet WCAG?
WCAG steht für Web Content Accessibility Guidelines, auf Deutsch Richtlinien für barrierefreie Webinhalte. Sie werden vom World Wide Web Consortium (W3C) herausgegeben und sind der internationale Standard dafür, wie Websites für Menschen mit Behinderungen zugänglich werden.
Welche WCAG-Version ist aktuell?
Aktuell ist WCAG 2.2, veröffentlicht am 5. Oktober 2023 und im Dezember 2024 aktualisiert. Sie enthält alle Kriterien von WCAG 2.1 bis auf das gestrichene Kriterium 4.1.1 und ergänzt neun neue. WCAG 3 ist noch ein Entwurf.
Welche Stufe sollte meine Website erreichen?
Üblich ist Stufe AA. Sie umfasst alle Kriterien der Stufen A und AA und ist auch die Stufe, die die europäische Norm EN 301 549 einbezieht. Einzelne Kriterien der Stufe AAA können zusätzlich sinnvoll sein.
Reicht ein automatischer Test aus?
Nein. Tools wie WAVE, axe oder Lighthouse finden nur einen Teil der Probleme. Ob Alternativtexte sinnvoll, Fehlermeldungen verständlich und Abläufe per Tastatur bedienbar sind, zeigt nur eine manuelle Prüfung, am besten ergänzt um einen Test mit Screenreader.
Gibt es die WCAG auf Deutsch?
Für WCAG 2.0 gibt es eine vom W3C autorisierte deutsche Übersetzung. Die Übersetzung von WCAG 2.1 entstand unter Koordination der Aktion Mensch und ist nicht autorisiert. Maßgeblich ist immer die englische Originalfassung.
Kann ein Overlay-Tool meine Website WCAG-konform machen?
Nein. Widgets, die per Knopfdruck Barrierefreiheit versprechen, beheben die Ursachen im Code nicht und können Screenreader sogar stören. Barrieren verschwinden nur, wenn Design, Code und Inhalte sie gar nicht erst erzeugen.
