Fehlermeldungs-Patterns: Inline-Validierung, Error-Summary und aria-invalid

Fehlermeldungen in Formularen sind ein entscheidender Moment der Nutzerinteraktion – und einer, der für Menschen mit Behinderungen besonders kritisch ist. Ein sehender Mausnutzer bemerkt sofort das rot umrandete Feld mit der Fehlermeldung darunter. Ein Screenreader-Nutzer hört möglicherweise nichts von dem Fehler, wenn dieser nicht korrekt mit dem Eingabefeld verknüpft ist. Ein Nutzer mit kognitiven Einschränkungen versteht möglicherweise nicht, was „Ungültige Eingabe" bedeutet, wenn keine konkrete Hilfestellung gegeben wird. Barrierefreie Fehlermeldungen sind klar, spezifisch, programmatisch verknüpft und auf mehreren Wegen wahrnehmbar.

WCAG-Anforderungen für Fehlermeldungen

Vier WCAG-Kriterien betreffen Fehlermeldungen direkt. WCAG 3.3.1 „Error Identification" (Level A) fordert: Wenn ein Fehler automatisch erkannt wird, muss das fehlerhafte Element identifiziert und der Fehler dem Nutzer in Text beschrieben werden. Rot allein reicht nicht – die Fehlermeldung muss als Text vorhanden sein. WCAG 3.3.3 „Error Suggestion" (Level AA) verlangt, dass Korrekturvorschläge angeboten werden, wenn der Fehler bekannt ist und die Sicherheit nicht gefährdet. Statt „Ungültiges Datum" besser „Bitte geben Sie das Datum im Format TT.MM.JJJJ ein". WCAG 3.3.4 „Error Prevention (Legal, Financial, Data)" (Level AA) fordert bei rechtlich bindenden oder finanziellen Transaktionen die Möglichkeit, Eingaben zu überprüfen, zu korrigieren oder rückgängig zu machen. WCAG 4.1.3 „Status Messages" (Level AA) verlangt, dass Statusmeldungen – einschließlich Fehlermeldungen – programmatisch als solche erkennbar sind, ohne den Fokus zu erhalten. Das bedeutet: Fehlermeldungen, die dynamisch erscheinen, müssen als Live-Region oder über Fokus-Management kommuniziert werden.

Inline-Validierung: Echtzeit-Feedback richtig umsetzen

Inline-Validierung zeigt Fehler direkt am betroffenen Feld an, während der Nutzer das Formular ausfüllt. Richtig umgesetzt ist sie extrem hilfreich – der Nutzer muss nicht erst das gesamte Formular absenden, um Fehler zu erfahren. Das empfohlene Pattern: Validierung beim Verlassen des Feldes (`blur`-Event), nicht bei jeder Tastatureingabe. Zu frühes Feedback (nach dem ersten Buchstaben) ist verwirrend und störend. Die Fehlermeldung erscheint unterhalb des Eingabefeldes und wird über `aria-describedby` programmatisch verknüpft. Das Feld erhält `aria-invalid="true"`. Die Fehlermeldung wird in einer `aria-live="polite"`-Region platziert oder das Feld selbst in eine Live-Region eingebettet, damit Screenreader die Meldung vorlesen. Visuell: Die Fehlermeldung sollte rot markiert sein UND ein Fehler-Icon enthalten – Farbe allein reicht nicht (WCAG 1.4.1). Der Rahmen des Feldes wird rot, und ein Warnsymbol verstärkt die visuelle Kommunikation. Bei erfolgreicher Validierung: Entfernen Sie `aria-invalid` und die Fehlermeldung, optional zeigen Sie ein Häkchen als positive Bestätigung.

Error-Summary: Fehlerzusammenfassung am Formularbeginn

