WCAG 2.4.11: Fokus nicht verdeckt (Minimum)

WCAG 2.4.11 verlangt, dass eine UI-Komponente, wenn sie den Tastaturfokus erhält, nicht vollständig durch vom Autor erstellte Inhalte wie Sticky-Header, Cookie-Banner oder Chat-Widgets verdeckt wird. Dieses Kriterium stellt sicher, dass Tastaturnutzende immer sehen können, wo sie sich auf der Seite befinden, was für Navigation und Benutzerfreundlichkeit unerlässlich ist.

Was diese Regel bedeutet

WCAG 2.4.11 Focus Not Obscured (Minimum) ist ein Kriterium der Stufe AA, das in WCAG 2.2 eingeführt wurde und ein häufiges, aber schwerwiegendes Barrierefreiheitsproblem adressiert: wenn ein fokussiertes Element vollständig hinter einer anderen Inhaltsschicht auf der Seite verborgen ist. Das Kriterium besagt, dass, wenn eine beliebige Benutzeroberflächenkomponente den Tastaturfokus erhält, diese Komponente nicht vollständig durch vom Autor erstellte Inhalte verdeckt sein darf.

Das Schlüsselwort hier ist vollständig. WCAG 2.4.11 legt die Mindestanforderung fest — es verlangt nur, dass ein Teil des fokussierten Elements sichtbar bleibt. Wenn eine sticky Navigationsleiste die obere Hälfte einer fokussierten Schaltfläche überlappt, die untere Hälfte aber noch sichtbar ist, besteht dies technisch gesehen 2.4.11. Das strengere Begleitkriterium, WCAG 2.4.12 Focus Not Obscured (Enhanced) auf Stufe AAA, geht weiter, indem es verlangt, dass die fokussierte Komponente überhaupt nicht durch vom Autor erstellte Inhalte verdeckt wird — nicht einmal teilweise.

Die Arten von vom Autor erstellten Inhalten, die am häufigsten für dieses Problem verantwortlich sind, umfassen sticky oder fest positionierte Header und Footer, Cookie-Einwilligungsbanner, Chat-Support-Widgets, Benachrichtigungs-Toasts, modale Overlays, Floating Action Buttons und untere Navigationsleisten in mobil-responsiven Layouts. Diese Elemente werden mit CSS-Eigenschaften wie position: fixed, position: sticky oder hohen z-index-Werten gerendert, wodurch sie über dem normalen Dokumentenfluss schweben und potenziell interaktive Elemente überdecken, die den Fokus erhalten.

Ein Pass bedeutet, dass beim Durchtabben der interaktiven Elemente durch Tastaturnutzende zumindest ein Teil jedes fokussierten Elements bzw. seines visuellen Indikators jederzeit auf dem Bildschirm sichtbar ist — selbst wenn ein sticky UI-Element einen Teil davon überlappt. Ein Fail tritt auf, wenn ein fokussiertes Element vollständig unter einer vom Autor erstellten Schicht verborgen ist, sodass die Nutzenden keinerlei visuellen Hinweis darauf haben, wo sich der Fokus aktuell befindet. Vom Browser gerenderte Inhalte wie die eigene Symbolleiste des Browsers gelten nicht als vom Autor erstellte Inhalte und sind daher vom Geltungsbereich dieses Kriteriums ausgenommen. Ebenso ist Inhalt ausgenommen, den die Nutzenden selbst umpositioniert haben (z. B. ein vom Nutzenden verschiebbares Panel).

Dieses Kriterium gilt für alle interaktiven HTML-Elemente, die standardmäßig per Tastatur fokussierbar sind oder über tabindex fokussierbar gemacht wurden, einschließlich <a>, <button>, <input>, <select>, <textarea> und Elemente mit tabindex='0' oder positiven tabindex-Werten.

Warum das wichtig ist

