WCAG 2.2.1: Zeitlich anpassbar

Was diese Regel bedeutet

WCAG 2.2.1 Timing Adjustable ist ein Erfolgskriterium der Stufe A unter Prinzip 2: Bedienbar. Es besagt, dass für jedes durch Inhalte gesetzte Zeitlimit mindestens eine der folgenden Bedingungen erfüllt sein muss: Die Nutzerin oder der Nutzer kann das Zeitlimit deaktivieren, bevor es erreicht wird; die Nutzerin oder der Nutzer kann das Zeitlimit in einem weiten Bereich anpassen (mindestens auf das Zehnfache der Standardeinstellung); oder die Nutzerin oder der Nutzer kann das Zeitlimit mit einer einfachen Aktion verlängern – etwa durch Drücken einer Taste oder Klicken auf eine Schaltfläche – bevor die Zeit abläuft, und wird mindestens 20 Sekunden im Voraus gewarnt, mit der Möglichkeit, das Limit mindestens zehnmal zu verlängern.

Praktisch gesehen gilt dieses Kriterium für jede Weboberfläche, die eine Sitzungszeitüberschreitung erzwingt, ein automatisch weiterlaufendes Karussell mit zeitgesteuerten Folien, ein Formular, das sich automatisch leert oder absendet, einen Countdown-Timer auf einer Checkout-Seite, einen Mediaplayer mit zeitgesteuerten Untertiteln, die nicht angehalten werden können, oder jeden anderen Mechanismus, der die Zeit begrenzt, die eine Nutzerin oder ein Nutzer zur Erledigung einer Aufgabe hat. Wenn Ihre Seite oder Anwendung einen Timer setzt, der nach Ablauf Inhalte entfernt, die Nutzerin oder den Nutzer abmeldet oder ohne deren Einwilligung in einen neuen Zustand überführt, müssen Sie eine Möglichkeit anbieten, dieses Limit anzupassen oder zu verlängern.

Das Kriterium definiert außerdem drei wichtige Ausnahmen, die es erlauben können, ein Zeitlimit ohne die oben beschriebenen Anpassungsmechanismen beizubehalten. Erstens die Echtzeit-Ausnahme: Wenn das Zeitlimit ein notwendiger Bestandteil eines Echtzeit-Ereignisses ist (z. B. eine Live-Auktion oder eine synchrone Online-Prüfung), würde eine Anpassung der Zeit die Aktivität selbst ungültig machen, und es ist keine Alternative praktikabel. Zweitens die essentielle Ausnahme: Wenn das Zeitlimit wesentlich ist und seine Verlängerung die Aktivität ungültig machen würde – etwa bei einem zeitgesteuerten Fähigkeitstest, bei dem die Messung der Reaktionsgeschwindigkeit der Zweck ist. Drittens die 20-Stunden-Ausnahme: Wenn das Zeitlimit länger als 20 Stunden ist, wird die Belastung für die Nutzenden als minimal angesehen, und Anpassungssteuerungen sind nicht erforderlich.

Ein Pass liegt vor, wenn eine zeitlich begrenzte Interaktion einen klaren Mechanismus bereitstellt – idealerweise bevor das Limit erreicht wird –, der es der Nutzerin oder dem Nutzer ermöglicht, die Zeitbeschränkung zu deaktivieren, zu verlängern oder anzupassen. Ein Fail liegt vor, wenn Inhalte automatisch ablaufen, weiterleiten, die Nutzerin oder den Nutzer abmelden oder fortfahren, ohne eine der drei oben genannten Anpassungsoptionen anzubieten, und keine der drei Ausnahmen zutrifft.

Warum es wichtig ist

Zeitlimits betreffen Menschen mit Behinderungen überproportional stark. Nutzende, die auf Screenreader angewiesen sind, navigieren Seiten oft langsamer als sehende Nutzende, weil sie Inhalte linear anhören und unbekannte Oberflächen schrittweise erkunden müssen. Nutzende mit motorischen Beeinträchtigungen – einschließlich Personen, die Schaltersteuerungen, Blickverfolgungssoftware, Mundstäbe oder Spracherkennungssoftware verwenden – benötigen möglicherweise deutlich länger, um ein Formularfeld auszufüllen, einen Kauf zu bestätigen oder zum nächsten Schritt zu navigieren. Nutzende mit kognitiven oder Lernbeeinträchtigungen, einschließlich Legasthenie, Aufmerksamkeitsstörungen oder Gedächtnisbeeinträchtigungen, benötigen möglicherweise zusätzliche Zeit, um Anweisungen zu lesen, zu verstehen und darauf zu reagieren. Ältere Erwachsene benötigen ebenfalls häufig mehr Zeit für dieselben Aufgaben und stellen einen schnell wachsenden Anteil der weltweiten Internetbevölkerung dar.

