Sichtbare Fokus-Indikatoren gestalten statt outline:none

1. Warum outline:none einer der schädlichsten Accessibility-Fehler ist

Kaum eine einzelne CSS-Zeile richtet in der Praxis so viel Schaden an wie outline: none oder outline: 0 ohne funktionierenden Ersatz. Der Browser zeichnet den Fokusrahmen standardmäßig, damit Tastaturnutzer, Screenreader-Nutzer mit Restsehvermögen und Menschen mit motorischen Einschränkungen jederzeit erkennen können, welches Element gerade aktiv ist. Wird dieser Rahmen entfernt, ohne dass ein gleichwertiger visueller Ersatz existiert, verlieren genau diese Nutzergruppen die Orientierung auf der Seite vollständig. Ein Klick auf den falschen Button, ein Formular, das nicht abgeschickt werden kann, weil unklar ist, welches Feld gerade aktiv ist, sind direkte Folgen.

Der Fehler entsteht meistens aus rein ästhetischen Gründen: Der browserseitige blaue Fokusrahmen passt nicht zum Design, also wird er per CSS-Reset großflächig entfernt, etwa über *:focus { outline: none; }. Diese Regel betrifft dann jedes fokussierbare Element der gesamten Seite, auch solche, die niemand bewusst gestaltet hat. Genau deshalb taucht dieser Fehler in Accessibility-Audits so häufig als kritischer Befund auf: Er ist leicht zu übersehen, weil er mit der Maus nicht auffällt, aber er blockiert die Bedienung für alle, die ausschließlich mit der Tastatur navigieren.

Die gute Nachricht: Das Problem lässt sich vollständig lösen, ohne auf ein durchdachtes visuelles Design zu verzichten. Statt den Fokusrahmen komplett zu entfernen, ersetzt man ihn durch einen eigenen, gestalteten Indikator, der zur Marke passt und trotzdem alle Kontrastanforderungen erfüllt. Die folgenden Abschnitte zeigen, wie das mit :focus-visible, klaren Kontrastwerten und praxistauglichem CSS gelingt.

2. Was WCAG 2.4.7 und 2.4.11 konkret verlangen

Das Success Criterion 2.4.7 Focus Visible der WCAG 2.1 verlangt, dass jede Benutzeroberfläche, die über die Tastatur bedienbar ist, auch einen sichtbaren Indikator besitzt, der zeigt, welches Element gerade den Fokus hat. Die Anforderung ist bewusst offen formuliert und schreibt keine konkrete Optik vor, aber sie schließt aus, dass der Fokus unsichtbar bleibt. Auf Level AA ist dieses Kriterium für die meisten kommerziellen Websites verpflichtend und wird in praktisch jedem Accessibility-Audit als erstes geprüft, weil es mit einem einfachen Tab-Durchlauf sofort erkennbar ist.

Mit WCAG 2.2 kam das schärfere Success Criterion 2.4.11 Focus Not Obscured (Minimum) hinzu: Der Fokusindikator darf nicht vollständig von anderen Inhalten wie Sticky-Headern, Cookie-Bannern oder Chat-Widgets verdeckt werden. Ein fokussiertes Element, das hinter einem fixierten Header verschwindet, verletzt dieses Kriterium, selbst wenn der Fokusring an sich korrekt gestaltet ist. Ergänzend definiert Success Criterion 1.4.11 Non-text Contrast die konkrete Kontrastanforderung: Der Fokusindikator muss einen Kontrastwert von mindestens 3:1 gegenüber den angrenzenden Farben erreichen, sowohl im fokussierten als auch im unfokussierten Zustand.

3. focus-visible: Fokus-Ringe nur für Tastaturnutzer

Ein berechtigter Einwand gegen sichtbare Fokusringe: Bei jedem Mausklick auf einen Button erscheint ein dicker Rahmen, obwohl visuell längst klar ist, welches Element aktiv ist. Genau dieses Problem löst die CSS-Pseudoklasse :focus-visible. Der Browser entscheidet heuristisch, ob ein Fokusereignis wahrscheinlich von einer Tastatureingabe stammt, etwa durch Tab, oder von einer Zeigereingabe wie einem Mausklick. Bei Tastaturfokus greift :focus-visible, bei einem einfachen Mausklick auf einen Button in der Regel nicht, während Formularfelder wie Text-Inputs auch bei Mausklick den Ring zeigen, weil dort die Eingabe sofort mit der Tastatur weitergeht.

Das Bash-Pattern für sauberen CSS-Aufbau lautet: :focus niemals komplett entfernen, sondern zunächst neutral gestalten oder auf :focus-visible auslagern, und für Browser ohne native Unterstützung das Polyfill focus-visible.js von WICG einsetzen. Wichtig ist, :focus-visible nicht mit :focus zu verwechseln: Wer nur :focus-visible stylt und :focus komplett auf outline: none setzt, verliert in älteren Browsern ohne Unterstützung jeden sichtbaren Indikator. Der sichere Weg kombiniert beide Selektoren mit einem Fallback-Wert.

