WCAG 3.2.1: Beim Fokus

Was diese Regel bedeutet

Das WCAG-Erfolgskriterium 3.2.1 „On Focus“ (Niveau A) besagt: „Wenn eine Komponente den Fokus erhält, darf dies nicht zu einer Änderung des Kontexts führen.“ Vereinfacht ausgedrückt: Der Vorgang, den Fokus auf ein interaktives Element zu verschieben – durch Drücken von Tab, Shift+Tab, Pfeiltasten oder einen anderen Tastaturmechanismus – darf für sich genommen nicht dazu führen, dass auf der Seite etwas Dramatisches und Unerwartetes passiert.

Eine Kontextänderung wird von den WCAG als eine wesentliche Änderung des Seiteninhalts definiert, die, wenn sie ohne Wissen der Nutzerin oder des Nutzers erfolgt, diese Person desorientieren könnte. Die Spezifikation benennt vier konkrete Arten von Kontextänderungen: Änderungen am User Agent (z. B. das Öffnen eines neuen Browserfensters oder -tabs), Änderungen am Viewport (z. B. automatisches Scrollen zu einem weit entfernten Teil der Seite), Änderungen am Fokus selbst (z. B. automatisches Verschieben des Fokus an eine andere Stelle) und Änderungen am Inhalt, die die Bedeutung der Seite wesentlich verändern (z. B. das Absenden eines Formulars oder das Laden einer völlig anderen Ansicht).

Der entscheidende Unterschied, den das Kriterium macht, liegt zwischen dem Erhalten des Fokus und dem Aktivieren eines Steuerelements. Wenn das Tabben auf eine Schaltfläche dazu führt, dass ein Formular abgeschickt wird, ist das ein Verstoß. Wenn jedoch bei fokussierter Schaltfläche Enter oder Leertaste gedrückt wird – also eine absichtliche, bewusste Aktivierung – ist das völlig akzeptabel und sogar zu erwarten. Die Absicht der Nutzerin oder des Nutzers ist das, was eine vorhersehbare Interaktion von einer desorientierenden trennt.

Häufige Muster, die gegen dieses Kriterium verstoßen, sind unter anderem:

• Ein <select>-Dropdown, das automatisch zu einer neuen URL navigiert, sobald eine Option den Fokus erhält (nicht, wenn die Nutzerin oder der Nutzer die Auswahl bestätigt).
• Ein Datumsauswahl-Widget, das in dem Moment einen modalen Dialog öffnet, in dem eines seiner Eingabefelder den Fokus erhält, ohne jegliche Aktivierung durch die Nutzerin oder den Nutzer.
• Ein Karussell oder eine Slideshow, die automatisch zum nächsten Slide weiterblättert, wenn ihre Navigationspunkte den Fokus erhalten.
• Ein Tooltip oder Popover, das, wenn es durch Fokus ausgelöst wird, gleichzeitig den Tastaturfokus ohne Vorwarnung auf sich selbst verschiebt und die Nutzerin oder den Nutzer an einem unerwarteten Ort „strandet“.
• Ein Suchfeld, das sofort absendet und die Seite neu lädt, wenn es den Fokus erhält.

Muster, die ausdrücklich keine Verstöße darstellen, sind unter anderem: ein Tooltip oder ein Beschreibungsbereich, der visuell erscheint, aber den Fokus nicht verschiebt und den primären Seiteninhalt nicht verändert; ein Fokusindikator (z. B. eine Kontur oder ein Ring), der um das fokussierte Element erscheint; oder ein Element, das sich erweitert und zusätzlichen Inhalt inline anzeigt, solange der Fokus dort bleibt, wo die Nutzerin oder der Nutzer ihn platziert hat.

In WCAG 3.2.1 sind keine offiziellen Ausnahmen definiert. Das Kriterium gilt universell für alle UI-Komponenten auf einer Seite. Das WCAG-Understanding-Dokument weist jedoch darauf hin, dass Kontextänderungen, die durch eine bewusste Aktivierung durch die Nutzerin oder den Nutzer ausgelöst werden (Klick, Enter, Leertaste), nicht in den Geltungsbereich dieses Kriteriums fallen, das sich ausschließlich auf den passiven Vorgang des Fokuserhalts bezieht.

Warum es wichtig ist

