Was WCAG 2.1 wirklich bedeutet und warum du sie brauchst
Die Web Content Accessibility Guidelines (WCAG) 2.1 sind nicht einfach nur technische Empfehlungen – sie sind der internationale Standard für digitale Barrierefreiheit. Entwickelt vom World Wide Web Consortium (W3C), legen sie fest, wie Websites und Webanwendungen gestaltet sein müssen, damit wirklich alle Menschen sie nutzen können.
Was viele nicht wissen: Die WCAG 2.1 sind explizit so formuliert, dass jedes einzelne Erfolgskriterium testbar ist. Das heißt, du kannst für jeden Punkt eindeutig feststellen, ob deine Website ihn erfüllt oder nicht. Entweder ja oder nein.
Die Richtlinien basieren auf vier Grundprinzipien: Wahrnehmbar, bedienbar, verständlich und robust. Inhalte müssen so präsentiert werden, dass Nutzer sie wahrnehmen können (visuell, auditiv oder taktil). Die Navigation muss bedienbar sein (Tastatur, Maus, Touch, Sprachsteuerung). Informationen müssen verständlich sein. Und alles muss robust genug sein, damit assistive Technologien wie Screenreader damit klarkommen.
In Deutschland verweist die BITV 2.0 direkt auf WCAG 2.1 Level AA. Öffentliche Stellen müssen ihre Webseiten und Apps barrierefrei gestalten. Das Barrierefreiheitsstärkungsgesetz (BFSG) erweitert ab 2025 den Kreis der verpflichteten Anbieter, besonders im E‑Commerce. Die EN 301 549 ist die europäische Norm, die praktisch WCAG 2.1 AA als Standard festschreibt.
WCAG sind technologieneutral formuliert: Sie sagen nicht wie etwas umgesetzt werden soll, sondern was erreicht werden muss. Konkrete Techniken und Code-Beispiele findest du in separaten Dokumenten – das macht die Richtlinien zukunftssicher.
Die drei Konformitätsstufen: A, AA und AAA erklärt
Level A
Level A bildet die absolute Basis. Diese Kriterien sind das Minimum, ohne das Menschen mit Behinderungen grundlegende Barrieren erleben würden. Beispiele: Alternativtexte für Bilder, Tastaturzugänglichkeit für alle Funktionen, oder dass Videos nicht automatisch mit Ton starten. Wenn du Level A nicht erfüllst, ist deine Website für viele Menschen praktisch unbenutzbar.
Level AA
Level AA ist der Sweet Spot – und genau die Stufe, die gesetzlich relevant ist. AA umfasst zusätzliche Anforderungen, die für eine wirklich gute Accessibility notwendig sind: ausreichende Farbkontraste (mindestens 4,5:1 für normalen Text), Textvergrößerung bis 200% ohne Funktionsverlust, aussagekräftige Fehlermeldungen bei Formularen und weitere praktische Aspekte. Für BITV-Konformität musst du AA erreichen.
Level AAA
Level AAA ist die Königsklasse: erhöhte Kontraste von 7:1, Gebärdensprache-Videos für Audioinhalte oder kontextsensitive Hilfen. AAA ist nicht für alle Inhalte umsetzbar und wird deshalb nicht flächendeckend gefordert, kann aber in spezialisierten Angeboten sinnvoll sein.
Wichtig: Um AA zu erreichen, musst du automatisch auch alle Level A Kriterien erfüllen. Die Stufen bauen aufeinander auf.
So testest du WCAG 2.1: Methoden und Werkzeuge in der Praxis
Ein vollständiger WCAG 2.1 Test kombiniert mehrere Methoden. Automatisierte Tools sind der erste Schritt. Werkzeuge wie Axe, WAVE, Lighthouse oder Siteimprove scannen HTML und finden technische Probleme (fehlende Alt-Texte, unzureichende Kontraste, falsche Überschriften-Hierarchien, ARIA-Fehler). Ich nutze gerne die Axe DevTools Browser-Extension – sie zeigt direkt im Browser, wo Probleme sind.
Automatisierte Tools finden aber nur etwa 30–40% aller Probleme. Viele Kriterien lassen sich nicht automatisch prüfen: Ob ein Alternativtext wirklich beschreibt, was relevant ist, kann Software nicht beurteilen. Deshalb sind manuelle Tests unverzichtbar:
- Tastaturnavigation: Bedien die Seite nur mit Tab, Enter, Pfeiltasten und Space
- Screenreader-Test: NVDA (Windows), JAWS oder VoiceOver (Mac/iOS) nutzen
- Zoom-Test: 200% Vergrößerung prüfen
- Farbkontrast-Prüfung: Tools wie Colour Contrast Analyser oder WebAIM Contrast Checker
In Deutschland ist der BIK BITV-Test etabliert: ein standardisiertes Vorgehen mit 98 Prüfschritten, das EN 301 549 und WCAG 2.1 AA abdeckt. Du wählst eine repräsentative Seitenauswahl und prüfst diese systematisch. Am Ende steht ein detaillierter Prüfbericht mit Bewertung und Verbesserungsvorschlägen.
Bind auch echte Nutzer mit Behinderungen ein – sie finden häufig Probleme, die automatisierte Tests nicht erfassen.
WCAG Kriterium 2.1: Tastaturzugänglichkeit im Detail
Kriterium 2.1 zur Tastaturzugänglichkeit ist fundamental. Viele Menschen sind auf Tastaturzugriff angewiesen: Blinde und sehbehinderte Nutzer mit Screenreadern, Menschen mit motorischen Einschränkungen und Power-User.
2.1.1 Tastatur (Level A)
Alle Funktionen müssen komplett mit der Tastatur bedienbar sein. Links, Buttons, Formularfelder, Dropdowns und modale Dialoge – alles muss ohne Maus erreichbar und nutzbar sein. Test: Maus weg und die Seite komplett mit Tab, Enter, Space und Pfeiltasten bedienen.
2.1.2 Keine Tastaturfalle (Level A)
Wenn der Fokus auf ein Element gelangt, muss er auch wieder wegkommen. Manche Widgets fangen den Fokus ein und geben ihn nicht frei – das sind Tastaturfallen. Test: Tabulator-Navigation vorwärts und rückwärts (Tab und Shift+Tab) durch die komplette Seite.
2.1.4 Tastaturkürzel mit einzelnen Zeichen (Level A)
Neu in WCAG 2.1: Single-Key-Shortcuts (z. B. 'S' für Suche) müssen abschaltbar, umlegbar oder nur aktiv bei Fokus sein. Sonst können sie ungewollt Aktionen auslösen (z. B. bei Sprachsteuerung) und Datenverlust verursachen. Test: Existieren Shortcuts? Sind sie dokumentiert und abschaltbar?
Seitenauswahl und Prüfschritte: So strukturierst du deinen Test
Ein häufiger Fehler: Nur die Startseite prüfen. Stattdessen brauchst du eine repräsentative Seitenauswahl, die alle Inhaltstypen und Funktionen abdeckt. Der BIK BITV-Test empfiehlt:
- Startseite
- Navigationsseitige Seiten (Sitemaps, Übersichtsseiten)
- Inhaltsseiten verschiedener Typen (Artikel, Produktseiten, Veranstaltungskalender)
- Formulare (Kontakt, Suche, Registrierung, Bestellprozess)
- Interaktive Elemente (Galerien, Videos, Karten, Tabellen)
- Fehlermeldungen und Erfolgsmeldungen
- Barrierefreiheitserklärung und Feedback-Mechanismus
Je nach Website sind typischerweise 8–12 Seiten zu prüfen. Die 98 Prüfschritte des BIK BITV-Tests beinhalten klare Fragestellungen, Prüfabläufe und Bewertungsoptionen (erfüllt / eher erfüllt / eher nicht / nicht erfüllt / nicht anwendbar).
Dokumentation ist entscheidend: Prüfbericht mit Version, Prüfdatum, ausgewählten Seiten, Ergebnissen pro Prüfschritt, Screenshots, Gesamtbewertung und priorisierten Empfehlungen.
Häufige Probleme beim Test und wie du sie löst
Unvollständige oder falsche Alt-Texte
Bilder haben oft keinen oder nutzlosen Alt-Text ("bild_final_v2.jpg"). Automatisierte Tools erkennen fehlende Alt-Attribute, aber nicht die Qualität des Textes.
Lösung: Jedes Bild braucht einen passenden Alternativtext, der den Informationsgehalt wiedergibt. Dekorative Bilder bekommen alt="". Komplexe Grafiken benötigen zusätzliche Beschreibungen im Text oder via longdesc.
Tastaturfallen und fehlender Fokus
Custom Dropdowns, Modals und Slider sind oft nicht tastaturfreundlich oder der Fokus-Indikator ist unsichtbar.
Lösung: Sichtbare Fokus-Zustände, Fokusmanagement bei Modals (Fokus ins Modal on open, zurück on close) und korrekte ARIA-Attribute sowie Tastaturnavigation implementieren.
Zu geringe Farbkontraste
Grauer Text auf weißem Grund oder weiße Texte auf bunten Hintergründen erreichen oft nicht 4,5:1 (normaler Text).
Lösung: WebAIM Contrast Checker oder Colour Contrast Analyser nutzen. Oft reicht schon ein dunklerer Grauton oder eine halbtransparente Overlay-Ebene.
Fehlende oder unlogische Überschriftenstruktur
Überschriften werden oft für Optik statt Struktur verwendet (h1 → h3 springen).
Lösung: Hierarchisch korrekt verwenden (h1 → h2 → h3), genau eine h1 pro Seite, Layout mit CSS regeln.
Formulare ohne Labels oder unklare Fehlermeldungen
Inputs ohne richtig verknüpftes <label> und Fehlermeldungen, die nur "Fehler" sagen.
Lösung: Jedes Feld braucht ein korrekt verknüpftes <label>; Fehlermeldungen müssen konkret sein und idealerweise mit aria-describedby verbunden werden.
Videos ohne Untertitel oder Transkripte
Multimedia ist oft unzugänglich für gehörlose oder hörgeschädigte Nutzer.
Lösung: Untertitel für alle Videos, Audiodeskriptionen für blinde Nutzer und Transkripte für Audio-Only-Inhalte. Bei eingebetteten Videos können automatische Untertitel (z. B. YouTube) eine Basis sein, die manuell korrigiert werden sollte.
BITV, BIK und EN 301 549: Der deutsche und europäische Kontext
In Deutschland und Europa ist Barrierefreiheit zunehmend gesetzlich vorgeschrieben. Die BITV 2.0 regelt seit 2011, dass öffentliche Stellen des Bundes ihre Websites und Apps barrierefrei gestalten müssen. Die BITV basiert auf WCAG 2.1 Level AA.
Die EN 301 549 ist die europäische Norm und verweist in den Web-Teilen komplett auf WCAG 2.1. Mit einer WCAG 2.1 AA konformen Website erfüllst du praktisch auch EN 301 549 für Web-Inhalte.
Der BIK BITV-Test ist das führende Testverfahren in Deutschland mit 98 Prüfschritten und praxisorientierten Anleitungen, die auch für Nicht-Techniker anwendbar sind.
Die EU Web Accessibility Directive (2016) und ihre Umsetzung verpflichten öffentliche Stellen zur Barrierefreiheit. Das BFSG (Barrierefreiheitsstärkungsgesetz) setzt den European Accessibility Act (EAA) um: Ab Juni 2025 müssen viele private Unternehmen bestimmte Produkte und Dienstleistungen barrierefrei anbieten (z. B. E-Commerce, Bankdienstleistungen, E-Books).
Von der Prüfung zur Umsetzung: Nächste Schritte nach dem Test
Nach dem Test folgt ein strukturierter Umsetzungsprozess:
Schritt 1: Priorisierung
Sortiere Probleme nach Kritikalität: kritisch (Blocker), hoch, mittel, niedrig. Fokus auf Blocker und High-Priority-Issues zuerst.
Schritt 2: Verantwortlichkeiten klären
Barrierefreiheit ist ein Teamthema: Entwickler, Designer, Content-Ersteller und QA sollten konkrete Aufgaben und Zieldaten erhalten.
Schritt 3: Quick Wins umsetzen
Schnelle Erfolge: Alt-Texte ergänzen, Kontraste anpassen, Focus-Styles hinzufügen, Labels verknüpfen.
Schritt 4: Strukturelle Änderungen planen
Aufwändigere Arbeiten (Custom-Komponenten, Navigation umbauen, CMS-Prozesse anpassen) in Sprints einplanen.
Schritt 5: Prozesse etablieren
Etabliere Checklisten, Accessibility-Reviews im Entwicklungsprozess, regelmäßige Tests und Team-Schulungen.
Schritt 6: Barrierefreiheitserklärung veröffentlichen
Die Erklärung muss Konformitätsstatus, bekannte Einschränkungen, Feedback-Mechanismus und Links zu Durchsetzungsstellen enthalten. Nutze das EU-Muster als Vorlage.
Schritt 7: Kontinuierliche Verbesserung
Sammle Nutzerfeedback, reagiere zeitnah und baue ein barrierefreies Design System mit Komponentenbibliothek und Linting-Tools (z. B. eslint-plugin-jsx-a11y, axe-linter).
