WCAG 2.4.12: Fokus nicht verdeckt (erweitert)

WCAG 2.4.12 verlangt, dass, wenn eine UI-Komponente den Tastaturfokus erhält, kein Teil dieser Komponente durch vom Autor erstellte Inhalte verdeckt wird – das fokussierte Element muss vollständig sichtbar sein. Dieses erweiterte (AAA-)Kriterium beseitigt die teilweise Sichtbarkeitszulassung seines AA-Gegenstücks und stellt sicher, dass Tastaturnutzende immer genau sehen, wo sich der Fokus befindet.

Was diese Regel bedeutet

WCAG 2.4.12 — Fokus nicht verdeckt (erweitert) — ist das AAA-Gegenstück zu WCAG 2.4.11 (Fokus nicht verdeckt, AA). Während das AA-Kriterium erlaubt, dass eine fokussierte Komponente teilweise sichtbar ist, verlangt das AAA-Kriterium, dass die fokussierte Komponente vollständig sichtbar ist — kein Teil von ihr darf durch vom Autor erstellte Inhalte verdeckt werden, wenn sie die Tastaturfokussierung erhält.

Praktisch bedeutet das: Wenn ein Nutzer per Tab zu einem interaktiven Element wie einem Link, Button, Formularfeld oder benutzerdefinierten Widget navigiert, muss der vollständige Begrenzungsbereich dieses Elements frei von Überlagerungen durch Sticky-Header, feste Footer, modale Overlays, Cookie-Banner, Chat-Widgets oder andere vom Autor platzierte Inhalte sein. Die Regel zielt ausdrücklich auf vom Autor erstellte Inhalte ab; das W3C macht eine explizite Ausnahme für Inhalte, die der Nutzer selbst so verschoben hat, dass sie den Fokusindikator verdecken — zum Beispiel ein schwebendes Panel, das der Nutzer vor das fokussierte Element gezogen hat. In diesem Fall trägt der Autor keine Verantwortung.

Ein Bestehen nach 2.4.12 setzt voraus, dass beim Erhalt des Fokus die gesamte fokussierte Komponente im Viewport sichtbar ist und nicht von einem Sticky-, Fixed- oder absolut positionierten Element verdeckt wird, das unter Kontrolle des Seitenautors steht. Ein Fehler liegt vor, wenn irgendein Teil der sichtbaren Begrenzung des fokussierten Elements hinter solchen Overlays verborgen ist — selbst ein einzelnes Pixel des Fokusrings oder des Elements selbst, das abgeschnitten wird, gilt auf AAA-Niveau als Fehler.

Es ist wichtig zu verstehen, was 2.4.12 nicht abdeckt. Es schreibt keinen bestimmten Stil für Fokusindikatoren vor (das wird durch 2.4.11 und 2.4.7 geregelt). Es verlangt nicht, dass Fokusindikatoren ein Mindestkontrastverhältnis haben (abgedeckt durch 2.4.13). Es befasst sich speziell mit der räumlichen Beziehung zwischen dem fokussierten Element und anderen Inhalten auf der Seite — dem Layering-Problem, das am häufigsten durch Fixed- und Sticky-Positionierung in CSS entsteht.

Betroffene HTML-Elemente sind alle fokussierbaren oder per Tab erreichbaren Elemente: <a>, <button>, <input>, <select>, <textarea>, <details>, Elemente mit tabindex und benutzerdefinierte interaktive Widgets, die mit ARIA-Rollen erstellt wurden. Das Kriterium gilt in allen Browsing-Kontexten, einschließlich iframes, Dialogen und Routenwechseln in Single-Page-Applications.

Warum das wichtig ist

Die Tastaturnavigation ist eine primäre Zugriffsmethode für eine breite Nutzergruppe. Menschen mit motorischen Beeinträchtigungen — einschließlich Personen mit Erkrankungen wie ALS, Multipler Sklerose, Zerebralparese oder Repetitive-Strain-Verletzungen — sind vollständig auf die Tastatur oder Schaltzugangsgeräte statt einer Maus angewiesen. Blinde und sehbehinderte Nutzer, die Screenreader verwenden, navigieren ebenfalls per Tastatur, und obwohl ihre Hilfstechnologie die Fokusposition akustisch ansagt, sind sehende Tastaturnutzer vollständig auf den visuellen Fokusindikator angewiesen, um sich auf der Seite zu orientieren.

