Fokus nicht verdeckt (Minimum)
Wenn ein Element den Tastaturfokus erhält, darf es nicht vollständig hinter einem anderen UI-Element verborgen sein — etwa hinter klebenden Kopfzeilen, Cookie-Bannern, Chat-Widgets oder klebenden Fußzeilen. Neu in WCAG 2.2 und verändert die Art, wie Teams klebende Elemente gestalten.
Was das Kriterium verlangt
Wenn Nutzende per Tabulatortaste zu einem Steuerelement navigieren, muss mindestens ein Teil dieses Steuerelements sichtbar bleiben. Das häufigste Fehlermuster: Nutzende tabben an einer klebenden Kopfzeile vorbei, die Seite scrollt automatisch so, dass der fokussierte Link hinter der klebenden Leiste landet, und der Fokusring ist nicht mehr zu sehen. Das Steuerelement hat zwar weiterhin den Fokus und reagiert auf die Eingabetaste, die Nutzenden können es aber nicht wahrnehmen.
Das Erfolgskriterium setzt eine Mindestanforderung: Das fokussierte Element darf teilweise verdeckt sein, nur nicht vollständig. Das AAA-Kriterium 2.4.12 verschärft dies auf „überhaupt nicht verdeckt“.
Dies ist eines der vier neuen Bedienbarkeitskriterien, die in WCAG 2.2 eingeführt wurden, und hat überdurchschnittlich großen Einfluss, weil klebende Kopfzeilen, klebende Fußzeilen, Cookie-Banner und Chat-Widget-Blasen allgegenwärtig sind.
So wird es umgesetzt
scroll-margin-topan fokussierbare Elemente in CSS anfügen, dessen Wert der Höhe der klebenden Kopfzeile entspricht, damit Browser das fokussierte Steuerelement automatisch unterhalb der Kopfzeile positionieren.- Bei klebenden Fußzeilen und Chat-Blasen sicherstellen, dass diese kein fokussierbares Element vollständig verdecken. Entweder werden sie beim Fokussieren verkleinert oder so verankert, dass ein Puffer am Seitenrand verbleibt.
- Cookie-Banner und ausblendbare Überlagerungen: niemals so klebend gestalten, dass spätere Tabstopps darunter verschwinden. Entweder modal umsetzen (mit Fokus-Trap) oder nicht-blockierend.
- Bei Seiten mit sowohl klebender Kopf- als auch klebender Fußzeile die Tabulatorreihenfolge rund um die vertikale Mitte des Viewports testen — dort gerät das fokussierte Element in die Enge.
scroll-padding-topam Scroll-Container als Fallback für ältere Browser verwenden.
html { scroll-padding-top: 80px; } /* Höhe der klebenden Kopfzeile anpassen */
:target, :focus { scroll-margin-top: 80px; }
Häufige Fehler
- Klebende Kopfzeile ohne Scroll-Padding-Ausgleich: jeder Tabstopp im oberen Bereich des Viewports verbirgt den Fokusring.
- Cookie-Einwilligungsbanner am unteren Seitenrand, das die letzte Reihe von Formularfeldern verdeckt, wenn diese den Fokus erhalten.
- Live-Chat-Widget-Blase unten rechts, die einen „Absenden“-Button in der Ecke eines Formulars überlappt.
- Werbebanner (z. B. Black-Friday-Leisten), die von Marketing-Teams ohne Aktualisierung der Scroll-Padding-Tokens hinzugefügt werden.
- Klebende Tabellenköpfe in Dashboards, bei denen der Tabstopp in der ersten Datenzeile hinter dem Tabellenkopf landet.
Warum es wichtig ist
Dieses Erfolgskriterium behebt eine Klasse von Fehlern, die Tastatur-Nutzende täglich beeinträchtigt, aber in automatisierten Scans selten auftaucht — kein axe-Regelsatz kann vorhersagen, bei welcher Scroll-Position ein klebendes Element ein fokussiertes Element überlappt. Besonders stark betroffen sind außerdem Nutzende von Bildschirmlupen, deren sichtbarer Viewport bereits auf ein Viertel der Bildschirmfläche reduziert ist, sodass das klebende Element einen noch größeren Anteil davon einnimmt.
Es ist davon auszugehen, dass 2.4.11 in den Audit-Berichten des Jahres 2026 zu den am häufigsten zitierten neuen Befunden gehören wird. Die Behebung ist klein (einige wenige CSS-Tokens), erfordert aber die Koordination aller Teams, die ein klebendes Element verantworten — Kopfzeile, Fußzeile, Banner, Widget.