Was Barrierefreiheits-Audits tatsächlich finden
Kontrastwerte sind der leichte Teil. Echte Arbeit machen Tastaturfallen, Fokusreihenfolge und Formulare, die nur visuell Sinn ergeben.
Teams erwarten, dass es bei einem Barrierefreiheits-Audit um Farbe geht. Kontrast ist tatsächlich der häufigste Einzelbefund und zugleich der billigste — meist eine Handvoll Token-Änderungen an einem Nachmittag.
Die Befunde, die echte Zeit kosten, sind strukturell. Ein Dialog, der den Tastaturfokus einsperrt. Ein eigenes Auswahlfeld, das ein Screenreader als Div ansagt. Ein Formular, bei dem der einzige Hinweis auf einen Validierungsfehler die rote Färbung ist.
Die Fokusreihenfolge ist das, was fast alle falsch machen, weil sie unsichtbar bleibt, solange man nicht darauf prüft. Stellt Ihr visuelles Layout die Hauptaktion nach vorn, das DOM sie aber nach hinten, erleben Tastaturnutzende eine andere Oberfläche als die, die Sie entworfen haben.
Das andere systemische Problem sind Fehlermeldungen, die für Menschen geschrieben sind, die das ganze Formular sehen. „Bitte korrigieren Sie die markierten Felder“ ist nutzlos, wenn Sie Markierungen nicht wahrnehmen können. Fehler müssen programmatisch mit ihrem Eingabefeld verknüpft und so formuliert sein, dass sie für sich allein stehen.
Wir lassen automatische Prüfungen inzwischen in der CI laufen und behandeln sie als Untergrenze, nicht als Ergebnis. Automatisierung findet vielleicht ein Drittel der echten Probleme; der Rest braucht einen Menschen mit Tastatur und Screenreader. Planen Sie das ein — in den meisten unserer Märkte ist das inzwischen gesetzliche Pflicht und keine Kür.