Barrierefreiheit im Web: WCAG 2.2 von Anfang an mitdenken

Version 2.2 der Web Content Accessibility Guidelines ist seit Oktober 2023 eine W3C-Empfehlung. Sie kippt die früheren Versionen nicht: Sie bleibt abwärtskompatibel und ergänzt lediglich neun Erfolgskriterien, die vor allem auf Tastaturbedienung, Touch-Interaktionen und Authentifizierung zielen. Barrierefreiheit in der Entwurfsphase zu behandeln statt als Korrektur am Projektende verändert die Kosten der Konformität grundlegend. Ein Projekt, das sie vorwegnimmt, nimmt diese Kriterien ohne sichtbaren Mehraufwand auf; eines, das sie bei der Abnahme entdeckt, zahlt jede Korrektur zum vollen Preis.

#Was WCAG 2.2 ergänzt

Die neun neuen Kriterien verteilen sich auf die drei Konformitätsstufen. Die Mehrheit fällt unter Stufe AA, jene, auf die regulatorische Rahmen abzielen.

Zwei Kriterien verdienen sofortige Aufmerksamkeit. Die Mindest-Zielgröße (2.5.8) verlangt klickbare Flächen von mindestens 24 mal 24 CSS-Pixeln, mit einigen Ausnahmen: ein dichtes Navigationsmenü oder zu eng stehende Icons werden nicht konform. Die barrierefreie Authentifizierung (3.3.8) verbietet es, einen kognitiven Test zu verlangen, etwa ein Passwort zu behalten oder ein Rätsel zu lösen, ohne Alternative: ein mit dem Passwortmanager kompatibles Feld genügt, um sie zu erfüllen.

Die übrigen Kriterien zielen auf konkrete Ärgernisse. Ziehbewegungen (2.5.7) verlangen, dass eine per Drag-and-drop ausführbare Aktion eine Alternative mit einem einzigen Zeiger bietet, zum Nutzen von Menschen mit Tremor ebenso wie von Touchscreen-Nutzern. Konsistente Hilfe (3.2.6) fordert, dass Hilfsmechanismen, ein Kontaktformular oder ein Link zur Hilfe, von Seite zu Seite an derselben Stelle erscheinen. Redundante Eingabe (3.3.7) verbietet es, bereits im selben Vorgang gelieferte Angaben erneut abzufragen, außer bei echtem Bedarf: eine Lieferadresse sollte im Abrechnungsschritt nicht noch einmal eingetippt werden müssen.

#Drei Stufen, ein realistisches Ziel

Die Kriterien ordnen sich in drei kumulative Stufen. AAA über eine ganze Website anzustreben ist weder gefordert noch immer möglich; Stufe AA ist das Referenzziel.

#Kriterien in Code übersetzen

Die meisten Kriterien lassen sich mit korrektem HTML und ein paar CSS-Regeln erfüllen, ohne Bibliothek. Ein barrierefreies Formularfeld verbindet eine eindeutige Beschriftung, einen passenden Typ und eine per aria-describedby verknüpfte Hilfe.

<label for="email">Adresse e-mail</label>
<input id="email" name="email" type="email"
       autocomplete="email" required
       aria-describedby="email-aide">
<p id="email-aide">Format attendu : [email protected]</p>

Das Attribut autocomplete erfüllt die barrierefreie Authentifizierung direkt: Es lässt Browser und Passwortmanager das Feld ausfüllen, ohne kognitiven Aufwand. Auf der Darstellungsseite werden Zielgröße und Fokus-Sichtbarkeit in wenigen Zeilen geregelt, gestützt auf die Variablen des Themes.

/* 2.5.8 Taille de cible (minimum) : 24 x 24 px */
.btn-icone {
  min-block-size: 24px;
  min-inline-size: 24px;
}

