WCAG-Erfolgskriterien · Level AAA

WCAG 2.4.13: Fokusdarstellung

WCAG 2.4.13 verlangt, dass Tastatur-Fokusindikatoren Mindestanforderungen an Größe und Kontrast erfüllen, damit Nutzer klar erkennen können, welches Element den Fokus hat. Dieses Kriterium stellt sicher, dass Menschen, die auf Tastaturen oder unterstützende Technologien angewiesen sind, in Benutzeroberflächen navigieren können, ohne ihre aktuelle Position aus den Augen zu verlieren.

Was diese Regel bedeutet

WCAG 2.4.13 Focus Appearance ist ein Kriterium der Stufe AAA, das in WCAG 2.2 eingeführt wurde und präzise, messbare Anforderungen an das visuelle Erscheinungsbild von Tastatur-Fokusindikatoren festlegt. Während das Kriterium 2.4.11 (Focus Not Obscured, Stufe AA) sicherstellt, dass das fokussierte Element nicht vollständig verdeckt ist, und 2.4.7 (Focus Visible, Stufe AA) lediglich verlangt, dass irgendein Fokusindikator vorhanden ist, geht 2.4.13 weiter, indem es definiert, wie sichtbar dieser Indikator sein muss.

Um dieses Kriterium zu erfüllen, muss der Tastatur-Fokusindikator alle folgenden Bedingungen erfüllen:

  • Mindestfläche: Der Fokusindikator muss eine Fläche haben, die mindestens dem Umfang der nicht fokussierten Komponente multipliziert mit 2 CSS-Pixeln entspricht. Praktisch bedeutet dies für eine typische rechteckige Schaltfläche, dass die Fokusumrandung eine Fläche haben muss, die mindestens dem Umfang der Schaltfläche mal 2px entspricht — ein Fokusring, der mindestens 2px dick um den gesamten Rand verläuft, erfüllt diese Anforderung.
  • Kontrastverhältnis des Fokusindikators: Die Pixel, die den Fokusindikator bilden, müssen ein Kontrastverhältnis von mindestens 3:1 zwischen ihrem fokussierten und ihrem nicht fokussierten Zustand aufweisen. Wenn eine Schaltfläche also im Standardzustand einen weißen Hintergrund hat, muss der Fokusring, der um sie herum gezeichnet wird, mindestens 3:1 zu diesem weißen Hintergrund kontrastieren.
  • Keine Verringerung des Kontrasts für eingeschlossene Inhalte: Der Fokusindikator darf den Kontrast von Text oder anderen Inhalten innerhalb der fokussierten Komponente nicht auf unter 4.5:1 (für Text unter 18pt / 14pt fett) oder 3:1 (für großen Text und Nicht-Text-Inhalte) reduzieren.

Alle drei Bedingungen müssen gleichzeitig erfüllt sein, damit eine Komponente besteht. Ein Fokusindikator, der groß genug ist, aber nicht ausreichend Kontrast hat, fällt durch. Ebenso fällt ein hochkontrastiger Indikator durch, der zu klein ist.

Die WCAG-Spezifikation definiert eine bemerkenswerte Ausnahme: Wenn der Standard-Fokusindikator des Browsers (die User-Agent-Voreinstellung) die Anforderungen erfüllt, muss der Autor keinen benutzerdefinierten Stil hinzufügen. Allerdings variieren die Browser-Standards erheblich — Chromium-basierte Browser bieten in der Regel eine blaue Umrandung, während Safari möglicherweise einen Ring rendert, dem in bestimmten Farbschemata ausreichender Kontrast fehlt. Autoren sollten überprüfen, ob der Standardindikator den Schwellenwert erfüllt, oder einen robusten benutzerdefinierten Stil bereitstellen.

Das Kriterium gilt für alle interaktiven und fokussierbaren Komponenten: Links, Schaltflächen, Formulareingaben, Auswahlmenüs, Kontrollkästchen, Optionsfelder, benutzerdefinierte Widget-Komponenten, die mit ARIA-Rollen erstellt wurden, und jedes Element, das über tabindex fokussierbar gemacht wurde. Es gilt auch für Fokusindikatoren, die ausschließlich über CSS auf Pseudo-Elementen oder über JavaScript-gesteuerte Klassenänderungen erzeugt werden.