Die Tastaturnavigation ist für mehrere Nutzergruppen grundlegend für die Barrierefreiheit. Menschen mit motorischen Beeinträchtigungen, die keine Maus verwenden können, sind vollständig auf Tastaturen, Schaltsysteme oder Sip-and-Puff-Steuerungen angewiesen, um sich durch eine Webseite zu bewegen. Blinde Menschen nutzen Screenreader in Kombination mit Tastaturen. Menschen mit Sehbehinderungen, die die Tastaturnavigation ohne Screenreader verwenden, sind stark auf den sichtbaren Fokusindikator angewiesen, um zu verstehen, wo sie sich befinden. Wenn dieses fokussierte Element hinter einem sticky Header oder einem schwebenden Widget verborgen ist, sind diese Nutzenden faktisch orientierungslos — sie müssen wiederholt Tab drücken, ihre Position erraten oder die Aufgabe ganz aufgeben.

Betrachten wir ein konkretes Szenario aus der Praxis: Eine Rollstuhlnutzerin mit eingeschränkter Handbeweglichkeit füllt ein Flugbuchungsformular auf der Website einer türkischen Fluggesellschaft aus. Sie verwendet die Tab-Taste, um sich durch die Formularfelder zu bewegen. Die Seite hat ein sticky Cookie-Einwilligungsbanner am unteren Rand des Viewports. Wenn die Nutzerin in das letzte Bestätigungs-Kontrollkästchen tabbt, wird das Kontrollkästchen vollständig unter dem Cookie-Banner gerendert. Die Nutzerin hat keinen visuellen Hinweis darauf, dass das Kontrollkästchen fokussiert ist. Sie kann nicht erkennen, ob ihr Tab-Tastendruck funktioniert hat, ob sie Tab erneut drücken muss oder ob das Kontrollkästchen überhaupt erforderlich ist. Diese Verwirrung kann zu Formularabbrüchen, verpassten Übermittlungen oder wiederholten Tastendrücken führen, die unbeabsichtigte Aktionen auslösen.

Die Auswirkungen gehen über Menschen mit Behinderungen hinaus. Power-User, die aus Gründen der Geschwindigkeit die Tastaturnavigation bevorzugen — Entwickler, Datenerfassungsfachkräfte und versierte Nutzende — profitieren ebenfalls von einer klaren Sichtbarkeit des Fokus. Laut der Weltgesundheitsorganisation leben weltweit etwa 1,3 Milliarden Menschen mit irgendeiner Form von Behinderung, und ein erheblicher Teil davon ist auf unterstützende Technologien oder Tastaturnavigation angewiesen. Speziell in der Türkei berichtet das Türkische Statistische Institut (TÜİK), dass rund 12,7% der Bevölkerung irgendeine Form von Behinderung haben, was etwa 10 Millionen Menschen entspricht, die direkt von einer verbesserten Fokusverwaltung auf digitalen Plattformen profitieren können.

Aus geschäftlicher Sicht erhöhen verdeckte Fokusindikatoren die Abbruchraten bei Aufgaben, verringern die Conversion und setzen Organisationen rechtlichen und regulatorischen Risiken aus. Websites, die dieses Kriterium nicht erfüllen, fallen wahrscheinlich auch bei Barrierefreiheitsaudits durch, die nach türkischem Recht erforderlich sind, und gefährden damit ihre Fähigkeit, das offizielle Erişilebilirlik Logosu (Accessibility Logo) zu erhalten oder zu behalten.

Wie man testet

