Fehlertoleranz in Formularen

Ein Beispiel für mangelnde Fehlertoleranz ist der Zwang, Eingaben so zu tätigen, wie es der Anbieter gerne hätte. Die dahinter stehenden Anforderungen oder Konventionen müssen dem Nutzer jedoch nicht unbedingt bekannt sein. So sollten Sie bei Eingabefeldern für Telefonnummern lediglich ein Feld anbieten und in diesem alle Schreibweisen akzeptieren, statt es auf zwei (Vorwahl/Durchwahl) oder sogar drei (mit Ländervorwahl) aufzuteilen. Unterschiedliche Eingaben (+49 - 12 34 - 56 78 90 oder 01234567890) können Sie auch serverseitig auflösen. Gleiches gilt für alle anderen Zahlen- oder Textfelder, in die der Nutzer freie Eingaben machen kann, wie Kreditkartennummern, Datumsangaben etc. Auch hier sollten Sie Eingaben mit und ohne Leerschritte oder Zeichen wie / für die Trennung in Telefonnummern akzeptieren.

Eine Aufteilung in mehrere Felder ist in der Regel nicht barrierefrei zu nutzen, da z. B. ein Label immer nur für ein einziges Formularelement definiert werden kann und somit eine logische Verknüpfung mit weiteren Feldern nicht möglich ist. Besonders für blinde Nutzer ist dies ein Problem – sie werden versuchen, die kompletten Daten im ersten Feld einzugeben und regelmäßig an dieser Stelle scheitern. Bei kalendarischen Daten hat sich mittlerweile durchgesetzt, zusätzlich zu den Eingabe- oder Auswahlfelder für Tag/Monat/Jahr auch noch einen echten Kalender in Form einer Tabelle anzubieten. Dies hat den Vorteil, dass hiermit in einem einzigen Kontrollelement umfassendere Daten (Kalendertage, Kalenderwochen, Wochenenden etc.) angezeigt werden können, womit man dem Nutzer eine Menge Denkarbeit abnimmt.

Sie sollten dem Nutzer bereits vor der Eingabe erklären, was zulässige Eingaben sind und diese Eingaben natürlich in einem zweiten Schritt validieren. Bei einer natürlichen, in der Art der Sache liegenden Begrenzung der Eingabe (z. B. maximal 160 Zeichen bei einem Online-SMS-Versand) können und sollten Sie sogar einen Zähler anbieten, der die verbleibenden Anschläge anzeigt. Generell gilt die Regel bei solchen Begrenzungen: was im maxlength-Attribut steht sollte auch nochmal im Klartext daneben stehen (idealerweise im Label des betreffenden Feldes).

Wenn Sie die Länge von Eingaben begrenzen, dann sollten sich Ihr HTML-Code auch daran halten und nicht stattdessen Fehler provozieren. Uns sind schon einige Passwort-Felder untergekommen bei denen zwar daneben stand, dass ein Passwort nur 16 Zeichen lang sein darf, die dann aber zunächst doch die Eingabe von mehr als 16 Zeichen zuließen, nur um danach eine entsprechende Fehlermeldung auszugeben.

Um beim obigen Kalender-Beispiel zu bleiben: hier kann es sinnvoll sein, nicht mehr wählbare (weil z. B. in der Vergangenheit liegende) Daten kurzerhand nicht mehr anzuzeigen oder zumindest optisch und technisch zu deaktivieren. Wenn in einem Produkt-Konfigurator bestimmte Optionen nicht miteinander kombinierbar sind, dann sollten Sie den Nutzer nicht dahin führen, diese »Fehl«-Konfiguration zu tätigen, nur um ihm hinterher eine Fehlermeldung zu präsentieren. Was nicht geht hat im Formular oder in der Anwendung nichts zu suchen.

Nicht so eilig!

Für Nutzer mit kognitiven Behinderungen stellen Zeitbegrenzungen und ablaufende Sessions ein echte Hürde dar; diese Nutzer haben oftmals nicht die nötige Ausdauer, um komplizierte Abläufe an einem Stück abzuarbeiten. Bei komplexen oder mehrstufigen Formularen sollten Sie daher dem Nutzer die Möglichkeit geben, den Prozess zu unterbrechen, Zwischenstände zu speichern und zu einem späteren Zeitpunkt wieder aufzunehmen. Da es sich bei diesen typischerweise um Anwendungen handelt, bei denen der Nutzer einen Account hat und somit identifizierbar ist, sollte eine Nachverfolgung kein Problem darstellen.

