WCAG erklärt: Der Standard hinter digitaler Barrierefreiheit

Auf meiner Website und hier im Blog verweise ich ständig auf die WCAG, meist mit einer gewissen Selbstverständlichkeit. Schon im Beitrag zu den vier Grundprinzipien digitaler Barrierefreiheit ging es um sie, denn die WCAG bauen auf genau diesen Prinzipien auf. Was eigentlich dahintersteckt, habe ich bisher aber nie richtig erklärt. Das hole ich jetzt nach.

Und zwar so, dass nicht nur Entwicklerinnen und Entwickler etwas davon haben. Die WCAG betreffen alle, die Inhalte ins Netz bringen: das Design, die Redaktion, das Social-Media-Team. Wer weiß, was drinsteht, trifft bessere Entscheidungen, lange bevor jemand Code schreibt.

Wer hinter den WCAG steht

Herausgegeben werden die WCAG vom World Wide Web Consortium, kurz W3C. Gegründet hat es Tim Berners-Lee 1994, also der Mann, der das World Wide Web erfunden hat. Bis heute legt das W3C fest, wie das Web technisch funktioniert: HTML und CSS, die Grundbausteine jeder Website, sind W3C-Standards.

Innerhalb des W3C kümmert sich seit 1997 die Web Accessibility Initiative (WAI) (öffnet in neuem Tab) um Barrierefreiheit. Sie entwickelt Standards, Richtlinien und Empfehlungen, die das Web für Menschen mit Behinderung zugänglich machen sollen, und stellt Materialien bereit, die beim Verstehen und Umsetzen helfen. Die WCAG sind davon die bekanntesten, aber nicht die einzigen. Es gibt zum Beispiel auch Richtlinien für Redaktionssysteme und andere Werkzeuge, mit denen Inhalte erstellt werden (ATAG), und für Browser (UAAG).

Wichtig für später: Das W3C ist weder Behörde noch Gesetzgeber. Die WCAG sind deshalb zunächst eine Empfehlung, im W3C-Sprech eine „Recommendation“. Warum sie trotzdem in Gesetzen landen, kommt weiter unten.

Was in den WCAG steht

Kurz gesagt beschreiben die WCAG, was digitale Inhalte leisten müssen, damit Menschen sie nutzen können. Egal, ob sie gut sehen, hören, eine Maus führen oder lange Texte verarbeiten können. Dabei schreiben sie weder eine bestimmte Technik noch ein Design vor. Da steht nicht „Der Button muss blau sein“, sondern: Wer den Button nicht sieht, muss trotzdem erfahren, dass er da ist und was er tut.

Mit digitalen Inhalten ist dabei mehr gemeint als die Website an sich. Geschrieben sind die WCAG zwar für Webinhalte, also Texte, Bilder, Videos und Bedienelemente auf Webseiten und in Web-Anwendungen. Laut W3C lassen sie sich aber auch auf Dokumente wie PDFs, auf Software und auf Apps übertragen. Und die Gedanken dahinter gelten genauso für jede Grafik und jedes Video, das auf Instagram, LinkedIn oder sonst wo landet.

Ein paar Beispiele machen das greifbarer.

Bilder brauchen eine Textalternative. Blinde Menschen nutzen häufig einen Screenreader. Das ist eine Software, die Bildschirminhalte vorliest oder über eine Braillezeile in Blindenschrift ausgibt. Ein Foto ohne Alternativtext ist für Screenreader-Nutzende bestenfalls „Bild“, schlimmstenfalls ein kryptischer Dateiname.

Videos brauchen Untertitel. Für gehörlose und schwerhörige Menschen sind sie oft die einzige Möglichkeit, gesprochene Inhalte mitzubekommen. Nebenbei helfen sie allen, die im Zug ohne Ton schauen.

Alles muss sich per Tastatur bedienen lassen. Viele Menschen können keine Maus benutzen, etwa wegen einer motorischen Einschränkung. Sie steuern mit der Tastatur oder mit Hilfsmitteln, die sich wie eine Tastatur verhalten. Ohne funktionierende Tastaturnavigation kommen sie nicht weiter.

Text muss sich vom Hintergrund abheben, und Farbe darf nicht die einzige Information sein. Ein rot umrandetes Feld als einziger Hinweis auf einen Fehler funktioniert für viele farbfehlsichtige Menschen schlicht nicht. Ich weiß, wovon ich rede.

Inhalte müssen verständlich sein. Klare Sprache, eine nachvollziehbare Navigation und Fehlermeldungen, die sagen, was schiefgelaufen ist und wie man es behebt.

