Formular-Fehlermeldungen.

Damit ein Formularfehler als barrierefrei gilt, muss er drei Dinge tun: den Fehler in Text benennen, programmatisch an das fehlerhafte Feld gebunden sein und dem Screenreader angekündigt werden.

Auf den meisten Websites ist das Formular der einzige Konversionspfad — der Ort, an dem aus dem Besucher ein Kunde wird. Ein Barrierefreiheitsfehler im Formular ist deshalb teurer als jeder andere Fehler der Website: Unlesbarer Text auf der Startseite ärgert; ein nicht absendbares Formular kostet Geschäft. Dennoch sind Formulare der am meisten vernachlässigte Bereich, weil meist getestet wird, ohne sie auszufüllen.

Vier Kriterien zusammen

Formularfehler regelt nicht ein Kriterium, sondern vier, die einander ergänzen. Alle vier zusammen zu sehen verhindert den Trugschluss „wir haben eine Fehlermeldung eingebaut, fertig“.

1. 3.3.2 Beschriftungen oder Anweisungen — A. Jedes Feld muss beschriftet und das erwartete Format vorab genannt sein. VOR jedem Fehler.
2. 3.3.1 Fehlererkennung — A. Tritt ein Fehler auf, muss in TEXT mitgeteilt werden, in welchem Feld. Ein roter Rahmen allein genügt nicht.
3. 3.3.3 Fehlervorschlag — AA. Wo möglich, soll auch gesagt werden, wie er zu beheben ist. Nicht „ungültig“, sondern „im Format tt.mm.jjjj eingeben“.
4. 4.1.3 Statusmeldungen — AA. Eine ohne Fokuswechsel erscheinende Meldung muss dem Screenreader angekündigt werden.

Die Logik der Reihenfolge: Die beste Fehlermeldung ist die, die nie entsteht. Deshalb kommt 3.3.2 zuerst — wird die Formaterwartung vorab genannt, sinkt die Fehlerquote. Dann die Benennung des Fehlers, dann der Korrekturvorschlag, dann die Ankündigung. Die meisten Teams machen nur das Zweite und überspringen die anderen drei.

Farbe allein genügt nicht

Der verbreitetste Fehler ist, den Fehler nur visuell zu markieren: Der Rahmen des Feldes wird rot, und sonst geschieht nichts. Das verletzt mehrere WCAG-Klauseln zugleich. Ein Nutzer mit Farbenblindheit kann das Rot nicht unterscheiden; ein Screenreader-Nutzer sieht die Farbe nie; und keiner erfährt, WAS der Fehler ist.

Das richtige Verhalten: Farbe als zusätzliches Zeichen verwenden — nicht als einziges. Der Fehler selbst muss in Text ausgedrückt sein, der Text direkt neben dem fehlerhaften Feld stehen und programmatisch an dieses Feld gebunden sein. Farbe ist eine Betonungsschicht darüber und darf allein keine Information tragen.

Dieselbe Logik gilt für Icons. Ein Ausrufezeichen-Icon neben dem Feld ist ohne Alternativtext für den Screenreader unsichtbar; mit dem Alternativtext „Fehler“ trägt es keine Information. Existiert die Information des Icons bereits als Text, gilt das Icon als dekorativ und bekommt eine leere Alternative.

Die programmatische Bindung: die Meldung ans Feld binden

Dass der Fehlertext auf dem Bildschirm unter dem Feld steht, schafft eine visuelle Beziehung, aber keine programmatische. Fokussiert ein Screenreader-Nutzer das Feld, hört er den Text darunter nicht — denn dieser Text ist nicht Teil der zugänglichen Beschreibung des Feldes. Die Beziehung muss ausdrücklich deklariert werden.

Zwei Dinge geschehen zusammen. Das Feld wird als fehlerhaft markiert, sodass der Screenreader beim Fokus „ungültige Eingabe“ sagt. Und der Fehlertext wird als Beschreibung des Feldes gebunden, sodass auch der Text selbst gelesen wird. Zusammen hört der Nutzer beim Erreichen des Feldes sowohl, dass es fehlerhaft ist, als auch warum.

Ein häufiger Fehler ist, das Feld als fehlerhaft zu markieren, ohne den Text zu binden. Der Nutzer hört dann „ungültige Eingabe“, erfährt aber nicht, was ungültig ist — und kann das Formular nicht korrigieren. Ein halb umgesetztes Barrierefreiheitsmerkmal beunruhigt den Nutzer, statt ihn zu informieren.

Die Ankündigung: die Live-Region

Lädt die Seite beim Absenden nicht neu — und bei den meisten modernen Formularen tut sie das nicht —, erscheint die Ergebnismeldung lautlos auf der Seite. Der sehende Nutzer bemerkt sie; der Screenreader-Nutzer nicht, denn sein Fokus liegt noch auf dem Absenden-Button, und er ahnt nicht, dass sich auf dem Bildschirm etwas geändert hat.

