Die Grenzen der automatischen Prüfung.

Automatische Barrierefreiheits-Werkzeuge können nur einen Teil der WCAG-Kriterien testen; der Rest verlangt menschliches Urteil und erscheint im Bericht nie.

Das Gefährlichste an Barrierefreiheits-Werkzeugen ist nicht, dass sie Fehler machen — das tun sie meist nicht. Gefährlich ist, dass die Fragen, die sie nicht stellen, im Bericht nicht erscheinen. Ein Werkzeug führt dreißig Regeln aus, und Sie bestehen alle dreißig; der Bericht ist grün. In diesem Bericht gibt es keine Spur vom Fehlen der hundert Regeln, die nie liefen.

Das Ergebnis ist ein verbreiteter und teurer Trugschluss: Ein hoher Score wird für eine barrierefreie Website gehalten. Doch der Score ist nur die Antwort auf die gestellten Fragen — und der Wert einer Prüfung steckt weniger in den gestellten als in den nicht gestellten.

Worin die Werkzeuge wirklich gut sind

Der Zweck dieser Seite ist nicht, die Werkzeuge kleinzureden. Die automatische Prüfung erledigt in Sekunden eine von Hand unmögliche Arbeit und sollte in jedem Projekt laufen. Ihre Stärken sind klar, und alle sind Fragen, die eine Maschine definitiv beantworten kann.

1. Gibt-es-oder-nicht-Fragen — existiert das Alternativtext-Attribut, hat das Formularfeld ein Etikett, ist die Seitensprache deklariert, gibt es einen Dokumenttitel.
2. Numerische Schwellen — liegt der Textkontrast über 4,5:1. Sind die Farben bekannt, ist die Rechnung exakt.
3. Strukturelle Konsistenz — gibt es mehr als ein h1, springt die Hierarchie, wird dieselbe ID zweimal verwendet.
4. Ungültige Deklarationen — ist eine nicht existierende Rolle zugewiesen, trägt ein Attribut einen falschen Wert, zeigt ein ID-Verweis ins Leere.
5. Fokussierbarkeit — ist ein Element klickbar, aber nicht fokussierbar.

Jeder Punkt dieser Liste steht für echte Fehler, und die automatische Prüfung findet sie weit besser als ein Mensch. Auf einer Website mit Tausenden Bildern die ohne Alternative von Hand zu finden dauert Tage; das Werkzeug listet sie in Sekunden. Deshalb gehört die automatische Prüfung VOR die manuelle, nicht an ihre Stelle.

Was die Werkzeuge nicht sehen können

Die Grenze liegt darin, ob die Frage maschinell beantwortbar ist. Die folgenden Posten erzeugen echte Barrierefreiheitsfehler, doch keiner lässt sich automatisch verlässlich erkennen.

1. Die RICHTIGKEIT des Alternativtextes — der Text existiert, aber beschreibt er das Bild? Auch ein Dateiname ist Text, und das Werkzeug zählt ihn als gültig.
2. Die Aussagekraft des Linktextes — „Mehr lesen“ ist gültiger Linktext; ob er ohne Kontext verständlich ist, kann das Werkzeug nicht wissen.
3. Ob eine Überschrift wirklich eine ist — das h2 existiert, aber beschreibt es den Abschnitt darunter?
4. Nicht-Text-Kontrast — welcher Teil die Begrenzung des Elements ist, verlangt visuelles Urteil; die meisten Werkzeuge testen dieses Kriterium nicht.
5. Ob die Fokusreihenfolge Sinn ergibt — die Reihenfolge kann technisch gültig und für den Nutzer trotzdem sinnlos sein.
6. Ob die Fehlermeldung hilft — die Meldung existiert und ist gebunden, aber sagt sie dem Nutzer, was zu tun ist?
7. Die Richtigkeit der Tastaturverträge — die Komponente funktioniert mit der Tastatur, aber bietet sie das erwartete Tastenverhalten?
8. Das Unbehagen der Bewegung — die Animation existiert; keine Regel misst, ob sie vestibuläre Beschwerden erzeugt.

Was diese Liste teilt, ist auffällig: Alles besteht die Frage „existiert es“ und scheitert an „funktioniert es“. Die automatische Prüfung misst das Vorhandensein; die Hinlänglichkeit kann sie nicht messen. Und die meisten Barrierefreiheitsfehler entstehen nicht aus etwas Fehlendem, sondern aus etwas Unzureichendem.

Ein konkreter Fall

Ein auf dieser Website geschehenes und dokumentiertes Beispiel lehrt mehr als Abstraktion. In einer Runde sah das Barrierefreiheitsbild so aus: Lighthouse-Score 96, null axe-Verstöße. Nach jedem Indikator eine Website in gutem Zustand.

