WCAG 2.4.11: Fokus nicht verdeckt (Minimum)

WCAG 2.4.11 verlangt, dass ein Bedienelement, das den Tastaturfokus erhält, nicht vollständig von Inhalten der Seite verdeckt wird – teilweise Verdeckung bleibt auf Stufe AA erlaubt. Gemeint sind vor allem klebende Kopf- und Fußleisten, Cookie-Banner und Chat-Fenster, unter denen der fokussierte Link beim Tabben verschwindet.

(Englisch: Focus Not Obscured (Minimum). Der BIK-BITV-Test führt den Prüfschritt unter demselben Namen.)

Das Wichtigste in Kürze

• Vollständig verdeckt ist der Verstoß, teilweise verdeckt nicht. Ein Streifen des fokussierten Elements muss sichtbar bleiben – wie breit dieser Streifen ist, legt der Normtext nicht fest.
• Die strengere Fassung ist 2.4.12 „Fokus nicht verdeckt (erweitert)“ auf Stufe AAA. Dort darf gar nichts überlappen. Wer auf AA prüft, bewertet nur vollständige Verdeckung.
• Verursacher Nummer eins ist der klebende Kopfbereich. Der Browser scrollt das Fokusziel exakt an den oberen Viewport-Rand – und genau dort sitzt der Header.
• Zwei CSS-Zeilen lösen den Regelfall: scroll-padding-top am html-Element oder scroll-margin-top an den fokussierbaren Elementen, jeweils in Höhe der klebenden Leiste.
• Vom Nutzer geöffnete Overlays dürfen verdecken – aber nur, wenn er sie ohne Fokusverschiebung wieder freiräumen kann, etwa mit Esc.
• Verschiebbare Elemente werden in ihrer Startposition bewertet. Zieht der Nutzer ein Werkzeugfenster selbst über den Fokus, ist das kein Mangel.
• Geprüft wird vorwärts und rückwärts. Mit Umschalt + Tab von unten nach oben fällt die Sticky-Falle meistens zuerst auf.
• Häufigste Fundstellen: Cookie-Banner als nicht-modaler Dialog am unteren Rand, Filterleisten in Shops, Chat-Widgets und die Fortschrittsleiste in mehrstufigen Formularen.

Mein Sticky-Header verdeckt den Fokus – ist das ein Fehler?

Ja, wenn er das fokussierte Element vollständig verdeckt. Teilweise Verdeckung bleibt auf Stufe AA erlaubt.

Der Normtext ist knapp: „Wenn ein Bestandteil der Benutzerschnittstelle den Tastaturfokus erhält, wird dieser Bestandteil nicht aufgrund von durch den Autor erstellten Inhalten vollständig verdeckt.“ Zwei Wörter tragen die ganze Anforderung.

„Vollständig“ zieht die Grenze zwischen AA und AAA. Auf Stufe AA darf der Fokusring zur Hälfte unter dem Header liegen, solange der Rest zu sehen ist. Erst 2.4.12 auf Stufe AAA verlangt, dass gar nichts überlappt. In Prüfberichten wird das regelmäßig verwechselt – wer nach AA prüft, notiert nur die Fälle, in denen vom fokussierten Element nichts mehr übrig ist.

„Durch den Autor erstellt“ grenzt ab, wofür du zuständig bist. Ein Popup des Browsers, eine eingeblendete Übersetzungsleiste, die Symbolleiste einer Erweiterung – alles nicht deine Baustelle. Dein Sticky-Header, dein Cookie-Banner, dein Chat-Widget schon.

Dazu kommen zwei Hinweise aus dem Normtext, die im Alltag oft den Ausschlag geben:

Vom Nutzer geöffnete Inhalte dürfen verdecken. Öffnet jemand selbst ein Ausklappmenü oder ein nicht-modales Fenster, das ein fokussiertes Element überlagert, ist das konform – solange er es ohne Verlust des Fokus wieder wegbekommt. In der Praxis heißt das: Esc schließt, die Bildlauftasten funktionieren weiter, und der Fokus bleibt, wo er war.

