Tastaturfokus hinter Sticky Headern: Sieht man noch, wo man ist?

Die Website sieht im Screenshot sauber aus. Der Header bleibt beim Scrollen oben, unten sitzt ein Cookie-Banner und rechts wartet ein Chat-Widget. Dann navigiert jemand ausschließlich mit der Tastatur.

Tab, Tab, Tab – und plötzlich ist nicht mehr zu erkennen, welches Element gerade aktiv ist. Der Link liegt vollständig hinter dem Sticky Header. Ein Formularfeld verschwindet unter dem Consent-Banner. Oder der Fokus wandert in einen Bereich, den ein aufgeklapptes Chatfenster verdeckt.

Das ist kein kosmetischer Randfall. Wer per Tastatur navigiert, muss sehen können, wo die nächste Eingabe stattfindet. WCAG 2.2 hat dafür mit 2.4.11 „Focus Not Obscured (Minimum)“ ein Erfolgskriterium auf Level AA ergänzt.

Die praktische Audit-Frage lautet deshalb: Wenn Fokus auf ein Bedienelement springt – ist dieses Element im aktuellen Viewport tatsächlich erkennbar oder nur technisch fokussiert?

Was WCAG 2.2 hier wirklich verlangt

Success Criterion 2.4.11 fordert, dass eine Benutzeroberflächen-Komponente beim Erhalt von Tastaturfokus nicht vollständig durch vom Autor erzeugte Inhalte verdeckt wird. Die W3C-Erklärung fasst das als „at least partially visible“ zusammen.

Das ist bewusst ein Mindestniveau. WCAG 2.4.12 „Focus Not Obscured (Enhanced)“ liegt auf Level AAA und verlangt, dass kein Teil der fokussierten Komponente durch solche Inhalte verdeckt wird.

Der Unterschied ist wichtig: Auf AA-Niveau darf das fokussierte Element nicht vollständig verschwinden; auf AAA-Niveau soll es vollständig sichtbar bleiben. W3C nennt als typische Überlagerungen ausdrücklich Sticky Footer, Sticky Header und nicht-modale Dialoge. Auch Cookie-Banner werden als konkretes Beispiel behandelt.

Für Produktteams ergibt sich daraus eine brauchbare Qualitätsregel: Zielen Sie nicht darauf, gerade eben genug Pixel sichtbar zu lassen. Gestalten Sie Fokus so, dass Nutzer ihn ohne Rätselraten verfolgen können.

Red Flag 1: Der Sticky Header gewinnt gegen den Browser-Scroll

Ein häufiger Fehler entsteht nicht beim manuellen Scrollen, sondern beim Fokuswechsel.

Der Browser versucht, ein neu fokussiertes Element in den sichtbaren Bereich zu bringen. Ein position: fixed oder position: sticky Header gehört jedoch zum von Ihnen gestalteten Overlay-System. Wenn der Browser das Ziel an die obere Viewport-Kante scrollt und dort 96 Pixel Navigation liegen, kann genau das fokussierte Element darunter verschwinden.

W3C führt dafür sogar eine eigene Failure Technique, F110: Ein Sticky Header oder Footer, der beim Tabben fokussierte Elemente vollständig verdeckt, ist ein dokumentierter Fehlerfall für 2.4.11.

Prüfen Sie deshalb nicht nur, ob der Header beim Scrollen sichtbar bleibt. Testen Sie Vorwärts-Tabben, Shift+Tab zurück nach oben, Sprunglinks, Fokus nach Formularfehlern und Zustände, in denen der Header auf Mobilgeräten, bei Zoom oder nach dem Login eine andere Höhe hat. Ein statischer Offset kann in einem Zustand stimmen und im nächsten falsch sein.

Red Flag 2: Das Cookie-Banner ist „nur unten“ – bis dort Fokus landet

Ein nicht-modales Banner kann optisch einen kleinen Teil des Bildschirms belegen und trotzdem mehrere Controls vollständig überdecken.

W3C nennt ein Sticky Cookie-Banner ausdrücklich als Beispiel: Wenn es eine fokussierte Komponente komplett verdeckt, kann 2.4.11 verletzt werden. Als mögliche Lösungen nennt W3C unter anderem echte Modalität oder ausreichenden Scroll-Abstand.

Wenn das Banner modal ist, sollte es sich auch wie ein Modal verhalten: Fokus befindet sich im Dialog und der Hintergrund wird währenddessen nicht per Tastatur bedient. Ist das Banner bewusst nicht modal, darf die Seite darunter weiter bedienbar sein – aber Layout und Scrollverhalten müssen den belegten Bereich berücksichtigen.

Das gefährliche Zwischenmodell ist ein großes Overlay, das den Hintergrund weiterhin in der Tab-Reihenfolge lässt und genau diesen Fokus verdeckt.