Die Lösung: den Bereich, in dem die Meldung erscheint, als Live-Region markieren. Diese Markierung sagt dem Screenreader: „Ändert sich der Inhalt hier, sag es dem Nutzer.“ Das kritische Detail: Die Live-Region muss auf der Seite existieren, BEVOR sich ihr Inhalt ändert. Eine zusammen mit der Meldung erzeugte Live-Region wird von den meisten Screenreadern nicht angekündigt.

Das richtige Muster ist also, eine leere Live-Region von Anfang an auf der Seite zu halten und die Meldung hineinzuschreiben. In den Dokumentationen wirkt dieses Detail wie eine Randnotiz; in der Praxis macht es den ganzen Unterschied zwischen angekündigter und nicht angekündigter Meldung.

Wird die Live-Region zusammen mit der Meldung geboren, wird die Meldung nie gehört.

Der Ablauf mit drei Zuständen

Damit ein Formular als barrierefrei gilt, müssen alle drei Zustände definiert sein — die meisten Formulare definieren nur zwei. Das Kontaktformular dieser Website trägt alle drei, und die Suite misst jeden einzeln.

1. Wartend — nach dem Druck auf Absenden, bis das Ergebnis kommt. Der Button wird deaktiviert und der Zustand in Text mitgeteilt; eine drehende Animation allein ist für den Screenreader stumm.
2. Erfolgreich — aus der Live-Region angekündigt, in der die Meldung landet, und der Fokus kann zum Ergebnis bewegt werden.
3. Fehlerhaft — der Fehlertext wird aus der Live-Region angekündigt, das fehlerhafte Feld markiert und der Fokus zum ersten fehlerhaften Feld bewegt.

Der Fokuswechsel im letzten Punkt bringt den Nutzer direkt dorthin, wo die Korrektur nötig ist, und macht in langen Formularen einen großen Unterschied. In einem Formular mit zehn Feldern „ein Feld ist fehlerhaft“ zu hören und von oben durchzutabben, um es zu finden, ist eine unnötige Last.

Dazu kommt das Fail-open-Prinzip, das mehr mit Verlässlichkeit als mit Barrierefreiheit zu tun hat: Scheitert die Übermittlung aus technischem Grund, darf der Nutzer nicht in einer Sackgasse landen. Auf dieser Website übergibt der Ablauf, wenn der Server nicht antwortet, an einen E-Mail-Link — der Kanal schließt sich in keinem Fall vollständig. Bei einem Formular, das der einzige Konversionspfad ist, zählt das so viel wie die Barrierefreiheit.

Wie man den Fehlertext schreibt

Ist die technische Seite der Kriterien gelöst, bleibt eine Schreibarbeit — und sie macht oft den größten Unterschied. 3.3.3 „Fehlervorschlag“ verlangt nicht nur die Meldung des Fehlers, sondern, wo möglich, die Nennung der Behebung — und das macht eine Meldung nützlich.

Schlechte Fehlermeldungen ähneln einander: „Ungültige Eingabe“, „Ein Fehler ist aufgetreten“, „Bitte versuchen Sie es erneut“. Keine sagt dem Nutzer, was zu tun ist. Eine gute Meldung trägt drei Dinge — welches Feld, was falsch ist, was zu tun ist. „Die Telefonnummer muss 10-stellig sein; geben Sie sie ohne führende Null ein“ trägt alle drei und lässt den Nutzer nichts raten.

1. Nennen Sie das Feld beim Namen — nicht „dieses Feld“, sondern „E-Mail-Adresse“. Ein Screenreader-Nutzer kann die Meldung ohne Kontext hören.
2. Sagen Sie, was erwartet wird — Format, Länge, erlaubte Zeichen. Ein Beispiel schlägt eine Beschreibung.
3. Vermeiden Sie anklagende Sprache — „dieses Format wurde nicht erkannt“ statt „Sie haben falsch eingegeben“. Der Fehler folgt aus der Erwartung des Formulars, nicht aus dem Nutzer.
4. Kein Fachjargon — „Validierung fehlgeschlagen“ sagt dem Nutzer nichts.
5. Sagen Sie, wie viele Fehler es sind — mit einer Zusammenfassung am Formularanfang gibt „3 Felder sind zu korrigieren“ dem Nutzer den Umfang.

Dazu die Frage des Zeitpunkts. Fehler zu zeigen, während der Nutzer noch tippt — bei jedem Tastendruck zu validieren —, ist nervend und erzeugt für den Screenreader Lärm, denn die Live-Region spricht ununterbrochen. Der richtige Moment ist meist das Verlassen des Feldes; beim Absenden werden alle Fehler gemeinsam gesammelt.

Zuletzt: Die beste Fehlermeldung ist die, die nie entsteht. Steht das erwartete Format von Anfang an unter dem Feld, wird für Daten ein Kalenderwähler angeboten, formatiert das Telefonfeld automatisch — sinkt die Fehlerquote. Barrierefreiheit deckt sich hier vollständig mit Gebrauchstauglichkeit; ein gutes Formular tut unter beiden Überschriften dasselbe.