Wenn das fokussierte Element auch nur teilweise verdeckt ist, erleben diese Nutzer eine frustrierende und potenziell desorientierende Situation: Die Seite scheint überhaupt kein fokussiertes Element anzubieten, oder der Nutzer muss raten, wo er sich im Dokument befindet. Auf AA-Niveau (2.4.11) wird teilweise Sichtbarkeit toleriert — zumindest ein Teil der Komponente ist sichtbar und liefert einen Hinweis. Das AAA-Kriterium beseitigt diesen Kompromiss vollständig und erkennt an, dass selbst ein teilweise verdeckter Fokusindikator von Nutzern mit reduzierter Kontrastsensitivität, Tunnelblick oder kognitiven Beeinträchtigungen, die das Scannen des Bildschirms erschweren, übersehen werden kann.

Betrachten wir ein konkretes Szenario: Eine türkische E-Commerce-Website verwendet eine feste Navigationsleiste mit 80px Höhe am oberen Rand des Viewports und ein Sticky-Cookie-Einwilligungsbanner mit 60px Höhe am unteren Rand. Ein Nutzer, der mit Tab durch Produktkarten navigiert, kann feststellen, dass die obere oder untere Kante der fokussierten Karte — einschließlich ihres Fokusrings — unter eine dieser festen Flächen gleitet. Unter WCAG 2.4.11 (AA) besteht die Seite, wenn irgendein Teil der Karte noch sichtbar ist. Unter 2.4.12 (AAA) muss die gesamte Karte vollständig sichtbar sein. Dieser Unterschied ist bedeutsam: Eine teilweise verdeckte Button-Beschriftung in Kombination mit einem teilweise verdeckten Fokusring kann es für einen sehbehinderten Nutzer tatsächlich unmöglich machen zu erkennen, welches Element aktiv ist oder welche Aktion es ausführt.

Laut Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen irgendeine Form von Sehbeeinträchtigung, und motorische Behinderungen betreffen Hunderte Millionen weitere. Verbesserungen der Tastaturzugänglichkeit kommen nicht nur diesen Gruppen zugute, sondern auch Power-Usern, die aus Geschwindigkeitsgründen die Tastaturnavigation bevorzugen, Nutzern auf Geräten ohne Zeigegerät und Nutzern in Situationen, in denen die Feinmotorik vorübergehend eingeschränkt ist.

Über den Zugang für Menschen mit Behinderungen hinaus verbessert ein vollständig sichtbarer Fokus die allgemeine Benutzerfreundlichkeit und senkt Supportkosten. Wenn alle Nutzer — einschließlich solcher ohne Behinderungen — die Fokusposition klar verfolgen können, steigen Formularabschlussraten und Fehlerquoten sinken. Für Websites, die den türkischen Markt adressieren, signalisiert der Nachweis von AAA-Konformität ein ausgereiftes Barrierefreiheitsprogramm und stärkt das Vertrauen sowohl bei Nutzern als auch bei institutionellen Beschaffungsstellen.

Wie man testet

