Die Web Content Accessibility Guidelines (WCAG) sind der internationale Standard für barrierefreie Webinhalte, herausgegeben vom World Wide Web Consortium (W3C) im Rahmen der Web Accessibility Initiative (WAI). Sie beschreiben in prüfbaren Erfolgskriterien, wann eine Website für Menschen mit Behinderungen nutzbar ist. In Europa sind sie über die Norm EN 301 549 der technische Maßstab, an dem sich Gesetze zur digitalen Barrierefreiheit orientieren.
Anders als viele Normen sind die WCAG kein Katalog von Design-Vorschriften. Sie schreiben keine Schriftgröße, keine Farbe und keinen Seitenaufbau vor. Sie definieren Ergebnisse: dass Inhalte wahrnehmbar sein müssen, dass sich alles bedienen lassen muss, dass Sprache und Verhalten verständlich sein müssen und dass die Umsetzung mit assistiven Technologien funktioniert. Wie man dorthin kommt, bleibt eine Frage der Umsetzung.
Die vier Prinzipien: POUR
Die gesamte Struktur der WCAG ruht auf vier Prinzipien, die unter dem Akronym POUR zusammengefasst werden – perceivable, operable, understandable, robust. Jedes Prinzip zerfällt in Richtlinien, jede Richtlinie in einzelne, testbare Erfolgskriterien. Wer die vier Prinzipien verstanden hat, kann fast jeden Barrierefreiheitsdefekt einordnen, auch ohne die Nummer des Kriteriums zu kennen.
Wahrnehmbar und bedienbar
Wahrnehmbar (perceivable) heißt: Jede Information muss über mindestens einen Sinneskanal ankommen, der dem Nutzer zur Verfügung steht. Ein Produktbild braucht eine Textalternative, ein Video Untertitel, eine Statusmeldung eine Form, die auch ohne Farbe funktioniert. Hierher gehören auch die Kontrastanforderungen: Text muss sich ausreichend vom Hintergrund abheben. Für die Prüfung einzelner Farbpaare eignet sich der Contrast Checker von WebAIM, der Vorder- und Hintergrundfarbe direkt gegen die WCAG-Schwellen rechnet.
Bedienbar (operable) heißt: Alle Funktionen müssen erreichbar sein, unabhängig vom Eingabegerät. Der wichtigste Testfall ist die Tastatur. Wer die Maus weglegt und sich ausschließlich mit Tab, Shift-Tab, Enter und den Pfeiltasten durch eine Seite bewegt, findet innerhalb weniger Minuten die meisten schweren Defekte: Elemente, die keinen Fokus bekommen, Fokusreihenfolgen, die durch das Layout springen, Overlays, aus denen man nicht mehr herauskommt. Dazu kommen Anforderungen an ausreichend Zeit, an den Verzicht auf Inhalte, die Anfälle auslösen können, und an nachvollziehbare Navigation.
Verständlich und robust
Verständlich (understandable) betrifft Sprache und Verhalten. Die Sprache der Seite muss technisch ausgezeichnet sein, damit Screenreader korrekt vorlesen. Bedienelemente müssen sich vorhersehbar verhalten – ein Auswahlfeld, das beim Ändern ungefragt die Seite neu lädt, verstößt gegen dieses Prinzip. Und Eingabefehler müssen benannt und, wo möglich, mit einem Korrekturvorschlag versehen werden. Gerade der letzte Punkt entscheidet in Formularen und Checkouts darüber, ob eine Bestellung zustande kommt.
Robust heißt: Der Code muss so beschaffen sein, dass aktuelle und künftige Hilfsmittel ihn interpretieren können. Praktisch bedeutet das valides, semantisch korrektes HTML und – wo native Elemente nicht ausreichen – korrekt eingesetzte ARIA-Attribute. Ein div mit Klick-Handler ist für einen Screenreader kein Button. Ein echtes <button> ist es, ohne Zusatzaufwand. Der überwiegende Teil der Robustheitsprobleme in der Praxis entsteht dadurch, dass native Elemente durch selbstgebaute ersetzt wurden.
Nützlich an dieser Aufteilung ist, dass sie sich auf reale Nutzungssituationen abbilden lässt. Hinter „wahrnehmbar" stehen unter anderem blinde und sehbehinderte Menschen sowie alle, die farbfehlsichtig sind. Hinter „bedienbar" stehen Menschen mit motorischen Einschränkungen, die keine Maus verwenden – aber auch jeder, der gerade nur eine Hand frei hat. Hinter „verständlich" stehen kognitive Einschränkungen, Lernschwierigkeiten und Nutzer, die die Seitensprache nicht als Muttersprache lesen. Und hinter „robust" steht schlicht die Frage, ob die eingesetzte Technik mit den Hilfsmitteln zusammenarbeitet, die tatsächlich im Einsatz sind. Wer einen Defekt einem Prinzip zuordnen kann, weiß meist auch schon, wen er betrifft und wie dringend er ist.
Konformitätsstufen A, AA und AAA
Die WCAG kennen drei Konformitätsstufen. Sie sind keine Qualitätsnoten, sondern Bündel von Erfolgskriterien mit unterschiedlicher Eingriffstiefe.
| Stufe | Bedeutung | Praktische Rolle |
|---|---|---|
| A | Mindestanforderungen | Ohne diese Stufe sind Inhalte für Teile der Nutzerschaft gar nicht zugänglich |
| AA | Erweiterte Anforderungen | Der übliche gesetzliche und vertragliche Maßstab |
| AAA | Höchste Stufe | Für ganze Websites oft nicht vollständig erreichbar; das W3C empfiehlt sie nicht als generelles Ziel |
Warum AA der praktische Maßstab ist
Wenn in Ausschreibungen, Gesetzen oder Verträgen von WCAG-Konformität die Rede ist, ist praktisch immer Level AA gemeint. Das hat einen sachlichen Grund: Stufe A allein lässt Lücken, die für viele Nutzer den Unterschied zwischen mühsam und unmöglich ausmachen – die verschärften Kontrastwerte etwa gehören erst zu AA. Stufe AAA wiederum enthält Kriterien, die sich nicht für jeden Inhaltstyp sinnvoll erfüllen lassen; das W3C selbst rät davon ab, AAA als flächendeckende Anforderung zu setzen.
Die Stufen sind kumulativ: AA schließt A ein, AAA schließt A und AA ein. Eine Aussage wie „wir erfüllen AA in den wichtigsten Bereichen" ist deshalb keine Konformitätsaussage. Konformität gilt immer für eine vollständige Seite – eine Seite, auf der ein einziges Erfolgskriterium verletzt ist, ist nicht konform, egal wie gut der Rest umgesetzt wurde. Das klingt streng, ist aber der Grund, warum die Angabe überhaupt Aussagekraft hat.
Versionen: 2.0, 2.1, 2.2 – und der Blick auf 3.0
Die WCAG entwickeln sich in klar abgegrenzten Versionen, die aufeinander aufbauen. Jede neue 2.x-Version übernimmt sämtliche Erfolgskriterien der Vorgängerversion und ergänzt weitere. Wer WCAG 2.2 AA erfüllt, erfüllt damit automatisch auch 2.1 AA und 2.0 AA.
- WCAG 2.0 (2008) – die Grundlage, bis heute vollständig in allen Folgeversionen enthalten.
- WCAG 2.1 (2018) – Ergänzungen vor allem für mobile Nutzung, Sehbehinderungen und kognitive Einschränkungen.
- WCAG 2.2 (2023) – neun zusätzliche Erfolgskriterien, unter anderem zu Fokussichtbarkeit, Zielgrößen von Bedienelementen und zugänglicher Authentifizierung.
- WCAG 3.0 – in Arbeit, mit grundlegend anderem Bewertungsmodell. Ein Termin für die Fertigstellung steht nicht fest.
Was das für die Planung heißt
WCAG 3.0 wird gelegentlich als Argument benutzt, um Projekte zu vertagen – nach dem Muster: Warum jetzt investieren, wenn ohnehin bald alles anders wird? Das Argument trägt nicht. Es gibt keinen Termin, der Entwurf steckt in einem frühen Stadium, und die Übergangsfristen wären nach einer Veröffentlichung erheblich. Wer heute plant, plant auf 2.1 als verbindlichem Minimum und legt 2.2 als Zielbild darüber. Die Differenz zwischen beiden ist überschaubar, und sie neu zu bauen ist deutlich billiger, als sie später nachzurüsten.
Den offiziellen Stand aller Versionen samt Übersicht der Dokumente pflegt das W3C auf seiner WCAG-Übersichtsseite der Web Accessibility Initiative. Sie ist die einzige Quelle, die für Versionsfragen zitierfähig ist – Sekundärquellen hinken bei Normänderungen regelmäßig hinterher.
WCAG prüfen: Was Tools können und was nicht
Die häufigste Fehleinschätzung in Barrierefreiheitsprojekten betrifft die Prüfung. Ein automatisierter Scan liefert eine Zahl, die Zahl sieht nach Wahrheit aus, und das Projekt gilt als erledigt. Tatsächlich deckt Automatisierung nur einen Teil der Erfolgskriterien ab.
Grenzen der Automatisierung
Ein Testwerkzeug kann zuverlässig feststellen, ob ein alt-Attribut fehlt. Ob der vorhandene Alternativtext den Bildinhalt sinnvoll beschreibt, kann es nicht beurteilen – „bild_4711.jpg" besteht den automatischen Test und ist trotzdem wertlos. Ähnlich verhält es sich mit Fokusreihenfolge, Verständlichkeit von Fehlermeldungen, sinnvoller Überschriftenhierarchie und der Frage, ob eine ARIA-Rolle zum tatsächlichen Verhalten passt. Wie groß der maschinell prüfbare Anteil ist, hat Deque in einem Report zur Abdeckung automatisierter Accessibility-Tests untersucht.
Daraus folgt kein Argument gegen Tools, sondern eines für die richtige Reihenfolge. Automatisierte Prüfung eignet sich hervorragend als Regressionsschutz in der Pipeline: Sie fängt die mechanischen Fehler ab, bevor sie live gehen, und zwar bei jedem Deploy. Die inhaltlichen Kriterien bleiben Handarbeit – dafür aber Handarbeit, die man nicht ständig wiederholen muss.
Praxisbeispiel: derselbe Checkout, drei Prüfebenen
Ein Beispiel aus einem Shop-Checkout macht das greifbar. Der automatisierte Scan meldet zwei Befunde: ein Eingabefeld ohne verknüpftes Label und einen Kontrastwert von 3,1:1 bei der Zusammenfassung der Versandkosten. Beides ist in einer halben Stunde behoben.
Die manuelle Tastaturprüfung derselben Strecke findet danach drei weitere Probleme, die kein Scan gemeldet hatte: Der Zahlungsarten-Dialog öffnet sich, ohne den Fokus mitzunehmen, sodass die Tastatur weiter im Hintergrund navigiert. Der Schließen-Button des Dialogs ist per Tab nicht erreichbar. Und die Reihenfolge der Felder springt zwischen den Spalten des zweispaltigen Layouts hin und her, weil die visuelle Anordnung per CSS von der DOM-Reihenfolge abweicht.
Der abschließende Durchgang mit einem Screenreader findet ein viertes: Die Fehlermeldung „Bitte prüfe deine Eingaben" wird zwar angezeigt, aber nicht als Live-Region ausgezeichnet und deshalb nicht angesagt. Der Nutzer bemerkt sie nur, wenn er zufällig dorthin navigiert. Kein einziges dieser vier Probleme wäre ohne manuelle Prüfung aufgefallen – und jedes einzelne verhindert im Zweifel eine Bestellung.
WCAG und die Rechtslage in Deutschland
Die WCAG sind kein Gesetz. Sie werden erst dadurch verbindlich, dass Gesetze auf sie verweisen. In Deutschland läuft dieser Verweis für den privatwirtschaftlichen Bereich über das BFSG (Barrierefreiheitsstärkungsgesetz), das seit dem 28. Juni 2025 gilt und den European Accessibility Act umsetzt. Der technische Maßstab dort ist WCAG 2.1 Level AA, eingebettet in die harmonisierte europäische Norm EN 301 549.
Diese Konstruktion erklärt, warum Versionsfragen rechtlich relevant sind: Maßgeblich ist nicht die jeweils neueste WCAG-Fassung, sondern diejenige, auf die die harmonisierte Norm verweist. Wer wissen will, wer konkret betroffen ist, welche Ausnahmen gelten und welche Sanktionen drohen, findet die Antworten im BFSG-Eintrag – dieser Eintrag hier beschreibt den technischen Standard selbst.
Warum sich der Aufwand über Compliance hinaus lohnt
Zum Schluss ein Punkt, der in der Pflichtdiskussion fast immer untergeht. Die WCAG sind im Kern gute Frontend-Praxis in normierter Form. Semantisch korrektes HTML, klare Fokuszustände, ausreichende Kontraste, verständliche Fehlermeldungen, sinnvolle Überschriftenstruktur – das ist keine Sonderausstattung für eine Minderheit, sondern die Grundlage einer Oberfläche, die generell funktioniert.
Dieselbe Struktur, die einen Screenreader in die Lage versetzt, eine Seite vorzulesen, hilft Suchmaschinen und KI-Systemen beim Verstehen der Inhalte. Größere Klickflächen helfen jedem, der unterwegs mit einer Hand bestellt. Und ein Checkout, der ohne Maus funktioniert, funktioniert erfahrungsgemäß auch mit Maus reibungsloser. Der Aufwand fließt nicht in eine Parallelversion für Spezialfälle, sondern in dieselbe Oberfläche, die alle nutzen.