Hilfsmittel wie Screenreader, Braillezeile, Bildschirmlupe oder Sprachsteuerung fasst man übrigens unter dem Begriff assistive Technologien zusammen. Der Begriff taucht in der Barrierefreiheit ständig auf.

Für ein Social-Media-Team oder eine Redaktion heißt das ganz praktisch: Alternativtexte für Bilder pflegen, Videos untertiteln, Text in Grafiken kontrastreich setzen und Informationen nicht allein über Farbe transportieren. Die Verantwortung teilt sich dabei. Die Plattform muss es möglich machen, einen Alternativtext zu hinterlegen oder Untertitel einzubinden. Ausfüllen muss ihn, wer postet.

So sind die WCAG aufgebaut

Die WCAG sind in Ebenen gegliedert, von allgemein nach konkret. Ganz oben stehen die vier Grundprinzipien Wahrnehmbar, Bedienbar, Verständlich und Robust. Darunter folgen 13 Richtlinien, die die Prinzipien in Themen aufteilen, etwa Textalternativen, Tastaturbedienbarkeit oder Lesbarkeit. Prüfbar wird es erst auf der nächsten Ebene: In den WCAG 2.2 gibt es 86 Erfolgskriterien. Jedes beschreibt eine Anforderung so, dass man am Ende sagen kann: erfüllt oder nicht erfüllt. Prüfbar heißt allerdings nicht, dass ein Tool das erledigen kann: Automatisierte Tests finden nur einen Teil der Probleme, vieles lässt sich nur von Menschen beurteilen.

Die Nummern, die in Audits und Prüfberichten auftauchen, folgen genau dieser Ordnung:

Wer in einem Prüfbericht „1.4.3 nicht erfüllt“ liest, weiß damit: Prinzip Wahrnehmbar, Richtlinie 1.4 Unterscheidbar, Erfolgskriterium 1.4.3 Kontrast (Minimum).

Konformitätsstufen: A, AA und AAA

Jedes Erfolgskriterium ist einer von drei Konformitätsstufen zugeordnet. A umfasst die grundlegenden Anforderungen. Wer sie nicht erfüllt, schließt bestimmte Gruppen oft komplett aus. AA baut darauf auf und ist die Stufe, die in der Praxis zählt: Die europäische Norm EN 301 549, auf die sich das Barrierefreiheitsstärkungsgesetz (BFSG) und die BITV 2.0 stützen, verlangt AA. AAA ist die höchste Stufe. Das W3C selbst rät davon ab, AAA pauschal für ganze Websites zu verlangen, weil manche Inhalte die Kriterien gar nicht erfüllen können.

Das heißt aber nicht, dass AAA egal ist. Für einzelne Menschen kann gerade ein AAA-Kriterium den Unterschied machen, etwa Gebärdensprache in Videos oder eine leicht verständliche Sprache. Wo es möglich und sinnvoll ist, lohnt es sich also, auch einzelne AAA-Kriterien umzusetzen. Für öffentliche Stellen geht die BITV 2.0 sogar ausdrücklich über AA hinaus. Für besonders wichtige Bereiche einer Website sollen sie das Maximum anstreben:

Das sagt das Gesetz

Für zentrale Navigations- und Einstiegsangebote sowie Angebote, die eine Nutzerinteraktion ermöglichen, beispielsweise Formulare und die Durchführung von Authentifizierungs-, Identifizierungs- und Zahlungsprozessen, soll ein höchstmögliches Maß an Barrierefreiheit angestrebt werden.

Gerade bei Formularen, Logins und Bezahlvorgängen lohnt sich also der Blick auf die AAA-Kriterien.

Und umgekehrt decken die WCAG nicht alles ab. Nicht jede Barriere lässt sich in ein prüfbares Erfolgskriterium fassen. Eine Seite kann formal AA erfüllen und für einzelne Menschen trotzdem schwer nutzbar sein. Die Erfolgskriterien sind die Untergrenze, nicht das Ziel.

Die Stufen bauen aufeinander auf. Wer AA erreichen will, muss alle Kriterien der Stufen A und AA erfüllen. Was die Stufen im Detail bedeuten, schaue ich mir in einem eigenen Teil der Reihe an.

Von WCAG 1.0 bis 2.2: eine kurze Geschichte

Die Geschichte der Standards für barrierefreie Webinhalte reicht bis in die 1990er-Jahre zurück, also ziemlich in die Anfangszeit des Webs. Im Mai 1999 veröffentlichte das W3C die erste Version der WCAG (öffnet in neuem Tab) als Empfehlung.