Betrachten Sie ein konkretes Szenario aus der Praxis: Eine Person mit Zerebralparese schließt eine Flugbuchung auf der Website einer türkischen Fluggesellschaft ab. Die Checkout-Sitzung läuft nach fünf Minuten Inaktivität automatisch ab. Die Nutzerin oder der Nutzer, die oder der langsam mit einem Kopfzeigergerät tippt, hat ihren oder seinen Namen, die Passnummer und Zahlungsdaten eingegeben – und dann lädt die Seite neu, löscht alle Daten und führt zurück zur Startseite. Nicht nur ist der gesamte Aufwand verloren, auch das Vertrauen in die Website ist erschüttert, und die Person ist möglicherweise überhaupt nicht in der Lage, den Kauf abzuschließen. Dies ist eine direkte Barriere für die gleichberechtigte Teilhabe am digitalen Handel.

Die Auswirkungen gehen über einzelne Nutzende hinaus. Laut der Weltgesundheitsorganisation leben weltweit etwa 1,3 Milliarden Menschen mit einer Form einer erheblichen Behinderung. Allein in der Türkei weisen offizielle Statistiken von TÜİK darauf hin, dass über 8,5 Millionen Menschen eine Behinderung haben, die sich auf alltägliche Aktivitäten auswirkt. Zeitlich begrenzte Oberflächen schließen einen messbaren Teil der potenziellen Nutzerschaft jeder Webanwendung aus.

Über die Barrierefreiheit hinaus kommt die Entfernung willkürlicher Zeitlimits oder deren Anpassbarkeit auch Nutzenden in Umgebungen mit geringer Bandbreite zugute, Nutzenden mit vorübergehend eingeschränkter Motorik (z. B. ein gebrochener Arm) und Nutzenden, die während einer Aufgabe einfach unterbrochen werden. Die Verbesserungen der Gebrauchstauglichkeit sind umfassend und können die Abbruchrate bei Formularen senken, die Konversionsraten auf E-Commerce-Seiten erhöhen und das Volumen beim Kundensupport verringern.

Verwandte Axe-core-Regeln

WCAG 2.2.1 erfordert manuelle Tests. Automatisierte Werkzeuge – einschließlich axe-core, Lighthouse und ähnlicher Engines – können Zeitüberschreitungsverstöße nicht zuverlässig erkennen, weil Zeitlimits häufig in serverseitiger Sitzungslogik, asynchron ausgeführtem JavaScript oder Drittanbieter-Integrationen implementiert sind. Das Werkzeug hat keine Möglichkeit festzustellen, dass eine Seite in fünf Minuten ablaufen wird oder dass ein Karussell ohne Nutzereingabe weiterläuft, nur durch Inspektion des DOM oder statische Analyse. Die folgenden Überlegungen erklären, was Prüferinnen und Prüfer manuell bewerten müssen.