Zum Abschluss sollten Sie dem Nutzer die Möglichkeit geben, seine Eingaben zu kontrollieren. Insbesondere bei Vorgängen mit erheblicher Tragweite sollte erst danach die eigentliche Übernahme der Formulardaten auf den Server geschehen, um den Vorgang abzuschliessen. Bei Änderungen an vorhandenen Datensätzen sollten Sie die nun manipulierte Ursprungsseite nochmals anzeigen, evtl. mit optischen Indikatoren und/oder einer textlichen Zusammenfassung der Änderungen.

Fehlerbehandlung in Formularen

Dass Sie Ihre Nutzer über Fehler informieren sollten versteht sich von selbst. Wie Sie Ihre Nutzer über Fehler informieren ist hingegen eine Frage der Philosophie und des Kontextes innerhalb der Anwendung. Die einzige Regel, die immer und überall gilt: wenn etwas schief geht, dann sollten Sie den Nutzer möglichst schnell und möglichst »laut« benachrichtigen.

Wann und in welcher Intensität dies geschieht ist Gegenstand langer Debatten unter Webdesignern und spiegelt die unterschiedlichen Ansätze der verschiedenen Betriebssysteme wieder. Typische Windows-Anwendungen konfrontieren den Nutzer eher mit zu vielen Meldungen (»Es ist nichts passiert. Bitte drücken Sie OK, um keine Änderungen zu bestätigen«), unixoide Betriebssysteme hingegen sagen nichts, wenn nichts passiert ist (geben also in der Regel auch keine Bestätigungen, wenn ein Vorgang ohne Fehler abgelaufen ist).

Die beste Lösung ist wohl, wie so oft, der goldene Mittelweg zwischen »Zu viel« und »Zu wenig« – wo dieser liegt müssen Sie im Kontext Ihrer Anwendung selbst herausfinden und durch Nutzertests verifizieren. Ein typisches Beispiel von »Zu viel«, das leider viel zu oft im Netz zu finden ist sehen Sie im folgenden Screenshot:

Das Problem bei dieser Fehlermeldung ist, dass der Nutzer den Alert nur per OK wegklicken kann, dann aber nicht zu den fehlerhaften Stellen geführt wird. Wenn Ihr Formular nur aus einer geringen Anzahl Felder besteht und somit die Fehleingaben überschaubar sind, sollten Sie den Nutzer besser einzeln auf die Fehler hinweisen, wie der folgende Screenshot zeigt:

Per JavaScript (z. B. document.forms["bestellung"].name.select();) wird dann beim Bestätigen des Alerts per OK-Button der Fokus direkt auf das jeweilige Eingabefeld gesetzt.

Allerdings hat auch diese Methode ihre Grenzen: ab einer gewissen Anzahl Felder (und damit potenzieller Fehler) erscheint es sinnvoller, diese dem Nutzer nicht als endlose Folge von einzelnen Alerts zu präsentieren, sondern sie als Auflistung im Formular selbst anzuzeigen:

1. <form id="bestellung">
2. […]
3. <h4>Fehler!</h4>
4. <p>Folgende Felder müssen ausgefüllt werden, um Ihre Bestellung abzuschließen:</p>
5. <ol>
6. <li><a href="#label-vorname">Bitte geben Sie Ihren Vornamen ein</a></li>
7. <li><a href="#label-nachname">Bitte geben Sie Ihren Nachnamen ein</a></li>
8. <li><a href="#label-strasse">Bitte geben Sie Ihre Straße ein</a></li>
9. </ol>
10. […]
11. <label for="vorname" id="label-vorname">Vorname:</label>
12. <input type="text" id="vorname">
13. […]

Bei einem statischen Reload der Fehlerseite sollten Sie zusätzlich noch den TITLE der Seite sowie deren primäre Überschrift ändern. Bereits hier sollte der klare Hinweis stehen, dass es sich um eine geänderte Seite mit Hinweisen auf Fehler und nicht um die Bestätigungsseite handelt, da der Titel im Screenreader immer zuerst vorgelesen wird.

Hilfen in Formularen

Wahrnehmbare Hilfen

Selbst wenn Sie in ihren Formularen deutlich darauf hingewiesen haben, welche Felder Pflichtfelder sind, kann und wird es passieren, dass diese Hinweise übersehen werden. In diesem Fall sollten Ihre clientseitige und insbesondere auch die serverseitige Programmierung in der Lage sein, das Formular entsprechend verändert zurückzugeben und nur die fehlenden Eingaben erneut abzufragen.

