WCAG 2.2.6: Zeitüberschreitungen

WCAG 2.2.6 verlangt, dass Nutzer vor Datenverlust durch Inaktivitäts-Timeouts gewarnt werden und dass ein solches Timeout mindestens 20 Stunden dauert, sofern die Daten nicht erhalten bleiben. Dies schützt Nutzer mit kognitiven Beeinträchtigungen, motorischen Einschränkungen und andere, die mehr Zeit benötigen, um Aufgaben zu erledigen.

Was diese Regel bedeutet

WCAG 2.2.6 Timeouts (Level AAA) verlangt, dass Nutzer über die Dauer jeder Inaktivität gewarnt werden, die zu Datenverlust führen könnte, es sei denn, die Daten werden für mehr als 20 Stunden Nutzerinaktivität erhalten. Praktisch bedeutet das: Wenn Ihre Webanwendung oder Ihr Dienst Daten eines Nutzers verlieren kann – etwa Formulareingaben, einen Warenkorb oder eine laufende Transaktion – weil der Nutzer für eine gewisse Zeit inaktiv war, müssen Sie die Nutzer genau darüber informieren, wie lange sie Zeit haben, bevor diese Daten verloren gehen.

Das Kriterium gilt für jede Situation, in der ein Timeout zu Datenverlust führt. Häufige Beispiele sind das Ablaufen von Sitzungen auf Bank- oder Regierungsportalen, bei dem Formulardaten gelöscht werden, Warenkörbe, die sich nach einer Phase der Inaktivität leeren, mehrstufige Assistenten oder Formulare, die zurückgesetzt werden, wenn ein Session-Cookie abläuft, sowie Online-Test- oder Buchungssysteme, die Teilantworten verwerfen. Der entscheidende Auslöser ist die Kombination aus Inaktivität (nicht eine feste Zeitbegrenzung für die Aufgabenerledigung, die durch 2.2.1 abgedeckt ist) und der Folge eines Datenverlusts.

Was als bestanden gilt: Eine Seite erfüllt 2.2.6, wenn sie Nutzer zu Beginn einer Sitzung – oder bevor sie mit der Dateneingabe beginnen – klar über die konkrete Dauer der Inaktivität informiert, die zu Datenverlust führt. Alternativ besteht eine Seite, wenn kein Datenverlust auftreten kann, unabhängig davon, wie lange der Nutzer inaktiv ist (zum Beispiel, weil der Server alle Formulardaten länger als 20 Stunden oder unbegrenzt speichert). Eine Warnung, die erst angezeigt wird, nachdem die Sitzung bereits abgelaufen ist, erfüllt das Kriterium nicht.

Was als nicht bestanden gilt: Eine Seite fällt durch, wenn sie Nutzerdaten nach einer Phase der Inaktivität stillschweigend verliert, ohne den Nutzer jemals über dieses Risiko zu informieren. Sie fällt ebenfalls durch, wenn es zwar eine Warnung gibt, diese aber erst im Moment des Datenverlusts angezeigt wird (zu spät, um zu handeln), oder wenn die Warnung vage ist – zum Beispiel, wenn sie sagt „Ihre Sitzung kann ablaufen“, ohne die tatsächliche Dauer der Inaktivität anzugeben, die das Timeout auslöst.

Offizielle Ausnahmen: Das Kriterium nimmt Situationen ausdrücklich aus, in denen Daten für mehr als 20 Stunden Inaktivität erhalten bleiben. Die Schwelle von 20 Stunden wurde gewählt, um Nutzer zu berücksichtigen, die eine Aufgabe an einem Tag beginnen und am nächsten fortsetzen. Wenn Ihr System alle eingegebenen Daten serverseitig zuverlässig für mindestens 20 Stunden speichert, ohne dass der Nutzer etwas tun muss, sind Sie nicht verpflichtet, eine Warnung anzuzeigen. Außerdem gilt dieses Kriterium nicht für Timeouts, die für die Sicherheit unerlässlich sind – zum Beispiel eine gesetzliche oder regulatorische Vorgabe, dass eine Sitzung nach einem festen Zeitraum unabhängig vom Nutzerverhalten beendet werden muss. In solchen Fällen empfiehlt das Kriterium zwar weiterhin eine Offenlegung, erkennt aber die rechtliche Einschränkung an.

