Zeitlimits anpassbar machen: Session-Timeouts, Countdowns und WCAG 2.2.1

Wo überall Zeitlimits stecken

Ein Zeitlimit im Sinn von WCAG ist jeder Prozess, der ohne Zutun der Nutzer:innen nach einer bestimmten Zeit oder in festen Abständen passiert: ein Logout nach Inaktivität, eine Seite, die sich selbst neu lädt, ein Eingabefenster, das sich schließt, und auch Inhalte, die schneller weiterziehen, als manche Menschen lesen können. Das Kriterium betrifft also weit mehr als den klassischen Session-Timeout.

Wichtig für die Einordnung: 2.2.1 gilt nur für Zeitlimits, die vom Inhalt selbst gesetzt werden, also von deiner Website oder deinem Server. Zeitgrenzen, die der Browser oder die Infrastruktur des Internets vorgibt, liegen außerhalb deiner Verantwortung.

Drei Wege, drei Ausnahmen: was WCAG 2.2.1 verlangt

Das Erfolgskriterium 2.2.1 „Zeiteinteilung anpassbar"(englisch Timing Adjustable , Stufe A) gehört seit WCAG 2.0 zum Standard und damit auch zu allen Regelwerken, die darauf aufbauen, von der BITV bis zur EN 301 549. Es verlangt: Für jedes vom Inhalt gesetzte Zeitlimit muss mindestens eine von sechs Bedingungen erfüllt sein, drei Lösungswege oder drei Ausnahmen.

Das W3C nennt die drei Lösungswege bewusst in dieser Reihenfolge: Abschalten ist besser als Anpassen, Anpassen ist besser als Verlängern. Wer das Limit gar nicht erst erlebt, kann auch nicht daran scheitern. In der Praxis ist der Verlängern-Dialog trotzdem der häufigste Weg, weil er sich mit Sicherheitsanforderungen am besten verträgt.

Warum 10-mal, 20 Sekunden, 20 Stunden?

Die Zahlen im Kriterium wirken willkürlich, sind aber laut dem Understanding-Dokument des W3C aus klinischer Erfahrung und bestehenden Richtlinien abgeleitet. Sie markieren die Schwelle, ab der fast alle Menschen eine Aufgabe schaffen:

Session-Timeouts richtig lösen

Der Klassiker ist die Sitzung, die nach Inaktivität abläuft, etwa zum Schutz vor fremden Blicken am offenen Rechner. Solche Timeouts sind erlaubt, brauchen aber einen der drei Lösungswege. Das bewährte Muster kombiniert die W3C-Techniken SCR16 und SCR1: rechtzeitig warnen, einfach verlängern lassen.

 // Sitzung: 20 Minuten. Warnung: 2 Minuten vor Ablauf. 
 // Damit bleiben weit mehr als die geforderten 20 Sekunden Reaktionszeit. 
const SITZUNG = 20 * 60 * 1000;
const VORLAUF = 2 * 60 * 1000;
let warnTimer = setTimeout(zeigeWarnung, SITZUNG - VORLAUF);
function zeigeWarnung() { // Modaler Dialog: „Deine Sitzung läuft in 2 Minuten ab." 
 // Fokus in den Dialog setzen, damit auch Screenreader ihn melden. 
dialog.showModal();
} // Eine einfache Aktion verlängert, bis zu 10-mal (Zähler führen): 
verlaengernButton.addEventListener('click', () => {
  dialog.close();
  sitzungVerlaengern(); // Server-Session erneuern, Formulardaten erhalten 
warnTimer = setTimeout(zeigeWarnung, SITZUNG - VORLAUF);
});

Drei Details entscheiden über die Konformität: Die Warnung muss vor dem Ablauf kommen, die Verlängerung muss eine einfache Aktion sein (ein Klick, ein Tastendruck, keine erneute Anmeldung), und sie muss mindestens 10-mal möglich sein. Ergänzend kannst du nach Technik G133 schon am Formularanfang eine Checkbox anbieten („Ich brauche mehr Zeit"), oder das Limit nach G198 ganz abschaltbar machen.

Meta-Refresh und automatische Weiterleitungen

Ein unterschätzter Stolperstein steckt im HTML-Kopf: das meta http-equiv="refresh" . Mit einer Verzögerung größer als null lädt es die Seite neu oder leitet weiter, ohne dass Nutzer:innen eingreifen können. Genau das dokumentiert das W3C als Fehlerfälle F41 (Neuladen) und F40 (zeitverzögerte Weiterleitung). Auch serverseitig erzwungene Weiterleitungen nach einem Timeout ohne Warnung sind ein dokumentierter Fehlerfall (F58).

 <!-- ✕ Nicht konform: Seite lädt alle 5 Minuten neu (F41). 
 Screenreader beginnen von vorn, Eingaben gehen verloren. --> 
<meta http-equiv="refresh" content="300"> <!-- ✕ Nicht konform: Weiterleitung nach 20 Sekunden (F40), 
 ein Zeitlimit ohne Ausweg. --> 
<meta http-equiv="refresh" content="20; url=/neue-adresse"> <!-- ✓ Zulässig: sofortige Weiterleitung, kein Zeitlimit. 
 Noch besser: serverseitig per 301-Redirect lösen. --> 
<meta http-equiv="refresh" content="0; url=/neue-adresse">

Die Faustregel: Sofort oder gar nicht. Eine Weiterleitung ohne Verzögerung erzeugt kein Zeitlimit und ist zulässig. Sobald ein Countdown dazwischen liegt („Du wirst in 10 Sekunden weitergeleitet…"), braucht es einen konformen Ausweg, und der ist meist aufwendiger als ein schlichter Link „Weiter zur neuen Seite", den Nutzer:innen selbst anklicken.

Zeitlimits beim Lesen: Ticker, Toasts und die Abgrenzung zu 2.2.2

Auch Inhalte, die sich schneller bewegen oder aktualisieren, als Menschen lesen können, setzen ein Zeitlimit, nämlich auf das Lesen selbst. Hier arbeiten zwei Kriterien Hand in Hand: Wenn die Inhalte sich wiederholen oder über Bedienelemente erreichbar bleiben, etwa bei einem durchlaufenden Ticker oder einem Karussell mit Pause-Taste, greift das Nachbar-Kriterium 2.2.2 „Pausieren, stoppen, ausblenden". Mehr zu bewegten Inhalten findest du im Artikel Bewegung und Animation.

Diese Logik hilft bei vielen Grenzfällen: Entscheidend ist nicht, ob etwas verschwindet, sondern ob damit die einzige Möglichkeit verschwindet, eine Information zu bekommen oder eine Funktion auszuführen.

Zwei Mythen zu Zeitlimits

Checkliste für Zeitlimits

Zeitdruck trifft nie alle gleich: Was für die einen eine Formalität ist, entscheidet für andere darüber, ob sie ein Formular überhaupt abschließen können. Ein gut gemachter „Mehr Zeit"-Dialog kostet wenig und nimmt genau diesen Druck heraus, auch für alle, die nur kurz vom Bildschirm weg mussten.