WCAG 2.2.4: Unterbrechungen

WCAG 2.2.4 verlangt, dass Nutzer alle Unterbrechungen – wie Warnmeldungen, Benachrichtigungen und automatische Inhaltsaktualisierungen – aufschieben oder unterdrücken können, mit Ausnahme solcher, die einen Notfall betreffen. Dieses Kriterium ist entscheidend für Nutzer mit Aufmerksamkeits-, kognitiven oder neurologischen Beeinträchtigungen, die durch unerwartete Unterbrechungen während einer Aufgabe stark beeinträchtigt werden können.

Was diese Regel bedeutet

WCAG 2.2.4: Unterbrechungen ist ein Erfolgskriterium der Stufe AAA unter Richtlinie 2.2 (Ausreichend Zeit). Es lautet: „Unterbrechungen können vom Benutzer aufgeschoben oder unterdrückt werden, außer bei Unterbrechungen, die einen Notfall betreffen.“ Praktisch bedeutet dies, dass alle Inhalte, Warnungen, Benachrichtigungen, Dialoge oder Aktualisierungen, die erscheinen, ohne direkt vom Benutzer ausgelöst zu werden, diesem Benutzer einen Mechanismus bieten müssen, um sie aufzuschieben oder zu deaktivieren – es sei denn, die Unterbrechung kommuniziert einen echten Notfall wie einen Feueralarm, eine lebensbedrohliche medizinische Warnung oder einen kritischen Systemausfall.

Eine Unterbrechung im Sinne der WCAG ist jedes Ereignis, das unabhängig von der aktuellen Aktion des Benutzers auftritt und die Aufmerksamkeit von dem ablenkt, was der Benutzer gerade tut. Dazu gehören unter anderem: Toast-Benachrichtigungen, Push-Alerts, Chat-Widgets, die sich automatisch öffnen, Statusbanner, die sich aktualisieren oder ändern, automatisch abspielende Medien, Live-Region-Ankündigungen, die per JavaScript eingefügt werden, modale Dialoge, die durch einen Timer ausgelöst werden, und Cookie-Einwilligungsbanner, die mitten in der Sitzung erscheinen. Das Kriterium verbietet diese Muster nicht grundsätzlich; es verlangt, dass Benutzer die Kontrolle darüber erhalten.

Eine Seite besteht 2.2.4, wenn jede nicht-notfallbezogene Unterbrechung mindestens eines der folgenden Merkmale aufweist: eine für den Benutzer zugängliche Einstellung, die die Unterbrechung deaktiviert, bevor sie ausgelöst wird, einen Mechanismus innerhalb der Unterbrechung selbst, um sie zu schließen oder aufzuschieben, oder eine globale, seitenweite Voreinstellung, die solche Unterbrechungen vollständig unterdrückt. Eine Seite verfehlt das Kriterium, wenn Unterbrechungen automatisch erscheinen, keinen Mechanismus zum Schließen oder Aufschieben bieten und sich nicht auf einen Notfall beziehen. Beispielsweise würden sowohl eine Live-Chat-Blase, die sich nach 10 Sekunden automatisch ohne Schließen-Schaltfläche erweitert, als auch ein Benachrichtigungsbanner, das Marketingbotschaften durchläuft und nicht angehalten werden kann, das Kriterium verfehlen.

Die eine ausdrücklich definierte Ausnahme sind Notfälle. Wenn Inhalte den Benutzer unterbrechen müssen, um eine Gefahr für Gesundheit, Sicherheit oder Leben zu kommunizieren – etwa ein Krankenhausportal, das eine kritische Medikamentenwarnung sendet – darf diese Unterbrechung die Präferenzen des Benutzers außer Kraft setzen. Diese Ausnahme ist bewusst eng gefasst; routinemäßige Marketingnachrichten, Sitzungs-Timeout-Warnungen mit ausreichend verbleibender Zeit und Statusaktualisierungen mit niedriger Priorität gelten nicht als Notfälle.

Da WCAG 2.2.4 zur Stufe AAA gehört, ist es für grundlegende Konformitätserklärungen nicht erforderlich, stellt aber einen bedeutenden Standard für Organisationen dar, die sich einer vollständigen Inklusion verpflichtet fühlen. Es gilt für alle Webinhalte: Desktop- und mobile Webanwendungen, Single-Page-Anwendungen, die JavaScript-gesteuerte Benachrichtigungen verwenden, und Progressive Web Apps, die die Web Notifications API nutzen.