Warum es wichtig ist

Die Sichtbarkeit des Fokus ist ein entscheidender Navigationshinweis für eine breite Nutzergruppe. Wenn Fokusindikatoren dünn, kontrastarm oder gar nicht vorhanden sind, verlieren diese Nutzer ihre räumliche Orientierung innerhalb einer Seite — sie können nicht erkennen, wo sie sich befinden oder wohin sie als Nächstes gehen können.

Nur-Tastatur-Nutzer — einschließlich Menschen mit motorischen Beeinträchtigungen wie Tremor, Lähmungen oder wiederholten Belastungsverletzungen — sind vollständig auf die Tastatur zur Navigation angewiesen. Für diese Nutzer ist ein unsichtbarer oder kaum sichtbarer Fokusindikator nicht nur ein Ärgernis; er macht die gesamte Oberfläche unbenutzbar. Laut Weltgesundheitsorganisation leben etwa 1,3 Milliarden Menschen mit irgendeiner Form von Behinderung, und motorische Beeinträchtigungen stellen eine der größten Kategorien unter den Menschen dar, die eine Maus meiden oder nicht verwenden können.

Sehbehinderte Nutzer, die Vergrößerungssoftware, aber keinen vollständigen Screenreader verwenden, sind ebenfalls auf den Fokusring angewiesen, um sich zu orientieren. Bei hohen Zoomstufen kann eine 1px-Standardumrandung vom Viewport abgeschnitten werden oder einfach unsichtbar gegen einen ähnlich gefärbten Hintergrund sein. Diese Nutzer navigieren häufig gerade deshalb mit der Tastatur, weil präzises Zielen mit der Maus bei hoher Vergrößerung schwierig ist.

Kognitive und auf Aufmerksamkeit bezogene Beeinträchtigungen wie ADHS, Angststörungen und traumatische Hirnverletzungen können es erschweren, visuelle Informationen über eine Seite hinweg zu verfolgen. Ein sehr gut sichtbarer, klar abgegrenzter Fokusindikator reduziert die kognitive Belastung bei der Navigation, indem er einen unmissverständlichen Anker für die aktuelle Position des Nutzers bietet.

Situative Beeinträchtigungen sind ebenfalls relevant: Eine Entwicklerin, die auf einem Laptop mit niedriger Helligkeit im Freien testet, oder ein älterer Nutzer mit altersbedingter Abnahme der Kontrastempfindlichkeit kann mit dünnen oder kontrastarmen Fokusringen Schwierigkeiten haben, selbst ohne klinische Diagnose.

Betrachten wir ein Szenario aus der Praxis: Ein Online-Formular einer Bank für Überweisungen enthält zehn Eingabefelder und vier Aktionsschaltflächen. Ein Nutzer mit Parkinson-Erkrankung durchläuft das Formular mit der Tastatur. Wenn der Fokusindikator eine standardmäßige 1px gepunktete Umrandung in Hellgrau auf weißem Hintergrund ist, kann der Nutzer nicht zuverlässig verfolgen, welches Feld er gerade bearbeitet. Er könnte versehentlich eine Überweisung auf das falsche Konto absenden, weil er nicht sehen konnte, dass der Fokus bereits über das Empfängerfeld hinausgewandert war. Eine robuste, kontrastreiche Fokusumrandung hätte dies vollständig verhindert.

Über die Barrierefreiheit hinaus ist ein klarer Fokusindikator eine Usability-Verbesserung für alle Nutzer. Power-User, die häufig Formulare und Menüs per Tastatur bedienen — ein gängiges Muster unter Entwicklern, Datenerfassungs-Fachkräften und Screenreader-Nutzern — profitieren von schneller, zuverlässiger Orientierung. Es gibt außerdem ein indirektes SEO-Signal: Websites mit hoher Barrierefreiheit haben tendenziell niedrigere Absprungraten und höhere Aufgabenerfüllung, was mit positiven Rankingfaktoren korreliert.

Verwandte Axe-core-Regeln

