2.4.11 Fokus nicht verdeckt (Minimum)

1. Was ist das Ziel dieses Kriteriums?

Tastaturbedienung gehört zum Internet wie das Smartphone zur Mittagspause. Aber was passiert, wenn du mit der Tab-Taste durch eine Website navigierst und plötzlich nicht mehr siehst, wo du bist? Der Fokus ist da, versteckt sich aber hinter einem Cookie-Banner, einem fixierten Header oder einem Chat-Fenster.

Das Ziel von Erfolgskriterium 2.4.11 der WCAG ist daher klar: Wenn ein Element den Tastaturfokus erhält, muss es zumindest teilweise sichtbar bleiben. Kein fokussiertes Element darf durch andere Inhalte komplett verdeckt werden – sonst weiß niemand mehr, wo er sich gerade befindet.

2. Was fordert das Erfolgskriterium genau?

Ganz konkret geht es um eine Level-AA-Anforderung an die Sichtbarkeit des Tastaturfokus, die mit WCAG 2.2 neu hinzugekommen ist:

Grundregel: Erhält ein Bedienelement den Tastaturfokus, darf es nicht vollständig durch Inhalte verdeckt sein, die du als Autor:in erstellt hast.

Teilweise Verdeckung ist erlaubt: Im Unterschied zur AAA-Variante Fokus nicht verdeckt (erweitert) darf ein fokussiertes Element teilweise verdeckt sein – solange ein Teil sichtbar bleibt. Gut ist das trotzdem nicht: Je mehr verdeckt ist, desto schwerer erkennt man den Fokus.

Typische Verursacher von Verdeckungen:

• fixierte („sticky“) Header und Footer
• Cookie-Banner und Hinweisleisten
• nicht-modale Dialoge
• Chat-Fenster und eingeblendete Hilfen

Was die Hinweise im Normtext klarstellen:

• Können Nutzer:innen Inhalte selbst verschieben (etwa eine verschiebbare Werkzeugleiste), wird nur deren Ausgangsposition bewertet.
• Inhalte, die Nutzer:innen selbst geöffnet haben, dürfen den Fokus verdecken – wenn sich das fokussierte Element wieder sichtbar machen lässt, ohne den Fokus weiterzubewegen, z. B. indem man das Element mit Esc schließt.

Ein einfaches Beispiel: Ein Cookie-Banner am unteren Rand, hinter dem fokussierte Links beim Tabben komplett verschwinden, verletzt dieses Kriterium. In Ordnung ist er, wenn er modal ist – der Fokus also im Banner bleibt, bis er geschlossen wurde – oder wenn er so platziert ist, dass er nichts vollständig verdeckt.

3. Warum ist das wichtig für Barrierefreiheit?

Stell dir vor, du navigierst mit der Tastatur durch einen Onlineshop und willst den „Kaufen“-Button erreichen – aber ein Chat-Fenster verdeckt ihn komplett. Du weißt nicht, ob der Fokus angekommen ist oder ob die Seite hängt.

Ein nicht verdeckter Fokus schafft Barrierefreiheit, weil er:

• Menschen mit motorischen Einschränkungen hilft, die auf die Tastatur angewiesen sind
• Menschen, die Schalter oder Sprachsteuerung mit Tastaturbefehlen nutzen, den aktuellen Fokuspunkt zeigt
• Menschen mit Sehbehinderung unterstützt, die stark vergrößern – dabei nehmen fixierte Elemente schnell einen großen Teil des Bildschirms ein
• Menschen mit Aufmerksamkeits- oder Gedächtnisschwierigkeiten hilft, ihre Position zu verfolgen
• die Orientierung für alle verbessert, die gerade keine Maus verwenden können

Und nicht zuletzt: Es macht die Bedienung vorhersagbar und verlässlich. Ein sichtbarer Fokus nützt nur, wenn er nicht hinter etwas anderem liegt – deshalb ergänzt 2.4.11 das Kriterium Fokus sichtbar.