Grundlegend überarbeitet wurden sie 2008 mit den WCAG 2.0 (öffnet in neuem Tab). Seitdem sind die Richtlinien technikneutral formuliert, gelten also nicht nur für HTML, sondern für Webinhalte jeder Art. 2018 folgten die WCAG 2.1 (öffnet in neuem Tab) mit einer neuen Richtlinie und 17 weiteren Erfolgskriterien, vor allem für die Bedienung auf Mobilgeräten, für Menschen mit Sehbehinderung und für Menschen mit kognitiven Einschränkungen.

Der aktuelle Stand sind die WCAG 2.2 (öffnet in neuem Tab), veröffentlicht im Oktober 2023. Sie bringen neun neue Erfolgskriterien mit, vor allem für Menschen mit motorischen und kognitiven Einschränkungen und für alle, die per Tastatur oder Touch bedienen. Dabei greifen sie auch aktuelle Designtrends auf. Ein Beispiel: Das Element, auf dem gerade der Tastaturfokus liegt, darf nicht komplett von einem Sticky-Header oder einer fest stehenden Leiste verdeckt werden. Der Fokus ist die Markierung, die zeigt, wo man sich beim Bedienen per Tastatur gerade befindet. Ein anderes Beispiel: Ein Login darf nicht verlangen, dass man sich ein Passwort merkt und abtippt, ohne es etwa aus einem Passwortmanager einfügen zu können.

Fertig im Sinne von abgeschlossen sind die WCAG damit aber nicht. Die 2.1 wurde 2023, 2024 und 2025 noch aktualisiert, die 2.2 im Dezember 2024. Da tut sich also laufend etwas, auch zwischen den großen Versionen.

Wichtig dabei: Eine neue Version ersetzt die alte nicht. WCAG 2.0, 2.1 und 2.2 sind alle gültige Standards, theoretisch kann man sich also auch „nur“ an 2.0 halten. Das W3C empfiehlt aber ausdrücklich die jeweils neueste Version. Und welche Version tatsächlich verlangt wird, entscheidet am Ende nicht das W3C, sondern die Norm, auf die sich ein Gesetz stützt. Dazu gleich mehr.

Die Versionen bauen aufeinander auf. Wer die WCAG 2.2 erfüllt, erfüllt automatisch auch 2.1 und 2.0.

Und was ist mit dem gestrichenen Kriterium 4.1.1?

Mit den WCAG 2.2 ist das Erfolgskriterium 4.1.1 Syntaxanalyse entfallen. Es verlangte sauber geschriebenes HTML, damit assistive Technologien den Code zuverlässig verstehen. Moderne Browser und Screenreader gleichen solche Fehler inzwischen selbst aus. Damit die Versionen trotzdem zusammenpassen, gilt 4.1.1 in den aktualisierten Fassungen von 2.0 und 2.1 für HTML als automatisch erfüllt. Unwichtig wird sauberes HTML dadurch nicht, denn erst die Semantik sagt assistiven Technologien, was ein Element ist.

WCAG 3: Was als Nächstes kommt

Und die Zukunft? Die wirft ihre Schatten bereits voraus. Die WCAG 3.0 (öffnet in neuem Tab) befinden sich im Status „Working Draft“, also Arbeitsentwurf. Beim Schreiben dieses Beitrags war der jüngste Entwurf vom 10. September 2026. Das heißt: Es gibt einen aktuellen Stand, an dem man sich mit Feedback beteiligen kann. Es heißt aber auch: Was heute im Dokument steht, muss nicht so in der finalen Version landen.

Ein paar Richtungen zeichnen sich trotzdem ab. Der Name ändert sich: Aus den Web Content Accessibility Guidelines werden die W3C Accessibility Guidelines, die Abkürzung bleibt. Der Geltungsbereich soll über Webinhalte im engeren Sinn hinausgehen. Und das Bewertungssystem wird ein anderes, die Stufen A, AA und AAA soll es in dieser Form nicht mehr geben.

Wann die WCAG 3 fertig sind? Das dauert noch, das W3C selbst spricht von einigen Jahren. Schaut man auf die bisherigen Abstände zwischen den Versionen, rechne ich nicht vor 2030 damit, dass sie den Status einer Empfehlung erreichen. Damit bin ich nicht allein, auch andere Einschätzungen gehen in diese Richtung.

