WCAG 2.2.3: Keine Zeitvorgaben

WCAG 2.2.3 (Level AAA) verlangt, dass Zeitvorgaben kein wesentlicher Bestandteil des durch Inhalte dargestellten Ereignisses oder der Aktivität sind, mit Ausnahme von nicht-interaktiven synchronisierten Medien und Echtzeitereignissen. Dies stellt sicher, dass Nutzer mit Behinderungen, die mehr Zeit zum Lesen, Interagieren oder Reagieren benötigen, niemals durch zeitabhängiges Design ausgeschlossen werden.

Was diese Regel bedeutet

WCAG 2.2.3 — No Timing befindet sich auf der Konformitätsstufe AAA unter Richtlinie 2.2: Enough Time. Ihre Anforderung ist eindeutig: Zeit darf kein wesentlicher Bestandteil eines Ereignisses oder einer Aktivität sein, die dem Nutzer präsentiert wird. Anders ausgedrückt: Wenn Ihre Inhalte oder Funktionen ein Zeitlimit, eine Frist oder irgendeine Art zeitkritischer Interaktion beinhalten, muss diese Zeitabhängigkeit entweder entfernbar sein oder für die jeweilige Aufgabe völlig irrelevant — es sei denn, eine der engen Ausnahmen greift.

Dieses Kriterium geht über das Kriterium der Stufe A 2.2.1 (Timing Adjustable) und das Kriterium der Stufe AA 2.2.2 (Pause, Stop, Hide) hinaus. Während diese früheren Kriterien anpassbare oder pausierbare Zeitlimits zulassen, verlangt 2.2.3, dass Zeit überhaupt nicht als sinnvolle Einschränkung existiert. Ein Nutzer, der zehn Sekunden oder zehn Minuten benötigt, um ein Formular auszufüllen, ein Menü zu navigieren oder einen Workflow abzuschließen, muss zum gleichen Ergebnis gelangen wie ein Nutzer, der sofort fertig ist.

Was als bestanden gilt: Inhalte, bei denen kein Zeitlimit existiert oder bei denen ein vorhandenes Zeitlimit rein kosmetischer Natur ist und keinen Einfluss auf das Ergebnis hat (zum Beispiel eine Animation, die in einer Schleife läuft, aber die Interaktion nicht verhindert). Inhalte, die vollständig funktionsfähig sind, unabhängig davon, wie lange der Nutzer benötigt, bestehen dieses Kriterium.

Was als nicht bestanden gilt: Sitzungstimeouts, die Nutzer nach Inaktivität abmelden; zeitgesteuerte Quizze oder Tests, bei denen die Punktzahl oder der Abschluss davon abhängt, innerhalb eines Zeitfensters fertig zu werden; Ablauf-Timer im Warenkorb, die Artikel löschen; Auktionsoberflächen mit Countdown-Uhren, die das Bieten schließen; Einmalpasswort-(OTP-)Felder, die ablaufen; CAPTCHA-Herausforderungen mit Zeitlimits; und jedes interaktive Element, das aufgrund verstrichener Zeit nicht mehr verfügbar ist oder automatisch absendet.

Offizielle Ausnahmen laut WCAG: Das Kriterium nimmt ausdrücklich zwei Kategorien aus. Erstens Echtzeit-Ausnahmen — Ereignisse, bei denen Zeit absolut inhärent für die Aktivität ist, wie eine Live-Auktion, eine Live-Übertragung oder ein Echtzeit-Multiplayer-Spiel. Zweitens essentielle Ausnahmen — Situationen, in denen das Entfernen des Zeitlimits die Aktivität grundlegend verändern würde. Ein Schreibmaschinentest zur Messung der Tippgeschwindigkeit misst zum Beispiel inhärent Geschwindigkeit, daher ist Zeit wesentlich. Entwickler und Produktverantwortliche müssen hier streng sein: Bequemlichkeit, technische Altlasten oder geschäftliche Präferenzen qualifizieren sich nicht als „wesentlich“. Maßstab ist, ob die Aktivität ohne Zeitbeschränkung ihre Kernbedeutung oder ihren Zweck verlieren würde.