• Sitzungs-Timeouts (manuell): Prüferinnen und Prüfer müssen auf eine Sitzungszeitüberschreitung warten oder sie simulieren, um festzustellen, ob die Seite eine Vorwarnung anzeigt, eine Verlängerungsoption anbietet und mindestens 20 Sekunden für die Reaktion der Nutzenden bereitstellt. Keine automatisierte Regel kann die Sitzungsdauer oder das rechtzeitige Erscheinen eines Warndialogs bestimmen, ohne tatsächlich die Zeitüberschreitung abzuwarten.
• Automatisch weiterlaufende Karussells und Slider (manuell): Prüferinnen und Prüfer müssen beobachten, ob Karussells automatisch weiterlaufen und, falls ja, ob eine Pause- oder Stopp-Steuerung vorhanden und per Tastatur erreichbar ist. Axe-core kann einige fehlende ARIA-Attribute an Karussellkomponenten erkennen, aber nicht feststellen, ob die zeitgesteuerte Weiterführung selbst anpassbar ist.
• Automatisch absendende oder automatisch geleerte Formulare (manuell): Wenn ein Formular nach einer Phase der Inaktivität abgesendet oder geleert wird, muss eine Prüferin oder ein Prüfer dieses Verhalten durch Beobachtung oder Code-Review identifizieren. Das DOM allein offenbart dieses Verhalten einem automatisierten Scanner nicht.
• Countdown-Timer in transaktionalen Abläufen (manuell): Checkout-Seiten, Ticketbuchungsabläufe und Prüfungsumgebungen enthalten häufig Countdown-Timer. Ob diese Timer wesentlich sind (und damit ausgenommen) oder ob sie einen Verlängerungsmechanismus erfordern, ist eine Ermessensfrage, die eine menschliche Prüfung sowohl der Implementierung als auch des geschäftlichen Kontexts erfordert.

Wie man testet

1. Automatisierter Scan als Basis: Führen Sie axe DevTools oder Lighthouse auf der Seite aus, um bekannte ARIA- oder Interaktionsverletzungen zu identifizieren, die Zeitprobleme verstärken könnten. Beachten Sie, dass diese Werkzeuge das Zeitlimit selbst nicht kennzeichnen, aber helfen, eine Basis anderer Barrierefreiheitsprobleme zu ermitteln. Öffnen Sie in den Chrome DevTools das Lighthouse-Panel, wählen Sie Accessibility und führen Sie den Audit aus. Aktivieren Sie in axe DevTools die Browsererweiterung, klicken Sie auf Analyze und prüfen Sie die Ergebnisse – es wird keine zeitbezogene Regel erscheinen, was bestätigt, dass manuelle Tests erforderlich sind.
2. Alle Zeitlimits identifizieren: Prüfen Sie den JavaScript-Quellcode der Seite, Netzwerkanfragen und die serverseitige Sitzungs-Konfiguration, um jedes Zeitlimit zu identifizieren. Häufige Stellen sind setTimeout- und setInterval-Aufrufe in JavaScript, Einstellungen zur Sitzungsablaufzeit in Backend-Frameworks, Cookie-Ablaufwerte und Konfigurationen von Drittanbieter-Widgets wie Zahlungsdienstleister oder Chat-Widgets.
3. Sitzungs-Timeout-Warnung mit NVDA + Firefox testen: Öffnen Sie die Website in Firefox mit laufendem NVDA. Navigieren Sie durch ein mehrstufiges Formular oder einen authentifizierten Bereich. Warten Sie auf den Sitzungswarn-Dialog (oder auf das Timeout selbst, falls keine Warnung erscheint). Vergewissern Sie sich, dass NVDA die Warnung automatisch ankündigt – idealerweise über eine Live-Region – und dass die Nutzerin oder der Nutzer die Sitzung verlängern kann, indem sie oder er Enter oder Leertaste auf einer fokussierten Schaltfläche drückt, ohne Formulardaten zu verlieren.
4. Sitzungs-Timeout-Warnung mit VoiceOver + Safari (macOS/iOS) testen: Wiederholen Sie den obigen Test in Safari mit aktiviertem VoiceOver. Verwenden Sie den Rotor, um zu interaktiven Elementen zu navigieren, und bestätigen Sie, dass die Timeout-Warnung angekündigt wird und dass die Verlängerungssteuerung innerhalb des 20-Sekunden-Fensters erreichbar ist.
5. Sitzungs-Timeout-Warnung mit JAWS + Chrome testen: Wiederholen Sie den Test mit JAWS in Chrome. Bestätigen Sie, dass der Fokus auf den Warndialog verschoben wird, dass JAWS die verbleibende Zeit und die Verlängerungsoption vorliest und dass das Aktivieren der Verlängerungsschaltfläche die Sitzung aufrechterhält, ohne dass ein Neuladen der Seite erforderlich ist.
6. Nur mit Tastatur testen (ohne Screenreader): Deaktivieren Sie Ihre Maus und navigieren Sie ausschließlich mit Tab, Shift+Tab, Enter und Leertaste. Bestätigen Sie, dass jeder Warndialog per Tastatur erreichbar ist, dass die Verlängerungsschaltfläche fokussierbar ist und dass der Fokus nach der Verlängerung der Sitzung an die richtige Stelle im Formular zurückkehrt.
7. Karussell- und Medien-Timing testen: Identifizieren Sie alle automatisch weiterlaufenden Karussells. Navigieren Sie mit Tab zum Karussell. Vergewissern Sie sich, dass eine Pause- oder Stopp-Schaltfläche vorhanden und ohne Maus erreichbar ist. Aktivieren Sie sie und bestätigen Sie, dass das automatische Weiterlaufen stoppt. Wenn das Karussell nach einer Nutzungsinteraktion wieder startet, bestätigen Sie, dass es nicht automatisch wieder anläuft.
8. Anwendbarkeit von Ausnahmen prüfen: Bestimmen Sie für jedes gefundene Zeitlimit, ob die Echtzeit-, essentielle oder 20-Stunden-Ausnahme zutrifft. Dokumentieren Sie Ihre Begründung. Wenn keine der Ausnahmen zutrifft und kein Anpassungsmechanismus existiert, vermerken Sie dies als Verstoß gegen WCAG 2.2.1.

