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 Fehlermeldung 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.
Wie die Verdrahtung im Markup aussieht
Drei Attribute halten Meldung und Feld zusammen. aria-describedby verbindet das Eingabefeld mit dem Text der Meldung, aria-invalid sagt, dass die Eingabe abgelehnt wurde, und role="alert" sorgt dafür, dass eine neu erscheinende Meldung vorgelesen wird. Ohne diese Verbindung bleibt der Fehler für einen Screenreader eine Farbänderung.
<div class="feld">
<label for="plz">Postleitzahl</label>
<input id="plz" name="plz" inputmode="numeric" autocomplete="postal-code"
aria-describedby="plz-hinweis plz-fehler"
aria-invalid="true">
<p id="plz-hinweis" class="hinweis">Fünf Ziffern, ohne Leerzeichen.</p>
<p id="plz-fehler" class="fehler" role="alert">
Die Postleitzahl besteht aus fünf Ziffern.
</p>
</div>Zwei Feinheiten entscheiden über die Wirkung. Erstens darf aria-describedby mehrere Kennungen tragen; Hinweis und Fehler werden dann nacheinander vorgelesen. Zweitens gehört aria-invalid="true" erst gesetzt, wenn der Fehler tatsächlich vorliegt; steht es von Anfang an im Markup, meldet die Seite jedes leere Pflichtfeld als falsch, bevor jemand etwas eingegeben hat.
Was die eingebaute Prüfung des Browsers abnimmt
Mehr, als die meisten Projekte nutzen. Der Browser prüft Typ, Pflichtangabe, Länge und Muster selbst und hält das Ergebnis in einem Objekt bereit. Mit novalidate am Formular schaltet man nur die eingebauten Sprechblasen ab und behält die Prüfung; die Meldungen schreibt man dann selbst, in der eigenen Sprache und an der eigenen Stelle.
formular.setAttribute('novalidate', ''); // eigene Meldungen, eigene Stelle
feld.addEventListener('blur', () => {
const f = feld.validity;
let text = '';
if (f.valueMissing) text = 'Wir brauchen deine Postleitzahl für die Anfahrt.';
else if (f.patternMismatch) text = 'Die Postleitzahl besteht aus fünf Ziffern.';
feld.setAttribute('aria-invalid', text ? 'true' : 'false');
document.getElementById('plz-fehler').textContent = text;
});Dazu kommt eine CSS-Angabe, die viel Skript erspart: :user-invalid greift erst, wenn jemand ein Feld bearbeitet und wieder verlassen hat. Anders als :invalid färbt sie leere Pflichtfelder beim Laden der Seite nicht rot ein. Alle großen Browser unterstützen sie seit 2023.
Fehlermeldungen in mehrstufigen Formularen
Hier kommt ein vierter Ort dazu: der Schritt selbst. Wer auf Schritt drei einen Fehler aus Schritt eins gemeldet bekommt, braucht einen Weg zurück, der die Eingaben erhält. Bewährt hat sich eine Zusammenfassung oben im Schritt mit Sprungmarken auf die betroffenen Felder, dazu eine Markierung in der Schrittanzeige.
Zwei Regeln halten das zusammen. Geprüft wird beim Verlassen eines Schritts und nicht erst am Ende, damit der Weg zurück kurz bleibt. Und die Eingaben überstehen das Zurückgehen, auch nach einem Neuladen der Seite; was nach einem Fehler verloren geht, ist der häufigste Grund für einen Abbruch.