Warum es wichtig ist

Timeouts ohne angemessene Warnung betreffen Menschen mit kognitiven Beeinträchtigungen, motorischen Einschränkungen sowie blinde und sehbehinderte Menschen überproportional stark. Nutzer mit kognitiven Beeinträchtigungen wie Dyslexie, ADHS oder traumatischer Hirnverletzung benötigen möglicherweise deutlich mehr Zeit, um Anweisungen zu lesen, Texte zu verfassen oder Informationen zu prüfen, bevor sie ein Formular absenden. Wenn eine Sitzung unbemerkt abläuft, während sie noch arbeiten, verlieren sie ihre gesamte Arbeit und müssen von vorne beginnen – eine zutiefst entmutigende Erfahrung, die dazu führen kann, dass sie die Aufgabe ganz aufgeben.

Menschen mit motorischen Behinderungen, die auf Schaltersteuerung, Blickverfolgungsgeräte oder andere alternative Eingabemethoden angewiesen sind, interagieren deutlich langsamer mit Oberflächen als Mausnutzer. Das Ausfüllen eines umfangreichen Schadensformulars oder eines mehrseitigen Antragsformulars einer Behörde kann für sie wesentlich länger dauern, als es der standardmäßige Session-Timeout annimmt. Ohne Kenntnis des Countdowns haben sie keine Möglichkeit zu handeln – etwa den Fortschritt zu speichern oder eine Verlängerung anzufordern –, bevor ihre Daten verschwinden.

Screenreader-Nutzer stehen ebenfalls vor einer verstärkten Herausforderung: Die Navigation durch komplexe Formulare dauert länger, wenn jedes Feld vorgelesen und per Tastatur bestätigt werden muss. Eine Sitzung, die abläuft, während ein Nutzer noch systematisch ein langes Formular bearbeitet, ist nicht nur unbequem – sie kann Stunden an Arbeit zunichtemachen und eine erhebliche Barriere beim Zugang zu wichtigen Diensten darstellen.

Betrachten Sie dieses Szenario aus der Praxis: Eine Nutzerin mit Multipler Sklerose beantragt eine Erwerbsminderungsleistung über ein Regierungsportal. Das Formular hat 12 Abschnitte und erfordert das Hochladen von Nachweisen. Die Sitzung läuft nach 15 Minuten Inaktivität ab, aber die Nutzerin hat in der Mitte von Abschnitt 7 pausiert, um ein Dokument aus einem anderen Raum zu holen. Bei ihrer Rückkehr wurden alle Daten gelöscht und sie muss von vorne beginnen – ohne vorherige Warnung, dass dies passieren würde. Nach 2.2.6 wäre das Portal verpflichtet, die Nutzerin zu Beginn darüber zu informieren, dass Inaktivität von mehr als 15 Minuten zu Datenverlust führt, damit sie entsprechend planen kann.

Über die Barrierefreiheit hinaus verbessert die proaktive Offenlegung des Timeout-Verhaltens die Nutzererfahrung für alle und reduziert Abbruchraten in wertvollen Conversion-Flows wie Checkout, Registrierung und Antragsformularen. Sie stärkt auch das Vertrauen, da Nutzer nicht im Unklaren darüber gelassen werden, warum ihre Daten verschwunden sind.

Wie man testet