Wie man es behebt

Sitzungs-Timeout ohne Warnung – falsch

<!-- Session expires silently after 5 minutes; page reloads with no warning -->
<script>
  setTimeout(function() {
    window.location.href = '/session-expired';
  }, 300000);
</script>

Sitzungs-Timeout mit Warnung und Verlängerung – korrekt

<!-- Warn user 60 seconds before expiry; offer extension; announce via live region -->
<div
  id='session-warning'
  role='alertdialog'
  aria-modal='true'
  aria-labelledby='warning-title'
  aria-describedby='warning-desc'
  hidden
>
  <h2 id='warning-title'>Your session is about to expire</h2>
  <p id='warning-desc'>
    Your session will expire in <span id='countdown'>60</span> seconds.
    Select "Stay logged in" to continue your session.
  </p>
  <button id='extend-btn' type='button'>Stay logged in</button>
  <button id='logout-btn' type='button'>Log out now</button>
</div>

<script>
  var SESSION_DURATION = 300000; // 5 minutes
  var WARNING_BEFORE   = 60000;  // warn 60 seconds before
  var sessionTimer, warningTimer, countdownInterval;

  function startSessionTimer() {
    warningTimer = setTimeout(showWarning, SESSION_DURATION - WARNING_BEFORE);
    sessionTimer = setTimeout(expireSession, SESSION_DURATION);
  }

  function showWarning() {
    var dialog = document.getElementById('session-warning');
    dialog.hidden = false;
    document.getElementById('extend-btn').focus(); // move focus to dialog
    var seconds = 60;
    countdownInterval = setInterval(function() {
      seconds--;
      document.getElementById('countdown').textContent = seconds;
      if (seconds <= 0) clearInterval(countdownInterval);
    }, 1000);
  }

  function extendSession() {
    clearTimeout(sessionTimer);
    clearTimeout(warningTimer);
    clearInterval(countdownInterval);
    document.getElementById('session-warning').hidden = true;
    startSessionTimer();
    // Return focus to last active element
  }

  function expireSession() {
    window.location.href = '/session-expired';
  }

  document.getElementById('extend-btn').addEventListener('click', extendSession);
  document.getElementById('logout-btn').addEventListener('click', expireSession);
  startSessionTimer();
</script>

Automatisch weiterlaufendes Karussell ohne Steuerung – falsch

<!-- Slides advance every 4 seconds; no pause control; no keyboard access -->
<div class='carousel'>
  <div class='slide active'>Slide 1 content</div>
  <div class='slide'>Slide 2 content</div>
  <div class='slide'>Slide 3 content</div>
</div>

Automatisch weiterlaufendes Karussell mit Pause-Steuerung – korrekt

<!-- Pause button stops auto-advance; button label updates to reflect state -->
<section aria-roledescription='carousel' aria-label='Featured announcements'>
  <div aria-live='off' aria-atomic='true'>
    <div class='slide active' role='group' aria-roledescription='slide' aria-label='Slide 1 of 3'>
      Slide 1 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 2 of 3'>
      Slide 2 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 3 of 3'>
      Slide 3 content
    </div>
  </div>
  <button id='carousel-pause' type='button' aria-pressed='false'>
    Pause slideshow
  </button>
