WCAG 2.2.1: Zeitbegrenzungen anpassbar

WCAG 2.2.1 verlangt, dass Nutzer jede Zeitbegrenzung, die der Inhalt setzt, entweder abschalten, auf mindestens das Zehnfache verlängern oder vor Ablauf verlängern können – Letzteres mit Vorwarnung, mindestens 20 Sekunden Reaktionszeit und mindestens zehn Wiederholungen. Ausgenommen sind nur Echtzeit-Ereignisse, Fälle, in denen das Limit unentbehrlich ist, und Zeitgrenzen über 20 Stunden.

(Englisch: Timing Adjustable. Der BIK-BITV-Test führt den Prüfschritt unter demselben Namen „Zeitbegrenzungen anpassbar“.)

Das Wichtigste in Kürze

• Drei Wege stehen zur Wahl: abschalten, vorher anpassen (mindestens Zehnfaches) oder rechtzeitig verlängern. Einer davon muss vorhanden sein.
• Die Verlängerung hat vier Bedingungen: Vorwarnung, mindestens 20 Sekunden Zeit zum Reagieren, eine einfache Aktion und mindestens zehn Wiederholungen.
• Drei Ausnahmen nennt der Normtext: Echtzeit-Ereignisse wie Auktionen, Fälle, in denen das Limit unentbehrlich ist (Prüfungen), und Grenzen über 20 Stunden.
• Session-Timeouts sind ausdrücklich erfasst. Auch serverseitig gesetzte Zeitgrenzen liegen in der Verantwortung des Anbieters.
• <meta http-equiv="refresh"> mit einem Wert über 0 ist ein direkter Verstoß – sowohl beim periodischen Neuladen als auch bei verzögerter Weiterleitung.
• Der häufigste Verstoß in der Praxis: Der Ablauf wird erst beim Absenden des Formulars mitgeteilt – dann sind die Eingaben schon weg.
• Der BITV-Test prüft mit 20 Minuten Untätigkeit und schaut, ob sich Daten danach noch absenden lassen.
• Automatisch verschwindende Statusmeldungen fallen ebenfalls darunter, wenn sie wesentliche Informationen vermitteln.

Darf eine Sitzung automatisch ablaufen?

Nur mit Ausweg: Die Frist muss abschaltbar, auf das Zehnfache verlängerbar oder mit mindestens 20 Sekunden Vorwarnung verlängerbar sein.

Eine Zeitbegrenzung im Sinne der Norm ist jedes Limit, das der Inhalt selbst setzt und nach dessen Ablauf etwas passiert: Die Sitzung endet, der Warenkorb löst sich auf, die Seite lädt neu, die Reservierung verfällt, die Meldung verschwindet. Nicht gemeint ist die Zeit, die jemand zum Lesen braucht – das regeln andere Kriterien.

Für jedes solche Limit muss einer von drei Mechanismen greifen:

• Abschalten: Der Nutzer kann das Limit vor seinem Ablauf ganz aufheben.
• Anpassen: Der Nutzer kann das Limit vor Beginn auf mindestens das Zehnfache des Standardwertes stellen – aus 20 Minuten werden dann bis zu 200.
• Verlängern: Der Nutzer wird vor Ablauf gewarnt, hat mindestens 20 Sekunden Zeit zu reagieren, kann mit einer einfachen Aktion verlängern – etwa einem Knopfdruck oder der Leertaste – und kann das mindestens zehnmal wiederholen.

In der Praxis ist der dritte Weg fast immer der passende, weil Sicherheits- und Datenschutzvorgaben ein dauerhaftes Abschalten oft ausschließen. Ein Sitzungs-Timeout aus Sicherheitsgründen bleibt zulässig – es muss nur angekündigt und verlängerbar sein.

Und die drei Ausnahmen:

• Echtzeit-Ereignis: Die Zeit ist Teil des Geschehens – eine Auktion, die um 20:00 Uhr endet, ein Live-Quiz, eine Videokonferenz. Hier lässt sich nichts verlängern, ohne das Ereignis selbst zu verändern.
• Unentbehrlich: Die Zeitbegrenzung ist wesentlicher Teil der Aufgabe. Der Standardfall ist die Prüfung unter Zeitdruck; eine Verlängerung würde das Ergebnis entwerten.
• 20 Stunden: Limits jenseits von 20 Stunden gelten als so großzügig, dass sie niemanden ausschließen.

Wichtig für die Abgrenzung: Bewegte Inhalte gehören nicht hierher. Automatisch weiterlaufende Karussells, Laufschriften und Animationen regelt 2.2.2 Pausieren, beenden, ausblenden. 2.2.1 betrifft Fristen, nicht Bewegung.

Der vollständige Wortlaut steht im Understanding-Dokument des W3C zu 2.2.1; das deutsche Prüfvorgehen beschreibt der Prüfschritt 2.2.1 des BIK BITV-Tests.

Wen betrifft es besonders?

Zeit ist die Ressource, die bei Behinderung als Erstes knapp wird – und zwar unabhängig von der Art der Behinderung.

