WCAG 2.4.3: Fokusreihenfolge

WCAG 2.4.3 verlangt, dass, wenn eine Webseite sequentiell navigiert werden kann und die Navigationssequenzen Bedeutung oder Funktion beeinflussen, fokussierbare Komponenten den Fokus in einer Reihenfolge erhalten müssen, die Bedeutung und Bedienbarkeit bewahrt. Dieses Kriterium ist entscheidend für Tastatur- und Assistenztechnologie-Nutzer, die auf eine logische, vorhersehbare Fokusreihenfolge angewiesen sind, um Inhalte zu verstehen und mit ihnen zu interagieren.

Was diese Regel bedeutet

WCAG 2.4.3 Focus Order ist ein Erfolgskriterium der Stufe A unter dem Prinzip „Bedienbar“. Es besagt: „Wenn eine Webseite sequentiell navigiert werden kann und die Navigationssequenzen Bedeutung oder Bedienung beeinflussen, erhalten fokussierbare Komponenten den Fokus in einer Reihenfolge, die Bedeutung und Bedienbarkeit erhält.“

Praktisch bedeutet das: Wenn ein Nutzer die Tab-Taste drückt, um sich durch interaktive Elemente auf einer Seite zu bewegen – Links, Buttons, Formularfelder, benutzerdefinierte Widgets und alle anderen fokussierbaren Komponenten – muss die Reihenfolge, in der diese Elemente den Fokus erhalten, logisch nachvollziehbar sein. Nutzende sollten nicht unerwartet von der Mitte eines Formulars zu einem Footer-Link springen, dann zurück zu einem Button in einem Modal, und dann weiter zu einem Navigationsmenüpunkt.

Das Kriterium gilt für die sequentielle Tastaturnavigation, die primäre Methode, mit der reine Tastaturnutzende und Screenreader-Nutzende eine Seite durchqueren. Die DOM-Reihenfolge ist die Standardquelle für die Fokusreihenfolge in Browsern: Elemente erscheinen in der Tab-Sequenz in der Reihenfolge, in der sie im Document Object Model (DOM) vorkommen, sofern CSS oder JavaScript diese Reihenfolge nicht bewusst verändern. Probleme entstehen, wenn das visuelle Layout von der DOM-Reihenfolge abweicht (zum Beispiel durch CSS Flexbox- oder Grid-Umsortierung) oder wenn tabindex-Werte eine unnatürliche Sequenz erzwingen.

Was als bestanden gilt: Die Fokusreihenfolge muss logisch und sinnvoll sein – nicht zwingend identisch mit der visuellen Lesereihenfolge, aber so kohärent, dass Nutzende die Seite verstehen und bedienen können. Ein modaler Dialog, der beim Öffnen den Fokus auf sich selbst verschiebt, den Fokus während der geöffneten Phase in sich einfängt und beim Schließen den Fokus auf das auslösende Element zurückgibt, erfüllt dieses Kriterium. Ein mehrstufiges Formular, bei dem Tab durch jedes Feld in der Reihenfolge weitergeht, in der ein Nutzer es ausfüllen würde (von oben nach unten, von links nach rechts in Sprachen mit Links-nach-rechts-Schreibrichtung), besteht ebenfalls.

Was als nicht bestanden gilt: Wenn der Fokus von einem „Benutzername“-Feld eines Login-Formulars zu einem völlig unzusammenhängenden Werbebanner springt, bevor das „Passwort“-Feld erreicht wird, ist das ein Fehler. Eine Single-Page-Anwendung, die einen Dialog öffnet, aber den Fokus auf der Hintergrundseite belässt, fällt durch. Die Verwendung positiver ganzzahliger tabindex-Werte (z. B. tabindex='2', tabindex='5'), die eine unlogische Tab-Sequenz über die Seite hinweg erzwingen, fällt ebenfalls durch.

