WCAG Leitfaden für Webentwickler und Accessibility-Teams

Was sind die WCAG und warum sind sie so wichtig?

Die Web Content Accessibility Guidelines (WCAG) wurden vom World Wide Web Consortium (W3C) entwickelt und sind der internationale Standard für barrierefreie Webinhalte. Sie sind nicht bloß Empfehlungen: Gesetze und Verordnungen weltweit beziehen sich auf diese Richtlinien. In Deutschland verweist das Barrierefreiheitsstärkungsgesetz (BFSG) direkt auf die WCAG, sodass kommerzielle Websites und digitale Dienste ab 2025 verpflichtet sind, die Anforderungen zu erfüllen – andernfalls drohen Abmahnungen und Strafen.

WCAG deckt alle digitalen Inhalte ab: Texte, Bilder, Videos, Formulare und Navigation. Barrierefreiheit hilft jedoch nicht nur Menschen mit Behinderungen – sie verbessert die Nutzererfahrung für alle, z. B. bei Nutzung im Freien oder mit eingeschränkter Mobilität.

Die aktuelle Version ist WCAG 2.2 (Dezember 2024). Sie ist abwärtskompatibel zu WCAG 2.1, was die Migration erleichtert. Offizielle Informationen und eine praktische Übersicht finden Sie auf der W3C-Website. Deutsche Übersetzungen sind auf der Seite der deutschen Übersetzungen verfügbar.

Warum das Thema persönlich wichtig ist

Aus eigener Erfahrung hat mich ein Kollege mit Sehbehinderung auf die praktischen Hürden hingewiesen, die beim Einsatz von Screenreadern entstehen. Solche Eindrücke machen deutlich, dass Barrierefreiheit kein Nischenthema ist, sondern ein zentraler Bestandteil professioneller Webentwicklung – vergleichbar mit responsive Design.

Das POUR-Prinzip: Die vier Säulen der Barrierefreiheit

Die WCAG basieren auf vier Prinzipien, die sich gut mit dem Akronym POUR merken lassen:

Perceivable (Wahrnehmbar)

Inhalte müssen so dargestellt werden, dass sie alle Nutzer wahrnehmen können. Beispiele: Alternativtexte für Bilder, Untertitel für Videos und Informationsvermittlung nicht ausschließlich über Farbe.

Operable (Bedienbar)

Interaktive Elemente müssen mit verschiedenen Eingabemethoden erreichbar sein – insbesondere über die Tastatur. Das betrifft Navigation, Formulare und dynamische Widgets.

Understandable (Verständlich)

Inhalte und Bedienung müssen logisch und nachvollziehbar sein: klare Überschriftenhierarchien, verständliche Sprache und hilfreiche Fehlermeldungen.

Robust (Robust)

Inhalte müssen von verschiedenen Technologien interpretiert werden können – saubere, semantische HTML-Struktur und standardkonformer Code sind zentral.

Konformitätsstufe A: Die absoluten Grundlagen

Stufe A beseitigt die schwerwiegendsten Barrieren. Ohne ihre Erfüllung ist die Nutzung für viele Menschen praktisch unmöglich. Zu den wichtigsten Anforderungen gehören:

• Alternativtexte für Bilder – informationstragende Bilder benötigen einen aussagekräftigen Alt-Text; dekorative Bilder erhalten alt="".
• Tastaturbedienbarkeit – sämtliche Funktionen müssen ohne Maus zugänglich sein (Tab-Reihenfolge, Enter, Pfeiltasten).
• Keine ausschließliche Informationsvermittlung über Farbe.
• Formularbeschriftungen – Labels müssen programmatisch mit Eingabefeldern verbunden sein.

Technisch ist Stufe A meist unkompliziert umzusetzen, kostet wenig Zeit, wenn sie von Anfang an berücksichtigt wird.

Konformitätsstufe AA: Der gesetzliche Standard

Stufe AA ist für die meisten Websites das Ziel – gesetzlich vorgeschrieben in vielen Ländern. Wichtige AA-Kriterien sind:

• Farbkontrast: mindestens 4,5:1 für normalen Text und 3:1 für großen Text.
• Sichtbare Fokus-Indikatoren für Tastaturnavigation.
• Logische Überschriftenstruktur (H1 → H2 → H3 … ohne Ebenen zu überspringen).
• Responsive Verhalten und Reflow bei kleinen Viewports; Inhalte müssen lesbar sein ohne horizontales Scrollen.
• Konkrete Fehlermeldungen in Formularen, die erklären, wie Fehler behoben werden können.

Viele dieser Anforderungen folgen aus sauberem Code und durchdachtem Design – aber sie müssen systematisch getestet werden.

Konformitätsstufe AAA: Die Königsklasse

Stufe AAA enthält die strengsten Anforderungen. Das W3C rät davon ab, AAA als allgemeines Ziel für komplette Websites anzustreben, da viele Kriterien schwer praktikabel oder unverhältnismäßig teuer sind. Beispiele:

• Farbkontrast 7:1 für normalen Text.
• Gebärdensprachverdolmetschung für aufgezeichnete Videos.
• Erweiterte Audiodeskriptionen, z. B. zeitlich ausgedehnte Beschreibungen während eines Films.
• Vereinfachte Sprache für komplexe Dokumente – oft juristisch problematisch.

Empfehlung: AA anstreben und selektiv AAA-Kriterien dort implementieren, wo sie echten Mehrwert bringen.

WCAG 2.1 vs. WCAG 2.2: Was hat sich geändert?

WCAG 2.1 (2018) erweiterte den Fokus auf mobile Nutzung und Sehbehinderungen. WCAG 2.2 (Dezember 2024) ist abwärtskompatibel und ergänzt neun neue Erfolgskriterien, mit besonderem Augenmerk auf kognitive Barrierefreiheit und mobile Interaktion.

Wichtige Änderungen in 2.2:

• Neun neue Erfolgskriterien über alle Konformitätsstufen verteilt.
• Mehr Fokus auf mobile Bedienbarkeit (z. B. Alternativen zu Drag-and-Drop).
• „Fokus sichtbar“ wurde auf Stufe A herabgestuft.
• Das Erfolgskriterium „Syntaxanalyse“ (4.1.1) wurde entfernt.

Insgesamt umfasst WCAG 2.2 nun 86 Erfolgskriterien. Für viele Projekte ist die Migration von 2.1 zu 2.2 durch Ergänzung der neuen Kriterien gut machbar.

Praktische Umsetzung: So erfüllt man die Anforderungen

Die Umsetzung verlangt Disziplin und gute Prozesse. Einige bewährte Maßnahmen:

Semantisches HTML

Nutzen Sie native Elemente wie <button> und <h2> statt gestylter <div>-Elemente. Semantisches HTML wird von Browsern und Hilfstechnologien besser verstanden.

Alternativtexte

Ein guter Alt-Text beschreibt den Informationsgehalt, nicht nur das Motiv. Dekorative Bilder erhalten bewusst leere Alt-Attribute alt="".

Tools und Tests

Automatisierte Tools wie Lighthouse, WAVE und Contrast Checker finden viele Probleme, aber nicht alles. Manuelle Tastatur- und Screenreader-Tests sowie Experten-Audits sind unverzichtbar.

ARIA richtig einsetzen

ARIA kann komplexe Widgets zugänglich machen, darf aber semantisches HTML nicht ersetzen. Die Faustregel unter Entwicklern lautet: „Use native HTML first; then ARIA if needed.”

Wichtig ist: Barrierefreiheit von Anfang an planen – im Wireframe, im Design und beim Development. So lassen sich Kosten und Verzögerungen vermeiden.