Automatischer Vorab-Scan: Führen Sie axe DevTools oder Lighthouse auf der Seite aus, die das Formular, den Checkout-Flow oder eine andere Dateneingabeoberfläche enthält. Auch wenn keines der Tools einen Verstoß gegen 2.2.6 direkt meldet, nutzen Sie diesen Schritt, um etwaige Timeout-bezogene ARIA-Live-Regionen oder Dialogkomponenten zu identifizieren, die Teil des Warnmechanismus sein könnten, und stellen Sie sicher, dass diese selbst barrierefrei sind (korrekte Rollen, Beschriftungen, Fokusmanagement).
Timeout-Verhalten identifizieren: Sprechen Sie mit dem Entwicklungsteam oder prüfen Sie die serverseitige Konfiguration, um die Dauer des Inaktivitäts-Timeouts für die Sitzung zu bestimmen. Häufige Orte sind Konfigurationsdateien des Webservers, Einstellungen der Session-Middleware der Anwendung und Dokumentation des Authentifizierungsanbieters. Notieren Sie die genaue Dauer in Minuten.
Prüfen, ob eine Vorab-Offenlegung erfolgt: Laden Sie die Seite frisch und lesen Sie alle Inhalte, die dem Nutzer angezeigt werden, bevor eine Dateneingabe beginnt. Suchen Sie nach einer klaren Aussage – im Seiteninhalt, in einem einleitenden Absatz, einem Banner oder einem Modal –, die die genaue Dauer des Inaktivitäts-Timeouts angibt und erklärt, dass Daten verloren gehen, wenn der Nutzer für diesen Zeitraum inaktiv ist. Die Offenlegung muss die Dauer ausdrücklich nennen (z. B. „15 Minuten“), nicht vage (z. B. „eine kurze Zeit“).
Test mit Screenreader: Navigieren Sie mit NVDA und Firefox, VoiceOver und Safari oder JAWS und Chrome von ganz am Anfang durch die Seite. Bestätigen Sie, dass jede Timeout-Offenlegung erreichbar ist und vom Screenreader vorgelesen wird, ohne dass der Nutzer sie aktiv suchen muss. Wenn die Offenlegung in einem visuell prominenten Banner steht, stellen Sie sicher, dass sie in der Lesereihenfolge vor dem ersten Formularfeld erscheint.
Inaktivität simulieren: Beginnen Sie mit dem Ausfüllen des Formulars. Unterbrechen Sie dann die Interaktion mit der Seite für eine Dauer, die etwas kürzer als der Timeout-Zeitraum ist, und beobachten Sie, was passiert. Wiederholen Sie den Vorgang, diesmal, nachdem der Timeout-Zeitraum abgelaufen ist. Notieren Sie, ob Daten verloren gehen, ob vor dem Datenverlust eine Warnung angezeigt wird und ob diese Warnung bereits vor Beginn der Sitzung kommuniziert wurde.
Die 20-Stunden-Ausnahme testen: Wenn das Team behauptet, dass Daten länger als 20 Stunden erhalten bleiben, überprüfen Sie dies empirisch, indem Sie ein Formular teilweise ausfüllen, mindestens 20 Stunden warten und zur Seite zurückkehren, um zu bestätigen, dass die Daten noch vorhanden sind. Alternativ können Sie gemeinsam mit dem Entwicklungsteam die Konfiguration des serverseitigen Session-Speichers prüfen.
Tastatur- und Fokus-Tests: Wenn ein Timeout-Warn-Dialog oder eine Benachrichtigung erscheint, stellen Sie mit reiner Tastaturnavigation sicher, dass er automatisch den Fokus erhält, dass sein Inhalt vollständig lesbar ist und dass der Nutzer ihn schließen oder eine Aktion ausführen kann (z. B. die Sitzung verlängern), ohne eine Maus zu verwenden.

Wie man es behebt

Sitzung mit stillem Datenverlust – Falsch

<!-- A multi-step form with a 10-minute server session timeout.
     No warning is displayed anywhere on the page.
     After 10 minutes of inactivity, the session is destroyed
     and all entered data is lost. -->
<form action='/submit-application' method='post'>
  <h1>Benefit Application</h1>
  <label for='full-name'>Full Name</label>
  <input type='text' id='full-name' name='full-name'>
  <!-- ... many more fields ... -->
  <button type='submit'>Submit Application</button>
</form>

Sitzung mit stillem Datenverlust – Richtig

<!-- The timeout duration is disclosed clearly before any form fields.
     The disclosure is in the natural reading order so screen readers
     encounter it before the first input. -->
<main>
  <h1>Benefit Application</h1>
  <div role='note' aria-label='Session timeout notice'>
    <p>
      <strong>Important:</strong> This form will time out after
      <strong>10 minutes of inactivity</strong>, and any information
      you have entered will be lost. Please have all required documents
      ready before you begin, or save your progress regularly.
    </p>
  </div>
  <form action='/submit-application' method='post'>
    <label for='full-name'>Full Name</label>
    <input type='text' id='full-name' name='full-name'>
    <!-- ... many more fields ... -->
    <button type='submit'>Submit Application</button>
  </form>
