Was ist WCAG 2.1?
Die Web Content Accessibility Guidelines (WCAG) 2.1 sind internationale Richtlinien für barrierefreie Webinhalte, entwickelt vom World Wide Web Consortium (W3C). Sie definieren technische Standards, die sicherstellen, dass Websites und Webanwendungen von allen Menschen genutzt werden können, unabhängig von körperlichen, sensorischen oder kognitiven Einschränkungen.
WCAG 2.1 wurde im Juni 2018 veröffentlicht und erweitert die Version 2.0 um 17 neue Erfolgskriterien. Die Richtlinien sind in drei Konformitätsstufen unterteilt: Level A (Mindestanforderungen), Level AA (empfohlener Standard) und Level AAA (höchste Zugänglichkeit).
In Deutschland ist WCAG 2.1 Level AA der rechtlich relevante Standard. Das Barrierefreiheitsstärkungsgesetz (BFSG), das ab Juni 2025 gilt, verweist auf die europäische Norm EN 301 549, die wiederum auf WCAG 2.1 basiert. Öffentliche Stellen sind bereits seit der EU-Richtlinie 2016/2102 zur Einhaltung verpflichtet.
Gut zu wissen
Diese Checkliste umfasst alle 50 Erfolgskriterien der Stufen A und AA. Level AAA ist in der Praxis oft nicht vollständig umsetzbar und wird daher nicht als allgemeiner Standard gefordert.
Die vier POUR-Prinzipien
WCAG 2.1 basiert auf vier grundlegenden Prinzipien, die als POUR-Prinzipien bekannt sind. Jedes Erfolgskriterium lässt sich einem dieser Prinzipien zuordnen:
1 Wahrnehmbar (Perceivable)
Informationen und Benutzeroberflächen müssen so dargestellt werden, dass sie von allen Nutzern wahrgenommen werden können. Dies betrifft Textalternativen, Untertitel, Kontraste und anpassbare Darstellung.
2 Bedienbar (Operable)
Alle Funktionen müssen über verschiedene Eingabemethoden bedienbar sein, insbesondere per Tastatur. Nutzer benötigen ausreichend Zeit und dürfen nicht durch blinkende Inhalte gefährdet werden.
3 Verständlich (Understandable)
Inhalte und Bedienung müssen verständlich sein. Texte sollen lesbar sein, die Navigation vorhersehbar funktionieren und Eingabehilfen bei Fehlern unterstützen.
4 Robust
Inhalte müssen robust genug sein, um von verschiedenen Benutzeragenten, einschließlich assistiver Technologien wie Screenreadern, zuverlässig interpretiert zu werden.
1 Wahrnehmbar (Perceivable)
Das erste Prinzip stellt sicher, dass alle Nutzer die präsentierten Informationen wahrnehmen können. Menschen mit Sehbehinderungen benötigen Textalternativen für Bilder, Gehörlose brauchen Untertitel für Videos, und alle profitieren von ausreichenden Kontrasten.
1.1 Textalternativen
1.1.1 Nicht-Text-Inhalte (Level A)
Alle nicht-textuellen Inhalte wie Bilder, Grafiken, Icons und Diagramme müssen eine Textalternative haben, die den gleichen Zweck erfüllt. Dekorative Bilder erhalten ein leeres alt-Attribut.
Praktisches Beispiel:
<img src="produkt.jpg" alt="Rotes Sofa aus Leder, 3-Sitzer">
<img src="dekoration.svg" alt="" role="presentation">1.2 Zeitbasierte Medien
1.2.1 Nur-Audio und Nur-Video (aufgezeichnet) (Level A)
Für aufgezeichnete Nur-Audio-Inhalte (z.B. Podcasts) muss ein Texttranskript bereitgestellt werden. Für Nur-Video-Inhalte ohne Ton ist entweder ein Transkript oder eine Audiobeschreibung erforderlich.
Tipp: Transkripte verbessern auch die SEO und ermöglichen das Durchsuchen von Audio-Inhalten.
1.2.2 Untertitel (aufgezeichnet) (Level A)
Alle aufgezeichneten Videos mit Ton müssen synchronisierte Untertitel haben. Diese müssen nicht nur gesprochene Inhalte, sondern auch relevante Geräusche (z.B. [Türklingel]) enthalten.
Tipp: YouTube generiert automatische Untertitel, die als Ausgangspunkt dienen können, aber manuell korrigiert werden sollten.
1.2.3 Audiodeskription oder Medienalternative (aufgezeichnet) (Level A)
Für Videos mit wichtigen visuellen Informationen, die nicht im Ton enthalten sind, muss eine Audiodeskription oder ein vollständiges Texttranskript bereitgestellt werden.
1.2.4 Untertitel (Live) (Level AA)
Live-Übertragungen mit Audio-Inhalten benötigen Echtzeit-Untertitel. Dies betrifft Webinare, Live-Streams und Video-Konferenzen, die öffentlich zugänglich sind.
1.2.5 Audiodeskription (aufgezeichnet) (Level AA)
Aufgezeichnete Videos müssen eine Audiodeskription haben, wenn wichtige visuelle Informationen nicht allein durch den vorhandenen Ton vermittelt werden. Die Beschreibung wird in natürlichen Pausen eingefügt.
1.3 Anpassbar
1.3.1 Informationen und Beziehungen (Level A)
Informationen, Struktur und Beziehungen, die durch die Darstellung vermittelt werden, müssen auch programmatisch bestimmbar sein. Überschriften müssen als solche im HTML markiert sein (h1-h6), nicht nur visuell größer dargestellt werden.
Praktisches Beispiel:
<!-- Richtig: -->
<h2>Produktübersicht</h2>
<!-- Falsch: -->
<p class="gross-fett">Produktübersicht</p>1.3.2 Bedeutungstragende Reihenfolge (Level A)
Die Lesereihenfolge im DOM muss der visuellen Reihenfolge entsprechen, wenn die Reihenfolge für das Verständnis wichtig ist. CSS-Techniken wie Flexbox order oder Grid dürfen die logische Reihenfolge nicht zerstören.
1.3.3 Sensorische Eigenschaften (Level A)
Anweisungen dürfen nicht ausschließlich auf sensorischen Eigenschaften wie Form, Größe, visuelle Position, Ausrichtung oder Ton basieren. Statt "Klicken Sie auf den grünen Button" sollte es heißen "Klicken Sie auf Absenden".
1.3.4 Ausrichtung (Level AA)
Inhalte dürfen nicht auf eine bestimmte Bildschirmausrichtung (Hochformat oder Querformat) beschränkt sein, es sei denn, eine bestimmte Ausrichtung ist wesentlich (z.B. bei einem Klavier-App).
1.3.5 Eingabezweck bestimmen (Level AA)
Bei Formulareingaben, die persönliche Daten des Nutzers betreffen, muss der Zweck programmatisch bestimmt werden können. Dies ermöglicht Autofill-Funktionen und personalisierte Icons.
Praktisches Beispiel:
<input type="email" autocomplete="email" name="email">
<input type="tel" autocomplete="tel" name="telefon">1.4 Unterscheidbar
1.4.1 Verwendung von Farbe (Level A)
Farbe darf nicht das einzige visuelle Mittel sein, um Informationen zu vermitteln, eine Handlung anzuzeigen oder ein Element zu unterscheiden. Links im Text müssen zusätzlich unterstrichen sein oder einen Kontrast von 3:1 zum umgebenden Text haben.
1.4.2 Audio-Steuerung (Level A)
Wenn Audio automatisch länger als 3 Sekunden abgespielt wird, muss es einen Mechanismus geben, um die Wiedergabe zu stoppen, zu pausieren oder die Lautstärke unabhängig vom System zu regeln.
1.4.3 Kontrast (Minimum) (Level AA)
Text und Bilder von Text müssen ein Kontrastverhältnis von mindestens 4,5:1 haben. Für großen Text (ab 18pt oder 14pt fett) reicht 3:1. Logos und dekorativer Text sind ausgenommen.
Tipp: Nutzen Sie den WebAIM Contrast Checker oder die Browser-DevTools zur Prüfung.
1.4.4 Textgröße ändern (Level AA)
Text muss ohne assistive Technologie auf 200% vergrößert werden können, ohne dass Inhalt oder Funktionalität verloren geht. Verwenden Sie relative Einheiten (rem, em) statt fester Pixelwerte.
1.4.5 Bilder von Text (Level AA)
Text sollte als echter Text dargestellt werden, nicht als Bild. Bilder von Text sind nur erlaubt, wenn sie wesentlich sind (z.B. Logos) oder visuell anpassbar sind.
1.4.10 Umfließen (Reflow) (Level AA)
Inhalte müssen bei einer Breite von 320 CSS-Pixeln ohne horizontales Scrollen dargestellt werden können (entspricht 400% Zoom bei 1280px). Ausnahmen sind Datentabellen, Karten und Diagramme.
1.4.11 Nicht-Text-Kontrast (Level AA)
Bedienelemente (Buttons, Formularfelder, Icons) und grafische Objekte, die für das Verständnis wichtig sind, müssen einen Kontrast von mindestens 3:1 zu angrenzenden Farben haben.
1.4.12 Textabstand (Level AA)
Nutzer müssen folgende Textabstände anpassen können, ohne dass Inhalt oder Funktionalität verloren geht: Zeilenhöhe 1,5-fach, Absatzabstand 2-fach, Buchstabenabstand 0,12-fach, Wortabstand 0,16-fach.
1.4.13 Eingeblendete Inhalte bei Hover oder Fokus (Level AA)
Tooltips und andere eingeblendete Inhalte müssen: abweisbar sein (z.B. mit Escape), überfahrbar sein (Maus kann darüber bewegt werden, ohne dass sie verschwinden) und persistent sein (bleiben sichtbar, bis aktiv geschlossen).
2 Bedienbar (Operable)
Das zweite Prinzip stellt sicher, dass alle interaktiven Elemente von verschiedenen Nutzern mit unterschiedlichen Eingabemethoden bedient werden können. Tastaturnutzer, Menschen mit motorischen Einschränkungen und Nutzer mit Aufmerksamkeitsstörungen profitieren besonders von diesen Kriterien.
2.1 Tastaturbedienbar
2.1.1 Tastatur (Level A)
Alle Funktionen müssen mit der Tastatur bedienbar sein, ohne dass bestimmte Zeitvorgaben für einzelne Tastenanschläge erforderlich sind. Ausnahme: Funktionen, die von der Art der Eingabebewegung abhängen (z.B. Freihandzeichnen).
Tipp: Testen Sie Ihre Website, indem Sie nur mit Tab, Enter und Pfeiltasten navigieren.
2.1.2 Keine Tastaturfalle (Level A)
Der Tastaturfokus darf nicht in einem Element gefangen werden. Nutzer müssen jede Komponente mit der Tastatur wieder verlassen können. Bei modalen Dialogen muss ein Schließen-Button fokussierbar sein.
2.1.4 Tastaturkürzel (Level A)
Wenn Tastaturkürzel mit einzelnen Buchstaben, Zahlen oder Sonderzeichen implementiert sind, muss es möglich sein, diese abzuschalten, neu zu belegen oder sie nur bei Fokus zu aktivieren.
2.2 Ausreichend Zeit
2.2.1 Zeitbegrenzung anpassbar (Level A)
Bei zeitbegrenzten Inhalten muss der Nutzer: die Zeit abschalten können, die Zeit verlängern können (mind. 10-fach) oder vor Ablauf gewarnt werden und mindestens 20 Sekunden Zeit haben, die Zeit mit einer einfachen Aktion zu verlängern.
2.2.2 Pausieren, Stoppen, Ausblenden (Level A)
Automatisch bewegte, blinkende oder scrollende Inhalte, die länger als 5 Sekunden dauern, müssen pausiert, gestoppt oder ausgeblendet werden können. Dies gilt für Slider, Animationen und Auto-Updates.
2.3 Anfälle und körperliche Reaktionen
2.3.1 Dreimaliges Blitzen oder unterhalb des Schwellenwerts (Level A)
Webseiten dürfen keine Elemente enthalten, die mehr als dreimal pro Sekunde blitzen, es sei denn, das Blitzen liegt unterhalb der allgemeinen Schwellenwerte für Blitzen und rotes Blitzen. Dies schützt Menschen mit Epilepsie.
Wichtig
Blitzende Inhalte können bei Menschen mit fotosensitiver Epilepsie Anfälle auslösen. Im Zweifel auf blitzende Elemente verzichten.
2.4 Navigierbar
2.4.1 Blöcke überspringen (Level A)
Es muss einen Mechanismus geben, um wiederkehrende Inhaltsblöcke zu überspringen. Ein Skiplink ("Zum Inhalt springen") am Seitenanfang erfüllt dieses Kriterium.
Praktisches Beispiel:
<a href="#main" class="skip-link">Zum Inhalt springen</a>2.4.2 Seite mit Titel versehen (Level A)
Jede Webseite muss einen beschreibenden, eindeutigen Titel haben. Der Titel sollte den Inhalt der Seite beschreiben und sich von anderen Seiten der Website unterscheiden.
2.4.3 Fokus-Reihenfolge (Level A)
Wenn die Navigationsreihenfolge die Bedeutung oder Bedienung beeinflusst, müssen fokussierbare Komponenten in einer sinnvollen Reihenfolge den Fokus erhalten. Die Tab-Reihenfolge sollte der visuellen Leserichtung folgen.
2.4.4 Linkzweck (im Kontext) (Level A)
Der Zweck jedes Links muss aus dem Linktext allein oder aus dem Linktext zusammen mit seinem programmatisch bestimmbaren Kontext erkennbar sein. "Klicken Sie hier" ist nicht aussagekräftig.
2.4.5 Verschiedene Wege (Level AA)
Es muss mehr als einen Weg geben, um eine Seite innerhalb einer Website zu finden (außer bei Schritt-für-Schritt-Prozessen). Beispiele: Navigation, Sitemap, Suche, Breadcrumbs.
2.4.6 Überschriften und Labels (Level AA)
Überschriften und Labels müssen das Thema oder den Zweck beschreiben. Sie sollten aussagekräftig und eindeutig sein, um Nutzern die Orientierung zu erleichtern.
2.4.7 Fokus sichtbar (Level AA)
Bei Tastaturbedienung muss der aktuelle Fokus immer sichtbar sein. Der Standard-Browser-Fokusring darf nicht entfernt werden, ohne einen gleichwertigen oder besseren Ersatz anzubieten.
Tipp: Verwenden Sie :focus-visible für moderne Fokus-Stile, die nur bei Tastaturnutzung erscheinen.
2.5 Eingabemodalitäten
2.5.1 Zeigergesten (Level A)
Funktionen, die Mehrpunkt- oder pfadbasierte Gesten verwenden (z.B. Pinch-to-Zoom, Wischgesten), müssen auch mit einfachen Zeigereingaben bedienbar sein (einfaches Tippen, Klicken).
2.5.2 Abbruch der Zeigereingabe (Level A)
Funktionen, die über einen einfachen Zeiger bedient werden, müssen mindestens eine der folgenden Bedingungen erfüllen: kein Down-Event, Abbruch oder Rückgängigmachen möglich, Up-Event kehrt vorheriges Down-Event um.
2.5.3 Label im Namen (Level A)
Wenn eine Komponente ein sichtbares Label hat, muss der zugängliche Name (für Screenreader) dieses sichtbare Label enthalten. Sprachsteuerungsnutzer können dann den Button benennen, den sie sehen.
2.5.4 Bewegungsaktivierung (Level A)
Funktionen, die durch Gerätebewegung (Schütteln, Kippen) ausgelöst werden, müssen auch über eine Benutzeroberfläche auslösbar sein und die Bewegungsaktivierung muss abschaltbar sein.
3 Verständlich (Understandable)
Das dritte Prinzip stellt sicher, dass Inhalte und Bedienung verständlich sind. Menschen mit kognitiven Einschränkungen, Lernschwierigkeiten oder mangelnden Sprachkenntnissen profitieren von klarer Sprache, konsistenter Navigation und hilfreichen Fehlermeldungen.
3.1 Lesbar
3.1.1 Sprache der Seite (Level A)
Die Hauptsprache jeder Webseite muss programmatisch bestimmbar sein. Dies erfolgt über das lang-Attribut im html-Element.
Praktisches Beispiel:
<html lang="de">3.1.2 Sprache von Teilen (Level AA)
Die Sprache jedes Textabschnitts oder Satzes, der in einer anderen Sprache als der Hauptsprache verfasst ist, muss programmatisch bestimmbar sein (außer bei Eigennamen, technischen Begriffen oder unbestimmter Sprache).
Praktisches Beispiel:
<p>Das nennt man <span lang="en">responsive design</span>.</p>3.2 Vorhersehbar
3.2.1 Bei Fokus (Level A)
Wenn eine Komponente den Fokus erhält, darf dies keine unerwartete Kontextänderung auslösen (z.B. automatisches Absenden eines Formulars, Öffnen eines neuen Fensters).
3.2.2 Bei Eingabe (Level A)
Das Ändern der Einstellung einer Komponente darf keine automatische Kontextänderung auslösen, es sei denn, der Nutzer wurde vorher informiert. Ein Dropdown-Menü sollte nicht automatisch navigieren.
3.2.3 Konsistente Navigation (Level AA)
Navigationsmechanismen, die auf mehreren Seiten wiederholt werden, müssen in der gleichen relativen Reihenfolge erscheinen, es sei denn, der Nutzer ändert dies. Die Hauptnavigation sollte auf allen Seiten gleich aufgebaut sein.
3.2.4 Konsistente Erkennung (Level AA)
Komponenten mit der gleichen Funktionalität müssen innerhalb einer Website konsistent bezeichnet werden. Ein Suchfeld sollte überall "Suche" oder "Suchen" heißen, nicht mal "Suche" und mal "Finden".
3.3 Eingabeunterstützung
3.3.1 Fehlererkennung (Level A)
Wenn ein Eingabefehler automatisch erkannt wird, muss das fehlerhafte Element identifiziert und der Fehler dem Nutzer in Textform beschrieben werden. Nicht nur rote Umrandung, sondern auch eine Fehlermeldung.
3.3.2 Labels oder Anweisungen (Level A)
Wenn Inhalt eine Benutzereingabe erfordert, werden Labels oder Anweisungen bereitgestellt. Jedes Formularfeld benötigt ein zugeordnetes Label.
Praktisches Beispiel:
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email">3.3.3 Fehlerempfehlung (Level AA)
Wenn ein Eingabefehler erkannt wird und Korrekturvorschläge bekannt sind, müssen diese dem Nutzer bereitgestellt werden (sofern dies die Sicherheit oder den Zweck nicht gefährdet).
Beispiel: "Bitte geben Sie eine gültige E-Mail-Adresse ein (z.B. name@beispiel.de)"
3.3.4 Fehlervermeidung (rechtlich, finanziell, Daten) (Level AA)
Bei Seiten mit rechtlichen, finanziellen oder datenrelevanten Konsequenzen muss mindestens eines zutreffen: Eingaben sind reversibel, Eingaben werden auf Fehler geprüft und können korrigiert werden, oder ein Mechanismus zur Überprüfung und Bestätigung ist vorhanden.
4 Robust
Das vierte Prinzip stellt sicher, dass Inhalte robust genug sind, um von einer Vielzahl von Benutzeragenten, einschließlich assistiver Technologien, zuverlässig interpretiert zu werden. Sauberer, valider Code ist die Grundlage.
4.1 Kompatibel
4.1.1 Syntaxanalyse (Level A) - Veraltet in WCAG 2.2
Dieses Kriterium wurde in WCAG 2.2 als veraltet markiert, da moderne Browser HTML-Fehler automatisch korrigieren. Dennoch ist valides HTML weiterhin Best Practice für Zugänglichkeit und Wartbarkeit.
4.1.2 Name, Rolle, Wert (Level A)
Für alle Benutzeroberflächenkomponenten müssen Name, Rolle und Zustand programmatisch bestimmbar sein. Bei benutzerdefinierten Komponenten müssen ARIA-Attribute korrekt verwendet werden.
Praktisches Beispiel:
<button aria-expanded="false" aria-controls="menu">
Menü öffnen
</button>4.1.3 Statusmeldungen (Level AA)
Statusmeldungen (z.B. "Artikel wurde zum Warenkorb hinzugefügt", "Fehler beim Laden") müssen programmatisch so präsentiert werden, dass assistive Technologien sie ohne Fokuswechsel wahrnehmen können.
Praktisches Beispiel:
<div role="status" aria-live="polite">
Artikel wurde zum Warenkorb hinzugefügt.
</div>Häufige Fragen zu WCAG in Deutschland
Ist WCAG 2.1 in Deutschland gesetzlich verpflichtend?
Ja, für bestimmte Bereiche. Öffentliche Stellen des Bundes und der Länder sind seit 2019 bzw. 2020 durch die EU-Richtlinie 2016/2102 und deren nationale Umsetzung verpflichtet, ihre Websites und Apps nach WCAG 2.1 AA barrierefrei zu gestalten. Ab dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) auch für private Unternehmen, die bestimmte Produkte und Dienstleistungen anbieten, darunter E-Commerce-Websites und Online-Banking. Das BFSG verweist auf die europäische Norm EN 301 549, die WCAG 2.1 Level AA als technischen Standard referenziert.
Was ist der Unterschied zwischen WCAG 2.0, 2.1 und 2.2?
WCAG 2.0 (2008) legte die Grundlage mit 61 Erfolgskriterien. WCAG 2.1 (2018) erweiterte diese um 17 neue Kriterien, die insbesondere mobile Nutzung und Menschen mit kognitiven oder Sehbeeinträchtigungen besser berücksichtigen. WCAG 2.2 (2023) fügte weitere 9 Kriterien hinzu, hauptsächlich für Menschen mit kognitiven Einschränkungen. In Deutschland und der EU ist aktuell WCAG 2.1 Level AA der rechtliche Standard. Die Einhaltung von WCAG 2.1 bedeutet automatisch auch Konformität mit WCAG 2.0, da alle älteren Kriterien enthalten sind.
Welche Tools helfen bei der WCAG-Prüfung?
Es gibt zahlreiche Tools zur Unterstützung, aber keines kann alle Kriterien automatisch prüfen. Empfehlenswerte Tools sind:
- WAVE (Browser-Extension) - Visuelle Fehleranzeige direkt auf der Seite
- axe DevTools (Browser-Extension) - Detaillierte technische Prüfung
- Lighthouse (in Chrome integriert) - Schnelle Accessibility-Audits
- WebAIM Contrast Checker - Prüfung von Farbkontrasten
- NVDA/VoiceOver - Kostenlose Screenreader zum manuellen Testen
Automatisierte Tests decken etwa 30-40% der möglichen Barrieren auf. Manuelle Tests mit Tastaturnavigation und Screenreadern sind unverzichtbar.
Muss meine Website zu 100% konform sein?
Für eine formale WCAG-Konformität müssen alle anwendbaren Erfolgskriterien der gewählten Stufe (A, AA oder AAA) erfüllt sein. In der Praxis streben die meisten Organisationen Level AA an, da Level AAA für viele Inhaltstypen nicht vollständig erreichbar ist. Wichtig ist ein kontinuierlicher Verbesserungsprozess: Priorisieren Sie kritische Barrieren (z.B. Tastaturzugänglichkeit, Kontraste, Alternativtexte) und arbeiten Sie systematisch an der Beseitigung. Eine Barrierefreiheitserklärung dokumentiert den aktuellen Stand und den Feedback-Mechanismus für Nutzer.