Automatisierter Basisscan: Führen Sie axe DevTools oder Lighthouse auf der Seite aus, um verwandte Probleme wie scrollable-region-focusable-Verstöße oder CSS-Overflow-Probleme zu identifizieren. Diese Befunde sind zwar keine direkten 2.4.12-Verstöße, weisen aber auf Bereiche der Seite hin, die am ehesten Fokus-verdeckende Probleme verursachen. Filtern Sie in axe DevTools nach WCAG-2.2-Kriterien und prüfen Sie alle „needs review“-Einträge im Zusammenhang mit der Fokus-Sichtbarkeit.
Alle persistenten überlagerten Inhalte identifizieren: Erfassen Sie vor dem Tastaturtest visuell alle Elemente mit position: fixed oder position: sticky auf der Seite — typischerweise Navigationsleisten, Cookie-Banner, Chat-Widgets, Floating-Action-Buttons und Footer-Toolbars. Notieren Sie deren Höhen und Positionen, damit Sie wissen, welche Zonen des Viewports sie einnehmen.
Tastaturnavigations-Walkthrough: Beginnen Sie am oberen Rand der Seite (oder nachdem Sie ein anfängliches Modal geschlossen haben) und drücken Sie wiederholt Tab, um den Fokus durch alle interaktiven Elemente zu bewegen. Überprüfen Sie bei jedem Fokusstopp, dass das gesamte fokussierte Element — einschließlich seines sichtbaren Fokusindikators (Umrandung oder Ring) — vollständig im unverdeckten Bereich des Viewports liegt. Akzeptieren Sie keine teilweise Sichtbarkeit. Wenn irgendein Teil des Elements oder seines Fokusrings hinter einem festen Element verschwindet, protokollieren Sie dies als 2.4.12-Verstoß.
Navigation in umgekehrter Richtung: Wiederholen Sie den Walkthrough mit Shift+Tab, um rückwärts zu navigieren. Feste Footer werden in Vorwärts-Tests oft übersehen, können aber beim Rückwärts-Tabben Elemente verdecken.
Screenreader-Test mit NVDA + Firefox: Starten Sie NVDA, öffnen Sie Firefox und navigieren Sie mit Tab. Wenn NVDA den Fokus auf einem Element ansagt, bestätigen Sie visuell, dass das Element vollständig sichtbar ist. Der Fokusmodus von NVDA scrollt Elemente nicht automatisch frei von festen Ebenen, sodass Verstöße von der browsernativen Darstellung abweichen können.
Screenreader-Test mit VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver und navigieren Sie mit Tab (oder per Wischgeste auf iOS). Das Scroll-Management von Safari unterscheidet sich teilweise von Chromium und kann Fokuszustände aufdecken, die in Chrome nicht verdeckt erscheinen.
Responsives Viewport-Testing: Wiederholen Sie den Tastatur-Walkthrough bei gängigen Breakpoints — 320px, 768px, 1024px und 1440px Breite. Sticky-Elemente werden an verschiedenen Breakpoints oft höher, niedriger oder neu positioniert, wodurch sich die gefährdeten Zonen ändern.
Test nach Nutzerinteraktionen: Öffnen Sie Dropdown-Menüs, erweitern Sie Akkordeons, lösen Sie Modals aus und navigieren Sie zu neuen Routen in Single-Page-Applications. Setzen Sie nach jeder Zustandsänderung die Tab-Navigation fort und überprüfen Sie die vollständige Fokus-Sichtbarkeit erneut, da dynamische Inhalte häufig neue feste Overlays einführen.

Wie man Probleme behebt

Sticky-Header verdeckt fokussierte Links — falsch

<!-- Fixed header with no scroll compensation -->
<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main>
  <!-- When Tab reaches this link near the top of main, the header covers it -->
  <a href='/products'>View all products</a>
</main>

Sticky-Header verdeckt fokussierte Links — korrekt

<!-- scroll-padding-top ensures focused elements scroll clear of the fixed header -->
<style>
  html {
    /* Match this value to the height of your fixed header */
    scroll-padding-top: 88px; /* 80px header + 8px breathing room */
  }
</style>

<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main style='margin-top:80px;'>
  <!-- Focus now scrolls the element fully clear of the header -->
  <a href='/products'>View all products</a>
</main>

Cookie-Banner verdeckt interaktive Elemente am unteren Viewport-Rand — falsch

<!-- Cookie banner fixed to the bottom, no scroll compensation -->
<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- These links at the bottom of the page get covered by the cookie banner -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

Cookie-Banner verdeckt interaktive Elemente am unteren Viewport-Rand — korrekt

<!-- Add scroll-padding-bottom and body padding to compensate for the banner height -->
<style>
  html {
    scroll-padding-bottom: 80px; /* 72px banner + 8px breathing room */
  }
  body {
    padding-bottom: 80px; /* Prevent content from being permanently under the banner */
  }
</style>

<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- Links now scroll fully into the unobscured viewport area -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

JavaScript-Fokusmanagement berücksichtigt feste Ebenen nicht — falsch