Offizielle Ausnahmen: WCAG weist ausdrücklich darauf hin, dass die Fokusreihenfolge nicht mit der visuellen Lesereihenfolge übereinstimmen muss, solange sie Bedeutung und Bedienbarkeit erhält. Es gibt außerdem eine Ausnahme für Fälle, in denen Navigationssequenzen Bedeutung oder Bedienung nicht beeinflussen – zum Beispiel eine Seite mit nur einem fokussierbaren Element, bei der es keine Sequenz zu bewerten gibt. Zusätzlich gilt: Wenn es mehrere gültige Reihenfolgen gibt, die alle die Bedeutung erhalten, ist jede dieser Reihenfolgen akzeptabel.

Zentrale HTML- und JavaScript-Mechanismen, die die Fokusreihenfolge beeinflussen, sind: die natürliche DOM-Reihenfolge interaktiver Elemente, das tabindex-Attribut (insbesondere positive ganzzahlige Werte), CSS-Eigenschaften, die das visuelle Layout umsortieren, ohne das DOM zu ändern (wie order in Flexbox/Grid, position: absolute und float), JavaScript-gesteuertes Fokusmanagement (Aufruf von .focus() auf Elementen) und ARIA-Dialogmuster, die explizites Fokusmanagement erfordern.

Warum das wichtig ist

Die Fokusreihenfolge ist kein kleines technisches Detail – sie ist das navigative Rückgrat des Webs für einen erheblichen Teil der Nutzenden. Mehrere unterschiedliche Gruppen von Menschen mit Behinderungen sind auf eine logische Fokussequenz angewiesen, um digitale Produkte effektiv nutzen zu können.

Motorisch beeinträchtigte Nutzende, die keine Maus verwenden können, sind vollständig auf die Tastatur (oder tastaturäquivalente Geräte wie Saug-und-Pust-Schalter, Kopfmaus oder Blickverfolgungssysteme) angewiesen. Für diese Menschen ist eine durcheinandergeratene Fokusreihenfolge nicht nur lästig – sie kann eine Seite vollständig unbenutzbar machen. Wenn die Tab-Taste eine Person an die falsche Stelle der Seite bringt, hat sie möglicherweise keinen effizienten Weg, das benötigte Steuerelement zu erreichen, und kann nicht einfach die Hand bewegen, um woanders zu klicken.

Blinde und sehbehinderte Nutzende, die Screenreader wie NVDA, JAWS oder VoiceOver verwenden, hören Elemente, wenn der Fokus auf ihnen landet. Eine logische Fokusreihenfolge bedeutet, dass der Audiostrom, den sie erhalten, dem beabsichtigten Ablauf der Benutzeroberfläche entspricht. Wenn der Fokus unberechenbar springt, verlieren Nutzende ihr mentales Modell davon, wo sie sich auf der Seite befinden. Laut Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen eine Form von Sehbeeinträchtigung, und für viele derjenigen, die Screenreader nutzen, ist die Fokusreihenfolge die primäre Art, die Seitenstruktur zu erleben.

Nutzende mit kognitiven Beeinträchtigungen profitieren ebenfalls von vorhersehbaren Fokussequenzen. Ein unerwarteter Fokus-Sprung mitten in einem Formular kann Verwirrung stiften, Nutzende zwingen, Arbeitsabläufe neu zu starten, oder dazu führen, dass Pflichtfelder übersehen werden. Menschen mit Aufmerksamkeitsproblemen oder Einschränkungen des Kurzzeitgedächtnisses benötigen konsistente, vorhersehbare Navigation, um Vertrauen in die Nutzung einer Website aufzubauen.

Ein konkretes Szenario aus der Praxis: Stellen Sie sich eine türkische E-Commerce-Checkout-Seite vor. Das visuelle Design verwendet CSS Grid, um die Bestellübersicht links und das Zahlungsformular rechts zu platzieren. Im DOM steht jedoch das Zahlungsformular zuerst und die Bestellübersicht an zweiter Stelle. Das visuelle Layout wirkt für sehende Mausnutzende korrekt, aber eine Tastaturnutzerin, die Tab drückt, landet in den Feldern des Zahlungsformulars, bevor sie die Bestellübersicht prüfen konnte. Sie könnte unwissentlich eine falsche Bestellung bestätigen. Noch schlimmer: Wenn ein „Kauf bestätigen“-Button aufgrund fehlerhaften Einsatzes positiver tabindex-Werte den Fokus vor einem „Gutschein anwenden“-Feld erhält, könnte eine Person versehentlich einen Kauf abschließen, den sie eigentlich rabattieren wollte. Das ist eine direkte, reale finanzielle Folge einer fehlerhaften Fokusreihenfolge.

