Meines Erachtens gehört das Fehlermanagement nicht in die digitale Barrierefreiheit, sondern gilt für alle Nutzenden. Es ist ja eher tragi-komisch, dass wir seit fast 30 Jahren digitale Formulalre haben und trotzdem jeden Tag Formulare finden, wo die grundlegenden Patterns eines guten Fehlermanagements nicht beachtet werden.
Die WCAG zum Thema Fehler
Die folgenden WCAG-Kriterien gelten speziell für das Fehler-Management.
3.3 Fehler identifizieren und beschreiben (Error Identification)
•Dieses Kriterium besagt, dass Fehler in Formularen so identifiziert und beschrieben werden müssen, dass Benutzerinnen verstehen können, was falsch ist und wie sie den Fehler beheben können. Zum Beispiel sollten Benutzerinnen darüber informiert werden, wenn sie ein Pflichtfeld leer gelassen haben oder wenn ihre Eingabe ungültig ist.
3.3.1 Fehlererkennung (Error Suggestion)
•Dieses Kriterium verlangt, dass Benutzern bei der Eingabe von Daten in Formularen Fehler automatisch erkannt werden, und ihnen Vorschläge zur Fehlerbehebung gemacht werden. Zum Beispiel könnte eine Webseite Benutzern eine Fehlermeldung anzeigen, wenn ihre E-Mail-Adresse ein ungültiges Format hat, und ihnen dann vorschlagen, die Adresse zu überprüfen und erneut einzugeben.
3.3.2 Labels oder Anweisungen (Labels or Instructions)
•Dieses Kriterium legt fest, dass Formularelemente (wie Textfelder, Dropdown-Listen usw.) klar beschriftet oder mit Anweisungen versehen sein müssen, damit Benutzer verstehen, welche Art von Informationen erwartet werden. Klare Beschriftungen helfen Benutzern auch dabei, Fehler in
Fehler-Toleranz
Formulare sollten wo möglich fehlertolerant sein. In der Regel spielt es zum Beispiel keine Rolle, ob jemand seine Telefonnummer mit Schrägstrich, Bindestrich oder anderen Zeichen dazwischen schreibt. Wenn man in Deutschland lebt, ist es auch relativ unwahrscheinlich, dass man eine andere Ländervorwahl hat – möglich ja, wahrscheinlich nein. Dennoch muss man z.B. bei der Deutschen Bahn seine Länder-Vorwahl eintragen. Manche Bank möchte keine Leerzeichen in der IBAN, mancher Onlineshop möchte keine Leerzeichen in der Kreditkarten-Nummer. Wenn aus irgendeinem Grund eindeutige Nummern notwendig wären, könnte das über die Programmierung problemlos herausgefiltert werden.
Unabhängig davon sollte immer direkt beim Eingabefeld erläutert werden, welche Zeichen erlaubt oder verboten sind. Oft kommt es bei Passwort-Vergaben vor, dass zwar alle möglichen Zeichen gefordert, aus unerfindlichen Gründen aber auch bestimmte Sonderzeichen verboten sind. Zusätzliche Angaben müssen ebenso wie Fehlermeldungen über ARIA described by eindeutig mit dem zugehörigen Eingabefeld verknüpft werden.
Häufig müssen Eingaben in Namensfeldern mindestens drei Zeichen haben, aber viele Asiatinnen haben Namen mit nur zwei Zeichen. Ein großer Unsinn sind auch Select-Felder mit der Auswahl des Landes, in denen alle 300 staatlichen Entitäten der Welt in alphabetischer Folge hinterlegt sind. Das mag bei der UNO Sinn machen, aber das jemand ein deutsches Formular ausfüllt und aus Mikronesien stammt ist sehr unwahrscheinlich. Sowas ließe sich mit einer Auto-Suggest wesentlich besser lösen: Man gibt etwa BRA ein und bekommt alle Staaten angezeigt, die mit Bra anfangen. Select-Felder sind nur für überschaubare Mengen an Optionen sinnvoll. Zumindest sollten bei einem solchen Select-Feld die naheliegenden Optionen am Anfang stehen, bei einer deutsch-sprachigen Person also Deutschland, Schweiz, Österreich und weitere Staaten, in denen Deutsch zu den offiziellen Sprachen gehört.
Wo möglich sollten mehrere Eingabe-Möglichkeiten angeboten werden. Leider muss man sagen, dass zum Beispiel die meisten Kalender-Widgets aus JavaScript-Bibliotheken nicht vernünftig mit der Tastatur bedienbar sind. Es sollte möglich sein, ein Datum einfach per Tastatur einzugeben. Alternativ gibt es auch die Möglichkeit, mit Select-Elementen oder mit Input-Feldern mit dem Attribut Date zu arbeiten.
Wo möglich sollte man eindeutige HTML-Elemente für die Eingabefelder verwenden. Diese können beim Korrigieren der Eingaben hilfreich sein oder beim automatischen Ausfüllen helfen. In HTML gibt es derzeit Attribute für Mail, Telefon und URLs.
Das WCAG-Kriterium 1.3.5 – Identifizierung von Eingabefeldern (Level AA) fordert die Hinterlegung von maschinen-lesbaren Attributen, um den Zweck von Eingabefeldern eindeutig identifizierbar zu machen, wenn sie sich auf die Nutzerin beziehen: Zum Beispiel Name, Wohnort, Telefonnummer und so weiter. Persönlich halte ich das für komplett überflüssig: Sowohl die Browser als auch die assistive Technologien verfügen über entsprechende Funktionalitäten, aber vielleicht ist das bei den zuständigen Leuten noch nicht angekommen. Eine Liste der Attribute gibt es beim Mozilla Developer Network.
Labels, also Beschriftungen, sollten eindeutig und verständlich sein. Schreiben Sie lieber „Vorname“ statt „Name“ oder „Straße“ statt „Anschrift“, wenn genau diese Angaben gemeint sind.
Fehler-Management
Bei langen Formularen sollten alle Fehler sowie die Stellen, an denen sie zu finden sind am Anfang zusammengefasst werden. Für verschiedene behinderte Menschen – und nicht nur für sie – ist es schwierig bis unmöglich, ein langes Formular zu überblicken. Außerdem sollte man mit Sprungankern direkt zu den Fehlerhaften Stellen geführt werden. Wenn es technisch möglich ist, wäre es am besten, wenn nur noch die fehlerhaften Felder angezeigt werden. Persönlich finde ich heutzutage eine dynamische Validierung sinnvoller als das serverseitig zu machen. Es ist ökologischer und auch barrierefreier: Der Screenreader muss jede neu aufgerufene Seite einmal komplett buffern, die blinde Nutzerin muss jede neu geladene Seite ein Stück weit neu erkunden und zum Beispiel das Formular ansteuern.
Lange Formulare sollten über mehrere Unterseiten verteilt werden. Ob es nun statische Seiten oder Tabs sind, ist Geschmackssache. Wichtig ist allerdings, dass einmal getätigte Eingaben automatisch gespeichert werden. Bei statischen und neu geladenen Webseiten sollten Fehlermeldungen direkt im Dokumenten-Titel sowie in der wichtigsten Überschrift untergebracht werden. Bei dynamischen Webseiten kann ARIA alert verwendet werden.
Fehler-Meldungen
Fehlermeldungen sollten so kurz wie möglich, verständlich und hilfreich sein. Bei einem Datum braucht man zum Beispiel ggf. ein Beispiel dafür, wie eine korrekte Eingabe aussieht, zum Beispiel TT.MM.JJJJ.
Fehlermeldungen dürfen nicht nur über Farbe oder andere sensorische Merkmale wie ein eingeblendetes Symbol gekennzeichnet werden. „Prüfen Sie die rot markierten Felder“ wie bei der Deutschen Bahn ist ein No-Go, aber leider nicht nur dort zu finden.
Fügen Sie einen Text wie „Fehler: Korrigieren Sie bitte …“ oder ähnlich mit hilfreichen Infos hinzu. Wie oben erwähnt muss die Fehlermeldung, wenn sie beim jeweiligen Element steht, wo der Fehler aufgetreten ist mit ARIA described by mit dem zugehörigen Eingabefeld verknüpft werden.
Pflichtangaben kennzeichnen
Bei Pflichtangaben sind zwei Wege zu unterscheiden, die beide erfüllt werden sollten:
- Wenn Symbole wie der Stern verwendet werden, muss die Bedeutung des Symbols AM ANFANG des Formulars beschrieben werden. Wenn alle Felder Pflichtfelder sind, muss dies ebenfalls am Anfang beschrieben werden. Tatsächlich wird empfohlen, Pflichtfelder textlich wie etwa „Name (Pflichtfeld)“ zu kennzeichnen, wobei Pflichtfeld Teil des maschinenlesbaren Labels ist.
- Unabhängig davon sollten alle Pflichtfelder auch maschinen-lesbar als solche gekennzeichnet werden, zum Beispiel über ARIA required
Zusammenfassung der Eingaben
Bei komplexen und mit Geld verbundenen Eingaben sollten die Eingaben am Ende noch einmal zusammengefasst dargestellt werden. Dabei ist es wichtig, dass zum Beispiel Tabellen richtig formatiert sind. Tabelen werden etwa verwendet, um Informationen wie eingekaufte Produkte, zugehörige Preise und Mehrwertsteuer strukturiert darzustellen.
Anwendungen
Bezüglich Anwendungen hilft uns die WCAG leider nicht weiter. Hier würde ich prüfen, wie schwerwiegend die Fehler sind. Können zum Beispiel Dokumente nicht gespeichert oder Mails nicht verschickt werden, würde ich einen Dialog empfehlen, der durch die Nutzerin aktiv weggeklickt werden muss. Und natürlich hilfreich sein sollte, auch das leider eine Seltenheit.
Handelt es sich um nicht-kritische Fehler, können auch Toast-Messages verwendet werden, darauf bin ich hier ausführlich eingegangen. Nicht-kritisch ist vielleicht eine sehr langsame Internet-Verbindung oder Ähnliches.
Server- und andere Fehlermeldungen
Auch andere Fehlermeldungen sollten verständlich und hilfreich sein. Nerds können mit 500, 400 oder 301 etwas anfangen. Normalsterbliche wissen allerdings nicht, was diese Serverfehler bedeuten und hilfreich sind sie auch nicht.
Das gilt entsprechend für alle Fehler-Meldungen, die auf Webseiten erzeugt werden. Die meisten häufig auftretenden Fehler lassen sich identifizieren. Und tun Sie mir bitte einen Gefallen: Schieben Sie die Fehler nicht auf die Nutzerinnnen. Hinweise wie „Wahrscheinlich haben Sie die URL falsch eingetippt“ bei 404-Fehlermeldungen sind unhöflich und in aller Regel falsch. Wann haben Sie das letzte Mal eine längere URL selbst eingetippt? Eben, es liegt eigentlich immer am Anbieter, der Seiten gelöscht und nicht umgeleitet hat.
Auch andere Hinweise etwa auf Werbeblocker, ausgeschaltetes JavaScript oder fehlende Rechte zur Anzeige von Social-Media-Inhalte sollten so formuliert werden, dass sie für Nicht-Techies verständlich sind.