Warum es wichtig ist

Unerwartete Unterbrechungen auf einer Webseite sind nicht nur lästig – für viele Benutzer stellen sie eine ernsthafte Barriere bei der Aufgabenerledigung dar und in manchen Fällen ein direktes Gesundheitsrisiko.

Benutzer mit kognitiven und auf Aufmerksamkeit bezogenen Beeinträchtigungen – darunter ADHS, traumatische Hirnverletzungen, Autismus-Spektrum-Bedingungen und Demenz – sind in hohem Maße auf eine stabile, vorhersehbare Umgebung angewiesen, um die Konzentration aufrechtzuerhalten. Eine plötzliche Benachrichtigung oder animierte Warnung kann ihre Konzentration vollständig unterbrechen und dazu führen, dass sie den Überblick über einen mehrstufigen Prozess verlieren, etwa das Ausfüllen eines Leistungsantrags, das Prüfen einer Krankenakte oder das Ausfüllen eines Steuerformulars. Die erneute Orientierung nach einer Unterbrechung kann für diese Benutzer deutlich länger dauern als für neurotypische Benutzer, und in manchen Fällen sind sie möglicherweise überhaupt nicht in der Lage, ihre Position wiederzufinden.

Screenreader-Benutzer sind von dynamischen Unterbrechungen besonders betroffen. Wenn eine Live-Region oder ein ARIA-Alert in den DOM eingefügt wird, sind Screenreader wie NVDA, JAWS und VoiceOver so konzipiert, dass sie diese sofort ankündigen und damit alles unterbrechen, was die unterstützende Technologie gerade vorliest. Wenn ein Benutzer einem langen Absatz mit wichtigen Anweisungen zuhört und mitten im Satz ein Marketing-Toast ausgelöst wird, bricht der Screenreader den Absatz ab und kündigt die Benachrichtigung an. Der Benutzer muss dann zurück navigieren, seine Stelle finden und erneut lesen – ein Prozess, der für jemanden, der ausschließlich mit Tastatur und Audio navigiert, deutlich mühsamer ist, als es klingt.

Benutzer mit Angststörungen und PTBS können körperliche Stressreaktionen – erhöhte Herzfrequenz, Konzentrationsverlust oder Panik – erleben, die durch plötzliche, unerwartete visuelle oder auditive Veränderungen ausgelöst werden. Die Unvorhersehbarkeit einer Umgebung mit unkontrollierten Unterbrechungen kann einige Websites für diese Personengruppen faktisch unbenutzbar machen.

Benutzer mit Epilepsie oder vestibulären Störungen können durch bestimmte Arten von Unterbrechungen geschädigt werden, insbesondere solche mit Blinken oder schnellen Bewegungen. Während Richtlinie 2.3 Anfallsrisiken speziell adressiert, überschneiden sich animierte Benachrichtigungsbanner und automatisch abspielende Videobenachrichtigungen, die unerwartet erscheinen, mit beiden Kriterien.

Betrachten Sie ein konkretes Szenario: Eine Person mit ADHS nutzt ein Online-Banking-Portal, um Geld zwischen Konten zu überweisen. Sie prüft sorgfältig den Überweisungsbetrag und die Zielkontonummer. Eine Benachrichtigung mit einem Sonderangebot fährt von der unteren rechten Ecke ein, löst eine Screenreader-Ankündigung und eine animierte Einblendung aus. Die Person verliert ihre Stelle, kann die Schließen-Schaltfläche nicht finden, weil die Animation die Aufmerksamkeit abgelenkt hat, und sendet versehentlich den falschen Betrag. Dies ist kein hypothetischer Randfall – es ist ein vorhersehbares Ergebnis, wenn dieses Kriterium ignoriert wird.

Über Behinderungen hinaus schaden unkontrollierte Unterbrechungen auch der Nutzbarkeit für alle Benutzer, erhöhen die Absprungraten (Benutzer verlassen einfach Seiten, die sie bombardieren) und können die Conversion bei genau den Aktionen verringern, die durch die Unterbrechungen gefördert werden sollten. Aus SEO-Perspektive stehen hohe Absprungraten und kurze Sitzungsdauern in Zusammenhang mit schlechteren Signalen für das Suchranking, was bedeutet, dass Barrierefreiheit und geschäftliche Leistung hier im Einklang stehen.

Wie man testet