Über die Barrierefreiheit hinaus verbessert eine logische Fokusreihenfolge die Nutzungserfahrung für Power-User, die aus Geschwindigkeitsgründen die Tastaturnavigation bevorzugen. Sie unterstützt außerdem indirekt SEO: Ein gut strukturiertes DOM, das eine natürliche Fokusreihenfolge erzeugt, spiegelt in der Regel sinnvolles semantisches Markup wider, das Suchmaschinen nutzen, um Inhalts-Hierarchie und -Wichtigkeit zu verstehen.

Wie man testet

Automatisierter Scan als Ausgangspunkt: Führen Sie axe DevTools (Browser-Erweiterung) oder Google Lighthouse auf der Seite aus. Achten Sie auf Warnungen zu positiven tabindex-Werten und markierten scrollbaren Bereichen. Beachten Sie, dass ein sauberer automatisierter Bericht nicht bedeutet, dass 2.4.3 erfüllt ist – manuelle Tests sind immer erforderlich. Protokollieren Sie alle markierten Probleme zur weiteren Untersuchung.
Trennen Sie Ihre Maus und navigieren Sie nur mit Tab: Beginnen Sie in der Adressleiste des Browsers oder am oberen Rand der Seite und drücken Sie wiederholt Tab, um alle fokussierbaren Elemente zu durchlaufen. Beobachten Sie die Sequenz sorgfältig. Fragen Sie sich: Bewegt sich der Fokus in einer Reihenfolge, die dem logischen Lese- und Interaktionsfluss der Seite entspricht? Springt der Fokus jemals in einen unerwarteten Bereich? Bleibt er jemals „stecken“ (kann nicht vor- oder zurückbewegt werden), außer innerhalb eines beabsichtigten Dialogs?
Testen Sie dynamische Komponenten: Aktivieren Sie Modals, Dialoge, Dropdown-Menüs, Akkordeons, Tab-Panels, Datepicker oder andere interaktive Widgets mit der Tastatur. Verifizieren Sie, dass der Fokus unmittelbar nach der Aktivierung in die neu sichtbaren Inhalte verschoben wird. Bestätigen Sie nach dem Schließen eines Dialogs, dass der Fokus zu dem Element zurückkehrt, das den Dialog ausgelöst hat – nicht an den Seitenanfang oder eine beliebige Stelle.
Testen Sie mit NVDA + Firefox: Öffnen Sie NVDA, starten Sie Firefox und navigieren Sie zur Seite. Verwenden Sie Tab, um sich durch interaktive Elemente zu bewegen, und hören Sie auf die Ansagen. Verifizieren Sie, dass die angesagte Sequenz im Kontext sinnvoll ist. Nutzen Sie den Browse-Modus von NVDA (Pfeiltasten), um statische Inhalte zu lesen, und bestätigen Sie, dass die Lesereihenfolge mit der Fokusreihenfolge für interaktive Elemente innerhalb dieser Inhalte übereinstimmt.
Testen Sie mit VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver und verwenden Sie Tab (Desktop) oder Wischgesten (iOS), um sich durch fokussierbare Elemente zu bewegen. Bestätigen Sie, dass die Fokussequenz logisch ist. Testen Sie auf iOS, dass Modals und Overlays den Fokus korrekt einfangen und ihn beim Schließen zurückgeben.
Testen Sie mit JAWS + Chrome: Verwenden Sie die Tab-Navigation von JAWS und bestätigen Sie, dass die angesagte Fokussequenz kohärent ist. Nutzen Sie den virtuellen Cursor von JAWS, um die Lesereihenfolge mit der interaktiven Fokusreihenfolge abzugleichen und Abweichungen zu identifizieren.
Untersuchen Sie DOM und visuelles Layout: Öffnen Sie die DevTools des Browsers und betrachten Sie die DOM-Struktur. Vergleichen Sie die Reihenfolge der interaktiven Elemente im DOM mit ihrer visuellen Position auf dem Bildschirm. Wenn CSS-Eigenschaften wie order, position: absolute oder float erhebliche Unterschiede erzeugen, verfolgen Sie die Tab-Sequenz manuell, um festzustellen, ob Bedeutung oder Bedienbarkeit beeinträchtigt sind.
Überprüfen Sie tabindex-Werte im DOM: Führen Sie in der Browserkonsole document.querySelectorAll('[tabindex]') aus, um alle Elemente mit expliziten tabindex-Attributen aufzulisten. Untersuchen Sie jedes Element mit einem positiven ganzzahligen Wert und bewerten Sie, ob seine Position in der modifizierten Tab-Reihenfolge logisch ist.

