Was sind die WCAG

WCAG steht für Web Content Accessibility Guidelines, auf Deutsch Richtlinien für barrierefreie Webinhalte. Herausgeber ist das W3C über seine Web Accessibility Initiative (WAI). Was sie gegenüber jedem Best-Practice-Handbuch auszeichnet, ist die Überprüfbarkeit: Jede Anforderung ist so formuliert, dass zwei unabhängige Prüfer beim selben Bildschirm zum selben Urteil kommen.

Drei Ebenen, die in der Praxis vermischt werden, gehören auseinandergehalten. Barrierefreiheit im Web ist die Eigenschaft der Website. Die WCAG sind der Maßstab, mit dem diese Eigenschaft gemessen wird. Und das Gesetz entscheidet, von wem sie ab wann verlangt wird. Das W3C erlässt keine Gesetze und verhängt keine Sanktionen: Es schreibt den Maßstab, und die europäischen und nationalen Normen übernehmen ihn per Verweis. Die Frage, «ob die WCAG verpflichtend sind», vermengt alle drei Ebenen.

Der Geltungsbereich umfasst dem Wortlaut nach Webinhalte, also alles, was an den Browser ausgeliefert wird und von einer assistiven Technologie interpretiert werden kann. Native mobile Apps, Desktop-Software und Office-Dokumente fallen wörtlich heraus, auch wenn die europäische Bezugsnorm und ein Großteil der Ausschreibungen sie nach denselben Kriterien analog bewerten.

Eine zweite Grenze wird häufig missverstanden. Die WCAG schreiben weder ein bestimmtes Design noch eine bestimmte Komponente vor. Sie beschreiben geforderte Ergebnisse, keine Umsetzungen, und deshalb erlaubt derselbe Bildschirm mehrere gleichermaßen konforme Lösungen.

Die Hierarchie hat drei Stufen. Ganz oben stehen vier Prinzipien: wahrnehmbar, bedienbar, verständlich und robust. Darunter liegen dreizehn Richtlinien, die thematische Ziele bündeln, etwa Kontrast, Tastaturbedienung oder Hilfe bei der Dateneingabe. Auf der operativen Ebene stehen die Erfolgskriterien, also die Sätze, die tatsächlich geprüft werden. Die Nummerierung bildet das ab: Kriterium 1.4.3 gehört zu Prinzip 1, Richtlinie 4, und ist das dritte dieser Richtlinie.

Jedem Kriterium ist eine Stufe zugeordnet. Fassung 2.2 nummeriert 86 Kriterien: 31 auf Stufe A, 24 auf Stufe AA und 31 auf Stufe AAA. Die Stufen sind kumulativ, wer also AA erklärt, muss auch die Kriterien der Stufe A erfüllen, insgesamt 55. AAA ist nicht als Gesamtziel für eine komplette Website gedacht, weil es Inhaltsarten gibt, für die es unerreichbar bleibt.

Eine Konformitätserklärung setzt zusätzlich fünf Bedingungen voraus, die gern übersehen werden: Erklärt wird eine vollständige Stufe, für vollständige Seiten, für vollständige Prozesse wie einen Kauf oder eine Registrierung, unter Einsatz ausschließlich barrierefreiheitsunterstützter Technologien, und ohne dass ein nicht konformer Teil den Rest der Seite stört. Eine Seite mit einem einzigen verletzten Kriterium ist nicht konform, wie viele sie sonst auch erfüllt.

Zu den Fassungen: Die 2.0 (2008) legte 61 Kriterien fest, die 2.1 (2018) ergänzte 17, und die 2.2 (Oktober 2023, mit redaktioneller Aktualisierung im Dezember 2024) kam auf neun weitere und strich 4.1.1 «Syntaxanalyse», das obsolet wurde. Die 3.0 ist weiterhin ein Arbeitsentwurf ohne normative Wirkung. Die europäische Norm EN 301 549, auf die Recht und Ausschreibungen verweisen, übernimmt in ihrer harmonisierten Fassung die WCAG 2.1 Stufe AA, und ihre Überarbeitung hin zur 2.2 läuft.

Die Entscheidung, die von den WCAG abhängt, ist nicht, ob eine Website barrierefrei werden soll, sondern wie sich das Budget zwischen automatischen Werkzeugen und menschlicher Prüfung aufteilt. Genau daran scheitern die meisten Barrierefreiheitspläne.

Die brauchbarste Zahl zu dieser Aufteilung stammt aus einem Test des britischen Government Digital Service: Das Team baute 142 Barrieren in eine Seite ein und schickte sie durch dreizehn automatische Werkzeuge; das beste fand 40 % der eingebauten Probleme. Was übrig bleibt, verlangt menschliches Urteil. Ob ein Alternativtext das Bild beschreibt oder nur den Dateinamen wiederholt, ob die Fokusreihenfolge der visuellen Logik folgt, ob eine Fehlermeldung erklärt, wie sich die Eingabe korrigieren lässt: Das löst kein Scanner.

Daraus folgen zwei praktische Konsequenzen. Ein automatischer Bericht ohne Befunde ist keine Konformitätserklärung, sondern ein Filter, der die gröbsten Fehler aussortiert hat. Und die Zielstufe, fast immer AA, wird zu Projektbeginn festgelegt, denn Kriterien wie Mindestkontrast oder Größe der Zielfläche prägen das Designsystem; sie am Ende zu korrigieren kostet ein Redesign statt eines Patches.

• Zielstufe (A plus AA) und konkrete Fassung schriftlich festlegen, bevor das Design beginnt, und in Ausschreibung oder Agenturvertrag aufnehmen.
• Vollständige Prozesse prüfen statt einzelner Seiten: Registrierung, Suche, Warenkorb, Bezahlung und Passwort-Wiederherstellung, samt Fehlerzuständen.
• Automatischen Scanner mit einer manuellen Mindestprüfung kombinieren: kompletter Durchlauf nur mit Tastatur, Test mit Screenreader und Kontrolle des Zooms auf 200 %.
• Kontrast, Größe der Zielfläche und Fokusindikator zu Tokens des Designsystems machen, damit jede neue Komponente sie von sich aus erfüllt.
• Eine Erklärung zur Barrierefreiheit veröffentlichen mit Normfassung, erreichter Stufe, Datum der Prüfung, verwendeter Methode und Kontaktweg zum Melden von Barrieren.
• Jeden bekannten Mangel mit Ursache und geplantem Korrekturdatum dokumentieren, statt ihn aus dem Bericht herauszuhalten.

• «Null Fehler im Scanner» als Konformitätsnachweis nehmen, obwohl der automatisierbare Anteil der Kriterien in der Minderheit ist.
• Ein Overlay einbauen und die Sache für erledigt halten. Das Overlay Fact Sheet, unterzeichnet von Fachleuten und Organisationen der Branche, hält fest, dass ein Overlay keine vollständige Konformität erreichen kann, weil es nicht alle Fehlerarten repariert, und warnt zusätzlich davor, dass das Erkennen der assistiven Technologie sensible personenbezogene Informationen preisgibt.
• AAA als generelle Sitepolitik festschreiben und am Ende ohne jede Erklärung dastehen, statt AA dauerhaft zu erreichen.
• Das Designmodell prüfen statt der echten Site mit Daten, ausgefüllten Formularen, geöffneten Dialogen und per JavaScript nachgeladenen Inhalten.
• Barrierefreiheit als abschließende QA-Phase behandeln, obwohl die teuersten Kriterien im Designsystem und im Markup entschieden werden.