</main>

Checkout-Sitzung mit vager Warnung – Falsch

<!-- The warning exists but is vague — it does not state the actual
     timeout duration, making it impossible for users to plan. -->
<p class='notice'>Your session may expire due to inactivity.</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Checkout-Sitzung mit vager Warnung – Richtig

<!-- The warning now states the exact duration so users can
     make an informed decision about when to begin the checkout. -->
<p class='notice'>
  For your security, your checkout session will expire after
  <strong>20 minutes of inactivity</strong>. Any payment information
  entered will need to be re-entered if the session expires.
</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Daten werden serverseitig länger als 20 Stunden erhalten – Richtig (Ausnahme greift)

<!-- When all form data is saved to the server continuously
     and preserved for at least 20 hours, no timeout warning
     is required by 2.2.6. This is the ideal UX pattern:
     autosave is indicated to the user for transparency. -->
<main>
  <h1>Job Application</h1>
  <p>
    Your progress is automatically saved as you type.
    You can leave and return to this form at any time within
    <strong>30 days</strong> and your answers will be preserved.
  </p>
  <form action='/apply' method='post'>
    <label for='cover-letter'>Cover Letter</label>
    <textarea id='cover-letter' name='cover-letter'></textarea>
    <p aria-live='polite' id='autosave-status'>Draft saved.</p>
    <button type='submit'>Submit Application</button>
  </form>
</main>

Häufige Fehler

Die Timeout-Warnung nur in der Browserkonsole oder in einem Server-Logeintrag anzuzeigen, der für Endnutzer unsichtbar ist – die Warnung muss in der Benutzeroberfläche an einer Stelle präsentiert werden, an der der Nutzer sie vor dem Datenverlust wahrnimmt.
Die Offenlegung in einem Footer, einer Datenschutzerklärung oder auf einer Seite mit Nutzungsbedingungen zu platzieren, die Nutzer wahrscheinlich nicht lesen, bevor sie mit der Dateneingabe beginnen, statt direkt auf dem Formular selbst oder unmittelbar davor.
Ein modales Dialogfenster zu verwenden, um Nutzer vor einem bevorstehenden Sitzungsablauf zu warnen, aber den Tastaturfokus nicht auf den Dialog zu verschieben – Tastatur- und Screenreader-Nutzer bemerken möglicherweise nie, dass die Warnung erschienen ist.
Eine Sitzungsdauer anzugeben (z. B. „Ihre Sitzung dauert 30 Minuten“) statt eines Inaktivitäts-Timeouts (z. B. „Nach 15 Minuten Inaktivität gehen Ihre Daten verloren“) – dies sind unterschiedliche Konzepte, und nur der durch Inaktivität ausgelöste Datenverlust wird von 2.2.6 geregelt.
Davon auszugehen, dass das Kriterium erfüllt ist, nur weil es ein Timeout-Warn-Modal für sehende Nutzer gibt – wenn das Modal nicht per Tastatur erreichbar ist, keinen zugänglichen Namen hat oder nicht über ARIA-Live-Regionen oder Fokusmanagement angekündigt wird, erhalten Screenreader-Nutzer die Warnung nicht.
Den serverseitigen Session-Timeout auf 25 Stunden zu setzen und zu schließen, dass keine Offenlegung nötig ist, ohne zu prüfen, dass der browserseitige oder anwendungsseitige Zustand (z. B. ein Redux-Store oder localStorage) nicht früher gelöscht wird – der effektive Timeout ist der Mechanismus, der zuerst Daten verliert.
Die Timeout-Dauer in einem Tooltip offenzulegen, der nur durch Hover ausgelöst wird – Nutzer, die auf Tastaturnavigation oder Touch-Geräte angewiesen sind, bekommen die Offenlegung möglicherweise nie zu sehen.
Sich auf eine generische CMS- oder Framework-Warnung „Session expired“ zu verlassen, die angezeigt wird, nachdem der Datenverlust bereits eingetreten ist, statt Nutzer proaktiv zu informieren, bevor sie mit der Dateneingabe beginnen.
Nutzer, die das Formular in einem Hintergrund-Tab öffnen, nicht zu berücksichtigen: Wenn der Sitzungs-Timer läuft, während der Tab inaktiv ist, können Daten verloren gehen, bevor der Nutzer überhaupt die Möglichkeit hatte, mit dem Formular zu interagieren. Dies ist besonders problematisch in mobilen Browsern, die Hintergrund-Tabs aggressiv aussetzen.
Die Warnung in mobilen Versionen oder Progressive-Web-App-(PWA)-Kontexten wegzulassen, während sie in der Desktop-Version angezeigt wird, wodurch eine inkonsistente Erfahrung entsteht, die 2.2.6 für einen erheblichen Teil der Nutzer verfehlt.

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 Web-Barrierefreiheitsverpflichtungen für eine breite Palette öffentlicher und privater Einrichtungen fest, die in der Türkei tätig sind. Die Verfügung schreibt die Einhaltung von WCAG 2.2 als technischen Standard vor und verlangt von den betroffenen Einrichtungen mindestens Konformität auf Level AA. WCAG 2.2.6 Timeouts ist ein Kriterium auf Level AAA und wird daher nicht direkt durch die Basisanforderungen der Verfügung vorgeschrieben. Der Umfang und die Zielsetzung der Verfügung schaffen jedoch starke praktische Gründe für betroffene Einrichtungen, eine AAA-Konformität bei Kriterien wie 2.2.6 anzustreben.

