Timeouts sind bei vielen Sicherheits-und datenschutz-relevanten Prozessen wichtig. Sie sollen verhindern, dass andere Personen Zugriff auf sensible Daten oder Prozesse bekommen. Sie barrierefrei einzusetzen ist allerdings nicht trivial.
Häufige Probleme
Die häufigsten Probleme, die mir in der Praxis untergekommen sind:
- Der Timeout wird gar nicht angezeigt. Das ist ziemlich häufig. Denken Sie an den timeout in Ihrer Banking-App. Sie loggen sich auf der Banken-Seite ein, es wird ein Code an Ihr Smartphone geschickt und wenn Sie diesen Code nicht innerhalb einer bestimmten Zeitspanne bestätigen wird der Prozess abgebrochen. Das wird aber weder auf der Website noch in der App angezeigt. Gleiches gilt für den Timeout im Online-Banking selbst. Er wird selten angezeigt.
- Die Zeitspanne ist zu kurz: Sie loggen sich ein, holen sich einen Baldrian-Tee, schauen aus dem Fenster, schon fliegen Sie raus und müssen sich neu einloggen. Oft üblich sind drei Minuten.
- Ein Prozess wird abgebrochen: Sie bearbeiten ein längeres Formular, bekommen zwischendurch einen Anruf und wenn Sie wieder auf den Bildschirm schauen sind Sie rausgeflogen und müssen von Neuem beginnen.
Das Problem ist, dass die Zeit-Limits für digitale Profis ausgelegt sind. Personen, die wenig Erfahrung mit dem Internet oder der konkreten Anwendung haben und ein wenig länger brauchen werden nicht berücksichtigt.
Was die WCAG fordert
Schauen wir uns zunächst einmal an, welche Anforderungen die WCAG speziell für diesen Bereich definiert.
SC 2.2.1 Timing adjustable
Entscheidend ist das SC 2.2.1: Timing Adjustable (Level A). Dazu die Anforderungen aus dem Understanding-Dokument, übersetzt mit DeepL:
Für jedes Zeitlimit, das durch den Inhalt festgelegt wird, ist mindestens eine der folgenden Bedingungen erfüllt:
Ausschalten
Der Benutzer kann das Zeitlimit ausschalten, bevor er es sieht; oder
Anpassen
Der Benutzer kann das Zeitlimit in einem weiten Bereich, der mindestens zehnmal so lang ist wie die Standardeinstellung, anpassen, bevor er darauf stößt; oder
Verlängern
Der Benutzer wird vor Ablauf der Zeit gewarnt und hat mindestens 20 Sekunden Zeit, das Zeitlimit mit einer einfachen Aktion (z. B. „Drücken Sie die Leertaste“) zu verlängern, und der Benutzer darf das Zeitlimit mindestens zehnmal verlängern; oder
Echtzeit-Ausnahme
Das Zeitlimit ist ein notwendiger Bestandteil eines Echtzeit-Ereignisses (z. B. einer Auktion), und es gibt keine Alternative zum Zeitlimit; oder
Wesentliche Ausnahme
Das Zeitlimit ist wesentlich und eine Verlängerung würde die Aktivität ungültig machen; oder
20-Stunden-Ausnahme
Das Zeitlimit ist länger als 20 Stunden
Quelle
Das Ausschalten des Zeit-Limits dürfte in den meisten Fällen nicht möglich sein, weil es aus Sicherheitsgründen notwendig ist. Das 20-Stunden-Limit (wie man wohl auf diese Zahl gekommen ist?) dürfte ebenfalls in den meisten Fällen nicht funktionieren: Es ist ja gerade das Ziel von Zeit-Limits, den fremden Zugriff auf Computer zu verhindern und die meisten Personen sitzen nicht 20 Stunden vor ihrem Computer. Bei einem Smartphone wird man meistens aus der Session ausgeloggt, wenn man den Bildschirm ausschaltet und mit sicherheits-relevanten Apps oder Websites interagiert.
Die beste Option ist also eine Verlängerung kurz vor dem Ablaufen des Zeitlimits durch einfache Interaktion.
Erforderlich ist allerdings, dass die Basis-Zeit ausreichend ist. So manche Bank gibt einem gerade einmal drei Minuten, was selbst für einige nicht-behinderte Personen zu kurz sein dürfte.
Ich war sehr überrascht, dass die WCAG in diesem verpflichtenden Kriterium nicht fordert, dass das Zeit-Limit tatsächlich angezeigt wird. Das zuständige Gremium WAI hat da wirklich einen Bock geschossen.
SC 2.2.6 – Timeouts (Stufe AAA)
Dieses AAA-Kriterium ist nicht verpflichtend zu erfüllen.
Benutzer müssen über Folgendes informiert werden:
- Existenz des Timeouts: Die Seite muss klarmachen, dass ein Timeout existiert.
- Dauer des Timeouts: Es muss angegeben werden, wie lange der Benutzer hat, bevor ein Timeout eintritt.
- Einfluss des Timeouts: Was passiert, wenn das Timeout abläuft? Z. B. ob Daten verloren gehen.
Die folgenden Unterschiede bestehen zwischen den beiden Kriterien:
• 2.2.1: Ermöglicht den Benutzern eine aktive Kontrolle über zeitliche Begrenzungen.
• 2.2.6: Bietet lediglich Informationen über das Timeout, ohne notwendigerweise Kontrolle darüber.
Zugänglichkeitsebene:
• 2.2.1: Stufe A (grundlegende Barrierefreiheit).
• 2.2.6: Stufe AAA (höhere Barrierefreiheit).
Verpflichtung zur Anpassbarkeit:
• 2.2.1: Erfordert, dass Benutzer eine Anpassung des Timeouts vornehmen können.
• 2.2.6: Keine Verpflichtung zur Anpassung, nur zur Information.
Ich lasse das mal kommentarlos so stehen. Aus meiner Sicht ist die Anzeige der ablaufenden Zeit UND die Kontrolle der Zeit erforderlich. Ohne Information über die noch zur Verfügung stehenden Zeit kann man nicht einschätzen, ob man einen komplexen Prozess beenden kann. Bank-Anwendungen interpretieren zum Beispiel nicht jede Interaktion, sondern nur solche wie das Absenden eines Formulars als Interaktion. Das heißt, das Lesen der Transaktionen mit Scrollen durch die Tabelle als client-seitige Prozesse zählt in der Regel nicht als Interaktion.
Was sind Ausnahmen?
Ausnahmen sind dort erlaubt, wo die Zeitbegrenzungen elementar sind, als Beispiel werden Auktionen genannt. Auch Online-Prüfungen dürften in diese Kategorie fallen. Eine Verlängerung wegen Behinderung wird administrativ beantragt und in der Anwendung nur ausgeführt, aber nicht vom Prüfling selbst angestoßen.
Das Problem PST 3
Spezifisch für Banken gilt das PST 3, eine Verordnung, die für mehr Sicherheit im Online-Banking sorgen soll. Sie fordert einheitlich bestimmte Sicherheits-Maßnahmen wie die Zwei-Fach-Authentifizierung oder eben den automatischen Logut bei Inaktivität. Diese Zeitspanne soll höchstens fünf Minuten sein.
Fünf Minuten sind für behinderte Menschen eine sehr kurze Zeit. Es gibt große Herausforderungen bei der Eingabe von komplexen Daten wie IBANs, die dann auch auf korrekte Übertragung geprüft werden müssen. Last but not least kann auch das Lesen von Konto-Tabellen länger dauern. Ja, es gibt Profis, die das schnell hinbekommen durch das hohe Tempo der Sprachausgabe. Für viele Blinde ist das aber aufgrund ihrer eher langsamen Arbeitsweise oder der Nutzung der Braillezeile nicht möglich. Zeit-Begrenzungen werden meistens nicht über den Client berechnet: Das heißt, zu scrollen oder ein Akkordeon auszuklappen führt in der Regel nicht zu einer Verlängerung, nur das Aufrrufen einer neuen Seite setzt den Timer zurück. Das wäre meines Erachtens ebenfalls ein Ansatzpunkt, um die Zeitspanne sicher zu verlängern.
Auch das Verwenden von Zwei-Faktor-Authentifizierungen kann deutlich länger dauern als die erlaubte Zeitspanne. Sie beträgt nach meiner Erfahrung wenige Sekunden zwischen dem Auslöser, also dem ersten Faktor und dem Bestätigen, also dem zweiten Faktor.
Erlaubt ist auch ein Ausloggen ohne Datenverlust und Fortsetzung dort, wo man aufgehört hat. Das heißt, wenn man sich in einem Prozess befindet sollte man ihn dort fortsetzen können, wo er unterbrochen wurde und nicht wieder von vorne anfangen müssen. Ein Beispiel ist eine Formularstrecke, die man ohne Verlust bereits eingegebener Informationen dort fortsetzen können soll, an der man unterbrochen wurde. Das erfordert in jedem Fall einen größeren technischen Umbau, da das Zwischen-Speichern von Formular-Daten nur mit JavaScript möglich ist. Bislang scheinen die meisten Formulare dieser Art eher statisch zu arbeiten. Unabhängig davon muss die Person immer ausreichend Zeit haben, um eine Aktion komfortabel abzuschließen. Wenn sie immer bei dem gleichen Formular, nur an verschiedenen Stellen, ausgeloggt wird und sich wieder einloggen muss, ist das nicht wirklich erfreulich für sie.
Timer für Screenreader zugänglich machen
Aus meiner Sicht muss der Timer immer möglichst weit oben und auf jeden Fall vor dem relevanten -Content platziert werden (WCAG-Anforderung Meaningful sequence. Er sollte eine eigene ARIA-Region erhalten, so dass er schnell wieder gefunden werden kann. Der Timer selbst sollte nicht in einer Live-Region sein, da Informationen, die zu oft ausgegeben werden die Sprachausgabe stören.
Der Mechanismus zum Verlängern kurz vor dem Ablauf muss leicht auffindbar und aktivierbar sein. Es bietet sich ein Dialog an, der als Focus Trap eingebunden wird. Nach dem Bestätigen sollte der Fokus zu dem Element zurückkehren, an dem er sich vor dem Öffnen des Dialogs befunden hat.