Fokus-Erscheinungsbild

Was gefordert wird

2.4.7 (Fokus sichtbar) verlangt, dass der Indikator vorhanden ist. 2.4.13 (Fokus-Erscheinungsbild) legt genau fest, wie er aussehen muss. Zur Erfüllung muss der Fokusindikator:

1. Eine Fläche aufweisen, die mindestens so groß ist wie ein 2 CSS-Pixel breiter Rahmen um das fokussierte Steuerelement — oder eine 1 Pixel starke Linie mit entsprechend gleicher Gesamtfläche.
2. Einen Kontrast von 3:1 zwischen dem fokussierten und dem unfokussierten Zustand derselben Pixel erreichen.
3. Nicht durch andere Inhalte verdeckt werden (was auch in den Bereich von 2.4.11 / 2.4.12 fällt).

Dies ist das erste Mal, dass WCAG Zahlen für die Fokusgestaltung vorgibt — und es hat die Art und Weise verändert, wie Design-Systeme Tastaturstile handhaben. In Barrierefreiheits-Audits 2026 wird dieses Kriterium namentlich aufgeführt werden.

Erfüllungshinweise

• Einen durchgehenden Rahmen von mindestens 2 Pixel Stärke verwenden. Gängiges Muster: outline: 2px solid currentColor; outline-offset: 2px;.
• Eine Fokusfarbe wählen, die 3:1 gegenüber der angrenzenden Farbe erreicht — nicht nur gegenüber dem Seitenhintergrund, denn Schaltflächen liegen auf Hover-Zuständen, Verläufen, Bildern.
• Für Dunkel- und Hellmodus zwei Fokusfarben bereitstellen und per prefers-color-scheme oder Token-Theming umschalten.
• Nicht auf einen Schein- oder box-shadow-Leuchteffekt mit geringem Kontrast setzen; beim Einsatz von box-shadow eine harte Kante und ausreichende Stärke sicherstellen.
• :focus-visible bevorzugen, damit Mausbenutzende den Rahmen nicht sehen — aber sicherstellen, dass er bei jedem Tastaturfokus ausgelöst wird, einschließlich programmatischen Fokus.

:focus-visible {
  outline: 2px solid #1d4ed8;       /* 3:1 gegen Weiß und graue Hover-Zustände */
  outline-offset: 2px;
  border-radius: inherit;
}

Häufige Fehler

• 1-Pixel-Fokusrahmen (die meisten Browser-Standards vor Komponentenbibliotheken aus 2023).
• Markenblaue Fokusrahmen auf einem markenblauen Schaltflächen-Hover-Zustand — identische Farbe, Kontrastverhältnis 1:1.
• Fokus, der nur durch einen weichen box-shadow gestaltet ist, ohne definierten Rand und auf gemusterten Hintergründen unsichtbar wird.
• Benutzerdefinierte Eingabefelder, bei denen der Fokuszustand nur die Rahmenfarbe, nicht aber die Stärke oder den Kontrast ändert — zu subtil, um zu zählen.
• „Eingebettete“ Fokusrahmen auf kleinen Symbol-Schaltflächen, die innerhalb der 16×16-Klickfläche gezeichnet werden und hinter dem Symbol unsichtbar sind.
• Komponenten, die auf weißem Hintergrund bestehen, aber beim Dunkelmodusvariante scheitern, die niemand getestet hat.

Praktische Kontrastprüfliste

Für jede interaktive Komponente alle Oberflächenzustände auflisten, auf denen sie liegen kann (Standard, Hover, Gedrückt, Deaktiviert, in einer Karte, in einem Modal, auf einem Hero-Bild), und prüfen, ob der Fokusrahmen gegenüber jedem davon 3:1 erreicht. Das ist aufwendig; Komponentenbibliotheken, die das nicht tun, werden mit versteckten Fehlern ausgeliefert. Storybook mit pa11y oder axe-playwright-Automatisierung rechnet sich hier.

Warum es wichtig ist

2.4.13 schließt die häufigste Lücke in 2.4.7: ein Fokusrahmen, der technisch vorhanden, aber zu dünn, zu kontrastarm oder positionsbedingt zu stark beschnitten ist, um nützlich zu sein. Nutzende mit Sehschwäche, die auf den Rahmen zur Fokusverfolgung angewiesen sind, erhalten eine messbare, prüfbare Garantie. Designer erhalten eine klare Regel, die sie vor dem Launch validieren können, anstatt sie danach auszuhandeln.

Selbst Teams, die sich formal nur zu AA verpflichten, übernehmen 2.4.13 zunehmend als Ziel — Fehler sind in Audits leicht erkennbar und in Klageverfahren leicht zu nutzen. Wenn aus WCAG 2.2 nur ein AAA-Erfolgskriterium übernommen werden soll, dann dieses.