Wichtig ist auch, dass synchronisierte Medien — etwa ein voraufgezeichnetes Video mit Untertiteln — ausgeschlossen sind, da die Zeitsteuerung der Medienwiedergabe durch den Mediaplayer des Nutzers erfolgt und keine Einschränkung für die Fähigkeit des Nutzers darstellt, mit dem Rest der Seite zu interagieren.

Warum das wichtig ist

Zeitlimits im Web schaden Nutzern mit einer breiten Palette von Behinderungen überproportional. Die Auswirkungen sind nicht abstrakt — für viele Nutzer ist eine zeitgesteuerte Oberfläche faktisch unzugänglich.

Nutzer mit motorischen Beeinträchtigungen — einschließlich derjenigen, die Schaltersteuerungen, Mundstäbe, Blickverfolgungssoftware oder andere alternative Eingabemethoden verwenden — arbeiten grundsätzlich in einem anderen Tempo als Maus-und-Tastatur-Nutzer. Das Ausfüllen eines mehrstufigen Formulars oder das Navigieren in einem Dropdown-Menü kann um ein Vielfaches länger dauern. Ein Sitzungstimeout oder ein automatisch ablaufender Warenkorb kann Minuten sorgfältiger, mühsamer Arbeit in einem Augenblick zunichtemachen.

Nutzer mit kognitiven Beeinträchtigungen, einschließlich Legasthenie, ADHS, Verarbeitungsstörungen und erworbenen Hirnverletzungen, benötigen möglicherweise deutlich mehr Zeit, um Anweisungen zu lesen, Optionen zu verstehen oder Antworten zu formulieren. Forschung, die von der Web Accessibility Initiative zusammengetragen wurde, schätzt, dass kognitive und Lernbehinderungen in irgendeiner Form etwa 15–20% der Weltbevölkerung betreffen. Für diese Nutzer ist ein Countdown-Timer nicht nur stressig — er beeinträchtigt aktiv die kognitive Verarbeitung, die zur Erledigung der Aufgabe nötig ist.

Screenreader-Nutzer, die blind oder sehbehindert sind, navigieren Inhalte linear und müssen sich Schnittstellenelemente nacheinander anhören oder durchlesen. Das Verständnis der Struktur und der Optionen auf einer komplexen Seite benötigt mehr Zeit als das visuelle Überfliegen durch sehende Nutzer. Ein zeitgesteuerter Checkout-Prozess, der abläuft, während ein blinder Nutzer sorgfältig seine Bestellübersicht prüft, ist eine direkte Barriere für den Handel.

Nutzer mit Angststörungen können feststellen, dass allein die Präsenz eines Countdowns eine so hohe kognitive und emotionale Belastung erzeugt, dass die Aufgabenerledigung verhindert wird, selbst wenn sie technisch genug Zeit hätten. Das Entfernen von Zeit als Faktor beseitigt diese Barriere vollständig.

Ein konkretes Szenario aus der Praxis: Betrachten Sie ein Online-Banking-Portal, das ein fünfminütiges Inaktivitäts-Timeout mit einem OTP kombiniert, das nach sechzig Sekunden abläuft. Ein Nutzer mit Parkinson, der unterstützende Eingabetechnologie zum Tippen benötigt, oder eine ältere Person, die nicht daran gewöhnt ist, schnell zwischen Apps zu wechseln, kann es physisch unmöglich finden, die SMS zu empfangen, die Anwendung zu wechseln, den Code zu lesen, zurückzuwechseln und ihn innerhalb des vorgegebenen Zeitfensters einzugeben. Sie werden aus ihrem eigenen Konto ausgesperrt — nicht aus Sicherheitsnotwendigkeit, sondern durch eine willkürliche Zeitbeschränkung. Wird das OTP so gestaltet, dass es über einen längeren Zeitraum gültig bleibt (oder wird das harte Ablaufdatum zugunsten eines erneuten Sende-Mechanismus entfernt), wird das Problem gelöst, ohne die Sicherheit zu beeinträchtigen.