Red Flag 3: Das Chat-Widget wächst, die Fokuslogik weiß nichts davon

Geschlossene Chatblasen sind meist klein. Geöffnete Chats können ein Drittel des Viewports belegen.

WCAG berücksichtigt ausdrücklich Inhalte, die Nutzer selbst öffnen. Solche Inhalte dürfen fokussierte Elemente unter bestimmten Bedingungen verdecken, wenn die Person das fokussierte Element wieder sichtbar machen kann, ohne den Tastaturfokus weiterbewegen zu müssen – beispielsweise über Escape zum Schließen oder eine andere direkt verfügbare Tastaturaktion.

Fragen Sie bei Chat, Feedback, Support, Minicart und ähnlichen Overlays: Bleibt das Overlay offen, nachdem Fokus es verlassen hat? Kann es mit Escape geschlossen werden? Verdeckt es auf schmalen Viewports Buttons oder Formularfelder? Kann Fokus hinter das Overlay wandern, obwohl Nutzer das dahinterliegende Element nicht sehen? Wird das Widget bei 200 oder 400 Prozent Zoom unverhältnismäßig groß?

Ein Overlay, das nur mit einem kleinen Maus-X zu schließen ist, löst das Tastaturproblem nicht.

Red Flag 4: Die Komponente ist sichtbar, der Fokuszustand aber nicht

2.4.11 bewertet primär, ob die Komponente nicht vollständig verdeckt wird. Das ist nicht identisch mit der Frage, ob der Fokusindikator gut sichtbar ist.

W3C weist darauf hin, dass zusätzlich 2.4.7 „Focus Visible“, Non-text Contrast und auf AAA-Level 2.4.13 „Focus Appearance“ relevant sein können. Eine halbtransparente oder weichgezeichnete Überlagerung kann die Komponente formal noch erkennen lassen und den Fokusindikator trotzdem praktisch unbrauchbar machen.

Ein Audit sollte deshalb zwei getrennte Fragen stellen: Ist das fokussierte Element sichtbar? Und ist der Fokuszustand darauf klar erkennbar? Ein kräftiger Fokus-Ring hilft wenig, wenn das komplette Element unter einer Sticky Bar liegt.

scroll-padding: kleiner CSS-Baustein, großer Effekt

Für feste Kopf- oder Fußleisten ist scroll-padding ein besonders nützlicher Baustein.

Die CSS Scroll Snap Spezifikation definiert scroll-padding nicht nur für Snap-Layouts. Sie beschreibt damit die optimale sichtbare Region eines Scrollcontainers und nennt ausdrücklich feste Toolbars oder Sidebars als Bereiche, die vom Zielraum für Scrollvorgänge ausgeschlossen werden können. Das beeinflusst unter anderem Scroll-into-view-Verhalten bei Fokus und Zielnavigation.

W3C führt scroll-padding in Technique C43 als ausreichende Technik für 2.4.11 und 2.4.12 auf. Das Prinzip ist einfach: Wenn oben ein fixer Header liegt, erhält der Scrollcontainer am Block-Anfang einen entsprechenden Sicherheitsabstand; bei einer festen Leiste unten gilt dasselbe für das Ende.

Wichtig: Hardcoden Sie nicht gedankenlos eine Desktop-Höhe. Header, Banner und Toolbars ändern sich durch Breakpoints, Textvergrößerung, Übersetzungen, eingeloggte Zustände oder dynamische Hinweise. Wenn die Overlay-Höhe variabel ist, muss auch die berücksichtigte Scrollzone robust auf diese Variation reagieren.

Zusätzlich kann scroll-margin an gezielten Elementen sinnvoll sein, etwa für Überschriften oder Fehlerziele. Die CSS-Spezifikation definiert damit zusätzlichen Raum, der bei Scroll-into-view-Operationen berücksichtigt werden kann.

Ein 15-Minuten-Audit ohne Spezialtool

Automatisierte Accessibility-Scanner finden viele Probleme. Fokus-Verdeckung ist jedoch stark von Fokusreihenfolge, Viewport und Zustand abhängig. Ein manueller Tastaturtest ist deshalb unverzichtbar.

