Eine Fehlermeldung ist die Rückmeldung in Textform, die benennt, welche Eingabe nicht angenommen wurde und was der Nutzer nun tun kann. Die Fehlervermeidung liegt davor und versucht, den Fall gar nicht eintreten zu lassen. Die Meldung ist damit die zweite Absicherung und taugt nicht als Ausgleich für ein Formular, das zu viel zulässt.
- Fehlermeldung
Rückmeldung in Textform, die benennt, welche Eingabe nicht angenommen wurde und was der Nutzer nun tun kann.
Beispiel: „Die Fehlermeldung stand oben am Seitenanfang, das betroffene Feld lag 800 Pixel darunter.“Auch: Error Message. Im Deutschen meint der Begriff zwei verschiedene Dinge: die Meldung an einem einzelnen Formularfeld und die Systemmeldung nach einem gescheiterten Vorgang. Für beide gelten dieselben Regeln.
Abgrenzung: Ein Hinweis, der eine Eingabe vorab erklärt, ist keine Fehlermeldung. Er gehört zur Microcopy am Feld und steht dort, bevor etwas schiefgeht.
Was in einer brauchbaren Meldung steht
Eine Meldung, die weiterhilft, benennt den Ort, die Ursache und den Weg heraus. „Ungültige Eingabe“ leistet davon nichts. „Die Telefonnummer darf nur Ziffern und ein Plus am Anfang enthalten“ leistet alles, weil daraus die Korrektur direkt folgt.
Der Ton bleibt sachlich. Schuldzuweisungen wie „Sie haben das Datum falsch eingegeben“ helfen niemandem, und ein Fehlercode ohne Klartext verschiebt die Arbeit auf den Leser. Wir empfehlen, jede Meldung einmal laut zu lesen und zu fragen, ob ein Kollege danach wüsste, was zu tun ist.
Barrierefreiheit: der Fehler muss im Text stehen
Das Erfolgskriterium 3.3.1 Error Identification der WCAG 2.2 verlangt auf Stufe A, dass ein automatisch erkannter Fehler benannt und in Textform beschrieben wird. Ein roter Rahmen allein erfüllt das nicht, weil er ohne Farbwahrnehmung verschwindet und von einem Screenreader nicht vorgelesen wird. Genau darauf zielt auch 1.4.1 Use of Color: Farbe darf nie das einzige Mittel sein, das eine Information überträgt. Das Kriterium 3.3.3 Error Suggestion ergänzt auf Stufe AA, dass eine bekannte Korrektur auch vorgeschlagen wird.
Technisch heißt das: Der Meldungstext wird über aria-describedby mit dem Feld verknüpft, das Feld über aria-invalid als fehlerhaft markiert, und die Meldung erscheint in einem Bereich mit der Rolle alert, damit ein Screenreader sie ansagt.
Woran Standardtexte scheitern
„Ein Fehler ist aufgetreten“ nennt weder Ort noch Ursache und lässt nur den Neuversuch. Ebenso unbrauchbar sind Meldungen, die nach vier Sekunden wieder verschwinden und Sammelmeldungen am Seitenanfang, die das betroffene Feld unmarkiert lassen. Der häufigste Schaden entsteht danach: Wenn das Formular beim Neuladen seine Werte verliert, wird aus einem Tippfehler ein Abbruch.
Wann die Prüfung greifen soll
Der Zeitpunkt entscheidet mit darüber, ob eine Meldung hilft. Eine Prüfung, die bei jedem Tastendruck anschlägt, meldet einen Fehler, während die Eingabe noch läuft: Nach dem ersten Zeichen ist jede E-Mail-Adresse unvollständig. Bewährt hat sich, beim Verlassen des Feldes zu prüfen und ab dann bei jeder Änderung erneut, damit eine angezeigte Meldung verschwindet, sobald der Nutzer sie behoben hat.
Zwei Orte, nicht einer
Bei einem längeren Formular gehört die Meldung an zwei Stellen: unmittelbar an das betroffene Feld und zusätzlich als Zusammenfassung über dem Formular. Die Zusammenfassung nennt die Zahl der betroffenen Felder und verlinkt jeden Punkt auf das zugehörige Feld. Wer nur die Sammelmeldung zeigt, lässt den Nutzer suchen. Wer nur am Feld meldet, verbirgt den Fehler, sobald er außerhalb des Bildschirms liegt. Nach dem Absenden springt der Fokus auf die Zusammenfassung, damit ein Screenreader sie erreicht.
Formulierungen, die tragen
Statt | Besser |
|---|---|
Ungültige Eingabe | Die Postleitzahl besteht aus fünf Ziffern |
Pflichtfeld | Wir brauchen deine E-Mail-Adresse, um die Anfrage zu beantworten |
Passwort zu schwach | Mindestens zehn Zeichen, davon eine Ziffer |
Es ist ein Fehler aufgetreten | Die Zahlung wurde abgelehnt. Prüfe die Kartennummer oder wähle eine andere Zahlungsart |
Alle vier Verbesserungen folgen derselben Regel: Die Meldung nennt die Bedingung, die erfüllt sein muss, und nicht den Zustand, der nicht erfüllt ist. Das ist dieselbe Denkweise, die das UX Writing für alle Texte einer Oberfläche verlangt.
Wenn nicht der Nutzer den Fehler gemacht hat
Ein Serverausfall, eine abgelehnte Zahlung oder eine überschrittene Zeitgrenze sind keine Eingabefehler. Die Meldung darf dort nicht klingen, als hätte der Nutzer etwas falsch gemacht. Sie benennt, was nicht geklappt hat, ob die eingegebenen Daten erhalten sind und was als Nächstes zu tun ist. Bei einem Fehler auf Anbieterseite gehört dazu, wie man Hilfe bekommt und ob ein zweiter Versuch sinnvoll ist. Eine Vorgangsnummer hilft dem Support und beruhigt den Nutzer, weil sie zeigt, dass der Fall erfasst wurde.