Verschiebbare Inhalte zählen nur in ihrer Ausgangsposition. Wenn ein Nutzer ein Werkzeugfenster über den halben Bildschirm zieht und dabei den Fokus zudeckt, ist das seine Entscheidung und kein Mangel deiner Seite. Verantwortlich bist du für die Position, mit der das Fenster startet.

Der vollständige Wortlaut steht im Understanding-Dokument des W3C zu 2.4.11; den deutschen Prüfablauf beschreibt der Prüfschritt 2.4.11 des BIK BITV-Tests.

Wen betrifft es besonders?

Sehende Tastaturnutzer sind die Kerngruppe. Sie navigieren über den sichtbaren Fokus – er ist ihr einziger Anhaltspunkt dafür, wo sie sich befinden. Verschwindet er unter einer Leiste, tabbt man blind weiter und drückt irgendwann Enter, ohne zu wissen, worauf. Das ist nicht bloß unbequem: In einem Formular kann es die falsche Schaltfläche auslösen.

Bei Bildschirmvergrößerung verschärft sich das Problem drastisch. Wer auf 400 % zoomt, sieht einen Ausschnitt, in dem ein Header von 80 Pixeln plötzlich ein Drittel der sichtbaren Höhe belegt. Was im Normalzoom noch halb sichtbar war, ist dann komplett weg. Genau deshalb gehört der Test bei kleinen Viewports und im Querformat wiederholt.

Menschen mit motorischen Einschränkungen, die per Switch-Scanning arbeiten, trifft es doppelt: Jeder Schritt kostet Zeit, und wer nicht sieht, wo der Fokus steht, muss die Kette von vorn durchlaufen.

Und dann die stille Mehrheit: Menschen, die Formulare mit Tab ausfüllen, weil es schneller geht. Die merken zwar, dass etwas nicht stimmt, greifen aber zur Maus – und tauchen in keiner Statistik auf.

Richtig & falsch im Code

Der Regelfall ist in drei Zeilen erledigt. Wichtig ist nur, dass der Puffer der tatsächlichen Höhe der klebenden Leiste entspricht:

/* Falsch: Sticky-Header ohne Scroll-Puffer.
   Der Browser scrollt das Fokusziel exakt an den oberen Rand –
   und genau dort klebt der Header darüber. */
.site-header {
  position: sticky;
  top: 0;
  height: 5rem;
}

/* Richtig: ein Puffer am Wurzelelement, einmal für die ganze Seite.
   Deckt Tab-Navigation, Sprungmarken und element.scrollIntoView() ab. */
html {
  scroll-padding-top: 6rem; /* Header 5rem + Luft */
}

scroll-padding-top an html ist der robustere Weg, weil es für jedes Scrollziel im Dokument gilt. Wenn du nur einzelne Elemente puffern willst – etwa in einem Bereich mit eigenem Bildlauf –, nimmst du scroll-margin-top am Element selbst:

/* Alternative: Puffer am Ziel statt am Container */
:focus,
:target {
  scroll-margin-top: 6rem;
}

/* Bei klebender Fußleiste zusätzlich nach unten */
html {
  scroll-padding-bottom: 4.5rem;
}

Ein Detail, das gern durchrutscht: Wenn die Kopfhöhe responsiv ist, muss der Puffer mitwandern. Eine Custom Property, die der Header selbst setzt, hält beides zusammen:

:root {
  --header-h: 3.5rem;
}
@media (min-width: 48rem) {
  :root {
    --header-h: 5rem;
  }
}
html {
  scroll-padding-top: calc(var(--header-h) + 1rem);
}

Die zweite Baustelle sind eigene Overlays. Ein Cookie-Banner, das als nicht-modaler Kasten am unteren Rand klebt, verdeckt beim Durchtabben genau die Elemente, die dort vorbeiscrollen. Drei Wege führen heraus – der erste ist der sauberste:

