Nicht-Text-Kontrast: das Problem des unsichtbaren Buttons.

WCAG 1.4.11 verlangt, dass Bedienelemente und bedeutungstragende Grafiken gegen ihre Umgebung mindestens 3:1 Kontrast tragen — eine vom Textkontrast völlig getrennte Messung.

Dies ist die in Barrierefreiheitsprüfungen am häufigsten übersehene Klausel, und der Grund des Übersehens ist technisch interessant: Die meisten verbreiteten automatischen Werkzeuge testen sie überhaupt nicht. Weil sie sie nicht testen, erscheint sie nicht im Bericht; weil sie nicht im Bericht steht, kennt das Team das Problem nicht; und weil der Score hoch ist, sucht niemand danach.

Diese Seite erklärt zuerst, was das Kriterium sagt, dann einen konkreten Fall von dieser Website — denn abstrakte Erklärung funktioniert bei dieser Klausel nicht.

Was das Kriterium sagt

1.4.11 „Nicht-Text-Kontrast“ liegt auf Stufe AA und umfasst zwei Dinge: Bedienelemente der Nutzeroberfläche und bedeutungstragende Grafiken. Die Schwelle ist für beide 3:1.

1. Bedienelement — die visuelle Information, die nötig ist, um zu verstehen, was ein Element ist und in welchem Zustand. Die Begrenzung eines Textfeldes, der Rahmen einer Checkbox, der Körper eines Schalters.
2. Bedeutungstragende Grafik — visuelle Elemente, die Information tragen. Die Linie in einem Diagramm, das Icon selbst, ein Warndreieck.
3. Außerhalb des Geltungsbereichs — reine Dekoration, deaktivierte Elemente und Logos. Für sie gilt keine Schwelle.
4. Was gemessen wird — nicht der TEXT des Elements, sondern seine BEGRENZUNG oder sein Körper. Zwei völlig verschiedene Messungen.

Der letzte Punkt ist der Kern des Kriteriums und die am meisten verwechselte Stelle. Die Beschriftung eines Buttons kann gegen ihren Grund 18:1 messen; misst der Button selbst gegen die Seite 1:1, ist 1.4.11 verletzt. Die Schrift liest sich — aber wo der Button beginnt und endet, ist nicht zu sehen.

Warum das zählt, wird beim Nachdenken offensichtlich: In ein Formularfeld, dessen Ort man nicht kennt, kann man nicht klicken. Für sehschwache Nutzer ist eine unklare Begrenzung fast dasselbe wie ein nicht existierendes Feld. Das ist keine ästhetische Feinheit, sondern eine funktionale Barriere.

Der Fall auf dieser Website

Ein konkretes Protokoll, damit die Erzählung nicht abstrakt bleibt. In einer Prüfrunde sah das Barrierefreiheitsbild dieser Website so aus: Lighthouse-Score 96, null axe-Verstöße. Eine nach jedem Maß gute Tabelle.

Zugleich maß die einzige sichtbare Begrenzung der Textfelder im Kontaktformular — dem einzigen Konversionspfad der Website — eine dünne Unterstreichung, 1,29:1 gegen den Grund. Die Schwelle ist 3:1. Wo ein Feld beginnt und endet, war selbst für voll sehende Nutzer unklar.

Ein zweiter Fehler kam in derselben Runde ans Licht: Der Text eines Buttons auf einem dunklen Band maß gegen seinen Grund 18,15:1 — makellos. Der KASTEN des Buttons maß gegen das Band 1,00:1. Der Button war buchstäblich unsichtbar; nur seine Beschriftung war zu sehen.

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

Bis zur Wurzel vorgedrungen ist es klar: Die Kontrastregel von axe misst nur TEXT gegen den eigenen Hintergrund. In beiden Fällen war der Text makellos, also bestand die Regel. 1.4.11 stellt eine andere Frage — sie betrifft die Begrenzung des Elements — und keine Einstellung von axe stellte sie.

Die Lücke war kein Werkzeugfehler. Die Lücke entstand daraus, nicht zu prüfen, WELCHE FRAGE das Werkzeug stellt.

Die Korrektur und der Wächter

Die Begrenzung des Formularfeldes wurde auf 3,13:1 angehoben. Der Wert wurde bewusst knapp über der Schwelle gehalten: Eine dunklere Linie war möglich, hätte aber den ruhigen Charakter des Formulars gebrochen. Barrierefreiheit arbeitete hier als Entwurfsbeschränkung, nicht als Regel, die das Design erdrückt.

Auch der Kasten des Buttons wurde sichtbar gemacht. Aber die eigentliche dauerhafte Korrektur war keines von beiden: Beide Messungen wurden an einen Test gebunden. Die Suite liest jetzt echte Pixelwerte von der Live-Seite und verifiziert bei jedem Lauf, dass die Feldbegrenzung über 3:1 bleibt.

Diese Unterscheidung ist kritisch. Einen Fehler zu beheben beseitigt ihn einmal; einen Wächter zu ergänzen verhindert seine Rückkehr. Der Großteil der Barrierefreiheitskorrekturen wird in späteren Deployments lautlos zurückgenommen — eine neue Komponente, eine neue Farbe, ein neues Band. Mit Wächter zeigt sich die Rücknahme im Moment ihres Geschehens.

Wie man auf der eigenen Website danach sucht

1.4.11-Fehler zu finden ist mit automatischen Werkzeugen schwer und von Hand leicht. Die Methode ist einfach und dauert zehn Minuten.