Über die Barrierefreiheit hinaus verbessert das Entfernen unnötiger Zeitbeschränkungen die allgemeine Nutzbarkeit und reduziert Abbruchraten. Ein E-Commerce-Checkout, der nicht mitten im Prozess abläuft, hält mehr Kundschaft, erhöht die Conversion und reduziert den Supportaufwand — und macht dies zu einer geschäftlich positiven Änderung ebenso wie zu einer ethischen Verpflichtung.

Wie man testet

Automatisierter Basisscan: Führen Sie axe DevTools oder Lighthouse auf der Seite aus, um etwaige verwandte Timing-Verstöße auf niedrigerer Ebene zu identifizieren (wie diejenigen, die von 2.2.1 oder 2.2.2 abgedeckt werden), die Sie auf Bereiche hinweisen können, die eine tiefere manuelle Prüfung erfordern. Obwohl keine axe-Regel 2.2.3 direkt testet, können Erkenntnisse zu Zeitlimit-Warnungen oder Auto-Refresh Ihre manuelle Prüfungsreichweite leiten. Überprüfen Sie in Lighthouse den Abschnitt „Accessibility“ auf zeitbezogene Hinweise.
Inventarisierung aller zeitabhängigen Funktionen: Erfassen Sie vor dem Testen systematisch jede Funktion in der Anwendung, die Timing beinhalten könnte. Dazu gehören: Sitzungsmanagement und Inaktivitäts-Timeouts; OTP- und Verifizierungscode-Felder; Warenkorb- oder Reservierungs-Reservierungen; zeitgesteuerte Quizze, Tests oder Umfragen; Auktions- oder Bietoberflächen; CAPTCHA-Herausforderungen; Auto-Save-Mechanismen mit Abgabefenstern; und alle sichtbaren Countdowns oder Fortschritts-Timer.
Test des Sitzungstimeout-Verhaltens: Öffnen Sie die Anwendung und beginnen Sie eine Aufgabe, die mehrere Schritte umfasst (zum Beispiel das Ausfüllen eines mehrseitigen Formulars oder das Abschließen eines Checkouts). Interagieren Sie nicht über einen Zeitraum, der das vermutete Timeout-Fenster überschreitet. Versuchen Sie dann fortzufahren. Beobachten Sie, ob Ihr Fortschritt erhalten bleibt, ob Sie gewarnt werden und die Möglichkeit erhalten, Ihre Sitzung zu verlängern, oder ob Sie abgemeldet werden oder Daten verlieren. Ein Bestehen erfordert, dass entweder kein Timeout existiert, das Timeout rein vorsorglich ist und Daten bei erneuter Authentifizierung erhalten bleiben, oder dass der Nutzer angemessen gewarnt wird und Kontrolle erhält.
Test des OTP- und Code-Ablaufs: Lösen Sie einen OTP- oder Verifizierungscode-Flow aus. Warten Sie bis nach der angegebenen Ablaufzeit des Codes (oder länger, wenn keine Zeit angezeigt wird). Versuchen Sie, den Code einzugeben. Wenn das System ihn ausschließlich aufgrund der Zeit zurückweist, ist dies ein Verstoß gegen 2.2.3. Hinweis: Ein „Erneut senden“-Mechanismus allein behebt 2.2.3 nicht — das ursprüngliche Code-Ablaufdatum erzwingt weiterhin Timing.
Screenreader-Tests (NVDA + Firefox): Navigieren Sie mit NVDA und Firefox durch jede zeitgesteuerte Oberfläche ausschließlich mit Tastatur und Screenreader. Notieren Sie, wie lange jeder Schritt mit dem Navigations-Overhead der unterstützenden Technologie dauert. Gehen Sie bewusst langsam vor — pausieren Sie, um alle Anweisungen anzuhören, erkunden Sie alle Optionen mit dem virtuellen Cursor — und versuchen Sie dann, abzusenden oder fortzufahren. Verifizieren Sie, dass langsame Navigation kein Timeout oder einen Zustandsverlust auslöst.
Screenreader-Tests (VoiceOver + Safari auf macOS): Wiederholen Sie denselben Langsam-Navigationstest mit VoiceOver auf macOS und Safari. Achten Sie besonders auf dynamische Countdown-Timer: Kündigt VoiceOver die verbleibende Zeit auf eine Weise an, die Dringlichkeit erzeugt, und schlägt die Oberfläche fehl, wenn die Zeit abläuft?
Screenreader-Tests (JAWS + Chrome): Testen Sie dieselben Abläufe mit JAWS und Chrome. JAWS-Nutzer stellen einen bedeutenden Anteil der professionellen Screenreader-Nutzer dar; Timing-Probleme, die NVDA-Nutzer betreffen, werden in der Regel JAWS-Nutzer gleichermaßen betreffen.
Überprüfung der Legitimität von Ausnahmen: Dokumentieren Sie für jedes Timing, das das Entwicklungsteam als „wesentlich“ oder „Echtzeit“ bezeichnet, die Begründung und bewerten Sie, ob das Timing wirklich inhärent zum Zweck der Aktivität gehört oder ob es gelockert, verlängert oder entfernt werden könnte, ohne die grundlegende Natur der Aufgabe zu verändern.