<!-- SPA route change: focus moved to heading but scrollIntoView ignores header -->
<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  heading.focus();
  // scrollIntoView with no offset — heading scrolls behind fixed header
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

JavaScript-Fokusmanagement berücksichtigt feste Ebenen nicht — korrekt

<!-- Use scroll-margin-top on the target element, or manually offset scrollY -->
<style>
  .focus-target {
    /* scroll-margin-top offsets this element's scroll position from the top */
    scroll-margin-top: 96px;
  }
</style>

<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  // scroll-margin-top on the element handles the visual offset automatically
  heading.classList.add('focus-target');
  heading.focus();
  // scrollIntoView now respects scroll-margin-top, clearing the fixed header
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

Häufige Fehler

scroll-padding-top auf body statt auf html setzen: Die CSS-Eigenschaft scroll-padding muss auf den Scroll-Container angewendet werden. Beim Scrollen der gesamten Seite ist der Scroll-Container das html-Element, nicht body. Die Anwendung auf body hat in den meisten Browsern keine Wirkung und ist einer der häufigsten Implementierungsfehler.
Einen festen Pixelwert für scroll-padding-top hart zu codieren, der nicht an allen Breakpoints der tatsächlichen Header-Höhe entspricht: Wenn der Header auf Mobilgeräten auf eine geringere Höhe schrumpft oder auf dem Desktop um eine sekundäre Navigationsleiste erweitert wird, ist der statische Offset falsch. Verwenden Sie per JavaScript aktualisierte CSS-Custom-Properties oder calc() mit relativen Einheiten, um den Wert synchron zu halten.
scroll-margin-top bei In-Page-Ankerzielen zu vergessen: Selbst wenn das globale scroll-padding-top für die Tab-Navigation korrekt ist, können Ankerlink-Ziele, die programmatisch den Fokus erhalten (z. B. Skip-Links, Hash-Navigation in SPAs), dennoch unter dem Header landen, sofern auf diesen spezifischen Elementen nicht ebenfalls scroll-margin-top gesetzt ist.
Das Cookie-Banner zu schließen, ohne erneut zu testen: Viele Teams testen die Tastaturnavigation erst, nachdem sie das Cookie-Banner akzeptiert haben. Da das Banner den unteren Bereich des Viewports einnimmt, können unten verankerte fokussierbare Elemente nur verdeckt sein, solange das Banner aktiv ist. Testen Sie immer mit allen persistenten UI-Ebenen in vollständig eingeblendetem Zustand.
Nur bei einer Viewport-Breite zu testen: Sticky-Elemente ändern an verschiedenen Breakpoints häufig ihre Höhe, werden sichtbar oder verschwinden ganz. Ein Fehler bei 375px tritt möglicherweise bei 1440px nicht auf und umgekehrt. Tests nur bei einer Größe übersehen einen erheblichen Teil realer Verstöße.
overflow: hidden auf einem Elternelement zu verwenden, um Fokusindikatoren abzuschneiden: Wenn eine Kartenkomponente oder ein Container overflow: hidden hat, wird die browserstandardmäßige Fokusumrandung von Kindelementen an der Containergrenze abgeschnitten. Dadurch kann der Fokus in der Elementinspektion der DevTools vollständig sichtbar erscheinen, während er für den Nutzer visuell abgeschnitten ist.
Davon auszugehen, dass Screenreader das Scrollen automatisch handhaben, sodass visuelle Tests unnötig sind: Während Screenreader das fokussierte Element akustisch ansagen, sind sehende Tastaturnutzer — einschließlich solcher, die Vergrößerungstools verwenden — vollständig auf die visuelle Position angewiesen. Ein visuell verdeckter Fokuszustand ist ein realer Fehler, unabhängig vom Verhalten des Screenreaders.
Modale Dialoge und Drawer-Overlays nicht zu testen: Wenn ein Modal geöffnet wird und der Fokus in das Modal verschoben wird, können der Hintergrund oder das Modal-Chrome selbst das erste fokussierte Element im Dialog verdecken. Dies ist besonders häufig bei Drawer-Panels, die von der Seite oder von unten herein animiert werden.
Drittanbieter-Widgets wie Live-Chat-Bubbles und Interstitial-Werbebanner zu ignorieren: Schwebende Chat-Widgets (z. B. Intercom, Zendesk) und feste Werbebanner, die von Tag-Managern injiziert werden, sind vom Autor erstellte Inhalte und fallen in den Geltungsbereich dieses Kriteriums. Teams übersehen sie oft, weil sie außerhalb des Haupt-Codebestands verwaltet werden.
Sich ausschließlich auf automatisierte Barrierefreiheits-Scans zu verlassen und das Ticket zu schließen: Da 2.4.12 manuelle Tests erfordert, bestätigt ein sauberer axe-core-Scan die Konformität nicht. Wenn Barrierefreiheits-Tickets allein auf Basis automatisierter Ergebnisse geschlossen werden, wird dieses Kriterium systematisch verfehlt.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Web- und mobile Barrierefreiheit für eine breite Palette von in der Türkei tätigen Einrichtungen fest. Die Verfügung übernimmt WCAG 2.1 Level AA als grundlegenden Konformitätsstandard, was bedeutet, dass WCAG 2.4.12 — als WCAG-2.2-AAA-Kriterium — nach der aktuellen Regelung nicht direkt vorgeschrieben ist. Dennoch ist sein Verhältnis zum türkischen Barrierefreiheitsrahmen aus mehreren Gründen bedeutsam.

