Fehlermeldung (UX)

Definition: Eine Fehlermeldung (Error Message) ist eine UI-Systemnachricht die den Nutzer darüber informiert dass eine Aktion nicht erfolgreich ausgeführt werden konnte oder eine Eingabe ungültig ist, und ihm Orientierung zur Fehlerkorrektur gibt. Fehlermeldungs-Typen nach Kontext: Formular-Validierungsfehler (Pflichtfeld leer; ungültiges Format; Passwort zu kurz; E-Mail-Format falsch); System-/Netzwerk-Fehler (Verbindung unterbrochen; Server nicht erreichbar; Session abgelaufen); Berechtigungs-/Zugriffsfehler (nicht angemeldet; keine Berechtigung für Aktion); HTTP-Statuscodes im Frontend (404 Not Found; 500 Internal Server Error; 403 Forbidden); Anwendungs-/Geschäftslogik-Fehler (Artikel nicht mehr auf Lager; Gutscheincode ungültig; Buchungszeitraum nicht verfügbar). Kernprinzipien guter Fehlermeldungen nach Jakob Nielsen (Heuristik #9, «Help Users Recognize, Diagnose, and Recover from Errors», 1994; überarbeitet 2020): das Fehler-Problem klar identifizieren (welche Aktion; welches Feld; was genau ist falsch?); in verständlicher Sprache ohne Fachjargon oder Fehlercodes beschreiben; konstruktiven Korrekturvorschlag anbieten; WCAG 3.3.1 (Level A): Fehlermeldungen müssen das betroffene Element identifizieren und den Fehler textlich beschreiben; 3.3.3 (Level AA): wenn Fehler automatisch erkannt werden soll ein Korrekturvorschlag geliefert werden.

Erläuterung

Die systematische Forschung zu Fehlermeldungen im Human-Computer-Interaction-Kontext geht auf Ben Shneiderman (University of Maryland; «Designing the User Interface», Addison-Wesley, 1987) zurück der als erster definierte dass Fehlermeldungen spezifisch (nicht generisch), konstruktiv (Lösung anbieten) und nicht beschuldigend (keine Nutzer-Schuldzuweisung) formuliert sein müssen. Jakob Nielsen formalisierte dies in seiner 10. Usability-Heuristik (Heuristik #9 in der überarbeiteten 2020-Version: «Help users recognize, diagnose, and recover from errors»): Error Messages sollten in einfacher Sprache ausgedrückt werden (kein Fehlercode wie «Error 0x8007000B»); das Problem präzise beschreiben; und einen konstruktiven Lösungsvorschlag enthalten. Luke Wroblewski («Web Form Design: Filling in the Blanks», Rosenfeld Media, 2008) quantifizierte in seiner Formular-Usability-Studie den Einfluss von Inline-Validierung auf die Formular-Completion-Rate: Inline-Validation (direkt am Feld; nach Verlassen des Feldes ausgelöst) erhöhte die Formular-Completion-Rate um 22% und reduzierte die Completion-Zeit um 42% gegenüber Post-Submit-Validierung (Fehlermeldungen nur nach Formular-Absenden); die Studie zeigte außerdem dass spezifische Fehlermeldungen («Ihre E-Mail muss ein @-Zeichen enthalten») gegenüber generischen («Ungültige E-Mail-Adresse») die Formular-Abbruchrate um weitere 15–18% reduzierten. Baymard Institute (2019; «Form Usability» Studie; Analyse von 50 großen E-Commerce-Sites) identifizierte Fehlermeldungs-Design als einen der kritischsten Faktoren für Checkout-Abschlussraten: 61% der getesteten E-Commerce-Sites hatten mangelhaftes Fehler-Design mit generischen Meldungen oder Fehlercodes; 27% zeigten Fehlermeldungen ausschließlich oben im Formular ohne Verbindung zum betroffenen Feld; nur 12% hatten exemplarisches Fehler-Design mit Inline-Anzeige + Summary + konkreten Korrekturvorschlägen. Kate Moran (NNGroup; 2018) untersuchte Micro-Copy in Fehlermeldungen und zeigte dass Ton-of-Voice einen messbaren Einfluss auf Nutzeremotion und -retention hat: anklagende Formulierungen («Sie haben ein Pflichtfeld vergessen») erzeugten signifikant höhere Frustrationswerte als neutrale-konstruktive Formulierungen («E-Mail-Adresse fehlt – bitte ergänzen»).

Formular-Fehlermeldungen: Inline-Validation und WCAG

Inline-Validation – Implementierung und Best Practices: Trigger-Zeitpunkt: On-Blur (beim Verlassen des Feldes): Standard; frühe Rückmeldung; nicht zu aggressiv; On-Submit (nach Absenden): späteste Rückmeldung; höhere Fehler-Akkumulation; On-Input (während Tippen): nur für spezifische Use Cases sinnvoll (Passwort-Stärke-Anzeige; Verfügbarkeitsprüfung Username); zu aggressiv für Standardvalidierung; HTML-Implementierung: <div class="form-field"> <label for="email">E-Mail-Adresse <span aria-hidden="true">*</span></label> <input type="email" id="email" aria-required="true" aria-describedby="email-error" aria-invalid="false"> <span id="email-error" role="alert" class="error-message" hidden>Bitte geben Sie eine gültige E-Mail-Adresse ein (z.B. name@beispiel.de)</span> </div>; JavaScript: bei Fehler: input.setAttribute('aria-invalid', 'true'); errorSpan.removeAttribute('hidden'); errorSpan.focus() oder Summary-Fokus; Visuelles Design: roten Rahmen um Eingabefeld (#CC0000 oder ähnlich; ≥ 3:1 Kontrast gegen Weiß); rotes Fehler-Icon (⚠ oder ✕); Fehlermeldungstext unter dem Feld in Rot; nicht nur Rahmenfarbe (Farbblindheit: zusätzlich Icon + Text); Warnungs-Yellow für nicht-kritische Validierungshinweise (z.B. «Passwort schwach»)
WCAG-Anforderungen für Fehlermeldungen: WCAG 3.3.1 Error Identification (Level A): wenn Fehler automatisch erkannt wird muss das fehlerhafte Element identifiziert werden und der Fehler textlich beschrieben werden; Implementierung: aria-invalid="true" auf dem fehlerhaften Input; aria-describedby="[id-der-fehlermeldung]" auf Input; Fehlermeldungs-Text mit id im DOM; WCAG 3.3.3 Error Suggestion (Level AA): wenn Fehler erkannt wird und Korrekturvorschläge bekannt sind und das Anbieten keine Sicherheitsrisiken erzeugt sollen Korrekturvorschläge angeboten werden; Praxis: «Bitte geben Sie eine gültige E-Mail-Adresse ein» statt nur «Ungültige E-Mail»; WCAG 3.3.4 Error Prevention (Level AA): bei rechtlich verbindlichen, finanziellen oder datenlöschenden Aktionen: Reversibilität (Undo) oder Überprüfbarkeit (Bestätigung vor Absenden) oder Korrigierbarkeit (Validierung und Fehlerkorrektur möglich); Screen-Reader-Ankündigung: role="alert" auf Fehlermeldungs-Container für sofortige Ankündigung bei Erscheinen; aria-live="polite" für nicht-kritische Validierungshinweise; Fokus-Management: nach Submit mit Fehlern: Fokus auf erste Fehlermeldung oder Summary; niemals Seite neu laden und Formular zurücksetzen
Formular-Fehler-Summary und komplexe Formulare: Error Summary Pattern: bei Formularen mit vielen Feldern zusätzlich zu Inline-Errors eine Summary oben im Formular; enthält Liste aller fehlerhaften Felder mit Links (Anker) direkt zum jeweiligen Feld; erscheint nach Submit; Fokus springt automatisch auf Summary; für Screen-Reader-Nutzer besonders wichtig: ohne Summary müssen Nutzer das gesamte Formular re-navigieren; HTML: <div role="alert" aria-label="Es sind 2 Fehler aufgetreten" tabindex="-1" id="error-summary"> <h2>Bitte korrigieren Sie folgende Felder:</h2> <ul> <li><a href="#email">E-Mail-Adresse ist ungültig</a></li> </ul> </div>; Javascript: errorSummary.focus() nach Submit; Anzahl Fehler: «3 Fehler gefunden» in Summary-Heading hilft Nutzern Überblick behalten; Feldwert-Erhalt: nach Submit mit Fehlern müssen bereits eingegebene Werte erhalten bleiben; nur fehlerhafte Felder leeren (oder gar nicht leeren bei Passwort-Feldern aus Sicherheitsgründen)

Fehlermeldungs-Micro-Copy, HTTP-Fehlerseiten und Ton

Fehlermeldungs-Micro-Copy-Prinzipien: Spezifisch statt generisch: «E-Mail-Format ungültig» → «Bitte geben Sie eine gültige E-Mail-Adresse ein (z.B. max@muster.de)»; «Eingabe erforderlich» → «Bitte geben Sie Ihre Postleitzahl ein»; Konstruktiv statt beschuldigend: «Falsche Eingabe» → «Diese Kombination aus E-Mail und Passwort ist uns unbekannt – Passwort vergessen?»; Beschreibend nicht technisch: «Error 422 Unprocessable Entity» → «Ihre Eingabe konnte nicht verarbeitet werden. Bitte überprüfen Sie die markierten Felder»; Konkrete nächste Schritte: «Gutscheincode ungültig» → «Dieser Code wurde bereits verwendet oder ist abgelaufen. Prüfen Sie ob der Code korrekt eingegeben wurde»; Ton: neutral-freundlich; kein «Sie haben vergessen» (Schuldzuweisung); kein «Leider» (Passivität); direktiv und lösungsorientiert; Keine technischen Fachbegriffe; Keine CAPSLOCK-Fehlermeldungen; Nicht übertrieben entschuldigend; Rechtschreibung und Grammatik perfekt (Fehlermeldung mit Tippfehler = Vertrauensverlust)
HTTP-Fehlerseiten UX-Gestaltung: 404 Not Found: häufigste Fehlerseite; schlecht gestaltete 404-Seiten erhöhen Bounce-Rate erheblich; Best-Practice-Elemente: klare Erklärung («Diese Seite existiert nicht mehr oder wurde verschoben»); Suche-Eingabefeld; Link zur Startseite; populäre oder empfohlene Inhalte; optional: humorvolle Illustration (markenkonform); Beispiele: GitHub 404 («Seems this page has gone for a walk»); DropBox 404 (animierte Illustration); 500 Internal Server Error: seltenere aber kritischere Seite; Nutzer verliert Vertrauen wenn keine Information; Best Practice: einfache Erklärung («Ein technisches Problem ist aufgetreten – unsere Entwickler wurden informiert»); Retry-Button; Status-Page-Link (status.domain.com); Service-Rückkehr-Zeitschätzung wenn möglich; 503 Service Unavailable / Maintenance: Maintenance-Seite mit geschätzter Rückkehrszeit; RSS/Twitter-Status-Kanal für Updates; Retry-After HTTP-Header; Offline-Seite (PWA): Service-Worker-gestützte Offline-Fallback-Seite; eigener Inhalt statt Browser-Standardfehler; Countdown oder cached Inhalte
System-Fehlermeldungen und Toasts: Toast-Fehlermeldungen: kurze Fehlermeldungen für nicht-kritische Fehler die nach kurzer Zeit verschwinden; Material Design Toast: untere Bildschirmmitte; max. 2–3 Sekunden sichtbar; nicht für kritische Fehler die Nutzeraktion erfordern; Aria: role="status" (nicht blockierend) oder role="alert" (kritisch; sofort vorgelesen); Modale Fehlerdialoge: nur für Fehler die sofortige Nutzeraktion erfordern (Session abgelaufen; kritischer Datenverlust droht); aria-modal="true"; aria-labelledby auf Dialog-Überschrift; Fokus-Trap; bestätigen/Wiederholen-Buttons; Verbindungsfehler-Pattern: offline-Erkennung (navigator.onLine); «Keine Internetverbindung» mit Retry-Button; Auto-Retry mit exponentialem Backoff; Nutzer über Reconnect informieren (aria-live="polite": «Verbindung wiederhergestellt. Ihre Daten wurden gespeichert»); Session-Timeout-Warnung: WCAG 2.2.1: Nutzer muss bei Timeout gewarnt werden; Warnung mindestens 20 Sekunden vor Timeout; Möglichkeit zur Verlängerung

Praxistipp: Überprüfen Sie alle Fehlermeldungen in Ihren Formularen auf drei Qualitätskriterien: (1) Ist klar welches Feld betroffen ist? (2) Steht da warum es ein Fehler ist (nicht nur «Ungültig»)? (3) Steht da wie der Nutzer es korrigieren kann? Wenn eine Fehlermeldung nur ein Ja für diese drei Fragen hat, umschreiben Sie sie. Zusätzlich: testen Sie alle Fehlermeldungen mit einem Screen-Reader – stellen Sie sicher dass aria-invalid="true" auf fehlerhaften Feldern gesetzt ist und aria-describedby auf die Fehlermeldungs-ID zeigt, da Screen-Reader sonst die Fehlermeldungen nicht ankündigen.