/* 2.4.11 Focus non masqué : un focus toujours visible */
:focus-visible {
  outline: 3px solid var(--focus, #1a9694);
  outline-offset: 2px;
}

Die Fokusfarbe in einer Variablen zu bündeln erspart es, sie in jeder Komponente erneut einzuführen, und hält die Darstellung in hellem wie dunklem Theme konsistent, im Sinne von Design Tokens. Derselbe Ansatz gilt für Abstände zwischen Zielen: eine Mindestzeilenhöhe auf Navigationslisten regelt die Konformität dutzender Links auf einen Schlag.

Redundante Eingabe wird ebenso auf dem Server wie im Markup behandelt. Ein mehrstufiges Formular gewinnt, wenn es bereits eingegebene Werte bewahrt und vorbelegt, statt leere Felder zu zeigen. Auch hier genügen ein gut gewähltes autocomplete-Attribut und der erhaltene Zustand zwischen den Schritten, ohne maßgeschneiderte Komponente.

#Der europäische Rechtsrahmen

Barrierefreiheit ist nicht mehr nur gute Praxis. Der European Accessibility Act gilt seit dem 28. Juni 2025 für zahlreiche digitale Dienste, die Verbrauchern in der Union verkauft werden: Onlinehandel, Bankwesen, Ticketverkauf, Content-Plattformen. In der Praxis verweist der technische Referenzstandard EN 301 549 auf die WCAG-Kriterien der Stufe AA. In Frankreich überträgt die RGAA dieselbe Anforderung auf die betroffenen Akteure, mit einem inzwischen gefestigten Grundsatz: das Fehlen einer Konformitätserklärung und eines Aktionsplans ist selbst ein Mangel, unabhängig von der tatsächlichen Qualität der Website.

Der betroffene Geltungsbereich ist breit und wird oft unterschätzt. Ein Marktplatz, eine Buchungsanwendung oder der Kundenbereich einer Bank fallen darunter, während eine reine Visitenkarten-Website in manchen Fällen ausgenommen bleiben kann. Die eigene Betroffenheit vor einem Relaunch zu prüfen erspart es, die Pflicht erst nach der Budgetfreigabe zu entdecken, und eine nicht konforme Website setzt sich heute einem rechtlichen Risiko aus, nicht nur einer Ergonomiekritik.

Ein im Entwurf behobenes Kriterium kostet ein paar Minuten; dasselbe, im Betrieb nachgerüstet, bindet ein ganzes Team.

#Barrierefreiheit in den Arbeitsablauf einbauen

Automatisierung fängt einen Teil der Mängel ab, ohne die menschliche Prüfung zu ersetzen. Ein Audit mit einer Engine wie axe oder dem Lighthouse-Tab des Browsers meldet unzureichende Kontraste, fehlende Beschriftungen und zu kleine Ziele. Diese Prüfungen laufen besser fortlaufend während der Entwicklung als bei der Auslieferung, genau wie das Monitoring einer Website kontinuierlich eingerichtet wird und nicht auf der Zielgeraden. In die Continuous-Integration-Pipeline eingebunden, blockieren sie eine Regression, bevor sie die Produktion erreicht, wie ein fehlgeschlagener Unittest.

Das semantische Markup, das der Barrierefreiheit zugrunde liegt, dient auch der Suche: eine korrekt strukturierte Überschrift nützt dem Screenreader wie der Suchmaschine gleichermaßen, und eine klare Überschriftenhierarchie hilft beiden. In eine saubere semantische Basis zu investieren dient somit zwei Zielen in einem Zug, was die Budgetabwägung gegenüber einem Kunden weit leichter vertretbar macht.

#Das Wichtigste in Kürze

WCAG 2.2 wirft nichts um, zieht die Anforderungen aber dort an, wo Nutzer am meisten straucheln: Touch-Ziele, Tastaturfokus, Authentifizierung. Stufe AA ist das konkrete Ziel, nun durch eine gesetzliche Pflicht in Europa gestützt. Der richtige Weg besteht darin, diese Kriterien von Anfang an mitzudenken, auf semantisches HTML und Theme-Variablen zu setzen und automatische Audits durch menschliche Tests zu ergänzen. Es ist weniger ein einmaliges Projekt als eine Gewohnheit, die im Arbeitsablauf verankert gehört.

Zum Weiterlesen: die Referenzspezifikation, Web Content Accessibility Guidelines (WCAG) 2.2 (W3C).