Wie offen vieles noch ist, zeigt ein Thema, das ich aus meinem Alltag sehr gut kenne: Farbkontraste. Bis 2023 sah der Entwurf vor, Kontraste mit dem Verfahren APCA zu berechnen, das näher an der menschlichen Wahrnehmung liegt als die bisherige Formel. Inzwischen ist APCA aus dem Entwurf verschwunden, und einen Ersatz gibt es noch nicht. In der Anforderung zum Textkontrast im aktuellen Entwurf (öffnet in neuem Tab) steht an der Stelle des Messverfahrens nur ein Platzhalter, dazu der Hinweis, dass der Algorithmus noch nicht feststeht. Angenommen wird lediglich, dass Schriftgröße und Schriftstärke in die Berechnung einfließen.

Für heute heißt das: Es gelten weiterhin die WCAG 2. Die WCAG 3 sollte man verfolgen, umsetzen muss man sie noch nicht. Wer sich schon an einzelnen Ansätzen orientieren will, kann das tun, aber immer mit dem Wissen, dass sich etwas ändern kann und wird.

Welche Version gilt denn nun? WCAG, Normen und Recht

Die WCAG selbst sind kein Gesetz. Verbindlich werden sie erst, weil Gesetze und Normen auf sie verweisen. In Deutschland sieht diese Kette vereinfacht so aus:

Das BFSG und die BITV 2.0 verlangen, dass digitale Angebote barrierefrei sind. Wie das technisch aussieht, beschreiben sie nicht selbst, sondern verweisen auf die europäische Norm EN 301 549. Wer diese Norm einhält, für den gilt die sogenannte Konformitätsvermutung: Es wird angenommen, dass auch die gesetzlichen Anforderungen erfüllt sind. Für Websites, Dokumente und Software übernimmt die EN 301 549 im Kern die WCAG auf Stufe AA. Außerdem sind die WCAG 2.2 als internationale Norm ISO/IEC 40500 anerkannt. Für Deutschland ist das eher eine Randnotiz, entscheidend ist der Weg über die EN 301 549.

Der Haken: Normen verweisen auf eine bestimmte WCAG-Version und ziehen neuen Fassungen oft erst Jahre später nach. Die EN 301 549 in der Fassung V3.2.1 von 2021 stützt sich deshalb noch auf die WCAG 2.1. Die neue Fassung V4.1.1 stellt auf die WCAG 2.2 um. Veröffentlicht ist sie seit September 2026, maßgeblich für die Konformitätsvermutung wird sie aber erst, wenn die EU-Kommission sie im Amtsblatt bekannt gibt. Erwartet wird das in den kommenden Monaten.

Deshalb lohnt es sich, sich an der aktuellen WCAG-Version zu orientieren statt an der, die eine Norm gerade nennt. Die Normen ziehen nach, nur eben mit Verzögerung. Und weil 2.2 die älteren Versionen einschließt, verliert man dabei nichts.

Nur eins sollte man nicht verwechseln: Die EN 301 549 geht über die WCAG hinaus und enthält weitere Anforderungen, etwa für Software, Hardware und Kommunikation. WCAG erfüllt heißt also nicht automatisch Norm erfüllt.

Wo man in den WCAG nachschlägt

Die WCAG selbst sind ein ziemlich trockenes Dokument. Deshalb stellt die WAI Begleitdokumente bereit, die im Alltag deutlich nützlicher sind. Die Schnellreferenz How to Meet WCAG (öffnet in neuem Tab) listet alle Erfolgskriterien kompakt auf und lässt sich nach Stufen oder Themen filtern, inklusive passender Techniken und typischer Fehler. Understanding WCAG 2.2 (öffnet in neuem Tab) erklärt zu jedem Kriterium, wozu es da ist und wem es hilft, und zeigt Beispiele. Die Techniques for WCAG 2.2 (öffnet in neuem Tab) sammeln konkrete Lösungswege und häufige Fehler.

Dabei gilt: Die Erfolgskriterien sind technikneutral, die Techniken dagegen konkret. Sie zeigen zum Beispiel, wie man ein Kriterium in HTML erfüllt. Verpflichtend sind sie nicht. Wer ein Kriterium auf anderem Weg erfüllt, erfüllt es genauso.

Eine gemeinsame Sprache

Man muss die WCAG nicht auswendig kennen, um barrierefreie Inhalte zu machen. Aber wer weiß, was hinter den vier Buchstaben steckt, was wo steht und was worunter fällt, redet in Projekten anders mit: im Design, in der Redaktion, im Social-Media-Team und natürlich in der Entwicklung. Die WCAG sind der Maßstab, auf den sich Gesetze, Normen, Audits und Prüfberichte beziehen. Und sie sind eine gemeinsame Sprache für alle, die an einem Projekt arbeiten.

Wer diese Sprache spricht, muss sich in keinem Audit mehr erklären lassen, was „1.4.3 nicht erfüllt“ bedeutet.