Welcher Anteil der bei manuellen Audits oder durch Nutzende gefundenen Barrierefreiheitsmängel hatte die automatisierten Prüfungen in der CI bestanden, und welche Arten entgingen ihnen?

Offene Frage

Automatisierte Barrierefreiheitsprüfer sind günstig im Betrieb: Eine Regel-Engine untersucht bei jedem Build das gerenderte DOM und lässt die Pipeline bei fehlendem Alternativtext, niedrigem Kontrast, Formularelementen ohne Beschriftung oder ungültigen ARIA-Attributen scheitern. Die W3C-WAI-Anleitung zur Auswahl von Evaluationswerkzeugen sagt ausdrücklich, dass Werkzeuge Zeit sparen, aber nicht alles leisten können, weil sich manche Barrierefreiheitsprüfungen nicht automatisieren lassen und manuelles Eingreifen erfordern. Die Versuchung besteht dennoch darin, einen grünen automatisierten Lauf als „Barrierefreiheit erledigt“ zu behandeln, weil ein manuelles Audit Geld kostet und Nutzerrückmeldungen über Support-Kanäle statt über den Build eintreffen.

Was dem Wiki fehlt, ist eine Aufzeichnung dieser Lücke bei realen Websites. Wenn bei einer Website, deren Builds bereits einen automatisierten Prüfer bestanden hatten, ein manuelles Audit durchgeführt wurde (eine Expertenprüfung mit Screenreader und Tastatur oder eine Sitzung mit Menschen mit Behinderung), welcher Anteil der gefundenen Mängel war bereits auf den geprüften Seiten vorhanden und trotzdem durchgerutscht? Welche Mängeltypen dominieren diesen Anteil: Fokusreihenfolge und Fokusverlust, Tastaturfallen in eigenen Widgets, technisch beschrifteter, aber bedeutungsloser Linktext, falsche Lesereihenfolge, Statusmeldungen, die nie angesagt werden, Alternativtext, der vorhanden, aber falsch ist, Bewegung, die sich nicht pausieren lässt? Und umgekehrt: Welcher Anteil der automatisierten Befunde erwies sich für keine Nutzerin und keinen Nutzer der Website als relevant, sodass das Team lernte, das Werkzeug zu ignorieren? Schrumpft die Lücke, wenn der automatisierte Lauf skriptgesteuerte Tastaturinteraktion einschliesst oder wenn die Komponentenbibliothek selbst geprüft wurde, sodass die verbleibenden Mängel eher in der Seitenzusammensetzung als in den Komponenten liegen?

Die Antwort entscheidet, wohin der begrenzte Barrierefreiheitsaufwand eines kleinen Teams fliessen sollte: mehr Regeln in der CI, ein periodischer manueller Durchgang oder ein Design-System-Audit.

Was eine nützliche Antwort enthält

Der Website-Typ, das Framework und die Komponentenbibliothek sowie der Prüfer mit seinem Regelsatz und seiner Version. Die Anzahl der Seiten, die der automatisierte Lauf und das manuelle Audit abdeckten. Je manuell gefundenem oder von Nutzenden gemeldetem Mangel: das betroffene Erfolgskriterium, ob die Seite den automatisierten Lauf bestanden hatte, und ob im Werkzeug eine Regel dafür existiert, aber nicht ausgelöst hat. Je automatisiertem Befund im selben Zeitraum: ob er behoben, unterdrückt oder als falsch positiv eingestuft wurde, mit Begründung. Die Auditmethode (Expertenprüfung, Test mit assistiver Technologie, Nutzersitzung), da jede andere Dinge findet. Ob das Team daraufhin etwas geändert hat: Regeln ergänzt, eine manuelle Checkliste in die Prüfung aufgenommen oder Komponenten ersetzt. Berichte zu einer einzelnen Website sind willkommen, sofern Regelsatz und Auditmethode angegeben sind; Vergleiche über mehrere Websites mit demselben Werkzeug sind nützlicher.