Stufe
A
Seit
WCAG 2.0
Einträge
1 / 193
/ WCAG-Kriterium

2.2.1 Zeiteinteilung anpassbar

Setzt die Seite eine Zeitbegrenzung, muss man sie abschalten, anpassen oder verlängern können, es sei denn, sie gehört zu einem Echtzeitereignis, ist wesentlich oder beträgt mehr als 20 Stunden.

/ Was es verlangt

Alles, was nach einer festgelegten Zeit geschieht, ohne dass die Person es auslöst, ist eine Zeitbegrenzung: eine Sitzung, die nach einer Zeit der Inaktivität abmeldet, ein Bestellvorgang, der den Warenkorb freigibt, ein Quiz mit Countdown, eine Seite, die sich selbst neu lädt oder weiterleitet, eine Meldung, die verschwindet, bevor man sie lesen kann. Blinde Menschen, die die Seite mit Screenreader erkunden, Menschen mit Sehbehinderung, mit eingeschränkter Motorik oder mit kognitiven oder sprachlichen Beeinträchtigungen brauchen unter Umständen ein Vielfaches der Zeit, mit der das Design rechnet. Läuft die Uhr ab, verlieren sie ihre Arbeit oder den Inhalt, den sie gerade lesen.

Für jede Zeitbegrenzung, die der Inhalt setzt, muss eine Möglichkeit gegeben sein. Die Person kann sie abschalten, bevor sie darauf trifft; oder sie vorher in einem weiten Bereich von mindestens dem Zehnfachen des Standardwerts anpassen; oder sie wird vor Ablauf gewarnt, erhält mindestens 20 Sekunden, um mit einer einfachen Handlung zu verlängern, und kann mindestens zehnmal verlängern. Drei Ausnahmen bleiben: ein Echtzeitereignis wie eine Auktion, bei dem keine Alternative möglich ist, eine wesentliche Begrenzung, deren Verlängerung die Aktivität ungültig machen würde, und eine Begrenzung von mehr als 20 Stunden. Ein Timer ist keine Begrenzung, wenn dieselbe Information auf anderem Weg verfügbar ist, und bewegte Inhalte wie ein Karussell regelt 2.2.2.

/ Woran Seiten scheitern

  • Eine Nachrichtenseite lädt sich alle paar Minuten per Meta-Refresh neu und schickt die Lesenden an den Seitenanfang zurück.
  • Eine Dankeseite leitet nach zehn Sekunden mit meta http-equiv="refresh" content="10; url=/" auf die Startseite weiter.
  • Eine angemeldete Sitzung endet nach einer Zeit der Inaktivität ohne Warnung, und das halb ausgefüllte Formular ist verloren.
  • Vor Ablauf der Sitzung erscheint eine Warnung, die aber nur eine Schaltfläche Abmelden bietet oder sich nach wenigen Sekunden selbst schließt.
  • Ein Übungsquiz läuft mit einem Countdown, der sich weder anhalten noch verlängern oder abschalten lässt, obwohl an der Aufgabe nichts von der Zeit abhängt.

/ So prüfen Sie es selbst

  1. Listen Sie jede Zeitbegrenzung der Website auf: Sitzungsablauf, Abmeldung nach Inaktivität, Countdowns, Reservierungen im Bestellvorgang, automatisches Neuladen, zeitgesteuerte Weiterleitungen und Meldungen, die von selbst verschwinden.
  2. Öffnen Sie den Quelltext der Seite und suchen Sie nach http-equiv="refresh". Eine Verzögerung über null, mit oder ohne URL, ist eine Begrenzung, die die Person nicht steuern kann, sofern sie nicht über 20 Stunden liegt.
  3. Lassen Sie eine angemeldete Seite ruhen und messen Sie, wann eine Warnung oder die Abmeldung erscheint. Eine Warnung muss mindestens 20 Sekunden geben und die Sitzung mit einer einfachen Handlung verlängern, und das muss zehnmal gehen.
  4. Suchen Sie vor einer zeitgebundenen Aufgabe eine Einstellung, die die Begrenzung abschaltet oder auf mindestens das Zehnfache des Standardwerts erhöht.
  5. Wiederholen Sie den Warnungstest nur mit der Tastatur und mit einem Screenreader, um zu prüfen, ob die Warnung angesagt wird und die Verlängern-Schaltfläche rechtzeitig erreichbar ist.

