WCAG 2.4.7: Fokus sichtbar

Was diese Regel bedeutet

WCAG 2.4.7 Focus Visible verlangt, dass jedes interaktive Element auf einer Webseite – Links, Buttons, Formulareingaben, benutzerdefinierte Widgets und jede andere per Tastatur bedienbare Komponente – einen sichtbaren Fokusindikator anzeigt, wenn es den Tastaturfokus erhält. Einfach ausgedrückt: Wenn ein Nutzer die Tab-Taste drückt, um sich durch eine Seite zu bewegen, muss er genau sehen können, welches Element aktuell aktiv ist.

Das Kriterium schreibt keinen bestimmten visuellen Stil für den Fokusindikator vor. Es verlangt nur, dass irgendeine sichtbare Veränderung auftritt. Das heißt jedoch: Ein kaum wahrnehmbarer Indikator – zum Beispiel eine ein Pixel breite gepunktete Umrandung, die mit dem Hintergrund verschmilzt – kann 2.4.7 technisch bestehen, aber dennoch am strengeren WCAG 2.4.11 (Focus Appearance) scheitern, das in WCAG 2.2 eingeführt wurde. Unter 2.4.7 allein genügt jede erkennbare visuelle Veränderung.

Was als bestanden gilt: Ein Fokusindikator besteht, wenn ein sehender Nutzer, der sich per Tab durch die Seite bewegt, erkennen kann, welches Element fokussiert ist, ohne sich auf Screenreader-Ausgaben oder andere nicht-visuelle Hinweise zu verlassen. Übliche akzeptable Umsetzungen sind die Standardumrandungen des Browsers, benutzerdefinierte CSS-Regeln mit outline oder box-shadow, Änderungen der Unterstreichung oder Hintergrundfarbe, die bei :focus oder :focus-visible angewendet werden.

Was als nicht bestanden gilt: Ein Fehler liegt vor, wenn ein Entwickler den standardmäßigen Fokusring des Browsers entfernt – typischerweise über outline: none oder outline: 0 in CSS – und ihn nicht durch einen gleichwertigen benutzerdefinierten Indikator ersetzt. Fehler treten auch auf, wenn eine benutzerdefinierte Komponente (mit <div>- oder <span>-Elementen erstellt) über tabindex tastaturfokussierbar gemacht wird, aber beim Fokus keine sichtbare Stiländerung erhält.

Offizielle Ausnahmen: WCAG weist darauf hin, dass das Kriterium nur für tastaturbedienbare Schnittstellen gilt. Komponenten, die rein dekorativ sind oder ausdrücklich aus der Tab-Reihenfolge ausgeschlossen werden (über tabindex='-1'), müssen keinen Fokusindikator anzeigen, da sie über die normale Tastaturnavigation keinen Fokus erhalten können.

Warum es wichtig ist

Die Sichtbarkeit des Fokus ist grundlegend für die Tastaturzugänglichkeit, und Tastaturzugänglichkeit ist das Einfallstor zum Zugang für eine breite Gruppe von Menschen mit Behinderungen. Laut CDC leben in den Vereinigten Staaten etwa 26% der Erwachsenen mit irgendeiner Form von Behinderung, und viele dieser Personen sind auf Tastaturen oder tastaturemulierende Hilfstechnologien angewiesen, statt auf Zeigegeräte.

Nutzer mit motorischen Beeinträchtigungen – darunter Menschen mit Erkrankungen wie ALS, Zerebralparese, RSI (Repetitive-Strain-Verletzungen) oder Parkinson – sind häufig auf Tastaturen, Schaltergeräte, Sip-and-Puff-Steuerungen oder Blickverfolgungssoftware angewiesen. All diese Eingabemethoden basieren auf dem Tastaturfokusmodell des Browsers. Ist der Fokusindikator unsichtbar, können diese Nutzer nicht erkennen, wo sie sich auf der Seite befinden, können das richtige Steuerelement nicht aktivieren und sind möglicherweise vollständig von kritischen Aufgaben ausgeschlossen, etwa dem Absenden eines Formulars, dem Abschluss eines Kaufs oder der Navigation in einem Menü.

