WCAG-Audit vor dem Relaunch: BFSG-Risiken vor der Freigabe finden

Rollen und Verantwortlichkeiten im Audit-Team

Ein WCAG-Audit scheitert selten an fehlendem Wissen, sondern an unklaren Zuständigkeiten. Wenn niemand konkret benennt, wer Fokusreihenfolgen prüft, wer Kontraste korrigiert und wer am Ende die Freigabe erteilt, bleiben gefundene Probleme in Tickets liegen, bis der Launch-Termin näherrückt und Kompromisse gemacht werden.

Sinnvoll ist eine klare Aufteilung in drei Rollen. Die Design- oder UX-Seite verantwortet Kontraste, Fokus-Sichtbarkeit und die Reihenfolge von Inhalten. Die Entwicklung übernimmt semantisches Markup, ARIA-Attribute und Tastaturbedienbarkeit der interaktiven Komponenten. Eine dritte, unabhängige Prüfperson testet am Ende gegen die ursprüngliche Anforderung, statt die eigene Arbeit selbst abzunehmen.

Wird das Audit intern durchgeführt, sollte die prüfende Person nicht dieselbe sein, die die Komponenten gebaut hat. Wer wochenlang an einem Formular gearbeitet hat, übersieht eigene Fehler leichter, weil die gedankliche Bedienlogik im Kopf bereits feststeht. Externe Prüfer bringen hier einen unvoreingenommenen Blick mit, kosten aber Zeit in der Abstimmung und kennen die internen Prioritäten nicht automatisch.

Für den Ablauf hat sich ein fester Eskalationsweg bewährt: Jeder gefundene Verstoß bekommt eine Einstufung nach Schweregrad, eine verantwortliche Person und ein Zieldatum. Blockierende Funde – etwa ein Checkout-Schritt, der mit der Tastatur nicht erreichbar ist – gehen direkt an die Entwicklung und stoppen im Zweifel die Freigabe. Kleinere Funde wie ein zu kurzer Alt-Text lassen sich sammeln und in einem zweiten Durchgang abarbeiten.

Wichtig ist außerdem eine Person, die am Ende die Freigabe tatsächlich erteilt oder verweigert. Ohne diese Instanz verwässert die Verantwortung: Jeder im Team geht davon aus, dass jemand anderes noch einmal draufschaut, und am Ende prüft niemand mit letzter Konsequenz. Diese Person muss nicht die tiefste technische Expertise haben, aber die Befugnis, den Launch-Termin notfalls zu verschieben, wenn kritische Barrieren offen sind.

Dokumentation: Was ins Freigabeprotokoll gehört

Ein WCAG-Audit ohne Protokoll verpufft, sobald der Launch vorbei ist. Wenn später eine Beschwerde eingeht oder nachgefragt wird, muss nachvollziehbar sein, was wann geprüft wurde und welche Entscheidung dazu getroffen wurde. Ein sauberes Freigabeprotokoll ist deshalb kein Selbstzweck, sondern die Grundlage für spätere Nachweise.

In das Protokoll gehören mindestens vier Angaben: welche Seiten und Komponenten geprüft wurden, mit welcher Methode (automatisierter Scan, manuelle Tastaturprüfung, Screenreader-Test), welche Verstöße gefunden wurden und wie mit jedem einzelnen umgegangen wurde. Bei Funden, die bewusst nicht vor dem Launch behoben wurden, sollte der Grund festgehalten werden – etwa geringe Nutzerzahl der betroffenen Seite oder ein bereits terminierter Fix nach dem Go-Live.

Screenshots oder kurze Videoaufnahmen der geprüften Zustände sind hilfreich, weil sich Oberflächen nach dem Launch weiterentwickeln und ein späterer Vergleich sonst schwerfällt. Auch die verwendeten Testgeräte und Screenreader-Versionen gehören in die Dokumentation, denn das Verhalten unterscheidet sich je nach Kombination aus Browser und Screenreader teilweise deutlich.

Am Ende steht eine unterschriebene oder zumindest datierte Freigabe durch die verantwortliche Person aus dem Audit-Team. Diese Freigabe sollte explizit benennen, für welchen Stand der Seite sie gilt – bei laufenden Nacharbeiten nach dem Launch verliert eine pauschale Freigabe schnell ihre Aussagekraft.

Für wiederkehrende Relaunches oder regelmäßige Updates lohnt sich eine feste Vorlage, die bei jedem Durchgang gleich aussieht. Das beschleunigt nicht nur die Arbeit, sondern macht Ergebnisse über mehrere Audits hinweg vergleichbar. So lässt sich erkennen, ob sich bestimmte Fehlerarten wiederholen und ob im Entwicklungsprozess grundsätzlicher nachgebessert werden muss, statt jedes Mal dieselben Symptome zu behandeln.

Nacharbeiten nach dem Go-Live: der zweite Audit-Zyklus

Ein Audit kurz vor der Freigabe deckt selten alles ab, was nach dem Launch tatsächlich passiert. Redakteure pflegen neue Inhalte ein, Marketing bindet neue Bannerkomponenten ein, und Tests verändern Layouts, ohne dass die ursprüngliche Prüfung davon wusste. Deshalb sollte ein erster Nach-Audit fest eingeplant werden, statt Barrierefreiheit als einmalig erledigtes Projekt zu behandeln.

In den ersten Wochen nach dem Go-Live lohnt sich ein enger Blick auf die Seiten mit dem höchsten Traffic und auf alle neu eingepflegten Inhalte. Gerade Redaktionssysteme erlauben es oft, Bilder ohne Alt-Text hochzuladen oder Überschriftenebenen frei zu wählen, wodurch Strukturen entstehen, die im ursprünglichen Audit noch korrekt waren und danach schleichend wieder kippen.

Sinnvoll ist außerdem ein technischer Regressionstest, der automatisiert bei jedem größeren Release mitläuft. Ein solcher Test ersetzt keine manuelle Prüfung, fängt aber grobe Fehler wie fehlende Formularbeschriftungen oder doppelte IDs früh ab, bevor sie in Produktion gehen und Nutzer tatsächlich betreffen.

Für Redakteure hilft eine kurze, verständliche Richtlinie, die ohne technisches Vorwissen auskommt: sinnvolle Alt-Texte statt Dateinamen, keine reinen Farbverweise wie „siehe roter Button“, korrekte Überschriftenhierarchie ohne Sprünge und Links mit aussagekräftigem Text statt wiederholtem „hier klicken“. Wird diese Richtlinie Teil der Redaktionsschulung, sinkt die Zahl neuer Barrieren spürbar, ohne dass jede Änderung einzeln durch das Entwicklungsteam muss.

Langfristig zahlt sich ein fester Rhythmus aus: ein technischer Kurzcheck monatlich, ein tieferer manueller Test halbjährlich oder bei größeren Funktionsänderungen. So bleibt die Freigabe vom Launch nicht die einzige Momentaufnahme, sondern der Startpunkt eines Prozesses, der mit der Seite mitwächst.

Häufig gestellte Fragen