<!-- Richtig: das Banner erhält beim Laden den Fokus und ist
     danach vom Tisch, statt die ganze Sitzung mitzulaufen -->
<div role="dialog" aria-modal="true" aria-labelledby="cc-titel">
  <h2 id="cc-titel">Cookie-Einstellungen</h2>
  …
</div>

/* Richtig: Das Banner belegt echten Platz statt darüberzuliegen */
body:has(.cookie-banner:not([hidden])) {
  padding-block-end: 8rem;
}

/* Richtig: Ein Chat-Widget bekommt einen Bereich, in den
   der Seiteninhalt nicht scrollt */
html:has(.chat-widget[data-offen]) {
  scroll-padding-bottom: 22rem;
}

Was nicht hilft: den Fokusring einfach dicker machen. Ein verdecktes Element bleibt verdeckt, egal wie kräftig der Ring ist – das regelt 2.4.7, nicht 2.4.11. Und auch scroll-behavior: smooth hilft nicht: Es ändert nur, wie schnell gescrollt wird, nicht wohin.

So testest du es

1. In Firefox öffnen. Der BITV-Prüfschritt nennt Firefox ausdrücklich; die Browser unterscheiden sich darin, wie weit sie ein Fokusziel in den sichtbaren Bereich scrollen. Chrome kaschiert manche Fälle.
2. Die Seite komplett durchtabben – vorwärts. Auf Seiten mit klebendem Kopf, Filterleiste oder Fußbanner nach jedem Tab prüfen: Ist vom fokussierten Element noch etwas zu sehen?
3. Denselben Weg rückwärts mit Umschalt + Tab. Das ist der Test, der die Sticky-Falle findet: Von unten nach oben landet der Fokus systematisch an der Oberkante des Viewports – also unter dem Header.
4. Mit offenem Cookie-Banner wiederholen, bevor du zustimmst oder ablehnst. Genau in diesem Zustand betreten alle Besucher die Seite zum ersten Mal.
5. Chat-Widget und andere schwebende Elemente aufklappen und noch einmal durchtabben. Nicht-modale Dialoge sind laut Prüfschritt die klassische Fehlerquelle.
6. Kleine Viewports prüfen: 320 × 256 CSS-Pixel und das Querformat eines Smartphones. Dort belegen klebende Leisten den größten Anteil der Höhe.
7. Gegenprobe mit Sprungmarken: Einen Anker-Link im Inhaltsverzeichnis aktivieren. Landet die Zielüberschrift unter dem Header, fehlt der Puffer auch für die Tastaturnavigation.

Für die schnelle Sichtprüfung hilft ein Blick in die DevTools: Wenn du in der Konsole document.activeElement beobachtest, siehst du, welches Element den Fokus hat, auch wenn optisch nichts zu erkennen ist. Weicht das vom Sichtbaren ab, hast du den Befund.

Häufiger Fehler in der Praxis

Der mit Abstand häufigste Fund ist der Sticky-Header ohne Scroll-Puffer. Er entsteht nicht aus Nachlässigkeit, sondern weil das Problem beim Bauen unsichtbar ist: Mit der Maus scrollt niemand ein Element unter den Header, das passiert erst bei Tastaturnavigation. Ich hab mir angewöhnt, scroll-padding-top gleich beim Anlegen der Header-Komponente zu setzen, im selben Commit. Nachträglich fällt es sonst niemandem ein.

Der zweite Fall ist das Cookie-Banner als nicht-modaler Kasten. Es liegt als schwebende Fläche über dem Inhalt, nimmt den Fokus aber nicht auf und lässt sich nicht mit Esc wegräumen. Der Nutzer tabbt durch die Seite, das Banner bleibt, und alle Elemente im unteren Viewport-Drittel sind unerreichbar. Wenn das Banner ohnehin eine Entscheidung erzwingt, ist ein echter modaler Dialog die naheliegendere Bauform – der löst 2.4.11 gleich mit.