Führen Sie zuerst einen automatisierten Barrierefreiheitsscan durch. Verwenden Sie axe DevTools (Browser-Erweiterung), Lighthouse in den Chrome DevTools oder einen CI-integrierten axe-core-Scan, um automatisch erkennbare Probleme auf der Seite zu identifizieren. Während 2.4.11 selbst eine manuelle Überprüfung erfordert, kann ein automatisierter Scan verwandte Probleme aufdecken, wie fehlende Fokusindikatoren (2.4.7) oder falsches z-index-Stacking, das auf überlappende Elemente hindeutet. Notieren Sie alle als potenziell problematisch markierten Elemente, bevor Sie mit den manuellen Tests beginnen.
Identifizieren Sie alle festen und sticky Elemente auf der Seite. Öffnen Sie die DevTools des Browsers und inspizieren Sie das CSS der Seite. Suchen Sie nach Elementen mit position: fixed oder position: sticky. Prüfen Sie auch Elemente mit hohen z-index-Werten (z. B. 100 oder höher). Dokumentieren Sie jedes dieser Elemente — Header, Footer, Banner, Chat-Widgets, Cookie-Hinweise — da sie die wahrscheinlichsten Kandidaten sind, um fokussierte Komponenten zu verdecken. Ändern Sie die Größe des Browserfensters, um verschiedene Viewport-Größen zu simulieren, einschließlich Tablet- und Mobilbreiten, da sticky/fixed Elemente sich häufig über Breakpoints hinweg unterschiedlich verhalten.
Führen Sie eine vollständige Tastatur-Tab-Durchquerung durch. Klicken Sie außerhalb eines interaktiven Elements, um sicherzustellen, dass der Fokus oben auf der Seite beginnt, und drücken Sie dann wiederholt Tab, um alle fokussierbaren Elemente zu durchlaufen. Beobachten Sie jedes Element sorgfältig, wenn es den Fokus erhält. Achten Sie besonders auf Elemente, die in der Nähe des oberen oder unteren Randes des Viewports erscheinen, wo feste Header oder Footer am ehesten überlappen. Wenn zu irgendeinem Zeitpunkt der sichtbare Fokusring oder das hervorgehobene Element vollständig hinter einer festen Schicht verschwindet, ist dies ein Verstoß gegen 2.4.11. Verwenden Sie auch Shift+Tab, um in umgekehrter Richtung zu traversieren, da sich Scrollposition und Layout unterscheiden können.
Testen Sie mit NVDA und Firefox. Öffnen Sie NVDA (kostenloser, Open-Source-Screenreader für Windows) und starten Sie Firefox. Aktivieren Sie den Browse-Modus von NVDA und verwenden Sie Tab, um sich durch die Seite zu bewegen. Während NVDA jedes fokussierte Element akustisch ankündigt, beobachten Sie den Bildschirm auch visuell. Notieren Sie jedes Element, bei dem NVDA den Fokus ankündigt, aber aufgrund verdeckender Inhalte kein visueller Fokusindikator sichtbar ist. Diese Kombination wird in der Türkei und weltweit häufig verwendet und stellt ein wichtiges Assistive-Technology-Paar dar.
Testen Sie mit VoiceOver und Safari auf macOS/iOS. Aktivieren Sie VoiceOver (Befehl+F5 auf dem Mac) und verwenden Sie Tab oder die Navigationsgesten von VoiceOver, um sich durch fokussierbare Elemente zu bewegen. Verwenden Sie auf iOS Wischgesten. Vergewissern Sie sich, dass fokussierte Elemente visuell vorhanden sind und nicht unter festen UI-Schichten verborgen sind, insbesondere auf Mobilgeräten, wo Navigationsleisten und Cookie-Banner einen größeren Teil des Viewports einnehmen können.
Testen Sie mit JAWS und Chrome. Öffnen Sie JAWS (Job Access With Speech) und verwenden Sie Chrome. Tabben Sie durch alle interaktiven Elemente und überwachen Sie jeden Moment, in dem der JAWS-Cursor zu einem Element wechselt, das visuell unter einer festen Schicht verborgen ist. JAWS wird in Unternehmens- und Regierungsumgebungen weit verbreitet eingesetzt, was diese Kombination für Tests von Websites des öffentlichen Sektors und von Unternehmen besonders wichtig macht.
Testen Sie nach Nutzerinteraktionen, die das Layout verändern. Schließen Sie Cookie-Banner, öffnen und schließen Sie Navigationsmenüs, lösen Sie Benachrichtigungs-Toasts aus und öffnen Sie Chat-Widgets. Führen Sie nach jeder Zustandsänderung eine neue Tab-Durchquerung durch, um sicherzustellen, dass das neue Layout keine neuen Fälle von verdecktem Fokus einführt. Dynamische Inhalte sind eine häufige Quelle für 2.4.11-Verstöße, die erst nach Nutzerinteraktion auftreten.
Testen Sie bei mehreren Scrollpositionen. Scrollen Sie in die Mitte oder an das Ende einer langen Seite und tabben Sie dann durch Elemente in diesem Bereich. Feste Header verdecken möglicherweise keine Elemente in der Nähe des oberen Seitenbereichs, können aber Elemente überdecken, die am oberen Rand des Viewports erscheinen, wenn die Nutzenden nach unten scrollen. Bestätigen Sie, dass keine Kombination aus Scrollposition und fokussiertem Element zu einer vollständigen visuellen Verdeckung führt.