Das Kriterium „On Focus“ gehört zu Prinzip 3 – Verständlich –, weil Vorhersehbarkeit eine grundlegende Voraussetzung für Benutzbarkeit ist. Wenn eine Seite allein als Reaktion auf den Fokus unerwartet reagiert, reichen die Folgen – je nach Bedürfnissen und Hilfsmitteln der Nutzerin oder des Nutzers – von leichter Verwirrung bis hin zum vollständigen Verlust des Zugangs.

Nur-Tastatur-Nutzerinnen und -Nutzer (Personen, die aufgrund motorischer Beeinträchtigungen, RSI oder Lähmungen keine Maus verwenden können) sind ausschließlich auf die Tastaturnavigation angewiesen. Wenn das Tabben in ein Formularfeld einen Seiten-Reload auslöst, können sie alle bereits eingegebenen Daten verlieren und von ihrem Ziel weggeleitet werden. Die Wiederherstellung nach einer solchen Unterbrechung kann erheblichen Zeit- und Kraftaufwand erfordern – oder sie geben schlicht ganz auf.

Screenreader-Nutzerinnen und -Nutzer (die häufig ebenfalls Nur-Tastatur-Nutzende sind) erleben eine zusätzliche Ebene der Desorientierung. Screenreader geben das aktuell fokussierte Element aus. Wenn der Fokus unerwartet auf ein neues Element springt – etwa auf ein Modal, das automatisch geöffnet wurde –, kündigt der Screenreader den neuen Kontext an, ohne der Nutzerin oder dem Nutzer einen Bezugsrahmen dafür zu geben, was gerade passiert ist und warum. Das ist vergleichbar damit, ohne Vorwarnung physisch in einen anderen Raum versetzt zu werden.

Nutzerinnen und Nutzer mit kognitiven Beeinträchtigungen, einschließlich Personen mit ADHS, Angststörungen oder Gedächtnisbeeinträchtigungen, sind auf vorhersehbare Oberflächen angewiesen, um ein mentales Modell einer Seite aufzubauen und aufrechtzuerhalten. Plötzliche, unerklärte Kontextänderungen zerstören dieses Modell und führen zu Verwirrung, Angst und Fehlern. Eine Studie des WebAIM-Million-Projekts zeigt immer wieder, dass komplexe interaktive Komponenten mit unerwartetem Verhalten zu den häufigsten Quellen von Barrierefreiheitsbeschwerden von Menschen mit kognitiven Beeinträchtigungen gehören.

Nutzerinnen und Nutzer mit Sehrest, die Bildschirmvergrößerungssoftware verwenden (z. B. ZoomText oder Windows-Magnifier), sehen jeweils nur einen kleinen Ausschnitt des Bildschirms. Wenn der Fokus ein automatisches Scrollen oder eine Navigation auslöst, kann der relevante Inhalt vollständig aus ihrem vergrößerten Viewport verschwinden, sodass sie auf einen leeren oder themenfremden Bereich des Bildschirms blicken.

Betrachten wir ein konkretes Szenario aus der Praxis: Das Online-Überweisungsformular einer türkischen Bank enthält ein Dropdown-Menü zur Auswahl der Zielbank. Die Entwicklerin oder der Entwickler hat ein onchange-ähnliches Ereignis auf dem <select>-Element implementiert, das nicht bei Bestätigung, sondern bereits dann ausgelöst wird, wenn eine Option per Pfeiltaste den Fokus erhält. Eine Screenreader-Nutzerin oder ein Screenreader-Nutzer, die bzw. der in das Feld tabbt und die Pfeil-nach-unten-Taste drückt, um die verfügbaren Banken zu erkunden, löst sofort eine Formularübermittlung oder einen Seiten-Reload aus. Die Überweisung wird nie abgeschlossen, und die Person kann nicht nachvollziehen, was schiefgelaufen ist. Dieses Szenario ist nicht hypothetisch – es war ein dokumentiertes Muster in vielen frühen Single-Page-Anwendungen.

Über die Barrierefreiheit hinaus gibt es handfeste Usability- und geschäftliche Vorteile. Formulare, die den Fokus nicht „kapern“, haben geringere Abbruchraten. Seiten, die sich vorhersehbar verhalten, erzielen in Usability-Tests mit allen Zielgruppen bessere Ergebnisse. Auch Suchmaschinen-Crawler profitieren von vorhersehbaren Navigationsabläufen, da unerwartete Weiterleitungen, die durch Fokusereignisse ausgelöst werden, die Crawling-Logik in bestimmten dynamischen Rendering-Szenarien verwirren können.