Menschen mit motorischen Einschränkungen brauchen für dieselbe Eingabe ein Vielfaches der Zeit. Mit Switch-Scanning dauert das Ausfüllen eines Adressfeldes nicht Sekunden, sondern Minuten – ein 20-Minuten-Timeout ist dann keine großzügige Frist, sondern eine harte Grenze mitten im Formular.

Screenreader-Nutzer erkunden ein Formular Feld für Feld, hören sich Hinweise an, springen zurück, lassen sich Fehlermeldungen vorlesen. Das ist gründlich und langsam. Kommt eine Warnung, muss sie zudem in einer Live-Region oder einem echten Dialog stehen, sonst wird sie gar nicht wahrgenommen – ein optischer Countdown allein ist wertlos.

Für Menschen mit kognitiven Einschränkungen kommt die Anspannung dazu: Ein sichtbarer Countdown erzeugt Druck, Druck erzeugt Fehler, und Fehler kosten wieder Zeit. Wenn ein Countdown sein muss, gehört er dezent gestaltet und nicht rot blinkend.

Und dann sind da alle anderen: die Versichertennummer, die man erst suchen muss; das Kind, das dazwischenkommt; der Anruf mitten im Bezahlvorgang. Der Curb-Cut-Effekt ist hier besonders deutlich – über verlorene Formulareingaben ärgert sich wirklich jeder.

Richtig & falsch im Code

Der schnellste Befund steckt im <head>. Ein verzögerter Refresh ist ein unmittelbarer Verstoß, weil der Nutzer ihn weder abschalten noch verlängern kann:

<!-- Falsch: die Seite lädt sich alle 5 Minuten selbst neu -->
<meta http-equiv="refresh" content="300" />

<!-- Falsch: verzögerte Weiterleitung nach 10 Sekunden -->
<meta http-equiv="refresh" content="10;url=/neue-seite.html" />

<!-- Zulässig: sofortige Weiterleitung ohne Wartezeit -->
<meta http-equiv="refresh" content="0;url=/neue-seite.html" />

Besser als jede sofortige Weiterleitung im Markup ist übrigens die Umleitung auf Serverebene mit dem Statuscode 301 oder 302 – die kostet keine Renderzeit und taucht in der Chronik nicht auf.

Die Vorwarnung selbst gehört in einen modalen Dialog, damit sie den Fokus bekommt und angesagt wird:

<!-- Richtig: Vorwarnung als Dialog mit einer einfachen Verlängerung -->
<dialog id="timeout-warnung" aria-labelledby="tw-titel">
  <h2 id="tw-titel">Sitzung läuft ab</h2>
  <p>
    Ihre Sitzung endet in
    <strong><span id="tw-rest" aria-live="polite">2 Minuten</span></strong>.
    Ihre Eingaben gehen dann verloren.
  </p>
  <button type="button" id="verlaengern" autofocus>
    Sitzung um 20 Minuten verlängern
  </button>
  <button type="button" id="abmelden">Jetzt abmelden</button>
</dialog>

// Warnung 2 Minuten vor Ablauf – deutlich mehr als die geforderten 20 Sekunden
const SITZUNG_MS = 20 * 60 * 1000;
const VORLAUF_MS = 2 * 60 * 1000;
let warnUhr;

function uhrStellen() {
  clearTimeout(warnUhr);
  warnUhr = setTimeout(
    () => document.getElementById('timeout-warnung').showModal(),
    SITZUNG_MS - VORLAUF_MS,
  );
}

document.getElementById('verlaengern').addEventListener('click', async () => {
  await fetch('/api/sitzung/verlaengern', { method: 'POST' });
  document.getElementById('timeout-warnung').close();
  uhrStellen(); // beliebig oft wiederholbar
});

uhrStellen();

Der wirksamste Schritt ist aber kein Dialog, sondern das Zwischenspeichern: Eingaben serverseitig oder im sessionStorage sichern, damit ein abgelaufenes Limit nicht das ganze Formular frisst. Das zahlt gleichzeitig auf 3.3.7 Redundante Eingabe und 3.3.4 Fehlervermeidung ein. Muster dafür stehen unter Mehrstufige Formulare.

So testest du es

1. Quelltext nach http-equiv="refresh" durchsuchen. Jeder Wert größer als 0 ist ein Befund – das ist der einzige Teil des Prüfschritts, der sich automatisieren lässt.
2. Zeitlimits inventarisieren: Session-Timeout, Warenkorb-Reservierung, Sitzplatz-Sperre im Ticketshop, Countdown bei Sonderangeboten, Weiterleitungsseiten, automatisch verschwindende Statusmeldungen.
3. Für jedes Limit den Mechanismus prüfen: Gibt es Abschalten, Anpassen oder Verlängern? Erfüllt die Verlängerung alle vier Bedingungen – Vorwarnung, 20 Sekunden, einfache Aktion, zehn Wiederholungen?
4. Der 20-Minuten-Test. So macht es der BITV-Test: Formular halb ausfüllen, 20 Minuten nichts tun, dann absenden. Kommt vorher eine bedienbare Warnung? Überleben die Eingaben? Oder erfährt man erst beim Klick auf „Absenden“, dass alles weg ist?
5. Die Warnung mit dem Screenreader gegenprüfen. Ein Countdown, der nur optisch herunterzählt, existiert für blinde Nutzer nicht. Die Meldung muss den Fokus bekommen oder über eine Live-Region angesagt werden.
6. Statusmeldungen beobachten. Verschwindet ein Hinweis wie „Ihre Änderungen wurden gespeichert“ nach drei Sekunden von selbst? Dann prüfen, ob die Information anderswo dauerhaft verfügbar bleibt.