Führen Sie einen automatisierten Scan als Grundlage durch. Öffnen Sie die Seite in Chrome oder Firefox und führen Sie axe DevTools oder Lighthouse aus. Obwohl keines der Tools eine dedizierte Regel für 2.2.4 hat, wird der automatisierte Scan verwandte Probleme markieren: fehlende Rollen bei dynamischen Inhalten, falsch konfigurierte Live-Regionen und Fokus-Management-Probleme in Dialogen. Notieren Sie alle markierten aria-live-Regionen oder role='alert'-Elemente, da diese einer manuellen Nachprüfung bedürfen.
Beobachten Sie die Seite passiv für mindestens zwei bis drei Minuten. Ohne etwas anzuklicken, beobachten und hören Sie, ob sich Inhalte ändern, erscheinen oder sich selbst ankündigen. Verwenden Sie einen im Hintergrund laufenden Screenreader (NVDA mit Firefox oder VoiceOver mit Safari unter macOS) und achten Sie auf Ankündigungen, die nicht durch Ihre Aktion ausgelöst wurden. Notieren Sie jede Unterbrechung, ihren Zeitpunkt und ihren Inhalt.
Testen Sie interaktive Abläufe, die häufig Benachrichtigungen auslösen. Melden Sie sich, falls zutreffend, in der Anwendung an, navigieren Sie zu einem Formular oder einem mehrstufigen Prozess und beginnen Sie langsam mit dem Ausfüllen. Notieren Sie alle auftretenden Unterbrechungen: Sitzungs-Timeout-Warnungen, Chateinladungen, Werbebanner, Fortschrittsaktualisierungen oder Abonnementhinweise. Versuchen Sie bei jeder Unterbrechung, sie ausschließlich mit der Tastatur (Tab, Escape, Enter, Leertaste) zu schließen oder aufzuschieben. Vergewissern Sie sich, dass der Fokus nach dem Schließen an eine logische Stelle zurückkehrt.
Testen Sie mit NVDA und Firefox. Aktivieren Sie NVDA, öffnen Sie Firefox und navigieren Sie auf der Seite. Hören Sie aufmerksam auf Sprachausgaben, die Ihre aktuelle Lektüre unterbrechen. Wenn eine automatische Benachrichtigung ausgelöst wird, versuchen Sie, sie mit Tastaturbefehlen zu schließen, und prüfen Sie, ob NVDA die Bestätigung des Schließens ankündigt oder ob der Fokus angemessen zurückkehrt.
Testen Sie mit JAWS und Chrome. Wiederholen Sie die passiven Beobachtungs- und Interaktionsfluss-Tests mit JAWS und Chrome. JAWS und NVDA behandeln Live-Regionen unterschiedlich, daher ist es wichtig, beide zu testen, um sicherzustellen, dass Unterbrechungen konsistent angekündigt werden und Schließen-Mechanismen in beiden Screenreadern funktionieren.
Testen Sie mit VoiceOver und Safari auf iOS. Verwenden Sie auf einem mobilen Gerät oder Simulator VoiceOver mit Safari, um die Seite zu navigieren. Wischen Sie durch die Inhalte und beobachten Sie, ob Unterbrechungen auftreten. Testen Sie den Schließen-Mechanismus mit Touch-Gesten (Doppeltippen zum Aktivieren) und prüfen Sie, ob der Fokus an eine sinnvolle Stelle zurückkehrt.
Prüfen Sie, ob eine Benachrichtigungs-Einstellung vorhanden ist. Suchen Sie in der Anwendung nach einem Benutzerprofil, einem Einstellungsbereich oder einem Abschnitt mit Barrierefreiheits-Einstellungen. Vergewissern Sie sich, dass es eine Steuerung gibt, um Benachrichtigungen global zu unterdrücken oder zu konfigurieren, und testen Sie, ob das Aktivieren dieser Einstellung tatsächlich verhindert, dass Unterbrechungen in einer nachfolgenden Sitzung auftreten.
Überprüfen Sie JavaScript-Quellcode oder Netzwerkaktivität. Beobachten Sie in den Browser-DevTools während der Sitzung die Registerkarten Network und Console. Achten Sie auf WebSocket-Verbindungen, Polling-Intervalle oder setTimeout/setInterval-Aufrufe, die Inhalte in den DOM einfügen. Jede dieser Quellen ist ein potenzieller Ursprung von Unterbrechungen und sollte nachverfolgt werden, um sicherzustellen, dass eine Benutzerkontrolle implementiert ist.