Verwandte Axe-core-Regeln

WCAG 3.2.1 „On Focus“ erfordert manuelle Tests, da automatisierte Tools weder die Absicht der Nutzerin oder des Nutzers zuverlässig erkennen noch alle möglichen Kontextänderungen vorhersagen können. Axe-core und ähnliche automatisierte Scanner können statisches HTML und ARIA-Attribute analysieren, aber sie können das Laufzeitverhalten von JavaScript als Reaktion auf Fokusereignisse nicht beobachten – insbesondere nicht, ob dieses Verhalten eine „wesentliche“ Kontextänderung im Sinne der WCAG darstellt. Ein Skript, das beim focus-Ereignis den Fokus verschiebt, ein Formular absendet oder zu einer URL navigiert, bleibt für einen statischen Scanner unsichtbar, sofern das Tool nicht tatsächlich Fokusinteraktionen für jedes interaktive Element simuliert und anschließend analysiert, was sich im DOM, im Viewport und in der URL verändert hat. Dieses Maß an Verhaltenssimulation ist in einem automatisierten Durchlauf nicht zuverlässig erreichbar, ohne eine unvertretbar hohe Rate an Fehlalarmen zu erzeugen.

• Manueller Test erforderlich – Kontextänderung bei Fokus: Testende müssen manuell mit Tab durch jedes interaktive Element auf der Seite gehen (Links, Schaltflächen, Eingabefelder, Selects, benutzerdefinierte Widgets) und beobachten, ob allein der Fokus – ohne Aktivierung – eine Kontextänderung im Sinne der WCAG auslöst. Dazu gehört das Beobachten von URL-Änderungen, dem Öffnen neuer Fenster oder Tabs, dem Wegspringen des Fokus vom aktuellen Element, Formularübermittlungen und größeren Inhaltswechseln. Automatisierte Tools markieren JavaScript-Ereignislistener, die an fokusbezogene Ereignisse (focus, focusin, onfocus) gebunden sind, als Kandidaten für eine manuelle Überprüfung, können aber nicht bestimmen, ob diese Handler eine unzulässige Kontextänderung verursachen.

Wie man testet

