WCAG 2.2.5: Erneute Authentifizierung

WCAG 2.2.5 verlangt, dass Benutzer nach Ablauf einer authentifizierten Sitzung sich erneut authentifizieren und ihre Tätigkeit fortsetzen können, ohne dabei Daten zu verlieren, die sie eingegeben haben. Dieses Kriterium ist entscheidend für Nutzer mit Behinderungen, die möglicherweise mehr Zeit benötigen, um Aufgaben zu erledigen, und nicht durch Sitzungs-Timeouts bestraft werden dürfen, die ihre Arbeit löschen.

Was diese Regel bedeutet

WCAG 2.2.5 Re-authenticating gehört zu Richtlinie 2.2 (Ausreichend Zeit) und ist eine Anforderung der Stufe AAA. Das Kriterium lautet: „Wenn eine authentifizierte Sitzung abläuft, kann der Nutzer die Aktivität nach der erneuten Authentifizierung ohne Datenverlust fortsetzen.“ Praktisch bedeutet das: Wenn ein Nutzer mitten im Ausfüllen eines Formulars, beim Abschluss eines Kaufs, beim Verfassen einer Nachricht oder bei einer anderen mehrstufigen Aufgabe auf einer authentifizierten Plattform ist und seine Sitzung abläuft, muss er sich erneut anmelden können und genau dort weitermachen, wo er aufgehört hat – mit allen zuvor eingegebenen Daten, die erhalten bleiben.

Dieses Kriterium steht in engem Zusammenhang mit WCAG 2.2.1 (Timing Adjustable, Stufe A) und 2.2.4 (Interruptions, Stufe AAA), behandelt aber ein spezifisches Szenario: den Moment, in dem eine Sitzungsgrenze überschritten wird. Während 2.2.1 verlangt, dass Sie den Nutzern genügend Zeit geben oder ihnen erlauben, ihre Sitzung zu verlängern, behandelt 2.2.5 den Fehlerfall – was nach Ablauf der Zeit passiert. Beide arbeiten zusammen: Idealerweise verlängern Sie sowohl die Sitzung als auch bewahren die Daten, falls sie doch abläuft.

Ein Bestehen nach diesem Kriterium erfordert, dass die Plattform alle vom Nutzer eingegebenen Daten – Texteingaben, ausgewählte Optionen, Dateianhänge, Kontrollkästchen, Radiobutton-Auswahlen und jeden anderen Formularzustand – über ein Re-Authentifizierungsereignis hinweg bewahrt. Nachdem der Nutzer sich erneut angemeldet hat, muss er zu demselben Punkt in der Aktivität zurückkehren, die er ausgeführt hat, mit intakten Daten und der Möglichkeit, die Aufgabe ohne Wiederholung abzuschließen.

Ein Fehlschlag tritt ein, wenn ein Sitzungs-Timeout Folgendes verursacht: Der Nutzer wird auf eine Login-Seite umgeleitet und nach erfolgreicher Anmeldung zur Startseite statt zu der Seite geschickt, auf der er sich befand; vor dem Timeout eingegebene Formulardaten gehen verloren und der Nutzer muss alles erneut eingeben; der teilweise abgeschlossene Zustand eines mehrstufigen Assistenten wird zurückgesetzt; oder der Nutzer wird einfach abgemeldet, ohne eine Möglichkeit zur erneuten Authentifizierung und Fortsetzung.

Die offizielle WCAG-Spezifikation definiert für dieses Kriterium keine minimale Sitzungsdauer – es gilt unabhängig davon, wie lang oder kurz der Timeout-Zeitraum ist. Beachten Sie jedoch, dass es keine Ausnahme für Datenverlust aus Sicherheitsgründen gibt; es wird erwartet, dass Implementierungen sichere Wege zur Zustandsbewahrung finden, etwa serverseitige Sitzungs-Speicherung, die an die Identität des Nutzers gekoppelt ist, oder verschlüsselte clientseitige Tokens, die den Re-Authentifizierungsfluss überdauern.

Warum das wichtig ist

