Der Fokusindikator.

Der Fokusindikator ist das visuelle Zeichen, das einem Tastaturnutzer zeigt, welches Element gerade ausgewählt ist.

Der Fokusindikator ist das im Web am häufigsten absichtlich gelöschte Barrierefreiheitsmerkmal. Der Grund ist fast immer ästhetisch: Der Standardring des Browsers passt nicht zum Design, jemand schreibt eine CSS-Regel, die ihn entfernt — und von diesem Moment an navigiert der Tastaturnutzer blind durch die Website.

Das Tragische: Die Lösung ist nicht schwer. Statt den Ring zu entfernen, einen eigenen zu gestalten ist Arbeit von wenigen Zeilen — sie bewahrt das Design und erfüllt zugleich das Kriterium.

Drei getrennte Kriterien

WCAG 2.2 behandelt den Fokus in drei getrennten Erfolgskriterien, und jedes fragt etwas anderes.

1. 2.4.7 Fokus sichtbar — AA. Der Tastaturfokus muss sichtbar sein. Das ist die Grundanforderung.
2. 2.4.11 Fokus nicht verdeckt (Minimum) — AA, neu in 2.2. Das fokussierte Element darf von klebendem Header, Cookie-Banner oder Chat-Blase nicht VOLLSTÄNDIG verdeckt werden.
3. 2.4.13 Fokusdarstellung — AAA, neu in 2.2. Eine numerische Basis für Dicke und Kontrast des Indikators: mindestens 2 CSS-Pixel Dicke und 3:1 Kontrast zwischen fokussiertem und unfokussiertem Zustand.

Zusammen bedeuten die drei: Der Fokus wird sichtbar sein, nicht verdeckt werden und deutlich genug sein. Auf den meisten Websites wird das Erste erfüllt, das Zweite bricht aus Versehen, das Dritte wird nie bedacht.

Gestalten statt löschen

Die Regel, die den Standard-Fokusring entfernt, ist, für sich allein geschrieben, ein Kriterienverstoß. Aber ihn zu entfernen und den eigenen Indikator an seine Stelle zu setzen ist völlig legitim — und liefert meist ein besseres Ergebnis, denn der Browser-Standard kennt Ihre Palette nicht.

Ein guter eigener Fokusindikator hat vier Eigenschaften.

1. Dick genug — mindestens 2 CSS-Pixel. Eine dünne Linie verschwindet auf niedrig auflösenden Bildschirmen und unter Vergrößerung.
2. Kontrastreich genug — sowohl gegen das fokussierte Element als auch gegen seine Umgebung unterscheidbar. 3:1 ist die Basis, höher ist besser.
3. Vom Element abgesetzt — wenige Pixel Abstand zwischen Ring und Element trennen den Indikator vom eigenen Rand des Elements.
4. Überall konsistent — derselbe Indikator an jeder Komponente. Ein je Komponente wechselnder Fokus erschwert das Lernen.

Auf dieser Website verwendet der Fokusring die Akzentfarbe, und diese Farbe misst gegen den Papiergrund 10,22:1. Die Dicke: 2 Pixel. Er erfüllt sowohl 2.4.7 als auch die numerische Basis von 2.4.13 — und das ist das Ergebnis einer einzigen Token-Entscheidung.

Die Trennung von Maus und Tastatur

Die echte Beschwerde hinter dem Wunsch, den Fokusring zu entfernen, lautet meist: Der Ring erscheint auch beim MAUSKLICK auf einen Button, und dort wirkt er überflüssig. Die Beschwerde ist berechtigt — ein Mausnutzer braucht keinen Fokusindikator.

Modernes CSS löst genau das. Es gibt einen Selektor, der den Fokusring nur zeigt, wenn per Tastatur angekommen wird, und der Browser entscheidet nach der Eingabemethode. Beim Mausklick erscheint kein Ring, bei Tab schon.

Das ist die technische Antwort auf die Debatte „entfernen wir den Ring“: Entfernen ist unnötig, Konditionieren genügt. Und eine wichtige Warnung — für ältere Browser muss auch der allgemeine Fokus-Selektor bleiben; wer sich nur auf den neuen stützt, lässt den Fokus in nicht unterstützenden Browsern völlig unsichtbar.

Den Fokusring zu entfernen ist keine Designentscheidung, sondern der Ausschluss einer Nutzergruppe von der Website.

Die Falle des klebenden Headers

2.4.11 ist die am häufigsten gebrochene neue Klausel der WCAG 2.2, und die Ursache ist ein verbreitetes Designmuster: der Header, der beim Scrollen oben bleibt.

Das Szenario: Der Nutzer tabbt die Seite hinab. Der Browser scrollt, um das fokussierte Element in den sichtbaren Bereich zu bringen — und platziert es genau unter dem klebenden Header. Das Element ist technisch „im sichtbaren Bereich“; für den Nutzer ist es unsichtbar.