Dazu gehört auch ein deutlicher Hinweis, welches die fehlerhaften Felder sind. Das kann in Form einer Hervorhebung durch Text, Form und Farbe geschehen. Sie sollten jedoch bedenken, dass ein einfaches Umfärben des Textes z. B. in die Signalfarbe Rot nicht ausreicht, da 8-10% aller Männer auf dieser Welt farbfehlsichtig sind und daher mit diesen vermeintlichen Hilfen nichts anfangen können.

Ebenso problematisch ist die Tatsache, dass verbreitete Screenreader nicht unbedingt immer alles vorlesen, was in einem Formular steht. Um die für die Bearbeitung von Formularen benötigten Tastaturkürzel bereitzustellen kennen manche Screenreader einen sogenannten Formularmodus. Dieser unterscheidet sich vom herkömmlichen Vorlesemodus dadurch, dass in Formularen nur noch die Inhalte der Formularelemente, ihrer Beschriftungen (Label>) und Links (a href="…) vorgelesen werden. Sämtliche anderen Inhalte wie P oder H4 werden ignoriert. Eine elegante Lösung für dieses »Problem«: wenn Ihr Formular ohne diese Texte Gefahr läuft, nicht verstanden zu werden, dann setzen Sie die benötigten Texte in Links und verknüpfen Sie diese mit der id des Labels.

Von diesem Verhalten sind tatsächlich sämtliche Inhalte betroffen, die nicht Formularelemente sind. Eine falsche Strukturierung kann dazu führen, dass vermeintliche Hilfen oder auch konkrete Fragen in einem Formular nicht wahrgenommen werden. So würde ein Screenreader-Programm im folgenden Beispiel lediglich die Label »Ja« und »Nein vorlesen – die eigentliche Frage bliebe dem Nutzer verborgen:

1. <form>
2. […]
3. <p>Möchten Sie Sardellen auf Ihrer Pizza?</p>
4. <input type="radio" name="belag" id="ja" value="anchovis-ja" checked="checked">
5. <label for="ja">Ja</label>
6. <input type="radio" name="belag" id="nein" value="anchovis-nein">
7. <label for="nein">Nein</label>

Die Lösung, hier ein separates Fieldset einzuführen und die Frage als Legende zu hinterlegen würde ein mehr an Code und damit ein Mehr an Komplexität bedeuten, die an dieser Stelle unnötig ist. Die sinnvollere Lösung wäre, die Antwort auf die Frage nicht als Radiobuttons, sondern als Checkbox und die Frage als deren Label. Eine Checkbox erfüllt hier aufgrund des binären Charakters der Antwort (Haken = Ja, kein Haken = Nein) den selben Zweck wie zwei Radiobuttons.

Barrieren können auch durch die mangelhafte Kennzeichnung der Fehleingaben entstehen. Die Hinweise werden oftmals nicht in unmittelbaren Zusammenhang mit dem betreffenden Kontrollelement gezeigt, sondern weit entfernt davon und sind nicht sinnvoll verknüpft. Gerade bei nicht-grafischen Zugangsarten wird so eine Zuordnung schwierig und oft ist es einfacher die gesamte Prozedur von vorne zu beginnen, wenn die Fehlermeldungen nicht sinnvoll mit dem Ort des Fehlers verknüpft sind und diesen so anspringbar machen.

Verständliche Hilfen

Bei Formularen und insbesondere bei Anleitungen und Fehlermeldungen greifen die Regeln der BITV zum allgemeinen Verständnis und zur einfachen Sprache. Demnach sollten Fehlermeldungen wie die folgende eigentlich der Vergangenheit angehören:

Bedienbare Hilfen

Während die Vorgaben zur Verständlichkeit uneingeschränkt anwendbar sind, können Sie andere Regeln der BITV ruhig etwas liberaler auslegen: so darf man den Sinn des generellen Verbots von Pop-Ups in Web-Angeboten mit Anwendungscharakter gerne hinterfragen. Nach strikter Lesart würden hierunter auch Alerts fallen, die jedoch bei korrekter Umsetzung auch in assistiven Programmen gut nutzbar sind und geeignet sind, den Nutzer vor groben Fehlern zu bewahren. Ähnliches gilt für Hilfe-Funktionen innerhalb einer Anwendung oder eines komplexen Ablaufs. Hier kann es durchaus sinnvoll sein, diese in einem separaten (Pop-Up-) Fenster zu öffnen, damit der Nutzer im Bedarfsfall beides im direkten Zugriff hat. Auch diese stellen keine Barriere dar, sondern helfen dabei, welche zu beseitigen.