Häufiger Fehler in der Praxis

Der teuerste Fehler ist die stille Abmeldung. Der Server beendet die Sitzung nach 15 oder 20 Minuten, aber die Oberfläche merkt davon nichts. Man tippt weiter, klickt auf „Absenden“ – und landet auf der Anmeldeseite. Alles weg. Der BITV-Test bewertet genau diesen Fall als nicht erfüllt, und in Formularen zu Anträgen, Versicherungen oder Steuern ist es der Punkt, an dem Menschen aufgeben.

Der zweite ist die zu späte Warnung. Es gibt einen Dialog, aber er erscheint zehn Sekunden vor Ablauf. Die Norm verlangt mindestens 20 Sekunden, und die sind knapp bemessen: Wer mit Screenreader arbeitet, muss die Meldung erst hören, den Knopf finden und ihn ansteuern. Ich würd dir raten, gleich zwei Minuten anzusetzen – es kostet nichts und nimmt den Druck heraus.

Der dritte ist der Countdown ohne Ausweg in Ticket- und Buchungssystemen. „Ihre Reservierung läuft in 07:31 ab“ ist an sich in Ordnung, wenn sich die Frist verlängern lässt. In vielen Systemen kann man nur zuschauen. Hier greift die Ausnahme „Echtzeit-Ereignis“ übrigens nicht: Eine Sitzplatzsperre ist kein Ereignis, sondern eine Geschäftsregel – und Geschäftsregeln lassen sich ändern.

Häufige Fragen

Ist ein Session-Timeout aus Sicherheitsgründen erlaubt?

Ja. Das Kriterium verbietet keine Zeitgrenzen, es verlangt nur, dass Nutzer darauf reagieren können. Ein Timeout aus Sicherheitsgründen bleibt zulässig, braucht aber eine Vorwarnung mit einfacher Verlängerungsmöglichkeit. Wer aus regulatorischen Gründen nicht verlängern darf – im Zahlungsverkehr kommt das vor –, sollte zumindest die Eingaben sichern, damit nach der erneuten Anmeldung nichts neu getippt werden muss. Dies ist keine Rechtsberatung.

Gilt das Kriterium auch für Karussells und Laufschriften?

Nein, dafür ist 2.2.2 Pausieren, beenden, ausblenden zuständig. 2.2.1 betrifft Fristen, nach deren Ablauf etwas passiert – 2.2.2 betrifft Inhalte, die sich von selbst bewegen oder aktualisieren. Ein Karussell mit Zeitschaltung fällt unter 2.2.2, ein Warenkorb mit Ablaufdatum unter 2.2.1.

Wie lang darf eine Sitzung mindestens sein?

Das Kriterium nennt keine Mindestdauer – es geht um die Reaktionsmöglichkeit, nicht um die Länge. Wer das Limit auf über 20 Stunden setzt, fällt unter die Ausnahme und braucht gar nichts weiter. Für alles darunter gilt: Vorwarnung mit mindestens 20 Sekunden Reaktionszeit und mindestens zehn Verlängerungen.

Zählt eine automatisch verschwindende Erfolgsmeldung als Zeitbegrenzung?

Wenn sie wesentliche Informationen vermittelt, ja – der BITV-Test prüft das ausdrücklich. Eine Meldung wie „Gespeichert“ darf verschwinden, wenn der Zustand auch anders erkennbar ist. Eine Meldung wie „Ihr Antrag hat die Nummer 2026-04412“ darf es nicht, weil die Nummer sonst verloren geht. Muster dafür unter Statusmeldungen und 4.1.3.

Was ist mit einer Weiterleitungsseite „Sie werden in 5 Sekunden weitergeleitet“?

Das ist ein Verstoß, wenn die Weiterleitung automatisch erfolgt und sich nicht abschalten lässt. Zulässig sind zwei Varianten: sofort weiterleiten – am besten serverseitig mit Statuscode 301 – oder gar nicht automatisch weiterleiten und stattdessen einen Link anbieten, den der Nutzer selbst anklickt.

Verwandte Themen

• 2.2.2 Pausieren, beenden, ausblenden – Zeitdruck durch Bewegung
• 3.3.4 Fehlervermeidung – verlorene Eingaben als Risiko
• 3.3.7 Redundante Eingabe – Daten nicht zweimal abfragen
• Mehrstufige Formulare – Zwischenspeichern als Muster
• Live-Regionen – damit die Warnung auch angesagt wird