1. Laden Sie die Seite neu und navigieren Sie ohne Maus mit Tab durch alle interaktiven Elemente. Beobachten Sie, ob jedes Ziel sinnvoll in den Viewport scrollt.
2. Gehen Sie denselben Weg mit Shift+Tab rückwärts. Sticky Header werden häufig erst beim Rückwärtsnavigieren zum Problem.
3. Öffnen Sie jedes persistente Overlay: Cookie-Banner, Chat, Feedback-Widget, Minicart, Sticky Promo, Supportpanel und Filterdrawer.
4. Testen Sie lange Formulare und provozieren Sie Validierungsfehler. Wenn Fokus zu einem Feld oder einer Fehlerzusammenfassung springt, muss das Ziel danach sichtbar sein.
5. Testen Sie Sprunglinks, Inhaltsverzeichnisse und Hash-Navigation. Fixed Header überdecken solche Ziele besonders häufig.
6. Prüfen Sie einen mobilen Viewport sowie mindestens 200 Prozent Zoom; wenn möglich auch 400 Prozent. Ein kompakter Banner kann durch Textumbruch plötzlich sehr hoch werden.
7. Ändern Sie den UI-Zustand: eingeloggt, ausgeloggt, vor und nach Consent, mit geöffnetem Supportwidget und mit sichtbaren Fehlermeldungen.

Warum Screenshots und Scores das leicht übersehen

Ein Screenshot zeigt nur einen Zustand und keinen Fokusweg. Ein automatischer Scan kann fehlende Fokusstyles oder semantische Probleme erkennen. Ob ein bestimmtes Element beim siebzehnten Tab unter einem dynamischen Header landet, hängt jedoch von Scrollposition, Viewport, geöffneten Overlays, Fokusreihenfolge und Layoutzustand ab.

Darum ist „Accessibility 100“ kein Ersatz für die Frage: Kann ich diese Seite vollständig mit der Tastatur benutzen und dabei jederzeit sehen, wo ich bin?

Für Conversion-Flows ist das genauso relevant wie für Standards. Ein verdeckter „Weiter“-Button, ein unsichtbar fokussiertes Formularfeld oder ein unter dem Banner verstecktes Fehlerziel erzeugt keinen spektakulären Crash. Nutzer hören einfach auf.

Was ins Design-System gehört

Wenn dieselben Header, Banner und Overlays auf dutzenden Seiten wiederkehren, sollte die Lösung nicht pro Landingpage neu erfunden werden.

Ein robustes Design-System definiert eine gemeinsame Strategie für fixed und sticky UI, zentrale scroll-padding- beziehungsweise Offset-Regeln, sichtbare Fokusindikatoren, Modalitätsregeln für Dialoge und Consent-Flows, einen Tastatur-Schließweg für persistente Overlays sowie Tests für Vorwärts- und Rückwärtsnavigation bei verschiedenen Viewports und Zoomstufen.

Ein kleiner End-to-End-Test kann kritische Tastatur-Journeys durchlaufen und nach Fokuswechseln prüfen, ob das aktive Element innerhalb des nutzbaren Viewports liegt. Das automatisiert nicht Barrierefreiheit als Ganzes, kann aber wiederkehrende Overlay-Regressionen früh erkennen.

Was Website-Pflichtencheck dabei prüfen würde

Bei einem Fokus-und-Overlay-Audit betrachten wir nicht nur sichtbare :focus-Styles. Je nach Website prüfen wir Fokusreihenfolge, Vorwärts- und Rückwärtsnavigation, Sticky Header und Footer, Cookie- und Consent-Banner, Chat- und Supportwidgets, nicht-modale Overlays und Drawer, Sprunglinks, Fokus nach Formularvalidierung, Verhalten bei kleinen Viewports und Zoom, scroll-padding, Fokusindikator und Kontrast sowie Unterschiede zwischen responsiven oder eingeloggten Zuständen.

Das Ergebnis sollte nicht bei „WCAG-Fehler: ja/nein“ enden. Sinnvoller ist eine priorisierte Liste: Wo verlieren Nutzer tatsächlich die Orientierung, welche Komponente verursacht es, und welcher Fix löst das Problem systemweit statt nur auf einer Seite?

Ein Fokus, den der Browser technisch gesetzt hat, ist noch kein nutzbarer Fokus. Wenn die Person nicht sehen kann, wo die Tastatur gerade ist, hat die Oberfläche ihren aktuellen Interaktionspunkt verloren.

Quellen

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 — https://www.w3.org/TR/WCAG22/
• W3C WAI: Understanding SC 2.4.11 Focus Not Obscured (Minimum) — https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html
• W3C WAI: Understanding SC 2.4.12 Focus Not Obscured (Enhanced) — https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-enhanced.html
• W3C WAI: Technique C43 — https://www.w3.org/WAI/WCAG22/Techniques/css/C43
• W3C WAI: Failure F110 — https://www.w3.org/WAI/WCAG22/Techniques/failures/F110
• W3C: CSS Scroll Snap Module Level 1 — https://www.w3.org/TR/css-scroll-snap-1/

Hinweis: Dieser Beitrag ist eine technische Einordnung von WCAG 2.2 und keine Rechtsberatung.