Sitzungs-Timeouts, die Daten löschen, erzeugen eine unverhältnismäßig schwere Belastung für Menschen mit Behinderungen. Viele Nutzer mit Behinderungen benötigen deutlich mehr Zeit für digitale Aufgaben als nichtbehinderte Personen und können oft nicht einfach „schneller tippen“ oder ein willkürliches Timeout „umgehen“.

Nutzer, die blind sind oder eine Sehbehinderung haben, navigieren Formulare mit Screenreadern, was von Natur aus langsamer ist als visuelles Scannen. Eine blinde Person, die ein umfangreiches Versicherungsformular ausfüllt, kann 20 oder 30 Minuten damit verbringen, sorgfältig Feld für Feld zu navigieren, nur um ihre Arbeit zu verlieren, wenn ein 15-minütiges Sitzungs-Timeout ausgelöst wird. Sie muss dann von vorne beginnen – ohne Garantie, dass es nicht ein zweites Mal passiert.

Menschen mit motorischen Beeinträchtigungen – etwa solche, die Schaltersteuerungen, Blickverfolgungstechnologie oder Mundstäbe verwenden – können ein Vielfaches der durchschnittlichen Zeit benötigen, um Text einzugeben und Formulare zu bedienen. Ein Nutzer mit ALS oder spinaler Muskelatrophie kann ein wichtiges medizinisches Überweisungsformular ausfüllen und nur wenige Zeichen pro Minute tippen. Sitzungs-Timeouts, die ihre Arbeit zerstören, sind keine kleine Unannehmlichkeit; sie können eine vollständige Barriere für den Abschluss essenzieller Aufgaben darstellen.

Nutzer mit kognitiven Beeinträchtigungen, einschließlich Menschen mit Dyslexie, ADHS, traumatischen Hirnverletzungen oder Demenz, müssen Anweisungen möglicherweise mehrfach lesen, Pausen einlegen, um Informationen zu verarbeiten, oder sich einfach langsamer durch mehrstufige Prozesse bewegen. Forschung zeigt konsistent, dass diese Bevölkerungsgruppe überproportional von Zeitdruck und Datenverlust betroffen ist – beides verstärkt die kognitive Belastung, wenn sie versuchen, komplett von vorne zu beginnen.

Betrachten Sie ein konkretes Szenario aus der Praxis: Eine Nutzerin mit Multipler Sklerose beantragt über das Webportal einer öffentlichen Institution eine staatliche Behindertenleistung. Der Antrag umfasst 8 Schritte und erfordert das Hochladen medizinischer Dokumente, die Eingabe der Beschäftigungshistorie und das Verfassen einer persönlichen Stellungnahme. Sie schafft 6 Schritte in 45 Minuten, ihre Sitzung läuft ab, und alle eingegebenen Daten gehen verloren. Sie muss nun dieselben Dokumente erneut zusammentragen und den gesamten Prozess wiederholen, was dazu führen kann, dass sie den Antrag ganz aufgibt. Das ist kein hypothetischer Fall – es handelt sich um ein Muster, das in Barrierefreiheitsforschung und Nutzertests wiederholt dokumentiert wurde.

Über Behinderungen hinaus betrifft Datenverlust bei Sitzungs-Timeouts alle Nutzer und hat messbare geschäftliche Auswirkungen: abgebrochene Warenkörbe, unvollständige Registrierungen und verlorene Leads. Die Bewahrung des Sitzungszustands ist sowohl ein Barrierefreiheitsgebot als auch eine sinnvolle UX- und Conversion-Optimierungsmaßnahme. Laut Baymard Institute ist Formularabbruch ein wesentlicher Beitrag zu Warenkorbabbruchraten im E-Commerce, und unerwarteter Datenverlust ist einer der am häufigsten genannten Gründe, warum Nutzer Online-Käufe nicht abschließen.

Wie man testet