1. Öffnen Sie das Formular und schauen Sie NICHT auf die Felder — verkleinern Sie den Bildschirm, kneifen Sie die Augen zu oder senken Sie die Helligkeit. Ist noch zu sehen, wo die Felder sind?
2. Trennen Sie jeden Button von seinem Grund — messen Sie den Kontrast zwischen Buttonkasten und dem Grund dahinter. Den Kasten, nicht die Beschriftung.
3. Prüfen Sie Checkboxen und Radiobuttons — eigens gestaltete brechen am häufigsten; Browser-Standards sind meist konform.
4. Klassifizieren Sie die Icons — trägt ein Icon allein Information (kein Text daneben), ist es bedeutungstragende Grafik und braucht 3:1.
5. Messen Sie Diagramme und Tabellen — jede Serie im Liniendiagramm muss gegen den Grund und gegeneinander unterscheidbar sein.
6. Vergessen Sie den Fokusring nicht — auch der Fokusindikator ist ein Bedienelement und braucht 3:1.

Der letzte Punkt ist besonders heimtückisch. Ein beim Standardblau belassener Fokusring fällt auf dunklem Grund leicht unter die Schwelle. Und dieser Fehler betrifft nur Tastaturnutzer — wer mit der Maus testet, sieht ihn nie.

Die allgemeine Lehre dieser Klausel passt in einen Satz: Der gefährlichste Zustand einer Barrierefreiheitsprüfung ist nicht der ungefundene, sondern der UNGESUCHTE Fehler. Ein grüner Bericht ist nur die Antwort auf die gestellten Fragen — und zu wissen, welche Fragen nicht gestellt wurden, ist die Verantwortung des Prüfenden.

Warum automatische Werkzeuge diese Klausel überspringen

Dass diese Klausel in automatischen Prüfungen fast nie auftaucht, hat einen technischen Grund, und ihn zu kennen hilft zu entscheiden, wie sehr dem Bericht eines Werkzeugs zu trauen ist. Textkontrast zu messen ist algorithmisch leicht: Es gibt einen Textknoten, seine Farbe ist bekannt, der Grund dahinter lässt sich berechnen, das Verhältnis folgt. Eine Elementbegrenzung zu messen ist ein ganz anderes Problem, denn das Werkzeug muss zuerst die Frage beantworten, „welches ist die Begrenzung dieses Elements“ — und diese Frage verlangt visuelles Urteil.

Die Begrenzung eines Textfeldes kann eine Unterstreichung sein, ein vierseitiger Rahmen, ein weicher Schatten oder bloß eine vom Seitengrund abweichende Füllfarbe. Alle vier sind gültige Entwurfslösungen, und damit ein Werkzeug entscheiden könnte, welche als „Begrenzung“ zählt, müsste es die Seite sehen wie ein Mensch. Das können die heutigen Werkzeuge nicht — also testen sie das Kriterium entweder gar nicht oder nur an Elementen mit ausdrücklich definierter Rahmeneigenschaft.

Im Ergebnis ist 1.4.11 das teuerste Mitglied der Kriterienmenge, die die automatische Prüfung nicht abdeckt: Gebrochen erzeugt es eine echte Nutzerbarriere, erscheint aber in keinem Bericht. Es muss deshalb von Hand gesucht werden — und solange es nicht gesucht wird, gilt es als nicht existent.

Checkliste: alles, was eine Begrenzung hat

Beim Suchen von Hand ist der Umfang schwer im Kopf zu behalten, weil das Kriterium in einem abstrakten Begriff wie „Bedienelement“ spricht. In der Praxis deckt die folgende Liste fast alle Situationen ab, in denen 1.4.11 auf echten Websites gilt, und sie lässt sich in einem zehnminütigen Durchgang abschreiten.

1. Textfelder und Textboxen — was immer die Begrenzung ist (Linie, Rahmen, Grunddifferenz): 3:1.
2. Checkboxen und Radiobuttons — besonders die eigens gestalteten; Browser-Standards sind meist konform.
3. Schalter — sowohl der Körper als auch die Markierung des Ein/Aus-Zustands.
4. Ghost-Buttons — das am häufigsten gebrochene Muster; der Kasten eines nur als Text existierenden Buttons ist unsichtbar.
5. Dropdown-Pfeile und Datumswähler-Icons — sie tragen Information, sie sind nicht dekorativ.
6. Fortschrittsbalken und Schieberegler — sowohl die Bahn als auch der Griff.
7. Serien in Diagrammen — jede Serie muss gegen den Grund und gegeneinander unterscheidbar sein; ein Farbunterschied allein genügt nicht.
8. Der Fokusring selbst — auch er ist ein Bedienelement und braucht 3:1.

Der letzte Punkt der Liste ist der heimtückischste und Gegenstand eines eigenen Beitrags: Weil der Fokusindikator nur Tastaturnutzer betrifft, bemerkt niemand, der mit der Maus testet, je seinen Kontrast. Auf dunklem Grund fällt der blaue Standardring leicht unter die Schwelle, und der Fehler kann Monate leben.

Die eigentliche Lehre des Falls auf dieser Seite ist nicht der Kontrastwert, sondern die Methode. Der Fehler wurde nicht durch den Bericht eines Werkzeugs gefunden, sondern durch die Frage „welche Frage stellt dieses Werkzeug“. Der gefährlichste Zustand einer Barrierefreiheitsprüfung ist nicht der Fehler, der sich nicht finden lässt, sondern der, der nie gesucht wird.