</section>

<script>
  var paused = false;
  var btn = document.getElementById('carousel-pause');
  btn.addEventListener('click', function() {
    paused = !paused;
    btn.setAttribute('aria-pressed', paused.toString());
    btn.textContent = paused ? 'Play slideshow' : 'Pause slideshow';
    // toggle the carousel's auto-advance logic accordingly
  });
</script>

Zeitgesteuerter Checkout-Countdown ohne Verlängerung – falsch

<!-- 10-minute checkout lock; no extension offered; not an essential exception -->
<p>Your items are reserved for: <span id='timer'>10:00</span></p>
<!-- Timer expires, cart is cleared silently -->

Zeitgesteuerter Checkout-Countdown mit Verlängerungsoption – korrekt

<!-- Warn before expiry and offer a one-click extension -->
<p>
  Your items are reserved for:
  <span id='timer' aria-live='polite' aria-atomic='true'>10:00</span>
</p>
<div id='extend-notice' hidden role='alert'>
  <p>Your reservation expires in 2 minutes.</p>
  <button type='button' id='extend-checkout'>Give me more time</button>
</div>
<!--
  When timer reaches 2:00, reveal #extend-notice.
  Clicking the button resets the reservation timer via an API call.
  aria-live='alert' ensures screen readers announce the warning immediately.
-->

Häufige Fehler

• Anzeigen einer Timeout-Warnung ohne Tastaturfokus-Verwaltung: Der Warndialog erscheint visuell, aber der Fokus wird nie auf ihn verschoben, sodass Tastaturnutzende und Screenreader-Nutzende nie entdecken, dass sie die Sitzung verlängern können, bevor sie abläuft.
• Weniger als 20 Sekunden Reaktionszeit auf eine Timeout-Warnung bereitstellen: Eine „Session expiring“-Warnung, die nur 10 Sekunden vor der Abmeldung angezeigt wird, erfüllt das Kriterium nicht, das mindestens 20 Sekunden für die Verlängerungsaktion verlangt.
• Verwendung von role='alert' für einen Timeout-Dialog, der eine Interaktion erfordert: Die Rolle alert ist für rein lesende Ankündigungen gedacht; ein Dialog, der eine Nutzereingabe erfordert, sollte role='alertdialog' mit aria-modal='true' und aria-labelledby verwenden, damit Screenreader ihn als modalen Dialog behandeln, der eine Reaktion erfordert.
• Unberechtigter Verweis auf die essentielle Ausnahme für einen Standard-E-Commerce-Warenkorbtimer: Das Reservieren von Artikeln in einem Warenkorb für 10 Minuten ist eine geschäftliche Bequemlichkeit, keine wirklich essentielle Aktivität, bei der die Messung der Geschwindigkeit der Zweck ist. Die Anwendung der essentiellen Ausnahme ist hier falsch; ein Verlängerungsmechanismus ist erforderlich.
• Automatisches Weiterlaufen eines Karussells ohne sichtbare, per Tastatur erreichbare Pause-Schaltfläche: Eine Pause-Schaltfläche, die nur bei Hover sichtbar ist oder nicht in der Tab-Reihenfolge erscheint, erfüllt das Kriterium nicht. Die Steuerung muss ohne Zeigegerät erreichbar sein.
• Zurücksetzen des Timeout-Zählers bei Mausbewegung, aber nicht bei Tastaturereignissen: JavaScript, das den Inaktivitäts-Timer bei mousemove-Ereignissen verlängert, aber keydown- oder focus-Ereignisse ignoriert, lässt Sitzungen für reine Tastaturnutzende unbemerkt ablaufen, obwohl sie aktiv auf der Seite arbeiten.
• Verlängerung der Sitzung über ein vollständiges Neuladen der Seite: Wenn eine Nutzerin oder ein Nutzer auf „Stay logged in“ klickt, löscht ein Neuladen der Seite alle Daten, die in Formulare eingegeben wurden. Die Verlängerung sollte über einen API-Aufruf oder eine Cookie-Aktualisierung im Hintergrund erfolgen, sodass der DOM-Zustand erhalten bleibt.
• Verwendung von setTimeout-Werten, die nicht konfigurierbar oder für die Nutzenden zugänglich sind: Das Hardcodieren einer Sitzungsdauer von fünf Minuten ohne UI-Steuerung, mit der die Nutzenden eine längere Dauer wählen können, verstößt gegen das Kriterium, sofern nicht einer der drei Anpassungsmechanismen (deaktivieren, anpassen oder verlängern) verfügbar ist.
• Unterlassen von Tests des Timeout-Ablaufs mit tatsächlichen Hilfstechnologien vor dem Launch: Entwickelnde, die nur mit der Maus testen, bemerken möglicherweise nicht, dass der Warndialog für Screenreader-Nutzende unzugänglich ist, weil visuelle Tests Probleme beim Fokusmanagement nicht offenlegen.
• Annahme, dass eingebettete Drittanbieter-Widgets automatisch konform sind: Zahlungsdienstleister, Live-Chat-Widgets und Buchungs-Engines, die über iframes oder Skripte eingebettet sind, erzwingen häufig eigene Zeitlimits. Die Verantwortung für die WCAG-Konformität der gesamten Seite – einschließlich eingebetteter Inhalte, die Sie steuern – liegt bei der Seitenbetreiberin oder dem Seitenbetreiber.

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 an WCAG 2.2 Level AA ausgerichtet sind, und zwar für eine breite Palette öffentlicher und privater Einrichtungen, die digitale Dienste in der Türkei betreiben. WCAG 2.2.1 Timing Adjustable ist ein Kriterium der Stufe A, was bedeutet, dass es zur grundlegenden Ebene der Konformität gehört – es zählt zu den ersten Anforderungen, die betroffene Einrichtungen erfüllen müssen.

