WCAG und Barrierefreiheit gehören zusammen wie Bauordnung und Statik: Die Web Content Accessibility Guidelines sind die technische Grundlage, an der sich Barrierefreiheit im Web bemisst. Über die europäische Norm EN 301 549 sind sie der Maßstab für die Anforderungen aus dem Barrierefreiheitsstärkungsgesetz, siehe BFSG-Pflichten.
Sie wirken auf den ersten Blick umfangreich: Dutzende Erfolgskriterien auf drei Stufen. Bei einer normalen Inhaltswebsite sind etwa fünfzehn Kriterien tatsächlich relevant, und die decken sich weitgehend mit gutem Handwerk. Diese Seite ordnet die Prinzipien, zeigt die relevanten AA-Kriterien mit je einem Praxisbeispiel und erklärt, was WCAG 2.2 neu bringt.
Die vier Prinzipien
Wahrnehmbar. Informationen müssen so dargeboten werden, dass sie auch bei eingeschränkter Nutzung eines Sinnes zugänglich sind.
Bedienbar. Alle Bedienelemente müssen erreichbar und auslösbar sein, unabhängig vom Eingabegerät.
Verständlich. Inhalte und Bedienung müssen nachvollziehbar sein.
Robust. Inhalte müssen von Hilfsmitteln zuverlässig interpretiert werden können.
Die AA-Kriterien mit Praxisbeispiel
Die Tabelle fasst die Kriterien zusammen, die bei einer typischen Inhaltswebsite tatsächlich Arbeit erzeugen. Sie ersetzt nicht den vollständigen Kriterienkatalog, deckt aber den Teil ab, an dem Prüfungen in der Praxis scheitern.
| Kriterium | Verlangt | Praxisbeispiel |
|---|---|---|
| Textalternativen | Alternativtext für informative Bilder, leerer für dekorative | Das Teamfoto bekommt eine Beschreibung, die Zierlinie einen leeren Alternativtext |
| Untertitel | Untertitel für Videos mit Sprache | Das Imagevideo auf der Startseite erhält Untertitel, nicht nur Musik-Erkennung |
| Kontrast von Text | 4,5 zu 1 für Fließtext, 3 zu 1 für große Schrift | Hellgrau #999999 auf Weiß fällt durch, #767676 besteht knapp |
| Kontrast von Bedienelementen | 3 zu 1 für grafische Elemente und Zustände | Der Rahmen des Eingabefelds muss sich vom Hintergrund abheben |
| Nicht nur Farbe | Information nie allein über Farbe | Das Fehlerfeld wird rot markiert und zusätzlich mit Text benannt |
| Text vergrößerbar | Bei 200 Prozent Zoom bleibt alles lesbar und erreichbar | Die Navigation bricht sauber um, statt Text abzuschneiden |
| Umbruch | Bei 320 Pixel Breite kein zweidimensionales Scrollen | Die Preistabelle scrollt in einem eigenen Bereich, nicht die ganze Seite |
| Tastaturbedienbarkeit | Alles per Tastatur erreichbar, keine Fokusfallen | Das Ausklappmenü öffnet mit Eingabetaste und schließt mit Escape |
| Sichtbarer Fokus | Fokus erkennbar und ausreichend abgehoben | Der Fokusring wird nicht per Stylesheet entfernt, sondern gestaltet |
| Sinnvolle Reihenfolge | Tab-Reihenfolge entspricht der Leseordnung | Nach dem Logo kommt die Navigation, nicht ein Element im Fußbereich |
| Sprungmarke | Link zum Überspringen wiederkehrender Blöcke | Der erste Tab-Stopp ist “Zum Inhalt springen” |
| Linktexte | Zweck aus dem Text erkennbar | “Preisliste als PDF” statt “hier klicken” |
| Seitensprache | Hauptsprache im Markup ausgezeichnet | Das lang-Attribut steht auf de, englische Zitate werden einzeln markiert |
| Beschriftungen | Formularfelder mit echten, verknüpften Labels | Das E-Mail-Feld hat ein Label, nicht nur einen Platzhaltertext |
| Fehlermeldungen | Benennen Feld, Problem und Lösung | “Bitte Telefonnummer im Format 0621 eingeben” statt “Eingabe ungültig” |
| Vorhersehbarkeit | Kein Kontextwechsel ohne Auslösung | Die Sprachauswahl springt nicht beim Fokussieren, sondern erst beim Bestätigen |
| Semantik | Überschriftenebenen folgen der Gliederung | Eine H1 pro Seite, H2 für Abschnitte, keine H4 aus optischen Gründen |
| Statusmeldungen | Änderungen für Hilfsmittel wahrnehmbar | Die Erfolgsmeldung nach dem Absenden wird angekündigt, nicht nur eingeblendet |
Wer diese Punkte erfüllt, hat bei einer Inhaltswebsite den überwiegenden Teil der Stufe AA abgedeckt. Die übrigen Kriterien betreffen Audio- und Videoinhalte, zeitgesteuerte Abläufe und komplexe Anwendungen.
Was WCAG 2.2 neu bringt
Die Version 2.2 ergänzt die Richtlinien um einige Kriterien, von denen vier für normale Websites praktisch relevant sind:
Fokus nicht verdeckt. Das fokussierte Element darf nicht vollständig hinter anderen Inhalten verschwinden, etwa hinter einer festgehefteten Kopfzeile oder einem Cookie-Banner. Wer mit fester Kopfzeile arbeitet, prüft, dass der Fokus beim Durchtabben sichtbar bleibt.
Zielgröße. Klickflächen brauchen eine Mindestgröße von 24 mal 24 Pixel oder entsprechenden Abstand zueinander. Die Empfehlung für Touch liegt weiterhin höher, bei etwa 44 Pixel.
Konsistente Hilfe. Wenn eine Seite Hilfsmechanismen anbietet, etwa Kontaktmöglichkeiten oder einen Chat, stehen sie auf allen Seiten an derselben Stelle.
Redundante Eingaben vermeiden. Informationen, die ein Nutzer im selben Vorgang bereits eingegeben hat, werden nicht erneut abgefragt, sondern übernommen oder zur Auswahl angeboten. Das betrifft vor allem mehrstufige Formulare und Kassenstrecken.
Dazu kommt: Das alte Kriterium zur Parserfähigkeit ist entfallen, und Authentifizierung darf keine reinen Merkaufgaben verlangen, ein Passwort-Manager muss also nutzbar bleiben.
Zur Einordnung des Zusammenspiels mit dem Gesetz: Die harmonisierte Fassung der EN 301 549 verweist derzeit auf die WCAG 2.1. Die 2.2-Kriterien sind der aktuelle Stand der Richtlinien und der sinnvolle Zielwert für neue Projekte, denn wer heute 2.2 erfüllt, erfüllt 2.1 vollständig mit.
Die Konformitätsstufen
| Stufe | Bedeutung |
|---|---|
| A | Untergrenze, allein nicht ausreichend |
| AA | üblicher Zielwert, Maßstab der europäischen Norm |
| AAA | weitergehend, selten vollständig erreichbar, nicht gefordert |
Stufe AA ist der praktische Bezugspunkt. Wer sie erfüllt, erfüllt den technischen Teil der gesetzlichen Anforderung.
Was ausdrücklich nicht genügt
Ein Overlay-Widget. Skripte, die per Schaltfläche Kontraste oder Schriftgrößen umschalten, beheben keines der oben genannten Kriterien. Ein fehlender Alternativtext bleibt fehlend.
Ein automatisierter Test allein. Prüfwerkzeuge finden zuverlässig fehlende Alternativtexte, fehlende Beschriftungen und Kontrastprobleme bei einfarbigen Hintergründen. Sie finden nicht, ob ein Alternativtext sinnvoll ist, ob die Tabreihenfolge logisch ist oder ob eine Fehlermeldung hilft.
Eine einmalige Prüfung. Jedes Update, jedes neue Plugin und jede eingebettete Fremdkomponente kann Kriterien brechen. Der Prüfablauf steht in Barrierefreiheit testen.
Wo anfangen
Die Reihenfolge mit der größten Wirkung pro Stunde: zuerst Kontraste prüfen und beheben, dann die Tastaturbedienung herstellen, dann Alternativtexte und Formularbeschriftungen ergänzen. Diese drei Baustellen decken die häufigsten Verstöße ab und sind bei einer kleinen Website an einem Arbeitstag zu schaffen. Dokumente nicht vergessen: Für angehängte Dateien gelten dieselben Maßstäbe, siehe Barrierefreie PDF.