WCAG 2.4.13 erfordert manuelle Tests, da automatisierte Tools die Größe und den Kontrast eines Fokusindikators nicht in jedem möglichen Browser-Rendering-Kontext vollständig bewerten können. Axe-core hat keine einzelne automatisierte Regel, die 2.4.13-Verstöße direkt kennzeichnet. Die Gründe sind technischer Natur:

  • Warum Automatisierung nicht ausreicht: Die exakte Pixel-Fläche eines Fokusindikators zu berechnen, erfordert die Simulation des Tastaturfokus auf jedem interaktiven Element, das Messen der gerenderten Umrandungsgeometrie (die von Browser, Betriebssystem, Zoomstufe und CSS abhängt), die Berechnung des Kontrastverhältnisses der Indikatorpixel zu ihren Nachbarn und die Überprüfung, dass keine dieser Bedingungen die Kontrastanforderung für eingeschlossene Inhalte verletzt. Keine aktuelle automatisierte Barrierefreiheits-Engine führt all diese Schritte zuverlässig für alle Komponenten aus. Axe-core kann das Fehlen jeglicher Fokusstile (bezogen auf 2.4.7) kennzeichnen, kann aber nicht messen, ob der vorhandene Stil die Flächen- und Kontrastschwellen von 2.4.13 erfüllt.
  • Teilabdeckung durch fokusbezogene Regeln: Die focus-visible-Regel von axe-core prüft, ob Elemente überhaupt einen sichtbaren Fokusindikator haben. Wenn ein Element outline: none oder outline: 0 ohne alternativen visuellen Indikator hat, wird diese Regel es kennzeichnen. Das Bestehen dieser Regel garantiert jedoch keine Konformität mit 2.4.13 — ein Element kann eine technisch sichtbare Umrandung haben, die dennoch zu dünn oder zu kontrastarm ist.
  • Manuelle Tests sind die maßgebliche Methode: Tester müssen jede interaktive Komponente im fokussierten Zustand visuell inspizieren, die Umrandungsmaße messen oder schätzen und Kontrastverhältnisse mit einem Farbkontrast-Analyzer überprüfen. Aus diesem Grund führt WCAG 2.4.13 für axe-core-Zwecke als ausschließlich manuell zu testendes Kriterium auf.

Wie man testet

  1. Automatischer Scan (nur Teilsignal): Führen Sie axe DevTools oder Lighthouse auf der Seite aus. Suchen Sie nach Fehlern im Zusammenhang mit focus-visible oder focus-order-semantics. Auch wenn diese nicht direkt 2.4.13-Verstöße kennzeichnen, können sie Elemente sichtbar machen, bei denen die Fokusgestaltung vollständig unterdrückt wurde, was ein grundlegender Verstoß ist. Öffnen Sie in den Chrome DevTools das Accessibility-Panel und verwenden Sie den „Tab“-Inspektionsmodus, um durch fokussierbare Elemente zu wechseln.
  2. Visueller Tastaturnavigationstest: Trennen Sie Ihre Maus oder legen Sie sie beiseite. Drücken Sie Tab, um durch jedes interaktive Element auf der Seite zu wechseln. Inspizieren Sie für jedes fokussierte Element den Fokusindikator visuell. Fragen Sie: Gibt es einen klar sichtbaren Ring oder einen anderen Indikator? Scheint er mindestens 2px dick zu sein? Kontrastiert er stark mit dem umgebenden Hintergrund? Notieren Sie alle Elemente, bei denen Sie zögern oder Schwierigkeiten haben zu erkennen, wo sich der Fokus befindet.
  3. Kontrastmessung: Verwenden Sie den WebAIM Contrast Checker oder das Desktop-Tool Colour Contrast Analyser. Wenn der Fokus auf einer Komponente liegt, machen Sie einen Screenshot. Messen Sie die Farbe der Fokusindikator-Pixel und die Farbe des unmittelbar angrenzenden Hintergrunds. Verifizieren Sie, dass das Kontrastverhältnis mindestens 3:1 beträgt.
  4. Maßmessung: Verwenden Sie die DevTools des Browsers (Chrome oder Firefox). Wählen Sie ein fokussiertes Element aus und inspizieren Sie seine berechneten Stile. Prüfen Sie outline-width, outline-offset und alle box-shadow-Angaben, die als Fokusring verwendet werden. Multiplizieren Sie den Umfang des Elements (2 × Breite + 2 × Höhe) mit 2px, um die Mindestfläche zu berechnen. Verifizieren Sie, dass die gerenderte Fläche des Indikators diesen Wert erreicht oder übersteigt.
  5. Screenreader + Tastaturtest (NVDA + Firefox): Öffnen Sie die Seite in Firefox mit laufendem NVDA. Navigieren Sie mit Tab- und Pfeiltasten. Bestätigen Sie, dass der visuelle Fokusindikator synchron mit dem von NVDA angekündigten Fokus wandert. Achten Sie besonders auf benutzerdefinierte Widgets (Karussells, Modale, Akkordeons), bei denen das Fokusmanagement über JavaScript gesteuert werden kann.
  6. VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver mit Command + F5. Navigieren Sie mit Tab durch interaktive Elemente. Verifizieren Sie, dass der VoiceOver-Cursor (die schwarze Umrandungsbox) keinen Ersatz für einen ordnungsgemäßen CSS-Fokusindikator darstellt — die Seite selbst muss unabhängig davon einen bereitstellen.
  7. Test im Hochkontrastmodus: Aktivieren Sie unter Windows den Hochkontrastmodus (Einstellungen → Erleichterte Bedienung → Hoher Kontrast). Laden Sie die Seite neu und wiederholen Sie den Tastaturnavigationstest. Einige CSS-Fokusstile werden im Hochkontrastmodus vom Betriebssystem überschrieben; verifizieren Sie, dass weiterhin ein sichtbarer Indikator erscheint. Verwenden Sie die CSS-Media-Query forced-colors: active, um bei Bedarf Styles bedingt anzupassen.