Wie man behebt

Sitzungstimeout — Falsch

<!-- Session expires after 5 minutes of inactivity with no warning.
     User data is lost and they are redirected to login. -->
<script>
  setTimeout(function() {
    window.location.href = '/logout?reason=timeout';
  }, 300000);
</script>

Sitzungstimeout — Richtig

<!-- No automatic session expiry on inactivity.
     Server session is maintained as long as the browser tab is open.
     If a timeout is legally required (e.g. banking regulation),
     warn the user well in advance and offer to extend the session
     without time pressure on the extension dialog itself. -->
<div role='dialog' aria-modal='true' aria-labelledby='session-dialog-title' aria-describedby='session-dialog-desc' id='session-warning' hidden>
  <h2 id='session-dialog-title'>Your session is about to expire</h2>
  <p id='session-dialog-desc'>For your security, your session will expire due to inactivity. Would you like to stay signed in?</p>
  <button type='button' id='extend-session'>Stay signed in</button>
  <button type='button' id='end-session'>Sign out now</button>
</div>
<!-- The "Stay signed in" button itself has no expiry —
     the user can take as long as they need to find and activate it. -->

Ablaufendes OTP-Feld — Falsch

<!-- OTP expires in 60 seconds. After expiry, form submission
     returns an error and the user must restart the entire flow. -->
<label for='otp'>Enter the code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p aria-live='assertive'>Code expires in: <span id='countdown'>60</span> seconds</p>
<button type='submit'>Verify</button>

Ablaufendes OTP-Feld — Richtig

<!-- OTP does not expire within a short user-facing window.
     A longer server-side validity period (e.g. 15-30 minutes) is used.
     A resend option is available but the original code remains valid.
     No countdown timer is shown, removing false urgency. -->
<label for='otp'>Enter the 6-digit code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p>The code is valid for 30 minutes. <button type='button' id='resend-otp'>Send a new code</button></p>
<button type='submit'>Verify</button>
<!-- Server invalidates the code after first successful use,
     not after a short time window. -->

Zeitgesteuertes Quiz — Falsch

<!-- Quiz auto-submits when the 10-minute timer reaches zero,
     regardless of whether the user has finished answering. -->
<div id='quiz-timer' aria-live='polite'>Time remaining: <span id='time-left'>10:00</span></div>
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>

Zeitgesteuertes Quiz — Richtig

<!-- Quiz has no time limit unless timing is the explicit
     subject being assessed (e.g. a certified speed test).
     If an optional time indicator is shown for user reference,
     it does not trigger auto-submission or penalise slow completion. -->
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>
<!-- If a time reference is genuinely needed, it is informational only:
<p>Most users complete this in about 10 minutes. Take as long as you need.</p> -->