Authentifizierte Workflows mit Formularen oder mehrstufigen Prozessen identifizieren. Beginnen Sie damit, alle Bereiche der Website zu kartieren, die eine Authentifizierung erfordern und Dateneingaben durch den Nutzer beinhalten – Checkout-Flows, Profil-Editoren, Antragsformulare, Buchungssysteme, Messaging-Oberflächen und Administrations-Dashboards. Dies sind die risikoreichsten Bereiche für 2.2.5-Fehler.
Die Dauer des Sitzungs-Timeouts bestimmen. Prüfen Sie Serverkonfiguration, Anwendungseinstellungen oder sprechen Sie mit dem Entwicklungsteam, um herauszufinden, wann Sitzungen ablaufen. Alternativ können Sie eine Sitzung starten und warten, bis Sie automatisch abgemeldet werden. Notieren Sie die Dauer. Übliche Timeouts liegen zwischen 15 Minuten und 2 Stunden.
Eine Aufgabe beginnen und umfangreiche Daten eingeben. Melden Sie sich an und beginnen Sie mit dem Ausfüllen eines repräsentativen Formulars – zum Beispiel eines mehrfeldrigen Registrierungs- oder Kaufprozesses. Geben Sie Text in Textfelder ein, treffen Sie Auswahlen und durchlaufen Sie etwaige Assistentenschritte. Senden Sie das Formular nicht ab.
Sitzungsablauf auslösen. Warten Sie entweder auf das natürliche Timeout oder – falls Sie Entwicklerzugriff haben – lassen Sie die Sitzung künstlich ablaufen, indem Sie das Sitzungs-Cookie in den Entwicklertools des Browsers ungültig machen (Tab „Application“ > Cookies > Sitzungs-Cookie löschen) oder indem Sie die Sitzung direkt serverseitig ablaufen lassen.
Die Re-Authentifizierungsaufforderung beobachten. Prüfen Sie, ob die Website Sie zur Re-Authentifizierung auffordert (Bestanden) oder Sie einfach ohne Vorwarnung auf eine Login-Seite umleitet (ein verwandtes Usability-Problem, obwohl 2.2.5 sich auf die Datenbewahrung, nicht auf die Warnung selbst konzentriert). Versuchen Sie, sich erneut anzumelden.
Datenbewahrung nach dem Login überprüfen. Beobachten Sie nach erfolgreicher Re-Authentifizierung, wohin Sie weitergeleitet werden und ob Ihre zuvor eingegebenen Daten intakt sind. Wenn Sie zur Startseite geschickt werden und/oder Ihre Formulardaten verschwunden sind, ist dies ein Verstoß gegen 2.2.5.
Mit unterstützenden Technologien testen. Wiederholen Sie die obige Testsequenz mit NVDA und Firefox, JAWS und Chrome sowie VoiceOver und Safari, um sicherzustellen, dass die Re-Authentifizierungsaufforderung für Screenreader-Nutzer zugänglich ist und der wiederhergestellte Seitenzustand korrekt angekündigt wird. Ein sehender Nutzer erkennt wiederhergestellte Daten möglicherweise visuell; ein Screenreader-Nutzer benötigt korrekt gesetzten Fokus und wiederhergestellte Inhalte in der Lesereihenfolge.
Nur mit Tastatur navigieren testen. Stellen Sie sicher, dass der gesamte Re-Authentifizierungsprozess – von der Sitzungsablauf-Benachrichtigung über die erneute Anmeldung bis zur Rückkehr zur bewahrten Aufgabe – ausschließlich mit der Tastatur, ohne Maus, durchführbar ist.
Mit verlängerten Timeout-Simulationen testen. Reduzieren Sie nach Möglichkeit das Sitzungs-Timeout in einer Entwicklungsumgebung auf 1–2 Minuten und führen Sie vollständige User-Journey-Tests durch, um den Testzyklus schneller und besser wiederholbar zu machen.

Wie man es behebt

Einfaches Login-Formular mit Sitzungs-Timeout – falsch

<!-- BAD: Session expires silently. On re-login, user is sent to homepage.
     All entered data in the checkout form is lost. -->
<form action='/checkout' method='POST' id='checkout-form'>
  <input type='text' name='full_name' placeholder='Full Name' />
  <input type='text' name='address' placeholder='Address' />
  <button type='submit'>Place Order</button>