Die Lösung erledigt eine einzige CSS-Eigenschaft: Fokussierbaren Elementen wird ein Abstand zugewiesen, der beim Scrollen über ihnen freigehalten wird, größer als die Höhe des Headers. Der Browser berücksichtigt diesen Raum, wenn er das Element heranholt.

Dieselbe Falle existiert am unteren Rand: Ein fixes Cookie-Band oder eine Chat-Blase verdeckt die Elemente am Seitenende. Der Test ist einfach — gehen Sie die Seite mit Tab durch und stellen Sie sicher, dass Sie das fokussierte Element bei jedem Schritt SEHEN. Jeder Schritt, bei dem Sie es nicht sehen, ist ein Verstoß.

Fokusverwaltung: Ebenen und Dialoge

Der Fokus muss nicht nur sichtbar sein, sondern auch am richtigen Ort. Wohin der Fokus geht, wenn sich eine Ebene öffnet, bestimmt das Erlebnis des Tastaturnutzers vollständig.

Das richtige Verhalten: Beim Öffnen der Ebene wandert der Fokus hinein; solange sie offen ist, erreicht Tab den Inhalt dahinter nicht; und beim Schließen kehrt der Fokus zum öffnenden Element zurück. Der dritte Teil wird am häufigsten übersprungen — der Fokus fällt an den Seitenanfang, und der Nutzer verliert seinen Ort.

Die zu wahrende Balance: Den Fokus in der Ebene zu halten ist nötig, aber den Ausgang per Escape zu blockieren ist ein Verstoß gegen 2.1.2. Der Fokus soll in der Ebene kreisen, doch der Nutzer muss sie jederzeit schließen können. Beides widerspricht sich nicht — das eine ist Einfassung, das andere der Fluchtweg.

Fokusring und Design: ein falscher Widerspruch

Die Begründung hinter dem Löschen des Fokusindikators ist fast immer ästhetisch, und diese Begründung errichtet einen Widerspruch zwischen Design und Barrierefreiheit, den es nicht gibt. Der Standardring des Browsers passt wirklich zu den meisten Designs nicht — blau, dick, hartkantig. Aber was das Kriterium verlangt, ist nicht dieser Ring, sondern EIN sichtbarer Indikator.

Der Indikator kann viele Formen annehmen, und keine muss das Design brechen. Eine dünne Außenlinie in der eigenen Akzentfarbe des Elements, ein deutlicher Wechsel der Grundfarbe, eine verdickte Unterstreichung oder ein abgesetzter Ring um das Element — alles ist gültig, und alles lässt sich nach Ihrer Palette gestalten. Die Beschränkung ist nur numerisch: dick genug und kontrastreich genug.

Auf dieser Website verwendet der Fokusring die einzige Akzentfarbe der Seite, und diese Farbe ist in der Palette bereits definiert. Der Fokusindikator ist kein von außen importiertes Fremdelement, sondern Teil der Designsprache. Zwei Pixel dick, 10,22:1 gegen den Papiergrund — er erfüllt bequem 2.4.7 und die numerische Basis des AAA-Kriteriums 2.4.13, und es hat nichts gekostet.

Das Problem ist nicht, dass der Fokusring hässlich ist; es ist, dass Sie keinen eigenen gestaltet haben.

Der einzige verlässliche Testweg

Fokusindikator-Fehler werden von automatischen Werkzeugen fast nie gefangen. Damit ein Werkzeug die Frage „ist der Fokus sichtbar“ beantworten könnte, müsste es den fokussierten und den unfokussierten Zustand rendern und vergleichen — machbar, aber die meisten verbreiteten Werkzeuge tun es nicht. Die Methode bleibt also manuell und besteht aus drei Schritten.

1. Gehen Sie die Seite mit Tab von Anfang bis Ende durch — SEHEN Sie bei jedem Schritt, wo der Fokus ist? Jeder Schritt ohne ist ein Verstoß gegen 2.4.7.
2. Wiederholen Sie die Tour bei gescrollter Seite — verdeckt der klebende Header oder das untere Band das fokussierte Element? Wenn ja: Verstoß gegen 2.4.11.
3. Gehen Sie dunkles und helles Thema getrennt durch — ein Ring mit genug Kontrast im einen Thema kann im anderen unter die Schwelle fallen. Zwei Themen sind zwei Messungen.

Der dritte Schritt wird am häufigsten übersprungen. Die meisten Teams, die ein dunkles Thema ergänzen, prüfen die Textfarben und vergessen den Fokusring; das Ergebnis ist ein auf dunklem Grund fast unsichtbarer Indikator. Weil der Fehler nur Tastaturnutzer und nur im dunklen Thema betrifft, kann er Monate unbemerkt leben.

Die dauerhafte Lösung ist, diese drei Schritte an einen Test zu binden. Dass das fokussierte Element wirklich einen sichtbaren Indikator trägt und dessen Kontrast über der Schwelle bleibt, lässt sich bei jedem Deployment automatisch verifizieren. Einmal von Hand getestet besteht es — und bricht mit der nächsten Komponente lautlos.