Wie man es behebt

Standard-Browserumrandung entfernt — Falsch

<!-- Viele Stylesheets unterdrücken global die Standard-Fokusumrandung -->
<style>
  * {
    outline: none; /* Entfernt ALLE Fokusindikatoren auf der gesamten Website */
  }
  a:focus, button:focus {
    outline: 0; /* Redundante Entfernung; kein Ersatz bereitgestellt */
  }
</style>
<button>Submit Payment</button>

Standard-Browserumrandung entfernt — Richtig

<!-- Entfernen Sie die Standardumrandung nur, wenn Sie einen überlegenen benutzerdefinierten Indikator bereitstellen -->
<style>
  /* Unterdrücken Sie die Standardumrandung nur, wenn :focus-visible greift, und stellen Sie dann einen starken Ersatz bereit */
  :focus-visible {
    outline: 3px solid #0057b8; /* 3px stellen sicher, dass die Flächenanforderung für typische Elemente erfüllt ist */
    outline-offset: 2px;       /* Offset trennt den Indikator zur besseren Erkennbarkeit von der Elementkante */
  }
  /* Respektieren Sie forced-colors (Windows Hochkontrast), indem Sie System-Schlüsselwörter verwenden */
  @media (forced-colors: active) {
    :focus-visible {
      outline: 3px solid ButtonText;
    }
  }
</style>
<button>Submit Payment</button>

Kontrastarmer Fokusring auf farbigem Hintergrund — Falsch

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus {
    outline: 2px solid #3399ff; /* Hellblaue Umrandung auf dunkelblauem Hintergrund: Kontrastverhältnis ~1.4:1 — nicht bestanden */
  }
</style>
<button class='cta-button'>Book Now</button>

Kontrastarmer Fokusring auf farbigem Hintergrund — Richtig

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus-visible {
    /* Weiße Umrandung kontrastiert stark mit der dunkelblauen Schaltfläche (Kontrast ~8:1) */
    outline: 3px solid #ffffff;
    outline-offset: 2px;
    /* Ein dunkler versetzter Box-Shadow hinter dem weißen Ring stellt den Kontrast zu hellen Seitenhintergründen sicher */
    box-shadow: 0 0 0 5px #0057b8;
  }
</style>
<button class='cta-button'>Book Now</button>

Benutzerdefiniertes, div-basiertes interaktives Widget ohne Fokusstil — Falsch