Wie man es behebt

Positive tabindex-Werte erzeugen unlogische Reihenfolge – Falsch

<!-- Positive tabindex values force an unnatural tab sequence -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email' tabindex='3'>

  <label for='name'>Full Name</label>
  <input type='text' id='name' tabindex='1'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone' tabindex='2'>

  <button type='submit' tabindex='4'>Submit</button>
</form>
<!-- Tab order: Full Name → Phone → Email → Submit
     Visual/logical order: Email → Full Name → Phone → Submit
     This mismatch breaks focus order. -->

Positive tabindex-Werte erzeugen unlogische Reihenfolge – Richtig

<!-- Remove all positive tabindex values; rely on DOM order.
     Rearrange DOM to match the logical sequence. -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email'>

  <label for='name'>Full Name</label>
  <input type='text' id='name'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone'>

  <button type='submit'>Submit</button>
</form>
<!-- Tab order now follows DOM order: Email → Full Name → Phone → Submit
     Matches logical and visual order. No tabindex needed. -->

CSS visuelle Umsortierung weicht von DOM-Reihenfolge ab – Falsch

<!-- DOM has sidebar first, main content second.
     CSS uses flexbox order to visually flip them.
     Keyboard users tab through sidebar links before main content links,
     which does not match what a sighted user sees first. -->
<style>
  .layout { display: flex; }
  .sidebar { order: 2; } /* Visually shown on the right */
  .main    { order: 1; } /* Visually shown on the left */
</style>

<div class='layout'>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
</div>
<!-- Focus order: About → Contact → Read Article
     Visual order: Read Article → About → Contact
     Mismatch breaks 2.4.3 -->

CSS visuelle Umsortierung weicht von DOM-Reihenfolge ab – Richtig

<!-- Fix: reorder the DOM to match the intended visual and logical order.
     Remove the CSS 'order' overrides that caused the mismatch. -->
<style>
  .layout { display: flex; }
  /* No 'order' overrides — DOM order determines both visual and tab order */
</style>

<div class='layout'>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
</div>
<!-- DOM order, visual order, and focus order now all match. -->

Modaler Dialog verwaltet Fokus nicht – Falsch

<!-- Button opens a modal, but focus stays on the background page.
     Keyboard users cannot interact with the dialog. -->
<button id='open-modal' onclick='document.getElementById("dialog").style.display="block"'>
  Open Settings
</button>

<div id='dialog' style='display:none;'>
  <h2>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>
<!-- When dialog opens, focus remains on #open-modal in the background.
     Tab continues to background page elements, not dialog elements. -->

Modaler Dialog verwaltet Fokus nicht – Richtig

<!-- Focus is moved into the dialog on open and returned to trigger on close.
     role='dialog' and aria-modal='true' inform screen readers of the context. -->
<button id='open-modal'>Open Settings</button>

<div id='dialog'
     role='dialog'
     aria-modal='true'
     aria-labelledby='dialog-title'
     style='display:none;'>
  <h2 id='dialog-title'>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>

<script>
  const openBtn = document.getElementById('open-modal');
  const dialog  = document.getElementById('dialog');
  const closeBtn = document.getElementById('close-modal');

  openBtn.addEventListener('click', () => {
    dialog.style.display = 'block';
    // Move focus to first focusable element in dialog
    document.getElementById('theme').focus();
  });

  closeBtn.addEventListener('click', () => {
    dialog.style.display = 'none';
    // Return focus to the element that triggered the dialog
    openBtn.focus();
  });