Wie man es behebt

Sticky Header überlappt fokussierte Links — Falsch

<!-- Sticky header with no scroll offset accommodation -->
<header style='position: fixed; top: 0; left: 0; width: 100%; height: 60px; z-index: 1000; background: white;'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- No scroll-margin-top set; focused link at top of main scrolls under the header -->
  <a href='/section-one'>Go to Section One</a>
  <a href='/section-two'>Go to Section Two</a>
</main>

Sticky Header überlappt fokussierte Links — Richtig

<!-- Fixed header with scroll-margin-top applied to all focusable elements -->
<header class='site-header'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top ensures the browser scrolls the element into view
       with enough clearance so the fixed header does not cover it -->
  <a href='/section-one' class='content-link'>Go to Section One</a>
  <a href='/section-two' class='content-link'>Go to Section Two</a>
</main>

<!-- In your stylesheet: -->
<!-- .site-header { position: fixed; top: 0; height: 60px; z-index: 1000; } -->
<!-- * { scroll-margin-top: 70px; } -->
<!-- The 70px (header height + 10px buffer) keeps focused elements
     visible below the fixed header when the browser auto-scrolls. -->

Cookie-Banner verdeckt unten fokussiertes Formularfeld — Falsch

<!-- Cookie banner fixed at bottom with no accommodation for form fields above it -->
<div id='cookie-banner' class='cookie-overlay'>
  <p>We use cookies. <button>Accept</button></p>
</div>

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <!-- This checkbox renders in the viewport area covered by the cookie banner -->
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Cookie-Banner verdeckt unten fokussiertes Formularfeld — Richtig

<!-- Cookie banner pushes page content up instead of overlapping it -->
<div id='cookie-banner' class='cookie-banner-flow'>
  <p>We use cookies. <button id='accept-cookies'>Accept</button></p>
</div>

<!-- In your stylesheet: -->
<!-- .cookie-banner-flow { position: static; } instead of position: fixed -->
<!-- Alternatively, if fixed positioning is required for design reasons,
     add scroll-margin-bottom to all focusable elements equal to the
     banner height, or apply padding-bottom to <body> equal to
     the banner height so content is never hidden beneath it. -->

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Chat-Widget eines Drittanbieters überlappt fokussierte Schaltfläche — Falsch

<!-- Third-party chat widget injected in bottom-right corner
     with a high z-index, obscuring the focused Submit button -->
<div id='chat-widget' class='chat-fixed'>
  <!-- Injected by third-party script, covers 120x120px in bottom-right -->
</div>

<section class='cta-section'>
  <!-- Button positioned in the bottom-right area of the layout;
       when focused, it is completely hidden beneath the chat widget -->
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

Chat-Widget eines Drittanbieters überlappt fokussierte Schaltfläche — Richtig

<!-- Approach 1: Reposition the chat widget to avoid overlapping focusable content -->
<div id='chat-widget' class='chat-fixed-adjusted'>
  <!-- Widget repositioned to bottom-left, away from the CTA button -->
</div>

<!-- Approach 2: Ensure the button has scroll-margin that keeps it
     clear of the widget when focused -->
<section class='cta-section'>
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

<!-- Approach 3: Use JavaScript to detect focus events on elements
     near the widget's bounding box and temporarily collapse or
     move the widget so the focused element is visible. -->