/ So beheben Sie es

  • Entfernen Sie Meta-Refresh. Leiten Sie mit einer HTTP-Antwort 301 oder 302 weiter statt mit einer zeitgesteuerten Seite, und lassen Sie wechselnde Inhalte über eine Schaltfläche neu laden.
  • Öffnen Sie vor Sitzungsende einen Dialog, der die verbleibende Zeit nennt und eine Schaltfläche Sitzung verlängern hat, warten Sie mindestens 20 Sekunden auf eine Antwort und erneuern Sie beim Drücken die Sitzung auf dem Server.
  • Bieten Sie zu Beginn einer zeitgebundenen Aufgabe eine Einstellung, die die Begrenzung abschaltet oder verzehnfacht.
  • Lassen Sie Toasts und Statusmeldungen stehen, bis die Person sie schließt, oder stellen Sie dieselbe Information an anderer Stelle bereit, etwa in einer Benachrichtigungsliste.
  • Speichern Sie Formulareingaben laufend, in sessionStorage oder auf dem Server, damit eine abgelaufene Sitzung die Arbeit nicht verwirft.

/ Was unser Scanner prüft

HTML_CodeSniffer läuft auf der gerenderten Seite und meldet ein meta-Element mit http-equiv="refresh", dessen content-Attribut mit einer Ziffer von 1 bis 9 beginnt: Technik F40, wenn content auch url= enthält, F41, wenn die Seite sich selbst neu lädt. Eine Verzögerung von 0 besteht. Die Prüfung meldet auch Verzögerungen jenseits der 20-Stunden-Ausnahme und sieht weder Timer im Skript noch Sitzungsabläufe oder Weiterleitungen, die der Server sendet.

/ Wer es verletzt, nach unseren eigenen Messungen

Gemessene Stellen, die dieses Kriterium verletzen, meiste Vorkommen zuerst
StelleSektorVorkommenWert
Detroitcity · US140

Eine Seite je Stelle, automatisch im Wochenrhythmus gemessen. Behebungen seit dem letzten Durchlauf erscheinen beim nächsten, und jede Eintragsseite bietet ein Recht auf Gegendarstellung.

/ Fragen zu diesem Kriterium

Wie viel Zeit muss eine Warnung vor Sitzungsablauf geben?

Mindestens 20 Sekunden, um mit einer einfachen Handlung zu reagieren, etwa mit einem Klick auf eine Schaltfläche oder der Leertaste, und die Person muss die Begrenzung mindestens zehnmal verlängern können. Die beiden anderen Wege sind, die Begrenzung abschalten oder sie auf mindestens das Zehnfache des Standardwerts setzen zu lassen, bevor man darauf trifft.

Sind Sitzungsabläufe aus Sicherheitsgründen von 2.2.1 ausgenommen?

Nicht automatisch. Das W3C behandelt eine aus Sicherheitsgründen gesetzte Begrenzung als vom Inhalt gesetzt, sie muss das Kriterium also erfüllen, meist über eine Warnung mit Verlängerungsmöglichkeit. Manche Sicherheitsbegrenzungen können als wesentlich gelten, etwa ein zeitbasierter Einmalcode. Begrenzungen außerhalb des Inhalts, durch den Browser oder das Netz, liegen nicht in der Verantwortung der Autoren, solche der eigenen Server der Website dagegen schon.

Verstößt ein Meta-Refresh gegen WCAG 2.2.1?

Ja, wenn er eine Verzögerung hat. Die Fehlertechniken F40 und F41 des W3C beschreiben eine zeitgesteuerte Weiterleitung und ein zeitgesteuertes Neuladen per Meta-Refresh. Eine Verzögerung von null leitet sofort weiter und setzt keine Zeitbegrenzung. Ebenso wenig tut das eine Server-Weiterleitung mit 3xx-Status, die der sauberere Weg ist, Besucher an eine andere Adresse zu schicken.