Zugleich maß die einzige sichtbare Begrenzung der Textfelder im Kontaktformular — dem einzigen Konversionspfad der Website — 1,29:1 Kontrast gegen den Grund. Die Schwelle von WCAG 1.4.11 ist 3:1. Wo ein Formularfeld beginnt und endet, war selbst für voll sehende Nutzer unklar — auf dem kritischsten Bildschirm der Website.

Die Wurzel war kein Werkzeugfehler. Die Kontrastregel von axe misst TEXT gegen den eigenen Hintergrund, und in dieser Messung war alles makellos. 1.4.11 stellt eine andere Frage — sie betrifft die Begrenzung des Elements — und das Werkzeug stellte sie nicht. Die Lücke entstand daraus, nicht zu prüfen, welche Frage das Werkzeug stellt.

Der Score war hoch, weil der Score diese Frage nicht stellte.

Geschichtete Prüfung

Der richtige Ansatz baut Schichten, statt einem Werkzeug oder einer Methode zu vertrauen. Jede Schicht fängt eine andere Fehlerklasse, und keine ersetzt eine andere.

1. Schicht 1 — die automatische Regelengine. Bei jedem Deployment, in Sekunden. Fängt: fehlende Attribute, ungültige Deklarationen, numerische Schwellenverstöße.
2. Schicht 2 — eigene Wächter. Projektspezifische Tests, die gemessene Entscheidungen einfrieren. Fängt: die Fragen, die das Werkzeug nicht stellt, die Sie aber kennen.
3. Schicht 3 — die Tastaturtour. Von Hand, zehn Minuten. Fängt: Fokusreihenfolge, Fokussichtbarkeit, Fallen, kaputte Komponenten.
4. Schicht 4 — die Screenreader-Tour. Von Hand, auf den kritischen Bildschirmen. Fängt: Aussagekraft, Ankündigung, Navigierbarkeit.
5. Schicht 5 — der echte Nutzer. Die wertvollste und die am seltensten gemachte. Fängt: alles, woran die anderen vier nie gedacht haben.

Die zweite Schicht wird am meisten übersprungen und trägt die höchste Rendite. Wird ein Fehler von Hand gefunden, beseitigt ihn die Korrektur einmal; ein Test, der ihn misst, verhindert seine Rückkehr dauerhaft. Genau das geschah im Formularfall oben — die Begrenzung wurde gerichtet und ein Wächter ergänzt.

Die allgemeine Lehre passt in einen Satz: Der gefährlichste Zustand der Barrierefreiheitsprüfung ist nicht der Fehler, der sich nicht finden lässt, sondern der Fehler, der nie GESUCHT wird. Ein grüner Bericht ist ein Anfang, kein Ergebnis.

Wenn der Score zum Ziel wird

Die Scores der automatischen Prüfung tragen eine zweite Gefahr, und sie betrifft nicht die Messung, sondern ihre Verwendung. Wird ein Score intern zum Ziel — „unser Barrierefreiheits-Score muss über 95 bleiben“ —, beginnt das Team, den Score zu heben, nicht die Barrierefreiheit.

Beide bewegen sich meist in dieselbe Richtung, aber wo sie sich trennen, gewinnt der Score. Einem Bild einen sinnlosen, aber vorhandenen Alternativtext zu geben hebt den Score und nützt keinem Nutzer. Eine Komponente vor dem Barrierefreiheitsbaum zu verstecken bringt die Warnungen über sie zum Schweigen und verschlechtert die Lage des Nutzers.

Der Score sollte deshalb als Indikator dienen, nicht als Ziel. Das richtige Ziel ist, dass auch der Teil der Checkliste abgeschritten wurde, der menschliches Urteil verlangt — und dafür gibt es keinen Score, nur ein Protokoll.

Wissen, welche Frage das Werkzeug stellt

Die praktische Zusammenfassung dieser Seite verdichtet sich in eine Gewohnheit: Besteht ein Werkzeug eine Regel, schauen Sie nach, was diese Regel GENAU misst. Misst die Kontrastregel den Text — oder auch die Begrenzung? Prüft die Alternativtext-Regel das Vorhandensein — oder auch den Inhalt? Prüft die Fokusregel die Fokussierbarkeit — oder auch die Sichtbarkeit?

Die Antworten stehen in den Dokumentationen der Werkzeuge, und das Lesen dauert eine halbe Stunde. Diese halbe Stunde lehrt dauerhaft, was der Bericht beweist und was nicht — und einem grünen Bericht wird nie wieder mehr Bedeutung aufgeladen, als er trägt.

Dann folgt der zweite Schritt: die Fragen, die das Werkzeug nicht stellt, die Sie aber kennen, in eigene Tests zu verwandeln. Jede gemessene Projektentscheidung — ein Kontrastwert, eine Zielgröße, eine Flussregel — kann zum Wächter werden. Diese Wächter schließen die Lücke, die kein allgemeines Werkzeug je abdecken wird.