</form>

<!-- Server-side: session expires after 10 minutes of inactivity.
     No state saved. POST redirect on login goes to /dashboard. -->

Einfaches Login-Formular mit Sitzungs-Timeout – korrekt

<!-- GOOD: Before session expires, form state is saved server-side
     (or to sessionStorage as a fallback). After re-auth, the user
     is redirected back to the checkout page with data restored. -->

<!-- 1. JavaScript saves form state periodically to the server -->
<script>
  function saveFormState() {
    const formData = new FormData(document.getElementById('checkout-form'));
    const data = Object.fromEntries(formData.entries());
    // Save to server-side session keyed to authenticated user identity
    fetch('/api/save-draft', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ formId: 'checkout', data })
    });
  }
  // Auto-save every 60 seconds and on input change
  setInterval(saveFormState, 60000);
  document.getElementById('checkout-form')
    .addEventListener('input', saveFormState);
</script>

<!-- 2. On the server: when user re-authenticates,
     redirect to /checkout?restore=true
     which reloads saved draft data into the form -->
<form action='/checkout' method='POST' id='checkout-form'>
  <!-- Form fields are pre-populated from saved draft -->
  <input type='text' name='full_name' value='[restored value]'
         aria-label='Full Name' />
  <input type='text' name='address' value='[restored value]'
         aria-label='Address' />
  <button type='submit'>Place Order</button>
</form>

Mehrstufiger Assistent verliert Fortschritt – falsch

<!-- BAD: Multi-step form uses only client-side state.
     Session expiry wipes wizard progress completely.
     Re-login sends user to step 1 with no data. -->

<div id='wizard'>
  <div class='step active' id='step-3'>
    <h2>Step 3 of 5: Employment History</h2>
    <textarea name='employment_history'>Typed content here...</textarea>
  </div>
</div>

<script>
  // State is only in JavaScript variables — lost on session expiry
  let wizardState = { step: 3, data: {} };
</script>

Mehrstufiger Assistent verliert Fortschritt – korrekt

<!-- GOOD: Wizard state is persisted server-side at each step
     and linked to the user's account. On re-authentication,
     the server restores the user to their last saved step
     with all data intact. A visible confirmation is shown. -->

<div id='wizard'>
  <div class='step active' id='step-3'
       aria-live='polite' aria-label='Step 3 of 5: Employment History'>
    <p role='status'>
      Your progress has been restored from your last session.
    </p>
    <h2>Step 3 of 5: Employment History</h2>
    <!-- Data is pre-populated from server-side draft -->
    <textarea name='employment_history'
              aria-label='Describe your employment history'>
      Previously entered content restored here...
    </textarea>
    <!-- Wizard nav saves progress before moving to next step -->
    <button type='button' onclick='saveAndProceed()'>Next Step</button>
  </div>
</div>

<script>
  async function saveAndProceed() {
    await fetch('/api/wizard/save', {
      method: 'POST',
      body: JSON.stringify({ step: 3, data: collectStepData() }),
      headers: { 'Content-Type': 'application/json' }
    });
    goToStep(4);
  }
</script>

Sitzungsablauf-Warnung ohne Datenbewahrung – falsch

<!-- BAD: Site shows a countdown warning but does not save data.
     If the user misses the warning (e.g., screen reader user
     focused elsewhere), they lose all their work. -->
<div id='timeout-warning' style='display:none'>
  <p>Your session will expire in 2 minutes. <a href='/extend'>Extend</a></p>
</div>

Sitzungsablauf-Warnung ohne Datenbewahrung – korrekt

<!-- GOOD: Warning uses aria-live so screen readers announce it.
     Data is saved server-side regardless of whether the user
     extends the session — so re-auth always restores state. -->