Nutzer mit Sehbehinderungen, die keinen Screenreader verwenden, aber den Bildschirm vergrößern, sind ebenfalls auf sichtbaren Fokus angewiesen. Wenn sie in einen Teil der Seite hineinzoomen, zeigt ihnen der sichtbare Fokusring, welches Element aktiv ist, und leitet ihre Interaktion.

Nutzer mit kognitiven Beeinträchtigungen und Aufmerksamkeitsstörungen profitieren ebenfalls von klaren Fokusindikatoren. Menschen mit ADHS oder Gedächtnisschwierigkeiten verlieren auf komplexen Seiten oft die Orientierung; ein prominenter Fokusindikator bietet einen verlässlichen visuellen Anker.

Ein konkretes Szenario aus der Praxis: Stellen Sie sich eine Nutzerin mit Multipler Sklerose vor, die eine E-Commerce-Seite ausschließlich mit der Tastatur nutzt, weil die Maussteuerung zu schwierig geworden ist. Sie tabbt auf der Produktseite bis zum Button „Add to Cart“. Wenn der Entwickler den Fokusring unterdrückt hat, sieht die Nutzerin keinen Hinweis darauf, wo der Fokus ist. Sie drückt Enter, und entweder passiert nichts (der Fokus liegt auf einem nicht interaktiven Element) oder es wird die falsche Aktion ausgelöst. Das Ergebnis sind Frustration, Abbruch der Aufgabe und Umsatzverlust für das Unternehmen – alles vermeidbar mit einer einzigen CSS-Regel.

Über Behinderungen hinaus kommen Fokusindikatoren allen Nutzern zugute, wenn die Mausbedienung unpraktisch ist: Power-User, die per Tastaturkürzel navigieren, Laptop-Nutzer ohne externe Maus und Nutzer, die lange Formulare ausfüllen. Sichtbarer Fokus verbessert zudem indirekt die SEO, indem er semantisches HTML und eine korrekte Tab-Reihenfolge fördert – beides wird von Suchmaschinen-Crawlern positiv bewertet.

Verwandte Axe-core-Regeln

WCAG 2.4.7 erfordert manuelle Tests, weil automatisierte Tools nicht zuverlässig feststellen können, ob ein Fokusindikator sichtbar ist. Axe-core und ähnliche Engines können erkennen, dass eine CSS-Regel wie outline: none existiert, aber sie können das gerenderte visuelle Ergebnis nicht über alle Themes, Hochkontrastmodi und Browser-Rendering-Engines hinweg beurteilen. Im Folgenden wird die Testlandschaft erläutert:

• Manuelle Tests erforderlich – Unterdrückung von focus-visible: Axe-core liefert keine dedizierte Regel, die 2.4.7-Verstöße eindeutig kennzeichnet, da dies erfordern würde, die Seite zu rendern, jedes Element per Tab zu durchlaufen und eine Pixel-für-Pixel-Kontrastanalyse des Fokusindikators durchzuführen – eine Aufgabe, die über statische oder DOM-basierte Analysen hinausgeht. Stattdessen müssen Tester die Seite manuell per Tab durchgehen und visuell bestätigen, dass jedes interaktive Element eine Fokusänderung zeigt.
• Teilweise Signale durch css-orientation-lock und Stilprüfungen: Einige axe-core-Konfigurationen markieren das Vorhandensein von outline: 0 oder outline: none in Stylesheets als Best-Practice-Warnung, aber dies ist eine Heuristik, kein eindeutiger Verstoß, da die Regel durch einen gültigen benutzerdefinierten Fokusstil an anderer Stelle in der Cascade überschrieben werden kann.
• Warum Automatisierung nicht ausreicht: Ein Fokusindikator kann nur in bestimmten Zuständen verborgen sein (z. B. wenn ein Modal geöffnet ist), nur für bestimmte Elementtypen oder nur in bestimmten Farbthemen. Diese bedingten Fehler erfordern, dass ein menschlicher Tester jedes interaktive Element in der tatsächlich gerenderten Umgebung durchläuft und die Sichtbarkeit bestätigt. Tools wie axe DevTools Pro können unterstützen, indem sie Elemente hervorheben, auf die outline: none angewendet wurde, aber die endgültige Entscheidung über Bestehen/Nichtbestehen muss ein Mensch treffen.