<script>
  // Example: collapse widget when nearby element gains focus
  document.querySelectorAll('.cta-button').forEach(function(btn) {
    btn.addEventListener('focus', function() {
      var widget = document.getElementById('chat-widget');
      if (widget) widget.setAttribute('aria-hidden', 'false');
      // Additional logic to reposition or minimize widget
    });
  });
</script>

Häufige Fehler

position: fixed auf Header und Footer anwenden, ohne scroll-margin-top oder scroll-margin-bottom zu fokussierbaren Elementen hinzuzufügen. Das native Fokus-Scrolling des Browsers berücksichtigt keine festen überlappenden Elemente, sodass fokussierte Elemente an den oberen oder unteren Rand des Viewports scrollen und hinter der festen Schicht enden. Eine globale CSS-Regel wie * { scroll-margin-top: [header-height]px; } löst dies effizient.
body { padding-top: 60px; } setzen, um einen festen Header auszugleichen, aber vergessen, einen entsprechenden scroll-margin-top für den Tastaturfokus hinzuzufügen. Das Padding stellt sicher, dass Inhalte anfangs nicht verborgen sind, aber wenn der Tastaturfokus das automatische Scrollen des Browsers auslöst, kann das Scrollziel dennoch hinter den Header rutschen. Beide Ansätze müssen zusammen verwendet werden.
z-index: 9999 auf Werbebannern oder Chat-Widgets setzen, ohne zu prüfen, welche fokussierbaren Elemente in ihren Bereich fallen. Ein hoher z-index stellt sicher, dass das Overlay über allem gerendert wird, einschließlich fokussierter Schaltflächen und Links, und ist damit die häufigste Hauptursache für 2.4.11-Verstöße.
Cookie-Banner per JavaScript schließen, ohne sie sofort aus dem Layout zu entfernen. Wenn das DOM-Element des Banners mit visibility: hidden oder opacity: 0 bestehen bleibt, aber weiterhin Platz einnimmt oder einen von Null verschiedenen z-index hat, kann es in bestimmten Browser-Rendering-Szenarien weiterhin fokussierte Elemente visuell verdecken.
Einbetten von Widgets Dritter (Live-Chat, Accessibility-Overlays, GDPR-Manager), ohne ihre Auswirkungen auf die Sichtbarkeit des Tastaturfokus zu überprüfen. Skripte von Drittanbietern fügen häufig fest positionierte Elemente mit sehr hohen z-index-Werten ein. Teams müssen diese Integrationen ausdrücklich als Teil ihres Accessibility-QA-Prozesses testen.
Versäumnis, 2.4.11 nach Änderungen an responsiven Breakpoints zu testen. Eine sticky Navigationsleiste, die auf dem Desktop 60px hoch ist, kann sich auf dem Tablet auf 120px erweitern, wenn ein Hamburger-Menü geöffnet ist, wodurch plötzlich ein viel größerer Bereich verdeckt wird und neue Fehler an Breakpoints entstehen, die auf dem Desktop bestanden haben.
scroll-margin-top nur auf Ankerziele (<h2>, <section>) anwenden, aber nicht auf interaktive Elemente wie <input>, <button> und <a>. Der Scrollversatz für Anker wird häufig berücksichtigt, aber das automatische Fokus-Scrolling der Tastatur zu Nicht-Anker-Elementen ist gleichermaßen betroffen und muss durch dieselbe CSS-Regel abgedeckt werden.
Annehmen, dass ein fokussiertes Element, weil es von einem Screenreader angekündigt wird, auch visuell sichtbar ist. Screenreader greifen auf den Accessibility-Tree zu, nicht auf das visuelle Rendering. Ein Element kann vollständig hinter einem festen Overlay verborgen sein und dennoch korrekt von NVDA oder JAWS angekündigt werden. Dies sind zwei getrennte Themen — 2.4.11 bezieht sich speziell auf die visuelle Fokus-Sichtbarkeit für sehende Tastaturnutzende.
Versäumnis, Fokusverdeckung nach Routenwechseln in Single-Page-Applications (SPA) zu testen. In React-, Vue- oder Angular-Apps rendern Routenübergänge häufig feste Header mit aktualisiertem Zustand neu, und das Fokusmanagement während der Navigation kann den Fokus auf Elemente setzen, die sofort von einem neu montierten sticky Header verdeckt werden, bevor die Nutzenden die neue Seite sehen.
Sich ausschließlich auf automatisierte Testtools verlassen und daraus schließen, dass keine 2.4.11-Probleme existieren, weil keine automatisierte Regel die Seite markiert hat. Da axe-core keine automatisierte Regel für dieses Kriterium hat, bedeutet ein sauberer automatisierter Bericht nicht, dass die Seite besteht. Manuelle Tastatur-Durchquerung über alle Viewport-Größen und Seitenzustände hinweg ist zwingend erforderlich.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