</script>
<!-- Focus order is now logical: trigger → dialog contents → back to trigger. -->

Häufige Fehler

Verwendung positiver ganzzahliger tabindex-Werte (z. B. tabindex='1', tabindex='5'), um die Fokusreihenfolge „zu steuern“, anstatt die DOM-Struktur zu korrigieren. Positive tabindex-Werte platzieren Elemente vor allen natürlich fokussierbaren Elementen der Seite und erzeugen eine chaotische globale Tab-Sequenz, die extrem schwer zu pflegen ist und fast immer Fehler einführt.
Anwenden von CSS-order in Flexbox oder CSS Grid, um Inhalte visuell umzusortieren, ohne das DOM umzusortieren, und anschließendes Unterlassen von Tastaturtests. Das visuelle Layout wirkt für sehende Nutzende korrekt, aber die Tab-Sequenz folgt der DOM-Reihenfolge, nicht der visuellen Reihenfolge – eine unsichtbare, aber schwerwiegende Diskrepanz für Tastaturnutzende.
Öffnen eines Modals oder Dialogs, ohne den Fokus programmatisch mit der .focus()-Methode von JavaScript in ihn zu verschieben. Screenreader- und Tastaturnutzende bleiben in den Hintergrundinhalten „gestrandet“ und können den Dialog oft nicht finden oder bedienen.
Den Fokus nach dem Schließen eines Modals, Drawers oder Dropdowns nicht auf das auslösende Element zurückgeben. Den Fokus an den Seitenanfang zu setzen oder auf einem nun versteckten Element zu belassen, zwingt Nutzende dazu, von vorne zu navigieren und ihren Platz auf einer möglicherweise langen Seite zu verlieren.
Dynamisch geladene Inhalte (z. B. eine Inline-Fehlermeldung, eine Toast-Benachrichtigung oder ein lazy-geladener Abschnitt) nach fokussierbaren Elementen in das DOM einzufügen, die ihm visuell vorausgehen, sodass Tastaturnutzende die neuen Inhalte in falscher Reihenfolge oder gar nicht erreichen.
Verwendung von tabindex='-1', um Elemente aus der Tab-Sequenz zu entfernen, ohne eine alternative Möglichkeit des Tastaturzugriffs bereitzustellen. Zwar ist tabindex='-1' an sich ein gültiges Werkzeug (es macht ein Element programmatisch fokussierbar, entfernt es aber aus der natürlichen Tab-Reihenfolge), doch wenn es auf Steuerelemente angewendet wird, die Nutzende tatsächlich erreichen müssen, werden diese Steuerelemente für Tastaturnutzende effektiv versteckt.
Erstellen von Single-Page-Application-Routenwechseln, die den Fokus auf den Dokument-Body oder die Browser-Chrome zurücksetzen, anstatt den Fokus auf die neue Seitenüberschrift oder ein Skip-Navigation-Landmark zu verschieben. Nutzende müssen dann bei jedem Routenwechsel die gesamte Navigation erneut durchtabben.
Implementierung benutzerdefinierter Karussell- oder Slider-Widgets, bei denen Pfeiltasten-Navigation nicht implementiert ist und Tab den Fokus durch jede versteckte Folie bewegt, sodass Nutzende sich durch Dutzende von Offscreen-Elementen tabben müssen, bevor sie zum nachfolgenden Seiteninhalt gelangen.
Platzierung eines „unsichtbaren“ Skip-Navigation-Links im DOM, der immer display:none ist (anstatt visuell mit einer .sr-only-/Clip-Technik versteckt zu werden). Ein Link mit display:none wird vollständig aus der Tab-Reihenfolge entfernt und bietet keinen Nutzen, während ein korrekt implementierter Skip-Link beim Tabben den Fokus erhält, sichtbar wird und die logische Fokusführung direkt zum Hauptinhalt unterstützt.
Verschachteln interaktiver Elemente in anderen interaktiven Elementen (zum Beispiel ein <button> innerhalb eines <a>-Tags), was zu browser-inkonsistentem Tab-Verhalten führt und dazu führen kann, dass der Fokus mehrfach auf demselben logischen Steuerelement landet oder es ganz überspringt.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