<div id='timeout-warning'
     role='alertdialog'
     aria-live='assertive'
     aria-labelledby='warning-title'
     aria-describedby='warning-desc'
     hidden>
  <h2 id='warning-title'>Session Expiring Soon</h2>
  <p id='warning-desc'>
    Your session will expire in 2 minutes. Your work has been
    saved automatically. You can extend your session or log in
    again to continue exactly where you left off.
  </p>
  <button onclick='extendSession()'>Extend Session</button>
  <button onclick='dismissWarning()'>Dismiss</button>
</div>

Häufige Fehler

Weiterleitung nach der Re-Authentifizierung auf die Startseite statt auf die ursprüngliche Seite: Das häufigste Fehlermuster. Nach dem Login sendet die Anwendung den Nutzer zu /dashboard oder / statt zu der URL, auf der er sich beim Sitzungsablauf befand, sodass er manuell zu seiner Aufgabe zurücknavigieren muss – und seine Daten sind bereits verloren.
Speichern des Formularzustands nur im JavaScript-Speicher oder im React/Vue-Komponentenstatus: Clientseitiger Framework-Zustand überlebt keinen Seiten-Reload, der durch eine Sitzungsablauf-Weiterleitung zur Login-Seite ausgelöst wird. Der Zustand muss serverseitig oder in einem Speichermedium (z. B. localStorage) persistiert werden, das bei der Rückkehr zuverlässig wiederhergestellt wird.
Speichern einer „Return-URL“, aber nicht der Formulardaten: Einige Implementierungen speichern die URL, zu der nach dem Login zurückgeleitet werden soll, sichern aber nicht die tatsächlichen Formularfeldwerte. Der Nutzer landet auf der richtigen Seite, aber mit leeren Feldern, was weiterhin gegen 2.2.5 verstößt.
Automatisches Speichern in sessionStorage, das beim Schließen des Tabs gelöscht wird: Wenn der Sitzungsablauf dazu führt, dass der Browser-Tab weg navigiert (z. B. Weiterleitung zum Login), wird sessionStorage gelöscht. Verwenden Sie localStorage mit einem benutzerspezifischen Namespace oder vorzugsweise serverseitige Entwurfs-Speicherung.
Kein Testen mit Datei-Upload-Feldern: Datei-Inputs können aus Sicherheitsgründen nicht per HTML vorbefüllt werden. Wenn ein Formular einen Datei-Upload enthält, der vor dem Sitzungsablauf abgeschlossen wurde, geht die Dateireferenz verloren. Anwendungen müssen dies handhaben, indem sie hochgeladene Dateireferenzen serverseitig speichern und dem Nutzer anzeigen, dass seine Datei weiterhin angehängt ist.
Sofortiges Löschen gespeicherter Entwurfsdaten bei Re-Authentifizierung: Einige Implementierungen löschen den Entwurf, sobald der Nutzer sich anmeldet, bevor sichergestellt ist, dass der Nutzer die wiederhergestellten Daten tatsächlich gesehen und bestätigt hat. Der Entwurf sollte erhalten bleiben, bis die Aufgabe ausdrücklich abgeschlossen oder abgebrochen wird.
Wiederhergestellte Daten nicht für Screenreader-Nutzer ankündigen: Nach Re-Authentifizierung und Weiterleitung benötigen Screenreader-Nutzer einen aria-live-Bereich oder eine fokussierte Ankündigung, die bestätigt, dass ihre Daten wiederhergestellt wurden und sie genau dort weitermachen können, wo sie aufgehört haben. Ohne dies wissen sie möglicherweise nicht, dass ihre Arbeit gespeichert wurde.
Unterschiedliche Behandlung von AJAX-basierten Sitzungen und seitenbasierten Sitzungen: Single-Page-Anwendungen mit tokenbasierter Authentifizierung (z. B. JWT-Ablauf) lassen API-Aufrufe beim Token-Ablauf oft stillschweigend fehlschlagen, ohne dem Nutzer die Möglichkeit zur Re-Authentifizierung und Fortsetzung zu geben. Der Re-Authentifizierungsmechanismus muss für SPA-Architekturen gleichermaßen robust sein.
Verwendung von <meta http-equiv='refresh'>, um ohne vorherige Datenspeicherung zum Logout zu zwingen: Ein Meta-Refresh, der beim Timeout ausgelöst wird, leitet den Nutzer sofort weiter, ohne serverseitige Zustandsbewahrung, wodurch eine Datenwiederherstellung unmöglich wird. Sitzungsmanagement muss auf Anwendungsebene mit ordnungsgemäßer Zustands-Persistenz erfolgen.
Die Annahme, kurze Sitzungen würden dieses Kriterium überflüssig machen: Selbst ein 5-minütiges Sitzungs-Timeout kann einen langsamen Tipper, einen Nutzer mit kognitiver Beeinträchtigung, der Anweisungen erneut liest, oder jemanden, der von einer Betreuungsperson unterbrochen wird, treffen. Die Dauer des Timeouts ändert nichts an der Verpflichtung, Daten über die Re-Authentifizierung hinweg zu bewahren.

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) legt den nationalen Rahmen für digitale Barrierefreiheit fest und verweist auf WCAG 2.2 als technische Standardgrundlage. Die Verfügung schreibt Konformität für eine breite Palette von in der Türkei tätigen Einrichtungen vor, darunter öffentliche Institutionen und Behörden, E-Commerce-Plattformen, Banken und Finanzdienstleister, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und private Bildungseinrichtungen, die vom Bildungsministerium (MoNE) autorisiert sind.