WCAG 2.4.11 Focus Not Obscured (Minimum) ist direkt relevant für den sich entwickelnden rechtlichen Rahmen zur Barrierefreiheit in der Türkei. Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die digitale Barrierefreiheit fest, die sich an WCAG 2.2 orientieren. Diese Verfügung stellt eine bedeutende Ausweitung des Engagements der Türkei für digitale Inklusion dar und auferlegt einer Vielzahl von Akteuren, die auf dem türkischen digitalen Markt tätig sind, durchsetzbare Verpflichtungen.

Die Verfügung umfasst einen breiten Kreis von Organisationen, darunter öffentliche Institutionen und Regierungsbehörden, E-Commerce-Plattformen, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitsorganisationen, Telekommunikationsunternehmen mit mehr als 200.000 Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind. All diese Akteure sollen sicherstellen, dass ihre digitalen Schnittstellen — Websites, mobile Anwendungen und webbasierte Tools — der Stufe AA von WCAG 2.2 entsprechen.

Da WCAG 2.4.11 ein Kriterium der Stufe AA in WCAG 2.2 ist, ist die Einhaltung dieser Regel für die betroffenen Akteure nicht optional. Organisationen, die das offizielle Erişilebilirlik Logosu (Accessibility Logo) erhalten oder behalten möchten, das vom Ministerium für Familie und Soziale Dienste (Aile ve Sosyal Hizmetler Bakanlığı) vergeben wird, müssen die Konformität der Stufe AA erreichen. Das Accessibility Logo dient als öffentliches Signal für das Engagement für digitale Inklusion und wird von türkischen Verbraucherinnen und Verbrauchern sowie von öffentlichen Beschaffungsstellen zunehmend erwartet.

Praktisch bedeutet dies, dass Websites türkischer öffentlicher Institutionen mit sticky Navigations-Headern, E-Commerce-Seiten mit persistenten Werbebannern, Bankportale mit schwebenden Hilfe-Widgets und Systeme zur Gesundheits-Terminvergabe mit Cookie-Einwilligungs-Overlays alle im Hinblick auf Fokusverdeckung nach 2.4.11 getestet und überarbeitet werden müssen. Verstöße gegen dieses Kriterium treten besonders wahrscheinlich in komplexen, marketinglastigen Oberflächen auf — genau der Art von Websites, die von den großen kommerziellen Akteuren betrieben werden, die von der Verfügung erfasst sind.

Organisationen, die unter die Verfügung fallen, sollten Tests zu 2.4.11 in ihre regelmäßigen Barrierefreiheitsaudit-Zyklen integrieren. Da dieses Kriterium manuelle Tests erfordert, wird die ausschließliche Nutzung automatisierter Scans die Sorgfaltspflichten nicht erfüllen. Türkischen Akteuren, die eine vollständige Konformität anstreben, wird empfohlen, manuelle Tastatur-Durchquerungstests über alle Viewport-Größen und dynamischen Seitenzustände hinweg als Teil ihrer Konformitätsdokumentation durchzuführen und alle identifizierten Probleme mit Fokusverdeckung im Rahmen ihres Maßnahmenplans zu beheben, bevor sie das Accessibility Logo beantragen oder erneuern.