Der dritte ist die klebende Fortschrittsleiste in mehrstufigen Formularen. Sie sitzt oben, ist meist schmal und wirkt harmlos. Bei 200 % Zoom auf einem Laptop verdeckt sie aber genau das erste Eingabefeld des Schritts – und das ist das Element, auf dem der Fokus nach dem Seitenwechsel landet. Der Fund taucht in Audits fast nur auf, wenn jemand zusätzlich zoomt.

Und ein Einordnungsfehler, der immer wieder in Berichten steht: Ein Fokusring, der gar nicht erst gezeichnet wird, weil jemand outline: none gesetzt hat, ist kein 2.4.11-Befund. Das ist 2.4.7 Fokus sichtbar auf Stufe AA – und existiert schon seit WCAG 2.0. 2.4.11 setzt einen sichtbaren Fokus voraus und fragt nur, ob man ihn auch zu Gesicht bekommt.

Häufige Fragen

Ist ein teilweise verdeckter Fokus ein Verstoß gegen 2.4.11?

Nein. Auf Stufe AA verlangt das Kriterium nur, dass das fokussierte Element nicht vollständig verdeckt ist. Ein Element, von dem noch ein Streifen zu sehen ist, erfüllt 2.4.11. Wer keine Überlappung zulassen will, prüft gegen 2.4.12 „Fokus nicht verdeckt (erweitert)“ auf Stufe AAA – das ist aber keine Pflicht für BFSG- oder BITV-Konformität.

Gilt 2.4.11 auch, wenn der Nutzer selbst ein Overlay geöffnet hat?

Nur eingeschränkt. Inhalte, die der Nutzer selbst aufgerufen hat, dürfen ein fokussiertes Element überlagern – vorausgesetzt, er kann es wieder freilegen, ohne den Tastaturfokus zu verlieren. In der Praxis heißt das: Esc schließt das Overlay, oder die Bildlauftasten funktionieren weiter, und der Fokus bleibt an derselben Stelle.

Muss ich 2.4.11 schon erfüllen, obwohl es nicht in der EN 301 549 steht?

Rechtlich verweisen BFSG und BITV 2.0 über die EN 301 549 noch auf WCAG 2.1; 2.4.11 kam erst mit WCAG 2.2 dazu (Stand Juli 2026). Der BIK-BITV-Test prüft es bereits, und die Umsetzung kostet zwei CSS-Zeilen – es jetzt mitzunehmen ist günstiger, als später nachzurüsten. Das ist keine Rechtsberatung.

Reicht scroll-behavior: smooth, damit der Fokus sichtbar bleibt?

Nein. scroll-behavior steuert nur, wie animiert gescrollt wird, nicht bis zu welcher Position. Das Fokusziel landet danach an derselben Stelle unter dem Header. Nötig ist ein Puffer: scroll-padding-top am html-Element oder scroll-margin-top am Element.

Was ist mit Werbebannern, die von einem Dienstleister eingebunden werden?

Sie gelten als vom Autor erstellter Inhalt, weil du sie in deine Seite einbaust. Verdeckt ein klebendes Anzeigenformat beim Tabben Bedienelemente vollständig, ist das ein Befund gegen deine Seite – unabhängig davon, wer das Skript liefert. Die Prüfschritte unterscheiden ausdrücklich nicht zwischen Werbung und redaktionellem Inhalt.

Verwandte Themen

• 2.4.7 Fokus sichtbar – erst sichtbar, dann unverdeckt
• 2.4.3 Fokus-Reihenfolge – die Reihenfolge, in der du durchtabbst
• 1.4.10 Reflow – kleine Viewports, in denen klebende Leisten teuer werden
• Cookie-Banner barrierefrei – das Bauteil mit den meisten Befunden
• Tastaturbedienung & Fokus – die Praxisseite mit dem kompletten Rezept
• Die neuen WCAG-2.2-Kriterien – alle Neuerungen im Überblick