Wie man es behebt

Automatisch öffnendes Chat-Widget – Falsch

<!-- Chat-Widget öffnet sich nach 10 Sekunden automatisch ohne Schließen-Schaltfläche -->
<div id='chat-widget' role='dialog' aria-label='Live chat'>
  <p>Hi! Can we help you today?</p>
  <button>Start chat</button>
</div>

<script>
  setTimeout(function() {
    document.getElementById('chat-widget').style.display = 'block';
  }, 10000);
</script>

Automatisch öffnendes Chat-Widget – Richtig

<!-- Chat-Widget enthält eine Schließen-Schaltfläche und respektiert eine Benutzereinstellung -->
<div id='chat-widget' role='dialog' aria-label='Live chat' aria-modal='true'>
  <p>Hi! Can we help you today?</p>
  <button id='chat-start'>Start chat</button>
  <!-- Schließen-Schaltfläche ermöglicht es dem Benutzer, die Unterbrechung aufzuschieben -->
  <button id='chat-dismiss' aria-label='Dismiss chat offer'>No thanks</button>
</div>

<script>
  // Prüfen, ob der Benutzer das Chat-Angebot zuvor abgelehnt hat
  if (!sessionStorage.getItem('chat-dismissed')) {
    setTimeout(function() {
      var widget = document.getElementById('chat-widget');
      widget.removeAttribute('hidden');
      // Fokus in den Dialog verschieben, damit Screenreader-Benutzer darauf aufmerksam werden
      document.getElementById('chat-dismiss').focus();
    }, 10000);
  }

  document.getElementById('chat-dismiss').addEventListener('click', function() {
    // Für den Rest der Sitzung unterdrücken
    sessionStorage.setItem('chat-dismissed', 'true');
    var widget = document.getElementById('chat-widget');
    widget.setAttribute('hidden', '');
    // Fokus auf das Element zurücksetzen, auf dem der Benutzer vor der Unterbrechung war
    document.getElementById('main-content').focus();
  });
</script>

Unkontrollierbare Marketing-Toast-Benachrichtigung – Falsch

<!-- Toast wird alle 30 Sekunden ausgelöst, keine Möglichkeit, ihn zu stoppen -->
<div role='alert' id='promo-toast'>
  <p>Use code SAVE20 for 20% off your next order!</p>
</div>

<script>
  setInterval(function() {
    document.getElementById('promo-toast').style.display = 'block';
    setTimeout(function() {
      document.getElementById('promo-toast').style.display = 'none';
    }, 5000);
  }, 30000);
</script>

Unkontrollierbare Marketing-Toast-Benachrichtigung – Richtig

<!-- Toast wird einmal ausgelöst, enthält eine Schließen-Steuerung und respektiert eine Präferenz -->
<div role='status' id='promo-toast' hidden>
  <p>Use code SAVE20 for 20% off your next order!</p>
  <!-- Schließen-Schaltfläche unterdrückt zukünftige Werbeaktionen in dieser Sitzung -->
  <button id='promo-dismiss' aria-label='Dismiss promotion'>&times;</button>
</div>

<script>
  // Nur einmal anzeigen und nur, wenn der Benutzer nicht abgewählt hat
  if (!localStorage.getItem('promos-suppressed')) {
    setTimeout(function() {
      document.getElementById('promo-toast').removeAttribute('hidden');
    }, 30000);
  }

  document.getElementById('promo-dismiss').addEventListener('click', function() {
    // Alle zukünftigen Werbeunterbrechungen dauerhaft unterdrücken
    localStorage.setItem('promos-suppressed', 'true');
    document.getElementById('promo-toast').setAttribute('hidden', '');
  });
</script>

Sitzungs-Timeout-Modal ohne Benutzerkontrolle – Falsch

<!-- Modal wird automatisch ausgelöst, fängt den Fokus ohne Aufschiebeoption -->
<div id='timeout-modal' role='dialog' aria-label='Session expiring'>
  <p>Your session will expire in 60 seconds.</p>
  <button id='logout-now'>Log out</button>
</div>

Sitzungs-Timeout-Modal ohne Benutzerkontrolle – Richtig

<!-- Modal bietet sowohl eine Fortsetzen- als auch eine Aufschiebeoption
     und kündigt sich Screenreadern deutlich an -->