Wie man testet

1. Automatischer Vorab-Scan: Führen Sie axe DevTools (Browser-Erweiterung oder CLI) oder Google Lighthouse auf der Seite aus. Suchen Sie nach Best-Practice- oder experimentellen Warnungen zu Fokusstilen. Auch wenn diese nicht endgültig einen 2.4.7-Verstoß bestätigen, machen sie auf Elemente aufmerksam, die überprüft werden sollten. Prüfen Sie in Lighthouse die Kategorie „Accessibility“ auf fokusbezogene Ergebnisse. Exportieren Sie den Bericht und notieren Sie alle markierten interaktiven Elemente.
2. Manueller Tastatur-Tab-Test: Trennen Sie die Maus oder legen Sie sie beiseite. Drücken Sie wiederholt Tab vom oberen Seitenbereich aus und navigieren Sie durch alle interaktiven Elemente – Links, Buttons, Eingabefelder, Dropdowns, Modals, Tabs, Akkordeons und Datepicker. Bestätigen Sie an jeder Station, dass sich das fokussierte Element visuell von seinen nicht fokussierten Nachbarn unterscheidet. Protokollieren Sie jedes Element, bei dem der Fokus keine sichtbare Veränderung bewirkt.
3. Rückwärts-Tab-Test: Verwenden Sie Shift+Tab, um rückwärts durch die Seite zu navigieren, und wiederholen Sie die visuelle Prüfung. Manche Implementierungen verlieren die Fokus-Sichtbarkeit nur in eine Richtung, etwa aufgrund von CSS-Spezifitätsproblemen.
4. NVDA- + Firefox-Test: Öffnen Sie Firefox mit laufendem NVDA. Verwenden Sie den Browse Mode (Pfeiltasten) und wechseln Sie dann in den Forms Mode (Enter), um mit Formularsteuerelementen zu interagieren. Bestätigen Sie, dass jedes Element, das NVDA als fokussiert ansagt, auch auf dem Bildschirm einen sichtbaren Indikator zeigt – hilfreich, um Abweichungen zwischen AT-Fokus und Browser-Fokus zu erkennen.
5. VoiceOver- + Safari-Test (macOS/iOS): Aktivieren Sie VoiceOver und verwenden Sie Tab oder VO+Pfeil rechts, um durch interaktive Elemente zu navigieren. Überprüfen Sie visuell, ob der Fokusring auf dem Bildschirm mit den VoiceOver-Ausgaben übereinstimmt.
6. JAWS- + Chrome-Test: Verwenden Sie JAWS im virtuellen Cursor-Modus und anschließend im Anwendungsmodus. Tabben Sie durch interaktive Steuerelemente und bestätigen Sie, dass der sichtbare Fokusindikator bei jedem fokussierten Element erscheint.
7. Test im Hochkontrastmodus: Aktivieren Sie den Windows-Hochkontrastmodus (oder „Kontrast erhöhen“ auf macOS) und wiederholen Sie den Tab-Test. Manche Fokusindikatoren basieren auf Farben, die in Hochkontrast-Themes verschwinden; der Indikator muss in diesen Modi sichtbar bleiben.
8. CSS-Inspektion: Öffnen Sie die DevTools des Browsers, wählen Sie ein interaktives Element aus, fokussieren Sie es, indem Sie Tab drücken, bis es aktiv ist, und prüfen Sie die berechneten Stile. Vergewissern Sie sich, dass keine Regel outline: none oder outline: 0 setzt, ohne einen ausgleichenden Fokusstil bereitzustellen. Prüfen Sie außerdem :focus-visible im Vergleich zu :focus, um sicherzustellen, dass tastaturausgelöster Fokus abgedeckt ist.

Wie man es behebt

Globale Unterdrückung von outline ohne Ersatz – Falsch