Zu den von der Präsidialverfügung 2025/10 erfassten Einrichtungen gehören öffentliche Institutionen und Behörden, E‑Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsanbieter mit mehr als 200.000 Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) zugelassen sind. Viele dieser Sektoren betreiben Online-Portale, die genau die Arten von Dateneingabe-Workflows umfassen, die 2.2.6 schützen soll: Kreditanträge, Patientenaufnahmeformulare, Ticketbuchungssysteme, Einschreibeanträge und Anträge auf staatliche Leistungen.

Gerade für Banken und E‑Commerce-Plattformen sind Session-Timeouts eine routinemäßige Sicherheitsmaßnahme, und das Zusammenspiel von Sicherheitsanforderungen und Barrierefreiheitsverpflichtungen ist direkt relevant. Auch wenn eine Bank regulatorisch verpflichtet sein kann, inaktive Sitzungen nach einem festen Zeitraum zu beenden, steht die Umsetzung von WCAG 2.2.6 durch die Vorab-Offenlegung der Timeout-Dauer nicht im Widerspruch zu dieser Sicherheitsanforderung – sie ergänzt sie. Nutzer werden über die Einschränkung informiert, ohne dass die Bank ihre Sicherheitsstrategie für Sitzungen abschwächen muss.

Gesundheitsdienstleister und Krankenhäuser, die von der Verfügung erfasst sind, bearbeiten einige der kritischsten Dateneingabeaufgaben überhaupt – Patientenanamneseformulare, Anträge auf Vorabgenehmigung und Terminvergabesysteme. Patienten mit kognitiven Beeinträchtigungen oder motorischen Einschränkungen, die in diesen Kontexten ihre Daten mitten im Formular verlieren, erleben nicht nur Frustration, sondern möglicherweise auch Verzögerungen bei der Versorgung. Die Umsetzung von 2.2.6 in diesen Umgebungen ist ein direkter Ausdruck des inklusiven Dienstleistungsauftrags, der der Verfügung zugrunde liegt.

Auch wenn Level AAA rechtlich nicht vorgeschrieben ist, stellt seine Erreichung bei Kriterien wie 2.2.6 – die einen relativ geringen Implementierungsaufwand erfordern (das Hinzufügen einer einzigen, korrekten Offenlegung zu einem Formular), während sie gleichzeitig erheblichen Nutzen für gefährdete Nutzergruppen bringen – eine erstklassige Barrierefreiheitspraxis dar. Organisationen, die ihr Engagement für digitale Inklusion auf dem türkischen Markt demonstrieren wollen oder mit strengeren künftigen Regelungen rechnen, sind gut beraten, 2.2.6 als praktisches Implementierungsziel und nicht als bloßes optionales Ideal zu behandeln.