Das Formular sagt „Fehler“ – aber nicht, wie es weitergeht
Unklare Validierungsfehler kosten Anfragen und schließen Menschen aus. So prüfen Sie Formulare auf verständliche, barrierearme Fehlerbehandlung.
Ein Kontaktformular kann technisch funktionieren und trotzdem Menschen verlieren.
Der Absenden-Button reagiert. Das Backend ist erreichbar. Die Nachricht würde ankommen. Doch nach dem Klick erscheint nur ein roter Rahmen, eine Meldung wie „Ungültige Eingabe“ oder gar nichts Sichtbares an der Stelle, an der der Fehler entstanden ist.
Für die Website ist das ein Validierungsfehler. Für die Person vor dem Bildschirm ist es ein Abbruchgrund.
Der stille Conversion-Blocker
Formulare stehen oft am Ende einer wichtigen Nutzerreise: Anfrage, Registrierung, Terminbuchung, Bewerbung, Bestellung oder Supportfall. Wer bis hierher gekommen ist, hat bereits Interesse gezeigt. Eine schlechte Fehlerbehandlung verliert daher nicht irgendeinen Besuch, sondern häufig einen qualifizierten Kontakt.
Typische Folgen sind:
- wiederholte, erfolglose Absendeversuche,
- falsch korrigierte Felder,
- verlorene Eingaben nach einem Neuladen,
- Abbruch auf Mobilgeräten,
- zusätzliche Supportanfragen,
- Ausschluss von Menschen, die Tastatur, Screenreader, Vergrößerung oder Spracheingabe verwenden.
Das Problem ist selten spektakulär. Gerade deshalb bleibt es lange unbemerkt.
Fünf Red Flags, die sich schnell prüfen lassen
1. Fehler werden nur über Farbe kommuniziert
Ein roter Rahmen allein erklärt weder, welches Feld betroffen ist, noch was korrigiert werden muss. Fehler sollten zusätzlich als verständlicher Text erscheinen.
„Ungültige Eingabe“ ist dabei kaum besser. Hilfreicher wäre beispielsweise: „Bitte geben Sie eine vollständige E-Mail-Adresse ein, zum Beispiel name@firma.de.“
2. Die Meldung ist nicht mit dem Feld verknüpft
Visuell direkt unter einem Eingabefeld platzierter Text kann für sehende Personen eindeutig wirken. Assistive Technik erkennt diese Beziehung jedoch nicht automatisch.
Eine robuste Umsetzung verbindet die Meldung programmatisch mit dem Feld, etwa über aria-describedby. Bei einem Fehler kann zusätzlich aria-invalid="true" gesetzt werden. Entscheidend ist nicht das Attribut allein, sondern dass Name, Status und Erklärung zusammen verständlich ausgegeben werden.
3. Nach dem Absenden bleibt der Fokus am Button
Bei langen Formularen kann ein Fehler weit oberhalb des sichtbaren Bereichs liegen. Bleibt der Tastaturfokus am Absenden-Button, erfahren Nutzerinnen und Nutzer möglicherweise nicht, dass etwas schiefging.
Sinnvoll ist eine klar erkennbare Fehlerzusammenfassung am Formularanfang. Sie sollte die betroffenen Felder benennen und kann Sprunglinks zu ihnen enthalten. Der Fokus kann nach einer fehlgeschlagenen Übermittlung gezielt auf diese Zusammenfassung gesetzt werden.
4. Hinweise existieren nur als Placeholder
Placeholder verschwinden häufig während der Eingabe und ersetzen kein dauerhaftes Label. Formatvorgaben, Pflichtangaben und Beispiele sollten auch dann verfügbar bleiben, wenn bereits Text im Feld steht.
Wer etwa ein Datum in einem bestimmten Format erwartet, sollte dieses Format vor oder direkt am Feld erklären – nicht erst nach dem dritten Fehlversuch.
5. Die Validierung ist unnötig streng
Telefonnummern, Namen, Postleitzahlen und Adressen haben mehr gültige Formen, als viele reguläre Ausdrücke zulassen. Starre Vorgaben erzeugen vermeidbare Fehler.
Validierung sollte falsche oder gefährliche Eingaben abfangen, aber legitime Varianten akzeptieren. Clientseitige Hinweise verbessern die Bedienung; sicherheitsrelevante Prüfung muss trotzdem serverseitig erfolgen.
Ein sinnvoller Prüfablauf
Ein Formular-Audit sollte nicht nur den Happy Path testen. Nützlicher ist eine kleine Fehler-Matrix:
- Alle Pflichtfelder leer absenden.
- Jedes Feld einzeln mit einem falschen Format testen.
- Nur mit Tastatur durch das Formular navigieren.
- Bei 200 bis 400 Prozent Zoom prüfen.
- Auf einem schmalen mobilen Viewport testen.
- Kontrollieren, ob bereits korrekte Eingaben erhalten bleiben.
- Mit Screenreader oder Accessibility Tree prüfen, ob Labels, Fehlerstatus und Beschreibungen verbunden sind.
- Einen Serverfehler simulieren und prüfen, ob eine verständliche, wiederholbare Handlung angeboten wird.
Auch Erfolgsmeldungen gehören dazu. Nach dem Absenden muss eindeutig sein, ob die Anfrage angekommen ist und was als Nächstes passiert.
Was Website-Pflichtencheck dabei untersucht
Bei einer technischen Formularprüfung betrachten wir nicht nur, ob ein Request gesendet wird. Wir prüfen unter anderem:
- sichtbare und programmatische Labels,
- Pflichtfeld- und Format-Hinweise,
- Textqualität der Fehlermeldungen,
- Fokusführung nach fehlgeschlagenen Übermittlungen,
- Tastaturbedienbarkeit,
- Erhalt bereits eingegebener Daten,
- Verhalten bei langsamen oder fehlerhaften Serverantworten,
- mobile Darstellung und Zoom,
- technische Verknüpfung von Feldern und Fehlern,
- Erfolgsmeldungen und tatsächliche Zustellung, soweit sicher testbar.
Das Ergebnis ist keine abstrakte WCAG-Liste, sondern eine priorisierte Übersicht: Was verhindert Abschlüsse, was erschwert die Bedienung und was sollte zuerst behoben werden?
Gute Fehlerbehandlung fühlt sich unspektakulär an
Ein gutes Formular zwingt Menschen nicht, seine Regeln zu erraten. Es sagt früh, was erwartet wird, erklärt Fehler konkret und führt zurück zur richtigen Stelle, ohne Eingaben zu vernichten.
Genau daran erkennt man reife Website-Qualität: nicht daran, dass nie etwas schiefgeht, sondern daran, dass Nutzerinnen und Nutzer nach einem Fehler zuverlässig weiterkommen.
Wenn ein wichtiges Formular Anfragen, Buchungen oder Registrierungen erzeugen soll, lohnt sich ein gezielter Test des Fehlerfalls – bevor echte Interessenten ihn unfreiwillig übernehmen.