Zu den von der Präsidialverfügung 2025/10 erfassten Einrichtungen gehören öffentliche Institutionen und Regierungsstellen aller Ebenen, E-Commerce-Plattformen, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitsorganisationen, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) zugelassen wurden. Für all diese Organisationen ist die Erreichung der WCAG-2.1-AA-Konformität eine gesetzliche Verpflichtung, und es wird erwartet, dass die Verfügung durch Prüfmechanismen der zuständigen Aufsichtsbehörden durchgesetzt wird.

Auch wenn AAA-Konformität durch die Verfügung nicht verlangt wird, haben Organisationen in regulierten Sektoren starke praktische Gründe, die Einhaltung von WCAG 2.4.12 anzustreben. Erstens entwickelt sich die türkische Regulierungslandschaft weiter: Die Verfügung stellt eine deutliche Verschärfung der Barrierefreiheitsdurchsetzung im Vergleich zu früheren Leitlinien dar, und künftige Überarbeitungen könnten WCAG 2.2 übernehmen oder das Konformitätsniveau anheben. Organisationen, die jetzt AAA-Praktiken etablieren, sind besser auf regulatorische Änderungen vorbereitet. Zweitens bevorzugen öffentliche Beschaffungsprozesse und der Zugang zum EU-Markt zunehmend Anbieter, die erweiterte Barrierefreiheitsprogramme nachweisen können, und AAA-Konformitätsdokumentation bietet ein wettbewerbsdifferenzierendes Merkmal.

Drittens — und in direktem Bezug zu WCAG 2.4.12 — adressiert das Kriterium eine Fehlerart, die Nutzer von Hilfstechnologien in der Türkei überproportional betrifft — eine Bevölkerungsgruppe, die auf mehrere Millionen Menschen geschätzt wird, wenn motorische, visuelle und kognitive Behinderungen zusammengezählt werden. Banken, Krankenhäuser und E-Government-Portale, die stark auf feste Navigations-Chrome und persistente Benachrichtigungsebenen setzen, sind genau die Websites, auf denen Fokus-verdeckende Fehler am häufigsten auftreten. Investitionen in eine vollständige WCAG-2.4.12-Konformität zeigen ein echtes Engagement für alle Nutzer, stehen im Einklang mit dem Geist der Präsidialverfügung, auch wenn der Wortlaut dies noch nicht verlangt, und reduzieren rechtliche sowie Reputationsrisiken, während die türkische Durchsetzung reift.

Für Organisationen, die das Accsible-Overlay-SDK verwenden, bietet die Plattform Werkzeuge zur Prüfung von Tastatur-Fokuspfaden und zur Identifizierung von Konflikten durch Sticky-Positionierung und unterstützt damit sowohl die verpflichtenden AA-Anforderungen der Präsidialverfügung 2025/10 als auch freiwillige AAA-Erweiterungen wie WCAG 2.4.12.