WCAG einfach erklärt: Die Standards für barrierefreie Websites

Wenn vom „barrierefreien Web” die Rede ist, steckt fast immer ein Regelwerk dahinter: die Web Content Accessibility Guidelines, kurz WCAG. Sie definieren, was eine Website technisch erfüllen muss, damit Menschen mit Behinderungen sie nutzen können – und genau auf sie verweist am Ende auch das deutsche Barrierefreiheitsstärkungsgesetz.

Viele Anbieter werben mit einem „WCAG-konform”-Siegel, als ließe sich Barrierefreiheit per Knopfdruck einschalten. Dieser Leitfaden erklärt, was die WCAG wirklich sind: ihre vier Prinzipien, die Konformitätsstufen, die Versionen, wie sie mit dem BFSG zusammenhängen – und wie man Konformität ehrlich prüft, statt sie nur zu behaupten.

Was WCAG ist – und was nicht

Die WCAG sind ein internationaler Standard des World Wide Web Consortium (W3C), der Organisation, die auch die grundlegenden Web-Technologien betreut. Sie bestehen aus prüfbaren Erfolgskriterien für digitale Inhalte – formuliert als testbare Aussagen, technologieunabhängig und weltweit anerkannt.

Genauso wichtig ist, was die WCAG nicht sind. Sie sind kein Gesetz: In Deutschland ist das Gesetz das BFSG, das auf die WCAG nur verweist. Sie sind auch nichts, was ein einzelnes Overlay oder Widget „anschalten” könnte – die Kriterien werden durch echte Entscheidungen im Design und im Quellcode erfüllt, nicht durch eine Skript-Schicht über der Seite. Und sie sind kein einmaliges Häkchen, sondern ein Zustand, den man herstellt und durch erneute Prüfungen hält.

Die WCAG sind die technische Grundlage, auf die sich Standards und Gesetze weltweit stützen – in Europa über die Norm EN 301 549, in Deutschland über das BFSG.

Die vier Prinzipien: wahrnehmbar, bedienbar, verständlich, robust

Alle WCAG-Kriterien ordnen sich vier Grundprinzipien unter, im Englischen als POUR abgekürzt. Sie sind der beste Einstieg, um zu verstehen, worum es geht:

• Wahrnehmbar – Inhalte müssen über mehr als einen Sinneskanal zugänglich sein. Dazu gehören Textalternativen für Bilder, Untertitel und Transkripte für Medien und ausreichende Farbkontraste. Konkret behandeln wir das in Alt-Texte richtig schreiben und Farbkontrast nach WCAG
• Bedienbar – die gesamte Seite muss ohne Maus funktionieren, allein per Tastatur, mit erkennbarem Fokus. Niemand darf an einer Funktion scheitern, weil sie nur mit der Maus erreichbar ist. Mehr dazu in Tastaturbedienbarkeit
• Verständlich – Sprache, Aufbau und Verhalten der Seite müssen nachvollziehbar und vorhersehbar sein; Formulare brauchen klare Beschriftungen und Eingabehilfen.
• Robust – der Code muss sauber und semantisch sein, damit assistive Technologien wie Screenreader ihn zuverlässig interpretieren.

Unter diesen vier Prinzipien stehen dreizehn Leitlinien, und unter den Leitlinien die einzelnen, prüfbaren Erfolgskriterien.

Konformitätsstufen A, AA und AAA

Die WCAG kennen drei Konformitätsstufen, die aufeinander aufbauen. Stufe A deckt grundlegende Barrieren ab – das absolute Minimum. Stufe AA ist der etablierte Standard für die meisten Websites und genau die Stufe, die rechtlich gefordert wird. Stufe AAA ist die höchste Stufe; sie lässt sich für eine ganze Website oft gar nicht durchgängig erreichen und wird deshalb in Gesetzen in der Regel nicht flächendeckend verlangt.

Für das BFSG ist Stufe AA maßgeblich. Welche Kriterien zu welcher Stufe gehören und was das in der Praxis bedeutet, vertieft WCAG-Konformitätsstufen A, AA und AAA. Wichtig zu wissen: Konformität wird je Seite bestimmt, und ein vollständiger Nutzungsablauf – etwa ein Checkout – muss durchgängig konform sein, nicht nur die Startseite.

Die WCAG-Versionen: 2.0, 2.1 und 2.2

Die WCAG werden über die Jahre weiterentwickelt:

• WCAG 2.0 (2008) legte das Fundament mit den vier Prinzipien.
• WCAG 2.1 (Juni 2018) ergänzte Kriterien vor allem für mobile Nutzung, Sehbeeinträchtigungen und kognitive Einschränkungen.
• WCAG 2.2 (Oktober 2023) fügte neun weitere Erfolgskriterien hinzu und strich eines (4.1.1 Parsing, das durch moderne Browser überflüssig geworden ist). Die neuen Kriterien betreffen unter anderem eine Mindest-Zielgröße für Schaltflächen (24×24 Pixel), eine konsistente Platzierung von Hilfen, barrierefreie Anmeldeverfahren und gut sichtbaren Tastaturfokus. WCAG 2.2 wurde 2025 zusätzlich als internationale Norm ISO/IEC 40500:2025 bestätigt.