1. Automatischer Vorab-Scan: Führen Sie axe DevTools (Browser-Erweiterung oder CLI) oder Google Lighthouse auf der Seite aus. Auch wenn keines der Tools Verstöße gegen „On Focus“ eindeutig erkennen kann, kann axe DevTools verwandte Probleme im Fokusmanagement aufzeigen (z. B. scrollable-region-focusable oder Fokusfallen-Muster), die eine genauere manuelle Prüfung rechtfertigen. Nutzen Sie das Panel „Needs Review“ in axe DevTools – dort markierte Punkte betreffen häufig das Verhalten interaktiver Komponenten, das menschliche Beurteilung erfordert.
2. Alle interaktiven Elemente identifizieren: Erstellen Sie vor den Tastaturtests eine Liste aller interaktiven Komponenten: Links, Schaltflächen, Formulareingaben, Dropdowns, Kontrollkästchen, Optionsfelder, Datumsauswahlen, Karussells, Akkordeons, Tabs, Modals und alle benutzerdefinierten Widgets mit tabindex. Achten Sie besonders auf benutzerdefinierte JavaScript-Widgets, die auf focus- oder focusin-Ereignisse hören.
3. Test mit reiner Tastaturnavigation: Verwenden Sie ausschließlich die Tastatur (keine Maus) und drücken Sie Tab nacheinander für jedes fokussierbare Element auf der Seite. Beobachten Sie nach jedem Tab-Tastendruck, bevor Sie etwas anderes drücken: Hat sich die URL geändert? Wurde ein neues Fenster oder ein neuer Tab geöffnet? Ist der Fokus vom Element, zu dem Sie gerade getabbt haben, weggesprungen? Wurde ein Formular abgesendet? Hat sich der primäre Seiteninhalt drastisch verändert? Jede „Ja“-Antwort ist ein potenzieller Verstoß.
4. Test für Select-Elemente: Fokussieren Sie jedes <select>-Dropdown. Verwenden Sie die Pfeil-auf- und Pfeil-ab-Tasten, um durch die Optionen zu navigieren, ohne Enter oder Leertaste zu drücken. Vergewissern Sie sich, dass das Navigieren durch die Optionen keine Navigation, Formularübermittlung oder Kontextänderung auslöst. Dies ist eines der am häufigsten verletzten Muster.
5. NVDA + Firefox: Aktivieren Sie NVDA (kostenlos, Windows). Öffnen Sie Firefox und rufen Sie die Seite auf. Drücken Sie Tab durch alle interaktiven Elemente. Hören Sie auf die Ausgaben von NVDA – wenn NVDA nach einem Tab-Druck (ohne dass Sie Enter oder Leertaste drücken) plötzlich einen völlig anderen Teil der Seite oder einen neuen Seitenkontext ankündigt, ist dies ein starkes Signal für einen Verstoß.
6. JAWS + Chrome: Aktivieren Sie JAWS. Öffnen Sie Chrome. Navigieren Sie mit Tab. JAWS kündigt jedes fokussierte Element an. Achten Sie auf unerwartete Ankündigungen neuer Dialoge, Seiten oder Fokuspositionen, zu denen Sie nicht bewusst navigiert haben.
7. VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver (Cmd+F5 auf macOS). Navigieren Sie mit Tab (oder per Wischgeste auf iOS). Achten Sie auf unerwartete Kontextwechsel. Testen Sie auf iOS außerdem mit Switch Control, um Nutzerinnen und Nutzer mit schweren motorischen Beeinträchtigungen zu simulieren, die per Scanning navigieren.
8. Überprüfung von Ereignis-Listenern in den Browser-DevTools: Wählen Sie in den Chrome DevTools ein verdächtiges interaktives Element aus, gehen Sie in das „Elements“-Panel und klicken Sie auf „Event Listeners“. Suchen Sie nach focus- oder focusin-Listenern. Wenn vorhanden, prüfen Sie den zugehörigen JavaScript-Code, um festzustellen, ob der Handler Navigation, Formularübermittlung, Fokusverschiebung oder andere kontextverändernde Aktionen auslöst.

Wie man es behebt

Automatisch absendendes Select-Dropdown – Falsch

<!-- FAIL: Selecting an option via arrow key immediately navigates to a new URL -->
<label for='region'>Select Region</label>
<select id='region' onchange='window.location = this.value;'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>

Automatisch absendendes Select-Dropdown – Richtig

<!-- PASS: Navigation only occurs when the user explicitly activates the Go button -->
<label for='region'>Select Region</label>
<select id='region'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>
<button type='button' onclick='navigateToRegion()'>Go</button>

<script>
function navigateToRegion() {
  var select = document.getElementById('region');
  window.location = select.value; // Only fires on deliberate button activation
}
</script>

Modal öffnet sich beim Fokus auf Eingabefeld – Falsch

<!-- FAIL: Focusing the date input immediately opens a modal dialog and moves focus -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' onfocus='openDatePickerModal()' />

<script>
function openDatePickerModal() {
  var modal = document.getElementById('date-modal');
  modal.style.display = 'block';
  modal.querySelector('button').focus(); // Moves focus away without user intent
}
</script>

Modal öffnet sich beim Fokus auf Eingabefeld – Richtig

<!-- PASS: The date picker opens only when the user explicitly clicks or presses Enter/Space -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' readonly aria-haspopup='dialog'
       aria-label='Departure Date — press Enter to open date picker' />
<button type='button' id='open-picker'
        aria-controls='date-modal'
        onclick='openDatePickerModal()'>
  Choose Date
</button>

<script>
function openDatePickerModal() {
  // Only called on explicit activation (click or Enter/Space on the button)
  var modal = document.getElementById('date-modal');
  modal.removeAttribute('hidden');
  modal.querySelector('[data-initial-focus]').focus();
}
</script>

Karussell wechselt bei Fokus automatisch – Falsch

<!-- FAIL: Focusing a navigation dot advances the carousel slide, changing page content -->
<div class='carousel-dots'>
  <button class='dot' onfocus='showSlide(0)'>1</button>
  <button class='dot' onfocus='showSlide(1)'>2</button>
  <button class='dot' onfocus='showSlide(2)'>3</button>
</div>

Karussell wechselt bei Fokus automatisch – Richtig

