Fokus darf nicht verdeckt sein (Focus not obscured)

von Rashid Bairamov

Der sichtbare Tastaturfokus ist ein zentrales Orientierungsmittel für Menschen, die mit der Tastatur oder unterstützenden Technologien navigieren. Er zeigt, welches Element gerade aktiv ist und mit welchem die Interaktion möglich ist.

Wird dieser Fokus durch andere Elemente verdeckt, verlieren Nutzer:innen schnell die Kontrolle. Das kann dazu führen, dass eine Website für ganze Gruppen nicht mehr zugänglich ist:

  • Menschen mit motorischen Einschränkungen, die ausschließlich die Tastatur nutzen,

  • Personen mit Sehbehinderungen (z. B. mit Vergrößerungssoftware oder Screenreadern),

  • Nutzer:innen von alternativen Eingaben (z. B. Sprache, Eye-Tracking).

Darum wurden in WCAG 2.2 neue Erfolgskriterien eingeführt:

  • 2.4.11 Focus Not Obscured (Minimum, Stufe AA) – das fokussierte Element muss zumindest teilweise sichtbar bleiben.

  • 2.4.12 Focus Not Obscured (Enhanced, Stufe AAA) – das fokussierte Element muss vollständig sichtbar sein.

 

Hier einige Beispiele von Problemen:

Fixierte Header oder Banner

Beim Scrollen wird der Fokus von einem festen Header überdeckt.
Beispiel: Das Navigationsmenü liegt über einem aktiven Eingabefeld.

Cookie-Banner oder Werbeeinblendungen

Ein undurchsichtiger Banner verdeckt Bedienelemente.
Beispiel: Mit der Tabulator-Taste springt der Fokus auf eine Schaltfläche, die im Banner verschwindet.

Tooltips und Popovers

Ein Tooltip liegt direkt über der Schaltfläche und verdeckt die Fokusmarkierung.
Beispiel: Ein Hinweis blockiert die Sicht auf eine Checkbox.

Falsch umgesetzte modale Dialoge

Der Hintergrund bleibt aktiv, und der Fokus wandert zu Elementen außerhalb des Modals.
Beispiel: Nutzer:innen verlieren die Orientierung und können das Fenster nicht schließen.

 

Best Practices und Lösungen

 

1. Scroll-Verhalten steuern

Mit scroll-padding im CSS lässt sich Platz für feste Elemente reservieren:

html {
  scroll-padding-top: 80px; /* Höhe des fixierten Headers */
}

So bleibt der Fokus sichtbar, auch wenn er per focus() angesteuert wird.

 

2. Modale Dialoge korrekt umsetzen

  • Den Hintergrund blockieren:

<div role="dialog" aria-modal="true">
  …
</div>

  • Beim Öffnen den Fokus ins Modal verschieben.

  • Beim Schließen den Fokus an das Ausgangselement zurückgeben.

 

3. Cookie-Banner und Hinweise

  • Banner als modal gestalten (Hintergrund blockieren) oder fixiert am oberen Rand platzieren.

  • Wichtige Navigationselemente nicht überdecken.
    Ein undurchsichtiger Banner, der Bedienelemente verdeckt, verstößt gegen 2.4.11.

 

4. Tooltips und Overlays

  • Den fokussierten Bereich niemals vollständig verdecken.

  • Hinweise neben dem Element platzieren, nicht darüber.

  • Für Tooltips Abstände definieren:

.tooltip {
  margin-top: 8px;
}

 

5. Testen

  • Manuelle Prüfung: Mit der Tab-Taste durch die Seite navigieren und sicherstellen, dass der Fokus immer sichtbar bleibt.

  • Hilfreiche Tools:

    • axe DevTools – automatische Accessibility-Prüfungen,

    • Chrome DevTools → Accessibility-Panel,

    • TPGi Colour Contrast Analyser für Sichtbarkeit und Kontrast.

 

Häufige Fehler

 

  • outline: none; ohne sichtbare Alternative,

  • halbtransparente Overlays über Buttons oder Formularen,

  • Sticky-Elemente ohne Berücksichtigung ihrer Höhe,

  • falsche Modallogik (fehlendes aria-modal, falscher tabindex).

 

Die Erfolgskriterien 2.4.11 und 2.4.12 „Focus not obscured“ sind mehr als eine reine WCAG-Anforderung. Sie erhöhen die Benutzbarkeit für alle.

Mit wenigen Anpassungen – wie scroll-padding, korrekt umgesetzten Modals oder durchdachten Bannern – werden Webseiten verständlicher, bedienbarer und deutlich zugänglicher.