<style>
  .tab-item { cursor: pointer; padding: 12px 20px; }
  /* Kein :focus- oder :focus-visible-Stil für benutzerdefinierten Tab definiert */
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Benutzerdefiniertes, div-basiertes interaktives Widget ohne Fokusstil — Richtig

<style>
  .tab-item {
    cursor: pointer;
    padding: 12px 20px;
    border-radius: 4px;
  }
  /* Expliziter :focus-visible-Stil — outline-width 3px mit Offset erfüllt die Flächenschwelle */
  .tab-item:focus-visible {
    outline: 3px solid #d4550a; /* 3:1+ Kontrast zu weißem Hintergrund */
    outline-offset: 3px;
  }
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Dünner Box-Shadow als Fokusindikator verwendet — Falsch

<style>
  .form-input:focus {
    outline: none;
    /* 1px Box-Shadow-Spread: für die meisten Eingabegrößen wahrscheinlich zu klein in der Fläche */
    box-shadow: 0 0 0 1px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Dünner Box-Shadow als Fokusindikator verwendet — Richtig

<style>
  .form-input:focus-visible {
    outline: none;
    /*
      3px Spread bietet ausreichend Fläche um eine typische 300px breite Eingabe.
      #005fcc auf weißem Hintergrund ergibt ~5.9:1 Kontrast — erfüllt sowohl 2.4.13 (3:1) als auch 1.4.3 (4.5:1).
    */
    box-shadow: 0 0 0 3px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Häufige Fehler

  • Verwendung von outline: none in einem CSS-Reset, ohne einen Ersatz-Fokusindikator bereitzustellen. Viele populäre CSS-Resets (ältere Versionen von Normalize.css, benutzerdefinierte Resets) entfernen Umrandungen pauschal. Koppeln Sie die Entfernung immer mit einem :focus-visible-Ersatz, der die Anforderungen an Größe und Kontrast erfüllt.
  • Bereitstellung eines Fokusstils nur für :focus, aber nicht für :focus-visible, was zu Fokusringen bei Mausklicks auf Schaltflächen führt, die sehende Mausnutzer stören — was Entwickler dazu verleitet, sie vollständig zu entfernen, statt die korrekte Aufteilung über die Pseudoklasse zu verwenden.
  • Auswahl einer Fokusringfarbe, die der Hintergrundfarbe der Komponente sehr ähnlich ist. Beispielsweise hat ein hellblauer #99ccff-Ring auf einem weißen #ffffff-Hintergrund ein Kontrastverhältnis von ungefähr 1.5:1, weit unter dem erforderlichen 3:1.
  • Verwendung von outline-width: 1px bei kleinen Komponenten wie Icon-Buttons oder Kontrollkästchen. Ein 1px-Ring um ein 24×24px-Icon hat eine Fläche von ungefähr 96 Quadratpixeln, aber die erforderliche Mindestfläche für ein 24×24-Element beträgt (24+24+24+24) × 2 = 192 Quadratpixel — genau 2px Dicke. Eine 1px-Umrandung fällt bei dieser Berechnung durch.
  • Vergessen, das Erscheinungsbild des Fokus bei benutzerdefinierten ARIA-Widgets zu testen wie role='combobox', role='listbox' oder role='slider'. Diese Komponenten haben häufig JavaScript-gesteuerten Fokus, der native CSS-Pseudoklassen umgeht, sofern er nicht explizit behandelt wird.
  • Anwendung eines Fokusstils nur auf a- und button-Tags, während input, select, textarea und alle Elemente mit tabindex='0' vernachlässigt werden.
  • Überschreiben von Fokusstilen tief in einer Komponentenbibliothek oder einem Drittanbieter-Widget, ohne zu bemerken, dass das Überschreiben den sichtbaren Indikator entfernt. Häufige Übeltäter sind UI-Kits wie Bootstrap 4 (das box-shadow auf einen subtilen Glow setzt), die möglicherweise nicht die 2.4.13-Schwelle erfüllen.
  • Kein Test des Fokus-Erscheinungsbilds im Windows-Hochkontrastmodus. Einige CSS-Outline- und Box-Shadow-Techniken werden im Hochkontrastmodus unsichtbar gerendert. Verwenden Sie den Block @media (forced-colors: active), um einen sichtbaren, auf Systemfarben basierenden Fallback sicherzustellen.
  • Verwendung von outline-offset mit einem sehr großen negativen Wert, um die Umrandung innerhalb des Rahmens des Elements zu verschieben. Dies kann dazu führen, dass der Indikator mit dem Hintergrund des Elements überlappt und der effektive Kontrast unter 3:1 sinkt.
  • Die Annahme, dass der Fokusindikator auf einem übergeordneten Container für untergeordnete interaktive Elemente ausreicht. Jedes fokussierbare Element muss das Kriterium unabhängig erfüllen; eine hervorgehobene Zeile in einer Tabelle erfüllt die Anforderung nicht für eine Linkzelle innerhalb dieser Zeile.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Web- und Mobile-Barrierefreiheitsanforderungen für einen breiten Kreis von in der Türkei tätigen Einrichtungen fest. Die Verfügung übernimmt WCAG 2.2 als technischen Referenzstandard und schreibt Konformität auf Stufe AA für die erfassten Einrichtungen vor. WCAG 2.4.13 Focus Appearance ist ein Kriterium der Stufe AAA und wird daher von der Verfügung nicht direkt für die Standardkonformität vorgeschrieben.

Der Anwendungsbereich der Verfügung ist jedoch weitreichend. Erfasste Einrichtungen umfassen öffentliche Institutionen und Regierungsbehörden, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitseinrichtungen, Telekommunikationsanbieter mit 200,000 oder mehr Abonnenten, E-Commerce-Plattformen, Reisebüros, private Transportunternehmen und Privatschulen, die vom Ministerium für Nationale Bildung (MoNE) autorisiert sind. Für all diese Organisationen signalisiert der Nachweis der Konformität auf Stufe AAA bei anwendbaren Kriterien — einschließlich 2.4.13 — ein Bekenntnis zu Barrierefreiheit auf höchstem Niveau, das über die gesetzliche Mindestanforderung hinausgeht.

Es gibt praktische und reputationsbezogene Gründe für erfasste türkische Einrichtungen, 2.4.13 freiwillig umzusetzen. Banken und Finanzdienstleister bedienen insbesondere Kundinnen und Kunden mit motorischen Beeinträchtigungen, die für sichere Transaktionen auf Tastaturnavigation angewiesen sind. Ein türkisches Online-Banking-Portal, das 2.4.13 erfüllt, übertrifft nicht nur die regulatorischen Anforderungen, sondern reduziert auch das Risiko von Benutzerfehlern und demonstriert unternehmerische gesellschaftliche Verantwortung. Ebenso sollten Krankenhäuser und Gesundheitsportale, über die Patientinnen und Patienten Termine buchen oder auf medizinische Unterlagen zugreifen, sicherstellen, dass alle Nutzer — einschließlich älterer Menschen mit eingeschränkter Feinmotorik oder Sehschwäche — diese Oberflächen mit Vertrauen navigieren können.

Telekommunikationsanbieter mit großen Abonnentenbasen gehören zu den meistgenutzten digitalen Diensten in der Türkei. Ihre Kundenportale und Self-Service-Anwendungen erreichen Millionen von Nutzern, darunter einen erheblichen Anteil älterer Menschen und Menschen mit Behinderungen. Die freiwillige Umsetzung von 2.4.13 auf diesen Plattformen stellt einen gleichberechtigten Zugang für alle Abonnenten sicher und positioniert den Anbieter vorteilhaft im Hinblick auf mögliche zukünftige regulatorische Verschärfungen, die die verpflichtende Konformität auf AAA-Kriterien ausweiten könnten.

Für Organisationen, die eine vollständige WCAG 2.2 AAA-Konformität erreichen möchten — sei es aufgrund von Beschaffungsanforderungen, Export in EU-Märkte, die dem European Accessibility Act unterliegen, oder internen Barrierefreiheitsrichtlinien — ist die Umsetzung von 2.4.13 ein notwendiger Bestandteil. Das Overlay-SDK von Accsible bietet konfigurierbare Fokusverbesserungsfunktionen, die Organisationen helfen können, starke, konforme Fokusindikatoren in ihren Oberflächen sichtbar zu machen und damit die auf Autorenebene beschriebenen CSS-Korrekturen in diesem Artikel zu ergänzen.