<!-- PASS: The carousel only changes slides when the dot is explicitly activated (click/Enter) -->
<div class='carousel-dots' role='tablist' aria-label='Carousel navigation'>
  <button class='dot' role='tab' aria-selected='true'
          aria-controls='slide-0' onclick='showSlide(0)'>
    Slide 1
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-1' onclick='showSlide(1)'>
    Slide 2
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-2' onclick='showSlide(2)'>
    Slide 3
  </button>
</div>
<!-- onclick only fires on deliberate activation, not on Tab focus -->

Häufige Fehler

• onfocus als Ersatz für onclick bei Navigationselementen verwenden: Entwickelnde hängen manchmal onfocus-Handler an Navigationslinks oder -schaltflächen, um ein Ziel „vorzuladen“, und lösen dabei versehentlich eine vollständige Navigation statt nur eines Prefetches aus. Verwenden Sie für jede Aktion, die den Kontext ändert, immer onclick oder onkeydown (mit Prüfung auf Enter/Leertaste).
• onchange an <select>-Elemente binden, ohne eine explizite Absendeaktion: In Desktop-Browsern wird onchange bei einem <select> ausgelöst, wenn eine Option bestätigt wird, in einigen älteren Implementierungen und bestimmten mobilen Browsern kann es jedoch ausgelöst werden, wenn die Pfeiltasten durch die Optionen bewegt werden. Kombinieren Sie Select-basierte Navigation immer mit einer expliziten Absende-Schaltfläche oder verwenden Sie ein <form> mit einem <button type='submit'>.
• Fokus programmatisch innerhalb eines focus-Ereignis-Handlers verschieben: Das Aufrufen von element.focus() innerhalb des onfocus- oder focusin-Handlers eines anderen Elements erzeugt einen unerwarteten Fokus-Sprung. Dies ist ein direkter Verstoß – die Nutzerin oder der Nutzer hat zu Element A getabbt, und der Fokus ist stillschweigend zu Element B gewandert. Verschieben Sie den Fokus immer nur als Reaktion auf bewusste Nutzeraktionen.
• Modale Dialoge bei Fokusereignissen eines Auslöseelements öffnen: Ein gängiger Shortcut ist, einen Modal-Öffnen-Handler an das focus-Ereignis einer Auslöser-Schaltfläche oder eines Eingabefelds zu hängen. Modals dürfen nur als Reaktion auf einen Klick, die Enter-Taste oder die Leertaste geöffnet werden – niemals allein durch Fokus.
• Automatisches Abspielen von Medien oder Animationen, die den Viewport-Kontext bei Fokus verändern: Ein Hero-Banner, das in dem Moment ein Vollbildvideo oder eine große Animation startet, in dem seine Abspiel-Schaltfläche den Fokus erhält, verändert den visuellen Kontext erheblich. Verknüpfen Sie Abspielaktionen mit Aktivierungsereignissen, nicht mit Fokusereignissen.
• Live-Region-Updates auslösen, die die Seite bei Fokus zu neuen Inhalten scrollen: Einige dynamische Widgets aktualisieren eine Live-Region und scrollen den Viewport dann zu dieser Region, sobald eine Eingabe den Fokus erhält. Dies verändert den Viewport-Kontext und desorientiert Nutzerinnen und Nutzer mit Bildschirmvergrößerung. Entkoppeln Sie Live-Region-Updates nach Möglichkeit von Fokusereignissen.
• Benutzerdefinierte Fokusfallen implementieren, die Nutzerinnen und Nutzer sofort und ohne Hinweis „einsperren“: Eine benutzerdefinierte Komponente, die alle Tab-Tastendrücke ab dem Moment abfängt, in dem sie den Fokus erhält, ohne der Nutzerin oder dem Nutzer mitzuteilen, dass sie bzw. er sich in einer Fokusfalle befindet, verstößt sowohl gegen Wortlaut als auch Geist dieses Kriteriums. Fokusfallen sind nur innerhalb vollständig geöffneter Modaldialoge angemessen, und die Nutzerinnen und Nutzer müssen darüber informiert werden, wie sie diese verlassen können.
• CSS-:focus verwenden, um display: block bei Dropdown-Menüs mit fokussierbaren Kindelementen auszulösen, was zu kaskadierenden unerwarteten Fokusbewegungen führt: Rein CSS-gesteuerte, fokusbasierte Menüs, die fokussierbare Elemente einblenden, können verwirrende Sprünge verursachen, wenn die Fokusreihenfolge des Browsers dann in die neu sichtbaren Elemente wechselt. Stellen Sie sicher, dass eingeblendete Menüs erwartet werden und klar über ARIA-Attribute wie aria-expanded kommuniziert werden.
• Sich auf Drittanbieter-Widget-Bibliotheken verlassen, ohne deren Fokusverhalten zu prüfen: Viele UI-Komponentenbibliotheken (Datumsauswahlen, Rich-Text-Editoren, Select2-ähnliche Dropdowns) haben historisch gegen 3.2.1 verstoßen, indem sie Popups öffneten oder den Fokus bei focus-Ereignissen verschoben. Prüfen Sie Drittanbieter-Komponenten vor dem Einsatz immer manuell, unabhängig von den Barrierefreiheitsversprechen der Bibliothek.
• Versäumnis, in Routing-Kontexten von Single-Page-Anwendungen (SPA) zu testen: In React-, Vue- und Angular-SPAs können Fokusereignisse auf Navigationslinks manchmal über die Router-Prefetch-Logik oder Event-Bubbling Routenwechsel auslösen, insbesondere wenn Fokusereignisse nicht korrekt am Weiterreichen gehindert werden. Testen Sie SPA-Navigationselemente ausdrücklich auf Konformität mit 3.2.1.

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 Anforderungen an die Web-Barrierefreiheit fest, die WCAG 2.2 ausdrücklich als technischen Standard referenzieren. WCAG 3.2.1 „On Focus“ ist ein Kriterium der Stufe A, was bedeutet, dass es zur grundlegenden, verpflichtenden Konformität unter der Verfügung gehört. Für Kriterien der Stufe A gibt es keine Ausnahmen – alle erfassten Stellen müssen sie innerhalb der festgelegten Fristen erfüllen.