Häufige Fehler

Die Annahme, dass Sitzungssicherheit ein hartes Timeout erfordert: Viele Teams implementieren kurze Inaktivitäts-Timeouts unter Verweis auf Sicherheitsanforderungen, aber die meisten Sicherheitsstandards (einschließlich PCI-DSS und OWASP) erlauben eine vom Nutzer gesteuerte Sitzungsverlängerung. Ein hartes Logout ohne Warnung oder Verlängerungsmöglichkeit ist ein Barrierefreiheitsproblem, keine Sicherheitsnotwendigkeit.
Anzeige eines Countdowns ohne Möglichkeit, ihn zu stoppen oder zu verlängern: Das Hinzufügen eines aria-live-Bereichs zu einem Countdown verschlimmert die Situation für Screenreader-Nutzer — jede Sekunde wird angesagt — ohne das zugrunde liegende Timing-Problem zu beheben. Die Lösung besteht darin, die Einschränkung zu entfernen, nicht darin, sie barrierefreier anzukündigen.
Die Behandlung von „Code erneut senden“ als Lösung für OTP-Ablauf: Das Bereitstellen eines Buttons zum erneuten Senden ermöglicht es Nutzern, einen neuen Code zu erhalten, behebt aber nicht die Tatsache, dass der ursprüngliche Code aufgrund von Timing abgelaufen ist. Das Zeitlimit ist weiterhin vorhanden. Die richtige Lösung besteht darin, das Gültigkeitsfenster zu verlängern, um den Zeitdruck zu beseitigen.
Automatisches Weiterblättern von Karussell- oder Assistentenschritten nach Inaktivität: Mehrstufige Formulare oder Assistenten, die nach einer festgelegten Zeit automatisch zum nächsten Schritt übergehen, erzwingen eine Zeitbeschränkung. Nutzer, die Anweisungen lesen oder über ihre Antwort nachdenken, werden benachteiligt. Schritte dürfen nur durch explizite Nutzeraktion voranschreiten.
Warenkorb-Timer, die Artikel löschen, ohne sie zu erhalten: Reservierungs-Timer im E-Commerce („Ihr Warenkorb läuft in 15 Minuten ab“) verstoßen gegen 2.2.3, wenn Artikel beim Ablauf dauerhaft verloren gehen, statt lediglich aus der Reservierung entlassen zu werden. Mindestens sollten Artikel in einer Wunschliste gespeichert oder die Sitzung wiederherstellbar sein.
Zu breite Anwendung der „Echtzeit-Ausnahme“: Eine Oberfläche als „Echtzeit“ zu bezeichnen, um Zeitbeschränkungen zu rechtfertigen, wenn sie nicht wirklich live ist. Eine voraufgezeichnete Auktionswiederholung, eine statische Bietoberfläche oder ein Quiz, das lediglich einer Spielshow ähnelt, qualifiziert sich nicht für die Echtzeit-Ausnahme.
Ignorieren von Timing in Back-End-API-Antworten: Teams beheben Frontend-Timer, übersehen aber, dass die API selbst Anfragen ablehnt, die nach einem bestimmten Zeitfenster gestellt werden. Der Nutzer sieht keinen Countdown, aber seine Übermittlung schlägt stillschweigend fehl. Back-End-Sitzungsmanagement muss mit der Frontend-Erfahrung übereinstimmen.
Verwendung von setTimeout für Auto-Logout ohne Persistierung des Formularzustands: Wenn ein automatisches Logout unvermeidbar ist (zum Beispiel aufgrund regulatorischer Anforderungen), führt das Versäumnis, die Formulardaten des Nutzers vor der Weiterleitung zu speichern, dazu, dass alle Arbeit verloren geht. Mindestens sollte ein Entwurf gespeichert und nach erneuter Authentifizierung wiederhergestellt werden.
Verwechslung von 2.2.1-Konformität mit 2.2.3-Konformität: Das Bereitstellen einer Steuerung zum „Ausschalten, Anpassen oder Verlängern“ (wie von 2.2.1 Stufe A gefordert) erfüllt 2.2.3 nicht. Stufe AAA verlangt, dass Timing nicht wesentlich ist — nicht nur handhabbar. Ein Zeitlimit mit großzügiger Verlängerung ist immer noch ein Zeitlimit.
Übersehen von Timing in eingebetteten Drittanbieter-Komponenten: Eingebettete Chat-Widgets, Zahlungsdienstleister, Identitätsverifizierungs-SDKs und Kartendienste können eigene Zeitbeschränkungen einführen. Der Drittanbieter-Ursprung befreit diese nicht von der Anwendbarkeit der WCAG, wenn sie in Ihre Oberfläche integriert sind.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, etabliert einen nationalen Rahmen für Web-Barrierefreiheit, der WCAG 2.2 als technische Grundlage heranzieht. Die Verfügung schreibt die Einhaltung für eine breite Palette von Einrichtungen vor, die digitale Dienste in der Türkei betreiben.