<div id='timeout-modal' role='alertdialog'
     aria-labelledby='timeout-heading'
     aria-describedby='timeout-description'
     aria-modal='true'>
  <h2 id='timeout-heading'>Session Expiring Soon</h2>
  <p id='timeout-description'>
    Your session will expire in <span id='countdown'>5 minutes</span>.
    Would you like to continue, or shall we log you out now?
  </p>
  <button id='continue-session'>Continue session</button>
  <button id='logout-now'>Log out now</button>
  <!-- Aufschiebeoption gibt dem Benutzer eine sinnvolle Kontrolle -->
  <button id='remind-later'>Remind me in 5 more minutes</button>
</div>

Häufige Fehler

Verwendung von role='alert' für Werbe- oder Nachrichten mit niedriger Priorität. Die Rolle alert signalisiert Screenreadern Dringlichkeit und führt zu einer sofortigen Unterbrechung der Sprachausgabe. Marketingnachrichten, Tipps und Funktionsankündigungen sollten stattdessen role='status' oder aria-live='polite' verwenden, wodurch Inhalte erst angekündigt werden, nachdem der Screenreader seine aktuelle Ausgabe beendet hat.
Bereitstellung einer Schließen-Schaltfläche, die nur bei Hover oder Fokus sichtbar ist und damit praktisch unzugänglich ist. Wenn der Schließen-Mechanismus erfordert, dass der Benutzer mit der Maus darüber fährt, um ihn sichtbar zu machen, können Tastaturbenutzer und Screenreader-Benutzer ihn nicht sehen oder erreichen. Die Schließen-Schaltfläche muss immer sichtbar sein oder zumindest stets über die Tab-Reihenfolge der Tastatur erreichbar sein.
Zurücksetzen des Fokus auf document.body nach dem Schließen einer Benachrichtigung. Wenn eine Benachrichtigung oder ein Dialog geschlossen wird, muss der Fokus auf ein sinnvolles, kontextuell passendes Element zurückkehren – typischerweise auf das Element, mit dem der Benutzer interagiert hat, bevor die Unterbrechung erschien. Den Fokus auf body zu setzen, zwingt Screenreader-Benutzer dazu, die gesamte Seite erneut zu navigieren.
Gleichzeitiges Auslösen mehrerer aria-live-Regionen. Wenn mehrere Live-Regionen gleichzeitig aktualisiert werden, stellen Screenreader Ankündigungen unvorhersehbar in eine Warteschlange oder lassen sie fallen. Jede Unterbrechung sollte sorgfältig so gesteuert werden, dass jeweils nur eine Live-Region ausgelöst wird und Aktualisierungen nach Möglichkeit gebündelt werden.
Die native Benachrichtigungs-Berechtigungsabfrage des Browsers als ausreichende Benutzerkontrolle betrachten. Der Berechtigungsdialog des Browsers für die Web Notifications API arbeitet auf Betriebssystemebene, nicht auf Anwendungsebene. WCAG 2.2.4 verlangt, dass Benutzer Benachrichtigungen innerhalb der Webanwendung selbst verwalten können und nicht nur, indem sie die Seite auf Browser-Ebene blockieren.
Zurücksetzen einer geschlossenen Benachrichtigung bei jedem Seitenaufruf. Wenn ein Benutzer eine Benachrichtigung schließt und sie beim nächsten Aufruf derselben Seite oder einer anderen Seite der Website erneut erscheint, war die Schließen-Aktion bedeutungslos. Präferenzen sollten mindestens für die Dauer der Sitzung mit sessionStorage oder dauerhaft mit localStorage oder einer serverseitigen Einstellung gespeichert werden.
Verwendung von setInterval, um rotierende Banner oder Tipps ohne Pausensteuerung durchlaufen zu lassen. Rotierende Inhalte, die durch einen Timer aktualisiert werden, sind eine Unterbrechung. Wenn sich der Inhalt ändert, während ein Screenreader-Benutzer ihn liest, beginnt die Ankündigung von vorn. Diese Karussells und rotierenden Banner benötigen eine Play/Pause-Steuerung und dürfen nicht ohne Zustimmung des Benutzers endlos durchlaufen.
Einfügen einer Benachrichtigung an einer Position im DOM, die unerwartete Scrollsprünge verursacht. Wenn ein Benachrichtigungsbanner am oberen Rand der Seite eingefügt wird und die Seite nach unten verschoben wird, verlieren Benutzer ihre visuelle Leseposition. Benachrichtigungen sollten so eingefügt werden, dass sie das Layout der Inhalte, die der Benutzer gerade betrachtet, nicht beeinflussen, typischerweise mit fester oder absoluter Positionierung.
Die Annahme, dass ein kurzer Auto-Schließen-Timer das Kriterium erfüllt. Ein Toast, der nach fünf Sekunden verschwindet, gibt Benutzern keine sinnvolle Kontrolle – viele Benutzer können Inhalte in dieser Zeit nicht lesen, verarbeiten oder darauf reagieren, insbesondere Personen mit kognitiven Beeinträchtigungen oder Screenreader-Benutzer. Nur einen Auto-Schließen-Timer ohne eine vom Benutzer gesteuerte Schließen-Schaltfläche bereitzustellen, ist nicht konform.
Unterlassene Tests des Unterbrechungsverhaltens, wenn das Betriebssystem oder der Browser des Benutzers Einstellungen für reduzierte Bewegung oder Benachrichtigungen aktiviert hat. Einige Benutzer stellen auf Betriebssystemebene Präferenzen für reduzierte Bewegung oder unterdrückte Benachrichtigungen ein. Diese Signale sollten von der Anwendung respektiert werden, und Entwickler sollten mit aktivem prefers-reduced-motion: reduce-Media-Query testen, um sicherzustellen, dass animierte Unterbrechungen entsprechend unterdrückt werden.

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, etabliert einen verbindlichen Rahmen für Web-Barrierefreiheit für eine breite Palette von Organisationen, die in der Türkei tätig sind. Die Verfügung übernimmt WCAG 2.2 als technischen Referenzstandard und schreibt Konformität für erfasste Einrichtungen vor. Zu den in der Verfügung ausdrücklich genannten Einrichtungstypen gehören öffentliche Institutionen und Behörden, E-Commerce-Plattformen, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, lizenzierte Reisebüros, private Transportunternehmen und Privatschulen, die unter der Genehmigung des Ministeriums für Nationale Bildung (MoNE) tätig sind.