Öffentliche Institutionen sind verpflichtet, innerhalb von einem Jahr nach Veröffentlichung der Verfügung vollständige Konformität zu erreichen. Private Unternehmen im Geltungsbereich erhalten zwei Jahre. Zu den von der Präsidialverfügung 2025/10 erfassten Stellen gehört eine breite Palette von Organisationen: alle öffentlichen Institutionen und Behörden, E‑Commerce-Plattformen und Online-Marktplätze, Banken und Finanzinstitute, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnentinnen und Abonnenten, Reisebüros und Buchungsplattformen, private Transportunternehmen sowie private Schulen und Bildungseinrichtungen, die vom Bildungsministerium (MoNE) zugelassen sind.

Die Relevanz von WCAG 3.2.1 „On Focus“ für diese Arten von Einrichtungen ist direkt und praktisch. Man denke an eine E‑Commerce-Plattform, bei der ein Produktkategorie-Dropdown bei Fokus automatisch navigiert – eine Kundin oder ein Kunde mit Mobilitätsbeeinträchtigung, die bzw. der die Tastatur verwendet, kann Produktkategorien nicht durchstöbern und bricht den Kauf ab. Ein Online-Überweisungsformular einer Bank mit fokusgesteuerten Formularübermittlungen könnte unbeabsichtigte Finanztransaktionen oder wiederholte Fehlversuche für Screenreader-Nutzerinnen und -Nutzer verursachen. Ein System zur Terminbuchung eines Krankenhauses, bei dem Datumsfelder bei Fokus Modals öffnen, kann Patientinnen und Patienten mit Behinderungen daran hindern, eigenständig Termine zu vereinbaren.

Ein Verstoß gegen die Verfügung setzt erfasste Stellen administrativen Sanktionen und Reputationsrisiken aus. Für Einrichtungen, die sich derzeit in der digitalen Transformation befinden oder neue Websysteme beschaffen, ist es sowohl kosteneffizienter als auch besser mit dem Geist der Regelung vereinbar, die Einhaltung von WCAG 3.2.1 bereits jetzt in Beschaffungsanforderungen und Entwicklerleitlinien zu verankern, statt erst nach einer Beschwerde nachzubessern. Organisationen, die das Accsible-Overlay-SDK verwenden, profitieren von integrierten Tools zum Fokusmanagement, die helfen, unerwartete On-Focus-Verhalten zu identifizieren und zu beheben – als Teil eines umfassenderen Workflows zur Einhaltung von WCAG 2.2 Stufe A.