4. So setzt du das Kriterium erfolgreich um

Ob die Fokusführung funktioniert, entscheidet darüber, ob eine Website mit der Tastatur wirklich nutzbar ist. Hier ein paar bewährte Praxis-Tipps:

Grundregeln für einen sichtbaren Fokus:

• Verwende CSS scroll-padding, damit Browser fokussierte Elemente nicht hinter fixierten Bereichen einscrollen.
• Setze modale Dialoge richtig um – der Fokus bleibt im Dialog, bis er geschlossen wird.
• Prüfe alle Breakpoints deines responsiven Designs auf verdeckten Fokus.
• Gib Hinweisleisten und Bannern einen gut erreichbaren Schließen-Button, auch per Esc.

Technische Umsetzung:

/* Verhindert, dass der fixierte Header fokussierte Elemente verdeckt */
html {
  scroll-padding-top: 5rem;    /* mindestens Höhe des Headers */
  scroll-padding-bottom: 4rem; /* falls unten ein Banner fixiert ist */
}

Das solltest du tun:

• scroll-padding für fixierte Elemente nutzen
• Banner und Hinweise als echte modale Dialoge umsetzen oder so platzieren, dass sie nichts verdecken
• Mit reiner Tastaturbedienung testen
• verschiedene Bildschirmgrößen und Zoomstufen berücksichtigen

Das solltest du lassen:

• Cookie-Banner oder Hinweise dauerhaft über dem Inhalt schweben lassen
• den Fokus komplett hinter fixierten Elementen verschwinden lassen
• Tests bei hohen Zoomstufen vergessen – dort wachsen fixierte Bereiche mit

Prüfen: Automatische Tests erkennen verdeckten Fokus kaum zuverlässig. Gehe die Seite mit der Tab-Taste vollständig durch – vorwärts und rückwärts mit Shift + Tab – auf mehreren Bildschirmbreiten und bei 200 % Zoom. Mehr dazu findest du im Artikel Tastaturbedienung und Fokus.

5. Warum dieses Erfolgskriterium für Unternehmen relevant ist

2.4.11 ist neu in WCAG 2.2. Die EN 301 549, auf die sich BFSG und BITV 2.0 stützen, verweist derzeit auf WCAG 2.1 Level AA – ausdrücklich gefordert ist 2.4.11 damit (Stand Oktober 2026) nicht. Empfehlenswert ist es trotzdem: Ein Fokus, der zwar sichtbar gestaltet ist, aber hinter einem Banner liegt, hilft niemandem.

1. Mehr Menschen erreichen

Tastaturbedienung ist nicht nur für Menschen mit Behinderungen wichtig. Auch viele geübte Nutzer:innen, die schnell arbeiten wollen, nutzen die Tastatur. Eine klare Fokusführung macht deine Website für alle zugänglicher.

2. Weniger Abbrüche

Wer beim Navigieren den Fokus verliert, bricht ab. Besonders kritisch ist das in Bestellprozessen und Formularen – also genau dort, wo es für dich um Umsatz geht.

3. Weniger Support-Anfragen

„Ich weiß nicht, wo ich bin“ oder „Die Website reagiert nicht“ – solche Rückmeldungen entstehen oft durch verdeckten Fokus. Eine saubere Umsetzung spart Aufwand im Kundenservice.

Dieser Abschnitt informiert allgemein und ersetzt keine Rechtsberatung.

6. Das Erfolgskriterium im Wortlaut des W3C

Success Criterion 2.4.11 Focus Not Obscured (Minimum) (Level AA)

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

Note 1: Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this success criterion.

Note 2: Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.

Kurz gesagt: Ein Element mit Tastaturfokus darf nie vollständig von Inhalten der Website verdeckt sein; vom Nutzer verschiebbare oder selbst geöffnete Inhalte werden dabei gesondert betrachtet.