WCAG 2.2.4: Unterbrechungen ist ein Kriterium der Stufe AAA, was bedeutet, dass es für die grundlegenden Konformitätsanforderungen nach der Präsidialverfügung 2025/10 für die meisten erfassten Einrichtungen nicht erforderlich ist. Organisationen, die Konformität der Stufen A und AA erreichen und erklären, gelten als rechtlich konform mit den Mindestanforderungen der Verfügung. Dennoch haben Kriterien der Stufe AAA wie 2.2.4 im türkischen Marktkontext erhebliches praktisches und reputationsbezogenes Gewicht.

Mehrere der erfassten Einrichtungstypen – insbesondere Krankenhäuser, Banken und öffentliche Institutionen – bedienen Nutzergruppen mit erhöhten Raten kognitiver und neurologischer Beeinträchtigungen, Angststörungen und altersbedingter Aufmerksamkeitsprobleme. Für diese Organisationen stellen unkontrollierte Unterbrechungen in digitalen Oberflächen nicht nur ein Barrierefreiheitsversagen dar, sondern ein potenzielles Risiko für Patientensicherheit oder finanziellen Schaden. Ein Krankenhaus-Patientenportal, das unkontrollierbare Medikamentenerinnerungen oder Terminerinnerungen während eines kritischen Formular-Ausfüllvorgangs auslöst, oder eine Banking-Anwendung, die nicht unterdrückbare Werbebanner während der Transaktionsprüfung anzeigt, verursacht für Benutzer in diesen Gruppen realen Schaden.

Für Organisationen in der Türkei, die Führungsstärke in digitaler Barrierefreiheit demonstrieren möchten – insbesondere solche, die freiwillige WCAG-2.2-Stufe-AAA-Erklärungen anstreben, auf Anforderungen zur Barrierefreiheit in der öffentlichen Beschaffung reagieren oder europäische Märkte anvisieren, in denen der European Accessibility Act (EAA) einen höheren Standard setzt – ist die Umsetzung von 2.2.4 ein bedeutendes Unterscheidungsmerkmal. Das Accsible-Overlay-SDK unterstützt Organisationen bei der Erfüllung dieser höheren Standards, indem es konfigurierbare Benachrichtigungs-Managementfunktionen, die Persistenz von Benutzerpräferenzen und barrierefreiheitsbewusste Widget-Verhaltensweisen bereitstellt, die sowohl mit den türkischen regulatorischen Erwartungen als auch mit internationalen Best Practices im Einklang stehen.