Die Error-Summary ist ein bewährtes Pattern, das alle Fehler eines Formulars gebündelt am Seitenbeginn anzeigt – besonders wichtig nach dem Absenden eines Formulars. Das GOV.UK Design System hat dieses Pattern populär gemacht. Die Implementierung: Nach fehlgeschlagener Validierung erscheint eine Zusammenfassung mit der Rolle `role="alert"` oder als `aria-live="assertive"`-Region oberhalb des Formulars. Jeder Fehler in der Zusammenfassung ist ein Link, der zum betroffenen Feld springt – das spart langes Scrollen. Der Fokus wird programmatisch auf die Error-Summary gesetzt, damit Screenreader sie sofort vorlesen. Die Überschrift lautet z.B. „Es sind 3 Fehler aufgetreten" – Anzahl und Schwere werden kommuniziert. Jeder Listeneintrag beschreibt den Fehler spezifisch und verlinkt zum Feld: „Geburtsdatum – Bitte geben Sie ein gültiges Datum ein". Die Error-Summary ersetzt nicht die Inline-Fehlermeldungen am jeweiligen Feld – beides sollte kombiniert werden. Der Nutzer sieht die Übersicht und kann gezielt zu den fehlerhaften Feldern springen, wo die detaillierte Fehlermeldung wartet.

aria-invalid, aria-describedby und aria-errormessage

Die ARIA-Attribute für Fehlermeldungen bilden ein zusammenhängendes System. `aria-invalid="true"` markiert ein Feld als fehlerhaft und wird von Screenreadern angekündigt – NVDA sagt „ungültig", VoiceOver „Ungültiger Wert". Verwenden Sie `aria-invalid` nur, wenn tatsächlich ein Fehler vorliegt, nicht präventiv. `aria-describedby` verknüpft das Eingabefeld mit der Fehlermeldung über deren ID. Wenn das Feld bereits eine Beschreibung hat (z.B. einen Hilfetext), können Sie mehrere IDs durch Leerzeichen getrennt angeben: `aria-describedby="help-text error-msg"`. `aria-errormessage` ist ein neueres Attribut speziell für Fehlermeldungen – es wird von Screenreadern nur vorgelesen, wenn `aria-invalid="true"` gesetzt ist. Der Browser-Support ist jedoch noch nicht universell, weshalb die Kombination aus `aria-invalid` und `aria-describedby` derzeit robuster ist. Entfernen Sie `aria-invalid` und die verknüpfte Fehlermeldung, sobald der Fehler behoben ist – veraltete Fehlermeldungen verwirren. Setzen Sie niemals `aria-invalid="false"` als Standard – lassen Sie das Attribut einfach weg, wenn kein Fehler vorliegt.

Fehlermeldungen verständlich formulieren

Die technische Verknüpfung ist nur die halbe Miete – die Fehlermeldung selbst muss verständlich sein. Vermeiden Sie technische Jargon: Statt „Validierungsfehler" schreiben Sie „Bitte überprüfen Sie Ihre Eingabe". Seien Sie spezifisch: Statt „Ungültige Eingabe" besser „Die Postleitzahl muss 5 Ziffern enthalten". Geben Sie Korrekturhinweise: Statt „Falsches Format" besser „Bitte geben Sie das Datum im Format TT.MM.JJJJ ein, z.B. 15.03.2025". Verwenden Sie einen freundlichen, nicht vorwurfsvollen Ton: „Es fehlt noch eine Angabe" statt „Sie haben ein Pflichtfeld nicht ausgefüllt". Bei komplexen Validierungen (Passwort-Regeln) zeigen Sie eine Checkliste an, die in Echtzeit aktualisiert wird: ✓ Mindestens 8 Zeichen, ✗ Mindestens eine Zahl. Übersetzen Sie System-Fehlermeldungen: „Error 422: Unprocessable Entity" muss in verständliche Sprache übersetzt werden. Berücksichtigen Sie Leichte Sprache – nicht jeder Nutzer versteht Formulierungen wie „Das Pflichtfeld darf nicht leer sein". Und testen Sie Ihre Fehlermeldungen mit echten Nutzern, nicht nur mit Entwicklern.