Nach der Verfügung sind öffentliche Institutionen und Behörden – einschließlich Ministerien, Gemeinden, Universitäten und staatseigene Unternehmen – verpflichtet, innerhalb eines Jahres nach Veröffentlichung der Verfügung vollständige Konformität zu erreichen. Private Sektorunternehmen, die von der Regelung erfasst sind, haben ein zweijähriges Zeitfenster zur Einhaltung. Der Geltungsbereich für den privaten Sektor ist ausdrücklich breit: Er umfasst E-Commerce-Plattformen, Banken und Finanzinstitute, private Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnentinnen und Abonnenten, Reisebüros, private Personenverkehrsunternehmen und Privatschulen, die unter einer Genehmigung des Ministry of National Education (MoNE) betrieben werden.

Für Organisationen in diesen Kategorien ist ein Verstoß gegen WCAG 2.2.1 nicht nur ein Versäumnis von Best Practices – er stellt eine rechtliche Nichtkonformität dar, die behördliche Prüfungen, Beschwerden über offizielle Kanäle und Reputationsschäden nach sich ziehen kann. Betrachten Sie die spezifischen Geschäftsabläufe, bei denen dieser Verstoß am ehesten auftritt: ein E-Commerce-Checkout mit zeitgesteuerter Warenkorb-Reservierung, eine Online-Banking-Sitzung, die stillschweigend abläuft, während eine Kundin oder ein Kunde ein Zahlungsformular ausfüllt, ein Krankenhaus-Terminvergabesystem, das abläuft, bevor eine Person mit motorischer Beeinträchtigung ihre Registrierung abschließen kann, oder ein Self-Service-Portal eines Telekommunikationsanbieters, das Nutzende automatisch aus einem Vertragsverwaltungsablauf abmeldet. Jeder dieser Fälle ist ein plausibles Fehlerszenario innerhalb eines in der Verfügung ausdrücklich genannten Einrichtungstyps.

Organisationen sollten die Einhaltung von WCAG 2.2.1 nicht als technische Checkliste behandeln, sondern als Designanforderung, die auf Architekturebene adressiert werden muss – in Richtlinien zum Sitzungsmanagement, Anforderungen an die Beschaffung von Drittanbieter-Widgets und Standards für UI-Komponenten – statt nachträglich als Zusatzlösung. Prüfprogramme sollten manuelle Tests aller zeitgesteuerten Interaktionen einschließen, nicht nur automatisierte Scans, gerade weil automatisierte Werkzeuge diese Art von Verstößen ohne menschliche Beobachtung nicht erkennen können.