<!-- CSS-Resets, die alle Fokusindikatoren global entfernen -->
<style>
  * {
    outline: none; /* Entfernt den Fokusring von jedem Element */
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>

Globale Unterdrückung von outline ohne Ersatz – Richtig

<!-- Entfernen Sie das globale outline: none-Reset.
     Stellen Sie einen benutzerdefinierten Fokusstil bereit, der visuell klar ist. -->
<style>
  /* Respektieren Sie Nutzer, die reduzierte Bewegung bevorzugen */
  :focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>
<!-- Jetzt zeigen beide Elemente eine kontrastreiche blaue Umrandung, wenn sie per Tastatur fokussiert werden -->

Benutzerdefinierter, auf div basierender Button ohne Fokusstil – Falsch

<!-- Ein als Button gestyltes div, fokussierbar gemacht, aber ohne :focus-CSS -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  /* Keine :focus- oder :focus-visible-Regel definiert */
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>

Benutzerdefinierter, auf div basierender Button ohne Fokusstil – Richtig

<!-- Fügen Sie :focus-visible zur benutzerdefinierten Komponente hinzu,
     damit Tastaturnutzer einen klaren Indikator sehen, wenn dieses Element fokussiert ist -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  .fake-btn:focus-visible {
    outline: 3px solid #ffcc00;
    outline-offset: 3px;
  }
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>
<!-- Die gelbe Umrandung erscheint nur bei Tastaturfokus, nicht bei Mausklick -->

Fokusring in einem Modal-Overlay verborgen – Falsch

<!-- Das Modal setzt overflow:hidden und einen Stacking-Kontext,
     der die Standardumrandung abschneidet und unsichtbar macht -->
<style>
  .modal-body {
    overflow: hidden; /* Schneidet Umrandungen ab, die über das Element hinausragen */
    border-radius: 8px;
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Fokusring in einem Modal-Overlay verborgen – Richtig

<!-- Verwenden Sie box-shadow statt outline, damit er
     innerhalb des Stacking-Kontexts gerendert wird und nie abgeschnitten wird -->
<style>
  .modal-body {
    overflow: hidden;
    border-radius: 8px;
  }
  .modal-body button:focus-visible {
    /* box-shadow wird nicht von overflow:hidden abgeschnitten --
       es bleibt innerhalb der eigenen Box des Elements -->
    box-shadow: 0 0 0 3px #005fcc;
    outline: none; /* Entfernt den Standard, um einen doppelten Ring zu vermeiden */
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Häufige Fehler

• Hinzufügen von outline: none zu einem grundlegenden CSS-Reset, ohne zu prüfen, welche Elemente betroffen sind. Viele populäre Resets (z. B. ältere Versionen von normalize.css oder Bootstrap-Utilities) unterdrücken Fokusringe global. Ergänzen Sie dies immer durch eine explizite :focus-visible-Regel, die die Sichtbarkeit für Tastaturnutzer wiederherstellt.
• Sich ausschließlich auf :focus zu verlassen, wenn :focus-visible angemessener wäre – oder umgekehrt. Nur :focus zu verwenden, zeigt den Indikator auch bei Mausklicks, was merkwürdig wirken kann. Nur :focus-visible ohne :focus-Fallback zu nutzen, kann dazu führen, dass ältere Browser gar keinen Indikator anzeigen. Testen Sie in allen Zielbrowsern.
• Anwenden von outline: none in einem Theme-Override einer Komponentenbibliothek, ohne die Cascade zu verstehen. Ein einziges Override in einer Theme-Datei kann Fokusindikatoren für jede Komponente, die davon erbt – einschließlich Drittanbieter-Widgets – unbemerkt entfernen.
• Verwendung einer Fokusfarbe mit unzureichendem Kontrast zum Element- oder Seitenhintergrund. Eine hellgraue Umrandung auf weißem Hintergrund fügt technisch eine Umrandung hinzu, kann aber kaum wahrnehmbar sein. Während 2.4.7 kein bestimmtes Kontrastverhältnis vorschreibt, tut dies 2.4.11 – und Fokusindikatoren mit geringem Kontrast sind eine häufige Ursache für Audit-Fehler, selbst wenn Entwickler glauben, die Anforderungen erfüllt zu haben.
• Setzen von overflow: hidden oder clip-path auf einem Container, wodurch die Standardumrandung des Browsers abgeschnitten wird. Die Lösung besteht darin, auf box-shadow-basierte Fokusindikatoren umzusteigen, die innerhalb der eigenen Box des Elements gerendert werden und nicht von overflow-Regeln der Eltern abgeschnitten werden.
• Vergessen von Fokusindikatoren für interaktive Elemente innerhalb von SVG- oder Canvas-Komponenten. Benutzerdefinierte Chart-Tooltips, SVG-basierte Icon-Buttons und Canvas-basierte Zeichenwerkzeuge haben oft keine nativen Fokusstile. Diese benötigen explizite ARIA-Rollen, tabindex und :focus-visible-CSS oder JavaScript-gesteuertes visuelles Feedback.
• Entfernen der Fokus-Sichtbarkeit nur in der Produktions-CSS (z. B. über einen Postprozessor oder Build-Schritt), während sie in der Entwicklungsumgebung sichtbar bleibt. Dadurch besteht das Entwicklungsteam die lokale QA, liefert aber fehlerhafte Barrierefreiheit an Endnutzer aus.
• Anwenden eines Fokusindikators nur auf das <a>-Element, nicht aber auf role='link'-span-Elemente, die für SPA-Navigationslinks verwendet werden. Jedes tastaturfokussierbare Element – unabhängig von seinem nativen Tag – benötigt einen sichtbaren Fokuszustand.
• Verbergen von Fokusringen nur in bestimmten Viewport-Breiten über Media Queries, in der Annahme, dass mobile Nutzer immer den Touchscreen verwenden. Tablet-Nutzer mit Bluetooth-Tastaturen und Nutzer im Querformat, die auf Tastatureingaben angewiesen sind, bleiben ohne Fokusindikator.
• Verwendung von JavaScript, um unmittelbar nach einem programmatischen Fokus .blur() aufzurufen, um das Erscheinen des Fokusrings zu verhindern. Dies ist ein kritischer Fehler, der die Fokus-Sichtbarkeit vollständig entfernt und niemals als Design-Abkürzung verwendet werden darf.

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 schreibt die Konformität mit WCAG 2.2 auf Level AA für die betroffenen Organisationen vor und macht WCAG 2.4.7 Focus Visible damit zu einer direkt durchsetzbaren Anforderung und nicht nur zu einer Best-Practice-Empfehlung.

Zu den von der Verfügung erfassten Einrichtungen gehören öffentliche Institutionen und Behörden, E-Commerce-Plattformen, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitseinrichtungen, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind. Für all diese Organisationen ist das Versäumnis, sichtbare Fokusindikatoren in ihren digitalen Oberflächen bereitzustellen, ein Verstoß gegen die Vorschriften und nicht nur ein Usability-Defizit.

Das Erişilebilirlik Logosu (Barrierefreiheitslogo), das vom Ministerium für Familie und Soziale Dienste vergeben wird, dient als offizielles Zertifizierungszeichen, das betroffene Einrichtungen zur Demonstration ihrer Konformität verwenden können. Der Erhalt des Barrierefreiheitslogos erfordert das Bestehen eines formellen Audits nach WCAG 2.2 Level AA. WCAG 2.4.7 ist eines der AA-Kriterien, die Auditoren bewerten werden, typischerweise durch manuelle Tastaturtests, wie im Testabschnitt oben beschrieben. Eine Organisation, deren Website Fokusringe unterdrückt oder keinen sichtbaren Fokus für benutzerdefinierte Komponenten implementiert, wird das für das Logo erforderliche Audit nicht bestehen.

Insbesondere für türkische E-Commerce-Plattformen hat die Sichtbarkeit des Fokus direkte kommerzielle Auswirkungen: Barrierefreie Seiten erreichen eine größere Nutzerbasis, einschließlich Kunden mit motorischen Beeinträchtigungen, die ausschließlich per Tastatur oder Schalterzugang einkaufen, und die Einhaltung der Präsidialverfügung 2025/10 schützt Organisationen vor Verwaltungsmaßnahmen. Fokus-sichtbare Muster von Anfang an in die Komponentenbibliothek einzubauen – statt sie nach einem Audit nachzurüsten – ist der kosteneffektivste Weg, um das Erişilebilirlik Logosu zu erhalten und die Barrierefreiheitsverpflichtungen der Türkei zu erfüllen.