WCAG 2.4.11 Fokus nicht verdeckt (Minimum)

Das Erfolgskriterium 2.4.11 ist neu in WCAG 2.2. Es sorgt dafür, dass Tastaturnutzer das Element, zu dem sie gesprungen sind, auch tatsächlich sehen, statt dass der Fokus hinter einem Sticky Header, Chat-Button oder Cookie-Banner verschwindet. Es gehört zur Konformitätsstufe AA und ist Teil von EN 301 549 (Abschnitt 9.2.4.11). Das BFSG verweist über die harmonisierte Norm EN 301 549 auf diese Anforderungen.

Was das Erfolgskriterium verlangt

Wenn ein Bedienelement der Benutzeroberfläche den Tastaturfokus erhält, ist es nicht vollständig durch vom Autor erstellte Inhalte verdeckt.

Wichtige Punkte laut W3C:

• auf Stufe AA ist eine teilweise Verdeckung zulässig — das Element darf nicht vollständig verdeckt sein. Stufe AAA (2.4.12 Fokus nicht verdeckt (Erweitert)) verlangt, dass kein Teil verdeckt ist;
• wo der Nutzer Inhalte verschieben kann (zum Beispiel eine Werkzeugleiste ziehen), zählt nur die Ausgangsposition dieser Inhalte;
• vom Nutzer geöffnete Inhalte dürfen das fokussierte Element verdecken; kann der Nutzer es ohne Bewegen des Tastaturfokus sichtbar machen (zum Beispiel per Esc ein Pop-up schließen), gilt es nicht als verdeckt.

Typische Fehler in Onlineshops

• ein Sticky Header oder eine „In den Warenkorb“-Leiste, die Links und Buttons verdeckt, während der Nutzer mit Tab die Seite hinunter navigiert;
• ein unten am Bildschirm fixiertes Cookie-Banner, das die Footer-Links und Formularfelder dahinter verdeckt;
• ein schwebender Chat- oder „Nach oben“-Button über Checkout-Feldern;
• eine Werbeleiste, die hereinfährt und das fokussierte Element verdeckt;
• ein nicht-modales „Newsletter“-Panel, das offen bleibt, während der Fokus dahinter weiterwandert.

So prüfen Sie es

Automatisch: Für dieses Kriterium gibt es keine axe-core-Regel. Ob der Fokus verdeckt ist, hängt von der Scrollposition und den überlappenden Ebenen im Moment des Fokus ab, was axe nicht testet, deshalb ist eine manuelle Prüfung nötig.

Manuell: Gehen Sie in einem Fenster in Laptopgröße und noch einmal bei 200 % Zoom die ganze Seite mit Tab durch, zuerst bei geöffnetem Cookie-Banner, dann nachdem Sie es geschlossen haben. Achten Sie auf den Sticky Header, fixierte „In den Warenkorb“-Leisten und schwebende Buttons. Jedes Mal, wenn der Fokus auf einem Element landet, muss zumindest ein Teil davon sichtbar sein. Achten Sie besonders auf das Checkout-Formular und den Footer.

So beheben Sie es

• Setzen Sie am scrollenden Container scroll-padding-top (und scroll-padding-bottom) in Höhe der fixierten Leisten, damit fokussierte Elemente in einen freien Bereich scrollen.
• Machen Sie das Cookie-Banner modal (der Fokus wandert hinein und bleibt dort, bis eine Wahl getroffen ist) oder platzieren Sie es so, dass es keine Inhalte verdeckt.
• Verkleinern Sie fixierte Elemente auf kleinen Bildschirmen und beim Zoomen.
• Lassen Sie Nutzer schwebende Widgets mit Esc und per Tastatur schließen.

Verwandte Kriterien

• 2.4.7 Fokus sichtbar — der Fokusindikator muss sichtbar sein.
• 2.4.3 Fokus-Reihenfolge — der Fokus muss sich in einer logischen Reihenfolge bewegen.
• WCAG-2.2-Checkliste — was in WCAG 2.2 sonst noch neu ist.

Häufige Fragen

Verstößt ein Sticky Header gegen WCAG 2.4.11?

Nur wenn er ein fokussiertes Element vollständig verdeckt. Bleibt ein Teil des Elements sichtbar, ist 2.4.11 (AA) erfüllt; das AAA-Kriterium 2.4.12 verlangt, dass kein Teil verdeckt ist. CSS scroll-padding löst das Problem meist.

Verstößt ein Cookie-Banner gegen 2.4.11?

Ein nicht-modales Cookie-Banner, das das fokussierte Element vollständig verdeckt, ist ein Verstoß. Das W3C beschreibt Wege, das zu vermeiden: das Banner modal machen, damit es den Fokus übernimmt, scroll-padding verwenden, damit fokussierte Elemente frei davon bleiben, oder das Banner schließen, wenn der Fokus es verlässt.

Ist 2.4.11 neu in WCAG 2.2?

Ja. Fokus nicht verdeckt (Minimum) kam mit WCAG 2.2 auf Stufe AA hinzu, zusammen mit Fokus nicht verdeckt (Erweitert) auf Stufe AAA.