Jede Version baut abwärtskompatibel auf der vorherigen auf: Wer WCAG 2.2 erfüllt, erfüllt automatisch auch 2.1.

Hier ist der rechtlich entscheidende Punkt, bei dem viele Quellen ungenau sind: Verbindlich für das BFSG ist derzeit WCAG 2.1, Stufe AA – vermittelt über die aktuell harmonisierte Norm EN 301 549 v3.2.1. WCAG 2.2 AA ist die empfohlene Best Practice und der Stand, auf den die kommende Fassung EN 301 549 v4.1.1 (Veröffentlichung 2026 erwartet) verweisen wird. Sinnvoll ist deshalb, schon heute auf 2.2 AA hinzuarbeiten – ohne aber zu behaupten, das BFSG verlange bereits 2.2. (Die nächste Hauptversion, WCAG 3.0, befindet sich noch in mehrjähriger Entwicklung und folgt einem ganz anderen Modell; sie ist heute nicht relevant.)

Wie WCAG mit BFSG und EN 301 549 zusammenhängt

Drei Ebenen greifen ineinander, und sie sauber auseinanderzuhalten erspart teure Missverständnisse:

1. WCAG – die internationale Richtlinie des W3C. Sie liefert die technischen Kriterien, ist aber selbst kein Gesetz.
2. EN 301 549 – die harmonisierte europäische Norm. Sie übernimmt die WCAG und ergänzt sie um weitere Anforderungen. Details in EN 301 549 erklärt
3. BFSG – das deutsche Gesetz. Es verweist auf EN 301 549 und macht die Anforderungen für private Anbieter verbindlich. Den rechtlichen Rahmen behandelt der BFSG-Leitfaden

Daraus folgt eine Konsequenz, die in keinem „WCAG-konform”-Siegel steht: EN 301 549 geht über die WCAG hinaus – etwa bei Hardware, Dokumentation und Echtzeit-Kommunikation. Das vollständige Erfüllen aller WCAG-2.1-AA-Kriterien sichert deshalb noch keine automatische BFSG-Konformität. „WCAG-konform” und „BFSG-konform” sind nicht dasselbe; Ersteres ist die notwendige Basis, nicht die Garantie.

WCAG prüfen: automatisiert oder manuell?

Wie stellst du fest, ob deine Seite die WCAG erfüllt? Es gibt zwei Wege, und beide sind nötig.

Automatisierte Tests scannen den Code und finden viele Probleme schnell und zuverlässig – fehlende Alternativtexte, unzureichende Kontraste, strukturelle Fehler. Ihre Grenze ist aber prinzipiell: Automatisierte Werkzeuge können nur einen Teil der WCAG-Kriterien überhaupt maschinell beurteilen, in der Praxis grob ein Drittel. Was ein Tool kann und was nicht, zeigt Automatisierte WCAG-Tests

Manuelle Prüfung deckt den Rest ab – alles, was Urteilsvermögen verlangt: Ist ein Alternativtext inhaltlich sinnvoll? Ist die Fokusreihenfolge logisch? Ist der Text wirklich verständlich? Dazu gehören der Tastaturtest, Tests mit Screenreadern und idealerweise echte Nutzer mit Behinderungen.

Daran scheitert auch der vermeintliche Abkürzungsweg: Ein Overlay-Widget erfüllt die WCAG nicht. Es verändert den Quellcode nicht, in dem die Kriterien erfüllt werden müssen – es legt nur eine Schicht darüber. Warum das nicht funktioniert und rechtlich nicht trägt, erklärt Accessibility-Overlays

Der ehrliche Weg ist ein Kreislauf: prüfen, gefundene Probleme im Code beheben, erneut prüfen – bis der Wert nachweisbar steigt. Wie das praktisch abläuft, beschreibt Website barrierefrei machen. Genau diesen Kreislauf bildet Welcoma ab: Es zeigt dir die echten Quellcode-Probleme, statt dir ein grünes Häkchen zu verkaufen, das einer Prüfung nicht standhält.

Willst du die WCAG-Konformität deiner Seite gezielt angehen, führt dich der umsetzungsorientierte Leitfaden Website WCAG-konform machen mit Tool-Unterstützung durch genau diesen Kreislauf.

Dieser Ratgeber gibt einen verständlichen Überblick und ersetzt keine Rechtsberatung. Für die rechtliche Einordnung im Einzelfall ziehe fachkundige Beratung hinzu.