Prüfpunkt 2.4.11Stufe AATastatur und Fokus
Warum darf ein fixierter Kopfbalken den Tastaturfokus nie ganz verdecken?
Ein fixierter Kopfbalken, ein Cookie-Hinweis oder eine klebende Fußleiste darf das gerade fokussierte Element nie vollständig verdecken, weil Tastaturnutzer sonst nicht mehr sehen, wo sie stehen. Das Kriterium 2.4.11 ist mit WCAG 2.2 neu hinzugekommen: Beim Bewegen des Fokus durch die Seite muss das aktive Element mindestens teilweise sichtbar bleiben — auch wenn Teile der Seite beim Rollen über dem Inhalt schweben.
Wie klebende Leisten den Fokus verschlucken
Viele Websites fixieren Elemente am Bildschirmrand: die Menüleiste oben, einen Cookie-Hinweis unten, dazwischen vielleicht ein Newsletter-Banner. Diese Schichten schweben über dem Inhalt. Wandert der Tastaturfokus nun durch die Seite, kann das aktive Element genau hinter so einer Leiste liegen — der Fokusrahmen ist da, aber niemand sieht ihn. Für Tastaturnutzer fühlt sich das an, als wäre der Fokus verschwunden: Sie tabben weiter und wissen nicht, welche Schaltfläche sie mit der Eingabetaste treffen. Besonders tückisch sind hohe Cookie-Hinweise am unteren Rand, hinter denen beim Durchtabben ganze Formularzeilen verschwinden können.
So misst der Prüfservice die Fokus-Verdeckung
Während des echten Tastatur-Durchgangs prüft der Prüfservice bei jedem Fokus-Halt mehrere Punkte des aktiven Elements: Liegt an all diesen Punkten eine undurchsichtige, fixierte oder klebende Fläche über dem Element, gilt es als vollständig verdeckt — das Kriterium ist verstoßen, und der Bericht benennt das Element samt Beleg-Bildschirmfoto. Die Messung urteilt bewusst vorsichtig: Elemente, die selbst Teil einer fixierten Leiste sind, gelten nie als dahinter verborgen, und durchsichtige Überlagerungen zählen nicht als Verdeckung. Bleibt das Element bei allen Halten mindestens teilweise sichtbar, gilt das Kriterium als bestanden.
Beispiele
Fokus hinter der klebenden Kopfzeile
header { position: sticky; top: 0; height: 80px; }
/* Tab scrollt das Element unter den Header */header { position: sticky; top: 0; height: 80px; }
html { scroll-padding-top: 88px; }scroll-padding hält beim Fokuswechsel den Bereich unter der Kopfzeile frei. Cookie-Banner fangen den Fokus ein, bis sie geschlossen sind.
So gehen Sie es an
- Tabben Sie durch Ihre Seite und beobachten Sie den unteren Bildschirmrand — verschwindet der Fokus zeitweise hinter dem Cookie-Hinweis?
- Halten Sie fixierte Leisten so schmal wie möglich, besonders auf kleinen Bildschirmen.
- Bitten Sie Ihre Agentur, beim Fokussieren einen Rollabstand einzuplanen, damit das aktive Element nie unter fixierten Leisten landet.
- Testen Sie mit sichtbarem Cookie-Hinweis — genau in diesem Zustand erleben Erstbesucher Ihre Seite.
Weiter im Prüfbereich Barrierefreiheit
- Warum brauchen Wischgesten eine einfache Klick-Alternative?Wisch- und Mehrfinger-Gesten kann nicht jeder ausführen. WCAG 2.5.1 verlangt für jede solche Geste einen gleichwertigen Weg mit einfachen Tipps.
- Warum soll ein Klick erst beim Loslassen auslösen?Löst ein Klick erst beim Loslassen aus, lässt sich ein Fehlgriff abbrechen: Finger zur Seite ziehen, außerhalb loslassen. Das verlangt WCAG 2.5.2.
- Warum muss die sichtbare Beschriftung im hinterlegten Namen vorkommen?Sprachsteuerungs-Nutzer sprechen, was sie sehen. Weicht der hinterlegte Name einer Schaltfläche vom sichtbaren Text ab, läuft der Befehl ins Leere.
- Warum brauchen Schüttel- und Neigefunktionen eine Alternative?Funktionen per Schütteln oder Kippen des Geräts brauchen normale Bedienelemente als Alternative und eine Abschaltung. Das verlangt WCAG 2.5.4.
Dieser Prüfpunkt gehört zum Prüfbereich Barrierefreiheit; dort stehen alle Prüfpunkte im Überblick. Was die Prüfung insgesamt leistet, zeigt die Leistungsseite; wie ein Ergebnis zustande kommt, erklärt das Prüfverfahren. Alle Prüfbereiche im Überblick: Wissensbasis.
Foto: Glenn Carstens-Peters, CC0
.jpg){kind=link}