Zu den erfassten Einrichtungstypen gehören öffentliche Institutionen und Regierungsstellen, E-Commerce-Plattformen, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200,000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind. Diese Organisationen müssen die in der Verfügung definierten oder referenzierten Barrierefreiheitsstandards einhalten, wenn sie digitale Dienste für die Öffentlichkeit bereitstellen.

WCAG 2.2.3 — No Timing ist ein Kriterium der Stufe AAA, und die Präsidialverfügung 2025/10 verlangt, ähnlich wie die europäische Norm EN 301 549, die Konformität mit den Stufen A und AA als gesetzliches Minimum. Die Einhaltung der Stufe AAA ist in diesem Rahmen keine direkte gesetzliche Verpflichtung. Die Erreichung der Stufe AAA — und insbesondere die Umsetzung von 2.2.3 — wird jedoch als Kennzeichen einer Barrierefreiheit auf höchstem Niveau anerkannt und zeigt ein echtes Engagement für inklusives Design, das über die gesetzlichen Mindestanforderungen hinausgeht.

Für bestimmte erfasste Einrichtungstypen, insbesondere Banken und Finanzdienstleister unter Aufsicht der BDDK und E-Commerce-Plattformen mit hohem Transaktionsvolumen, sind Zeitbeschränkungen wie OTP-Ablauf, Sitzungsmanagement und Checkout-Timer allgegenwärtige Funktionen. Selbst wenn 2.2.3 rechtlich nicht vorgeschrieben ist, führt das Versäumnis, Zeitbarrieren in diesen Abläufen zu beseitigen, zu einem realen Diskriminierungsrisiko — insbesondere, wenn sich die Durchsetzungsmechanismen für Barrierefreiheit in der Türkei weiterentwickeln und Beschwerdeverfahren etablierter werden.

Öffentliche Institutionen und Gesundheitsdienstleister, die Menschen mit Behinderungen, ältere Menschen und Nutzer mit geringer digitaler Kompetenz bedienen, haben einen besonders starken ethischen Grund, Zeitbeschränkungen vollständig zu eliminieren. Die Entfernung von Zeitlimits aus digitalen Regierungsdiensten und Gesundheitsportalen steht im Einklang mit den breiteren E-Government-Inklusionszielen der Türkei und reduziert das Risiko zukünftiger regulatorischer Risiken, da die Einführung von AAA in der öffentlichen Beschaffung häufiger wird.

Organisationen, die ihre digitalen Produkte als vollständig inklusiv positionieren möchten — sei es für nationale Vorreiterrolle, internationalen Marktzugang oder Vorteile bei Ausschreibungen im Kontext der Europäischen Union (wo EN 301 549 und der European Accessibility Act gelten) — sollten die Einhaltung von WCAG 2.2.3 als strategische Investition und nicht als optionale Verbesserung betrachten.