WCAG 2.4.3 Focus Order ist direkt relevant für die wegweisende Barrierefreiheitsgesetzgebung der Türkei: die Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025. Diese Verfügung legt verbindliche Web-Barrierefreiheitsstandards für eine breite Palette öffentlicher und privater Einrichtungen in der Türkei fest und verlangt die Einhaltung international anerkannter Richtlinien – einschließlich aller WCAG-2.x-Erfolgskriterien der Stufe A, zu denen 2.4.3 gehört.

Die Verfügung umfasst eine breite Palette von Einrichtungstypen. Öffentliche Institutionen – darunter Ministerien, Kommunen, staatliche Universitäten und Regierungsbehörden – müssen innerhalb von einem Jahr nach Veröffentlichung der Verfügung vollständige Konformität erreichen. Private Einrichtungen in den erfassten Kategorien müssen denselben Konformitätsstandard innerhalb von zwei Jahren erreichen. Zu den erfassten privaten Kategorien gehören E-Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnentinnen und Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die unter der Genehmigung des Ministeriums für Nationale Bildung (MoNE) tätig sind.

Für all diese Organisationen ist eine fehlerhafte oder unlogische Fokusreihenfolge nicht nur ein Usability-Mangel – sie ist eine Nicht-Einhaltung von Vorschriften, die die Einrichtung rechtlichen und administrativen Konsequenzen im Rahmen der Durchsetzungsbestimmungen der Verfügung aussetzen kann. Stellen Sie sich das Online-Banking-Portal einer türkischen Bank vor, bei dem die Fokusreihenfolge auf dem Überweisungsbildschirm vom Betragsfeld direkt zum Bestätigungsbutton springt und das IBAN-Feld des Begünstigten überspringt. Eine reine Tastaturnutzerin – vielleicht eine Kundin mit motorischer Behinderung – könnte versehentlich eine Überweisung auslösen, ohne alle Pflichtfelder korrekt ausgefüllt zu haben. Dieses Szenario stellt gleichzeitig einen Verstoß gegen WCAG 2.4.3, einen Verstoß gegen die Anforderungen der Verfügung und einen potenziell schweren finanziellen Schaden für die Nutzerin dar.

Ebenso wäre eine vom Rundschreiben erfasste E-Commerce-Website, die CSS Grid-Umsortierung verwendet, um eine optisch ansprechende Produktseite darzustellen, deren Tab-Sequenz aber von Produktbildern zu Footer-Links springt, bevor der „In den Warenkorb“-Button erreicht wird, in direktem Verstoß zu 2.4.3 und damit nicht konform mit der Verfügung. Die Fristen von einem bzw. zwei Jahren bedeuten, dass Organisationen die Behebung von Fokusreihenfolge-Problemen als Priorität in ihren Barrierefreiheits-Roadmaps behandeln sollten – nicht als aufgeschobene Verbesserung. Da Probleme mit der Fokusreihenfolge häufig aus Architekturentscheidungen zur DOM-Struktur und zu JavaScript-Interaktionsmustern resultieren, ist ihre frühzeitige Berücksichtigung im Entwicklungsprozess deutlich kostengünstiger als eine nachträgliche Korrektur nach dem Launch.

Das Overlay-SDK von Accsible unterstützt Organisationen auf ihrem Weg zur Konformität, indem es konfigurierbare Verbesserungen des Fokusmanagements bereitstellt. Es ist jedoch wichtig zu betonen, dass Overlay-Lösungen am besten ergänzend zu – nicht anstelle von – sauberem semantischem HTML und verantwortungsvollem Fokusmanagement im eigenen Code der Anwendung funktionieren. Eine nachhaltige, prüfbare Konformität mit der Präsidialverfügung 2025/10 erfordert, dass das zugrunde liegende Produkt 2.4.3 durch korrekte Entwicklungspraktiken erfüllt.