WCAG 2.2.5 Re-authenticating ist ein Kriterium der Stufe AAA, was bedeutet, dass es nicht zu den minimal gesetzlich vorgeschriebenen Anforderungen nach der Verfügung gehört (die auf Konformität mit Stufe A und AA abzielt). Organisationen, die eine Vorreiterrolle in der Barrierefreiheit einnehmen, vielfältige Nutzergruppen einschließlich Menschen mit Behinderungen bedienen oder sich als erstklassige digitale Dienstleister positionieren wollen, sollten Kriterien der Stufe AAA – insbesondere solche mit so praktischer Wirkung wie 2.2.5 – jedoch als erstrebenswerte Ziele betrachten.

Bestimmte Kategorien betroffener Einrichtungen haben besonders starke Gründe, 2.2.5 umzusetzen. Banken und Finanzplattformen verlangen von Nutzern häufig das Ausfüllen langer Formulare für Kreditanträge, Kontoeröffnungen oder Anlageprodukte, und ihre sicherheitsgetriebenen kurzen Sitzungs-Timeouts stehen in direktem Spannungsverhältnis zu Verpflichtungen zur Datenbewahrung. Krankenhäuser und Gesundheitsportale setzen Patienten dem Risiko von Datenverlust bei kritischen Aufgaben wie Terminbuchungen oder dem Ausfüllen von Gesundheitsfragebögen aus, was reale Folgen für die Kontinuität der Versorgung haben kann. Öffentliche Institutionen, die E-Government-Dienste betreiben – etwa Steuererklärungen, Genehmigungsanträge oder Leistungsansprüche – bedienen Bürger mit Behinderungen, die möglicherweise mehr Zeit benötigen, um komplexe Behördenformulare auszufüllen.

Auch wenn die Einhaltung der Stufe AAA rechtlich nicht vorgeschrieben ist, sollten sich türkische Organisationen bewusst sein, dass Regulierungsbehörden, zivilgesellschaftliche Organisationen und Behindertenrechtsaktivisten die Qualität und Vollständigkeit von Barrierefreiheitsumsetzungen zunehmend kritisch prüfen. Die Dokumentation der Konformität mit Kriterien der Stufe AAA wie 2.2.5 stärkt die Barrierefreiheits-Erklärung einer Organisation, reduziert das Risiko von Rechtsstreitigkeiten und zeigt ein echtes Engagement für inklusives Design, das über ein Mindestmaß an „Checkbox“-Konformität hinausgeht. Für Einrichtungen mit internationaler Reichweite, insbesondere solche, die neben der Türkei auch in EU-Märkten tätig sind, können Kriterien der Stufe AAA mit Anforderungen nach dem European Accessibility Act (EAA) und entsprechenden nationalen Umsetzungen überschneiden.