/* Safe baseline: fallback for old browsers, clean ring for keyboard */
a, button, input, select, textarea, [tabindex] {
  /* Never remove entirely, only neutralize as a base */
  outline-offset: 2px;
}

/* Fallback for browsers without :focus-visible support */
a:focus, button:focus, input:focus, select:focus, textarea:focus {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

/* Precise: ring only on keyboard focus, not on mouse click */
a:focus:not(:focus-visible),
button:focus:not(:focus-visible) {
  outline: none;
}

a:focus-visible, button:focus-visible,
input:focus-visible, select:focus-visible, textarea:focus-visible {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
  border-radius: 4px;
}

4. Kontrastanforderungen an Fokus-Indikatoren erfüllen

Ein Fokusring, der zwar sichtbar ist, aber nur einen Kontrastwert von 1,5:1 gegenüber dem Hintergrund erreicht, erfüllt formal WCAG 2.4.7, scheitert aber praktisch an 1.4.11 Non-text Contrast. Die Mindestanforderung von 3:1 gilt für den Fokusindikator selbst gegenüber den unmittelbar angrenzenden Farben, in beiden Zuständen: Der Ring muss sich vom Hintergrund abheben und zusätzlich vom Element, das er umrahmt. Ein dunkelblauer Ring auf dunkelblauem Button-Hintergrund erfüllt diese Anforderung typischerweise nicht, selbst wenn der Ring gegenüber der Seite insgesamt ausreichend Kontrast hätte.

In der Praxis bewährt sich ein zweifarbiger Ansatz: ein heller, dünner outline direkt am Element und ein zusätzlicher box-shadow mit größerem Radius und Gegenfarbe. Diese Kombination funktioniert auf hellen wie dunklen Hintergründen zuverlässig, weil mindestens eine der beiden Farben immer ausreichend Kontrast zum jeweiligen Untergrund liefert. Tools wie der WebAIM Contrast Checker oder die Chrome-DevTools-Kontrastprüfung im Accessibility-Panel berechnen den tatsächlichen Kontrastwert zwischen Ringfarbe und Hintergrundfarbe und zeigen sofort, ob 3:1 erreicht wird.

/* Two-color focus ring: works on both light and dark surfaces */
.btn-primary:focus-visible {
  outline: 2px solid #ffffff;
  outline-offset: 2px;
  box-shadow: 0 0 0 4px #18181b;
}

/* Check contrast ratio: ring color vs. background color >= 3:1 */
.card--dark {
  background-color: #18181b;
}

.card--dark a:focus-visible {
  /* Light ring on dark background: guaranteed high contrast */
  outline: 2px solid #f4f4f5;
  outline-offset: 3px;
}

.card--light a:focus-visible {
  /* Dark ring on light background */
  outline: 2px solid #18181b;
  outline-offset: 3px;
}

5. Eigene Fokus-Ringe gestalten statt Browser-Default

Der browserseitige Standard-Fokusrahmen ist funktional korrekt, aber optisch selten passend zum eigenen Design-System. Statt ihn ersatzlos zu entfernen, lohnt sich die Investition in einen konsistenten, markengerechten Fokusstil, der auf allen interaktiven Elementen gleich funktioniert. Dabei helfen CSS-Custom-Properties: Eine einzige Variable wie --focus-ring-color zentral definiert, sorgt dafür, dass sich Farbe und Stärke des Rings projektweit an einer Stelle pflegen lassen, statt in jeder Komponente einzeln.

Wichtig ist außerdem outline-offset: Ein Ring, der direkt an der Kante des Elements ohne Abstand sitzt, verschmilzt bei abgerundeten Ecken oder engen Layouts optisch mit dem Element selbst. Ein Versatz von 2 bis 4 Pixeln schafft sichtbaren Raum zwischen Element und Ring und verbessert die Wahrnehmbarkeit deutlich, ohne zusätzlichen Platz im Layout zu beanspruchen, da outline anders als border keinen Einfluss auf den Box-Model-Fluss hat. Bei Elementen mit overflow: hidden im Elternelement muss zusätzlich geprüft werden, ob der Ring nicht abgeschnitten wird, da dies ein häufig übersehener Bug ist.

/* Central focus variables for the entire design system */
:root {
  --focus-ring-color: #18181b;
  --focus-ring-color-on-dark: #f4f4f5;
  --focus-ring-width: 2px;
  --focus-ring-offset: 3px;
}

/* Reusable utility class instead of duplicating per component */
.focus-ring:focus-visible {
  outline: var(--focus-ring-width) solid var(--focus-ring-color);
  outline-offset: var(--focus-ring-offset);
  border-radius: 0.375rem;
}

/* Automatically switch context on a dark background */
.bg-dark .focus-ring:focus-visible {
  outline-color: var(--focus-ring-color-on-dark);
}

/* overflow:hidden on the parent element clips rings: avoid this */
.card {
  overflow: visible; /* instead of hidden, when focusable children are present */
  padding: var(--focus-ring-offset);
}

6. Fokus-Stile für Buttons, Links, Formulare und Custom-Komponenten

Native HTML-Elemente wie <button>, <a href> und <input> erhalten Tastaturfokus automatisch, weil der Browser sie in die native Tab-Reihenfolge aufnimmt. Bei Custom-Komponenten wie einem per <div> gebauten Dropdown oder einer Kartenkomponente mit Klick-Handler fehlt dieses Verhalten vollständig, sofern nicht explizit tabindex="0" gesetzt und eine passende ARIA-Rolle wie role="button" vergeben wird. Wer ein <div> mit onclick als Button missbraucht, muss zusätzlich tabindex, Tastatur-Event-Handler für Enter und Leertaste sowie einen Fokusring von Hand nachrüsten, den native Buttons kostenlos mitbringen.

Formularfelder brauchen besondere Aufmerksamkeit, weil Validierungsfehler häufig zusätzliche visuelle Signale wie einen roten Rand verwenden. Der Fokusring darf dabei nicht mit dem Fehlerzustand kollidieren oder ihn überdecken: Beide Zustände müssen gleichzeitig erkennbar bleiben, etwa durch unterschiedliche Ring-Radien oder eine Kombination aus Randfarbe und Outline. Bei Custom-Select-Komponenten, die häufig mit Alpine.js oder ähnlichen Bibliotheken gebaut werden, muss der Fokusring auf dem sichtbaren Trigger-Element erscheinen, nicht auf dem oft visuell versteckten nativen <select> darunter.

<!-- Custom dropdown trigger: retrofit keyboard accessibility and focus ring manually -->
<div
    x-data="{ open: false }"
    class="relative inline-block"
>
  <button
      type="button"
      class="focus-ring inline-flex items-center gap-2 px-4 py-2 rounded-lg border border-zinc-300 bg-white text-sm font-medium"
      :aria-expanded="open"
      aria-haspopup="listbox"
      @click="open = !open"
      @keydown.escape="open = false"
  >
    Sortierung wählen
  </button>

  <ul
      x-show="open"
      x-cloak
      role="listbox"
      class="absolute mt-1 w-56 bg-white border border-zinc-200 rounded-lg shadow-lg py-1"
  >
    <li role="option" tabindex="0"
        class="focus-ring px-4 py-2 text-sm cursor-pointer hover:bg-zinc-50">
      Preis aufsteigend
    </li>
    <li role="option" tabindex="0"
        class="focus-ring px-4 py-2 text-sm cursor-pointer hover:bg-zinc-50">
      Preis absteigend
    </li>
  </ul>
</div>

7. Fokus-Management in Hyvä-Themes und Alpine.js

Hyvä-Themes ersetzen jQuery und Knockout.js durch Alpine.js, was für Fokus-Management sowohl Chancen als auch neue Sorgfaltspflichten mit sich bringt. Modale Dialoge wie der Mini-Cart oder das Such-Overlay müssen den Fokus beim Öffnen aktiv auf das erste fokussierbare Element im Dialog setzen und beim Schließen wieder auf das auslösende Element zurückgeben. Ohne dieses Fokus-Trapping springt der Tastaturfokus beim Öffnen eines Overlays ins Leere oder bleibt auf einem Element im Hintergrund stehen, das durch das Overlay optisch verdeckt ist, was für Tastaturnutzer extrem verwirrend ist.

Alpine.js bietet mit dem offiziellen @alpinejs/focus-Plugin eine direkte Lösung: Die Direktive x-trap hält den Fokus innerhalb eines geöffneten Elements gefangen, solange eine Bedingung wahr ist, und stellt beim Schließen automatisch den vorherigen Fokus wieder her. In Hyvä-Standardkomponenten wie dem Mini-Cart-Slideout oder dem mobilen Menü ist dieses Muster bereits häufig vorbereitet, sollte aber bei jeder eigenen Overlay-Komponente explizit geprüft werden, da ein fehlendes Fokus-Trapping in Accessibility-Audits regelmäßig als kritischer Befund auftaucht.

<!-- Hyva phtml: mini-cart overlay with focus trapping via the Alpine Focus plugin -->
<div x-data="{ open: false }">
  <button
      type="button"
      class="focus-ring"
      @click="open = !open"
      aria-haspopup="dialog"
      :aria-expanded="open"
  >
    Warenkorb öffnen
  </button>

  <div
      x-show="open"
      x-trap.inert.noscroll="open"
      role="dialog"
      aria-modal="true"
      aria-label="Warenkorb"
      @keydown.escape.window="open = false"
      class="fixed inset-y-0 right-0 w-full max-w-md bg-white shadow-xl"
  >
    <button type="button" class="focus-ring" @click="open = false">
      Schließen
    </button>
    <!-- Cart content -->
  </div>
</div>

8. Fokus-Indikatoren testen und automatisiert prüfen

Der schnellste manuelle Test für sichtbare Fokus-Indikatoren braucht keine Software: Maus beiseitelegen, mit der Tab-Taste durch die gesamte Seite navigieren und bei jedem Stopp prüfen, ob eindeutig erkennbar ist, welches Element aktiv ist. Besonders wichtig ist die Prüfung an Übergängen zwischen Komponenten, etwa vom letzten Link in der Navigation zum ersten Element im Hauptinhalt, sowie in Bereichen mit dunklem Hintergrund, wo helle Standardringe schnell verschwinden. Ein zweiter Durchlauf mit Shift+Tab rückwärts deckt zusätzlich Fälle auf, in denen die Tab-Reihenfolge nicht der visuellen Reihenfolge entspricht.

Für automatisierte Prüfungen eignet sich axe-core, das als Browser-Extension oder in CI-Pipelines über @axe-core/playwright beziehungsweise jest-axe läuft. axe-core erkennt zuverlässig fehlenden Fokusindikator-Kontrast und Elemente ohne sichtbaren Fokus, kann aber nicht automatisch prüfen, ob der Fokus bei dynamischen Overlays korrekt gesetzt wird. Für diese dynamischen Fälle bleibt der manuelle Tastaturtest unverzichtbar. Lighthouse und die Chrome-DevTools-Accessibility-Prüfung ergänzen die Kontrastmessung des Fokusrings zusätzlich mit einer visuellen Übersicht.

9. Fokus-Patterns im direkten Vergleich

Über alle vorherigen Abschnitte hinweg wird ein Muster deutlich: Fehlerhafte Fokus-Patterns entstehen fast immer aus denselben wenigen Ursachen, meist reiner Ästhetik oder Unwissenheit über die Kontrastanforderung. Die folgende Übersicht fasst die häufigsten Stolperfallen und die jeweils empfohlene Lösung zusammen, damit sich neue Komponenten von Anfang an am richtigen Muster orientieren, statt Fehler zu wiederholen, die in Audits ohnehin immer wieder auffallen.

Der Aufwand für ein sauberes Fokus-Pattern ist in jedem Fall gering, meist wenige Zeilen CSS und eine Plugin-Direktive, aber die Wirkung auf die tatsächliche Bedienbarkeit ist erheblich. Wer diese Patterns einmal projektweit als Utility-Klasse oder CSS-Custom-Property etabliert, muss sie nicht mehr für jede neue Komponente neu erfinden.

Entscheidend ist außerdem die konsequente Anwendung: Ein Shop, der auf der Startseite saubere Fokusringe zeigt, aber im Checkout-Formular oder im Custom-Dropdown des Produktfilters wieder auf outline: none zurückfällt, bleibt für Tastaturnutzer an genau den kritischen Stellen unzugänglich, an denen Barrierefreiheit rechtlich und geschäftlich am wichtigsten ist. Ein zentrales Fokus-Pattern, das über das gesamte Theme hinweg wiederverwendet wird, verhindert solche Inkonsistenzen zuverlässiger als Einzelfall-Korrekturen nach einem Audit.

10. Zusammenfassung

Sichtbare Fokus-Indikatoren sind kein optionales Design-Detail, sondern eine Grundvoraussetzung für die Bedienbarkeit jeder Website mit Tastatur oder assistiven Technologien. outline: none ohne Ersatz verstößt gegen WCAG 2.4.7 und macht die Seite für Tastaturnutzer faktisch unbenutzbar. Die Lösung liegt nicht im Verzicht auf gestalterische Kontrolle, sondern in einem bewusst designten Fokusring, der mit :focus-visible gezielt nur bei Tastaturfokus erscheint und mindestens 3:1 Kontrast zum Hintergrund erreicht.

Für Custom-Komponenten wie Dropdowns und Overlays kommt Fokus-Management als zweite Ebene hinzu: tabindex, passende ARIA-Rollen und in Hyvä-Themes das Alpine.js-Focus-Plugin mit x-trap sorgen dafür, dass der Fokus beim Öffnen eines Dialogs korrekt gesetzt und beim Schließen zuverlässig zurückgegeben wird. Regelmäßige Tastaturtests, ergänzt durch automatisierte Tools wie axe-core, decken Regressionen frühzeitig auf, bevor sie im Live-Betrieb zu echten Barrieren werden.

11. FAQ: Sichtbare Fokus-Indikatoren gestalten