Fehlermeldungen in Formularen schreiben: So verlieren Sie keine Nutzer

Dieser Leitfaden behandelt Fehlermeldungen in Formularen von Anfang bis Ende: Position, Zeitpunkt, Tonfall, Anforderungen der Barrierefreiheit und eine Checkliste vor dem Start. Für das große Ganze, also Feldanzahl, Aufbau und Buttons, lesen Sie unseren Beitrag zum Formulardesign und seinem Einfluss auf die Conversion. Hier geht es nur um einen Moment: den Text, den Sie zeigen, wenn etwas schiefgeht.

Wir, Talha Aslan und Team, arbeiten seit 2012 an Unternehmenswebsites, Angebotsformularen und Checkout Schritten. Dabei sehen wir zudem immer wieder dasselbe Muster. Besucher wollen das Formular meist abschließen. Allerdings vertreibt sie selten der Fehler selbst, sondern die Art, wie er erklärt wird. Deshalb behandeln wir den Text der Meldung als Teil des Designs.

Welche drei Fragen beantwortet jede gute Fehlermeldung?

Jede Fehlermeldung sollte also drei Fragen beantworten, die sich Nutzer sofort stellen. Erstens: Wo liegt das Problem? Zweitens: Was genau stimmt nicht? Schließlich: Was muss ich tun, damit es klappt? Fehlt eine dieser Antworten, muss der Nutzer raten. Raten kostet zudem Zeit und Geduld.

• Ort: Die Meldung steht neben dem zugehörigen Feld und nennt dessen Namen.
• Ursache: Statt "Ungültige Eingabe" benennt sie das Problem, etwa "In der E-Mail Adresse fehlt das @ Zeichen".
• Lösung: Sie zeigt das erwartete Format, zum Beispiel "Schreiben Sie name@example.com".

Stellen Sie sich zum Beispiel ein Telefonfeld vor, unter dem nur "Fehlerhaft" steht. Soll der Nutzer eine Ländervorwahl ergänzen, Leerzeichen löschen oder fehlt eine Ziffer? Dagegen beantwortet der Satz "Geben Sie Ihre Telefonnummer mit Vorwahl ein, zum Beispiel 030 1234567" alle drei Fragen auf einmal. Daher klappt der zweite Versuch meist sofort.

Dieser Aufbau folgt den Grundsätzen guter Oberflächentexte. Wie wir kurze Texte in Interfaces angehen, beschreiben wir ausführlich in unserem Beitrag UX Writing und Mikrotexte auf der Website. Die Fehlermeldung ist dabei der Teil, der am härtesten geprüft wird.

Was verlangt die WCAG für Fehlermeldungen in Formularen?

Die Web Content Accessibility Guidelines (WCAG) sind der internationale Standard für Barrierefreiheit im Web, herausgegeben vom W3C. Zwei Erfolgskriterien betreffen Fehlermeldungen direkt. Sie bilden somit den Kern für Konformität und gute Nutzererfahrung zugleich.

WCAG 3.3.1 Fehlererkennung (Stufe A) verlangt: Erkennt das System automatisch einen Eingabefehler, muss es das fehlerhafte Element kennzeichnen und den Fehler in Textform beschreiben. Laut W3C genügt es daher nicht, das Formular nach dem Absenden einfach ohne Hinweis erneut anzuzeigen. Farbe oder Icons dürfen Sie ergänzen. Der Text selbst ist allerdings Pflicht.

WCAG 3.3.3 Korrekturvorschlag (Stufe AA) geht einen Schritt weiter. Kennt das System den Fehler und eine mögliche Korrektur, sollten Sie dem Nutzer einen Vorschlag machen. Die einzige Ausnahme gilt, wenn ein Vorschlag die Sicherheit oder den Zweck des Inhalts gefährden würde. Beim Login nennen Sie also nie das richtige Passwort.

Kurz gesagt beantwortet 3.3.1 die Frage "Was ist falsch?" und 3.3.3 die Frage "Wie behebe ich es?". Einen Überblick über die Anforderungen insgesamt bietet unser Beitrag zur barrierefreien Website nach WCAG und BFSG.

Wo sollte eine Fehlermeldung auf dem Bildschirm stehen?

Die sicherste Position ist direkt unter oder über dem betroffenen Feld. Auch die Richtlinien der Nielsen Norman Group zu Fehlern in Formularen empfehlen, die Meldung neben dem Feld zu platzieren. Denn so müssen sich Nutzer die Meldung nicht merken. Ihr Blick ist also ohnehin schon dort, wo die Korrektur stattfindet.

Andererseits zwingt ein einzelner Hinweis ganz oben im Formular die Nutzer zum Scrollen, vor allem bei langen Formularen. Ebenso problematisch ist ein kleines Warnsymbol, hinter dem sich die Meldung in einem Tooltip versteckt. Solche Symbole übersieht man leicht, und zum Lesen braucht es dann einen zusätzlichen Klick.

• Platzieren Sie die Meldung unter dem Feld, bündig mit dem Label.
• Reservieren Sie vorab Platz, damit das Layout beim Einblenden nicht springt.
• Gibt es mehrere Fehler, steht jeder bei seinem eigenen Feld.
• Schaffen Sie eine klare visuelle Verbindung: gleicher Rahmen, gleiches Icon, geringer Abstand.

Denken Sie bei der Entscheidung zudem an Mobilgeräte. Auf schmalen Bildschirmen rutscht eine Meldung rechts neben dem Feld schnell aus dem sichtbaren Bereich. Daher ist die Position unter dem Feld fast immer die robustere Wahl.

Wann sollte die Inlinevalidierung greifen?

Inlinevalidierung bedeutet, dass Sie jedes Feld schon vor dem Absenden prüfen und eine Rückmeldung geben. Mit dem richtigen Timing hilft das sehr. Mit dem falschen Timing dagegen entsteht eine Oberfläche, die Nutzer schon beim Tippen ermahnt.

Die praktische Regel ist einfach: Prüfen Sie, wenn der Nutzer das Feld verlässt. Der Leitfaden von web.dev zur Formularvalidierung zeigt die Prüfung beim Verlassen des Feldes, also beim Blur Ereignis. Auch NN/g rät davon ab, Fehler vor Abschluss der Eingabe anzuzeigen. Wer nach drei Buchstaben schon "ungültige E-Mail" liest, fühlt sich also zu Unrecht ertappt.

Allerdings gibt es eine Ausnahme. Beginnt ein Nutzer, ein bereits markiertes Feld zu korrigieren, sollte die Meldung verschwinden, sobald der Wert stimmt. So sieht die Person sofort, dass die Korrektur geklappt hat. Kurz gesagt: Fehler spät zeigen, Korrekturen früh bestätigen.

Dieselbe Logik gilt im CSS. Laut web.dev trifft der Selektor :invalid schon vor jeder Interaktion zu, was Nutzer verwirren kann. Stattdessen empfiehlt web.dev :user-invalid, das erst nach einer Interaktion greift. Ein leeres Formular beim Laden rot einzufärben, signalisiert Besuchern einen Fehler, bevor sie überhaupt angefangen haben.

Warum reicht Farbe allein nicht, um Fehler anzuzeigen?

Ein roter Rahmen ist zunächst ein vertrautes Fehlersignal. Allein genügt er allerdings nicht. WCAG 1.4.1 Benutzung von Farbe verlangt, dass Farbe nicht das einzige visuelle Mittel zur Vermittlung von Information ist. Das W3C nennt Pflicht und Fehlerfelder, die nur durch Farbunterschiede markiert sind, ausdrücklich als Verstoß gegen dieses Kriterium.

Menschen mit Farbsehschwäche unterscheiden einen roten Rahmen womöglich nicht von einer grauen Linie. Wer im hellen Sonnenlicht aufs Handy schaut, hat dasselbe Problem. Ergänzen Sie deshalb mindestens ein Signal, das ohne Farbe funktioniert:

• Sichtbarer Text, der den Fehler erklärt (Pflicht).
• Ein Warn oder Ausrufezeichensymbol.
• Dickere oder anders gestaltete Feldrahmen.
• Ein Präfix wie "Fehler:" am Anfang der Meldung.

Prüfen Sie beim Einsatz von Farbe außerdem den Kontrast. Hellroter Text auf zartrosa Grund ist kaum lesbar. Das Verhältnis zwischen Text und Hintergrund messen Sie in Sekunden mit unserem Kontrastrechner. Somit bleibt die Meldung für Menschen mit anderer Farbwahrnehmung und für alle anderen lesbar.

Wie hören Screenreader Nutzer eine Fehlermeldung?

Eine Meldung, die optisch perfekt aussieht, existiert für Screenreader Nutzer womöglich gar nicht. Deshalb müssen Sie die Meldung im Code mit dem Feld verknüpfen. Dafür gibt es drei zentrale Werkzeuge.

1. aria-invalid: Setzen Sie den Wert "true" bei einem Feld, das die Prüfung nicht besteht. MDN rät davon ab, ihn bei leeren Pflichtfeldern zu setzen, bevor der Nutzer das Absenden versucht, denn die Person füllt womöglich noch aus.
2. aria-describedby oder aria-errormessage: Diese Attribute verbinden den Fehlertext mit dem Feld, sodass der Screenreader die Meldung beim Fokus vorliest.
3. Live Region: Sie sorgt dafür, dass der Screenreader die Fehlerübersicht direkt nach dem Absenden ansagt.

Setzen Sie aria-invalid zudem wieder auf "false", sobald das Feld korrekt ist. Sonst liest der Screenreader ein korrigiertes Feld weiterhin als fehlerhaft vor. Nach unserer Erfahrung gehört dieser kleine Synchronisationsfehler zu den häufigsten Barrieren in echten Formularen.

Außerdem zählt das Fokusmanagement. Schlägt das Absenden fehl, setzen Sie den Fokus auf die Fehlerübersicht oder auf das erste fehlerhafte Feld. So verlieren Tastaturnutzer nicht die Orientierung auf der Seite.

Wozu dient eine Fehlerübersicht oberhalb des Formulars?

Eine Fehlerübersicht ist ein Kasten am Anfang des Formulars, der nach einem gescheiterten Absenden alle Fehler auflistet. Bei langen Formularen verschafft sie Überblick: Wie viele Probleme gibt es, und wo? Allein reicht sie allerdings nicht. NN/g rät, sich nicht nur auf eine Übersicht zu verlassen, sondern jeden Fehler auch am Feld zu zeigen.

Eine gute Übersicht hat einige Merkmale. Zunächst nennt sie die Anzahl der Fehler, etwa "Bitte prüfen Sie 2 Felder". Dann listet sie jeden Punkt als Link zum betreffenden Feld. Ein Klick führt den Nutzer also direkt dorthin. Diese Sprungmöglichkeit zum fehlerhaften Feld findet sich auch unter den WCAG Techniken.

Bei kurzen Formularen, etwa einer Newsletteranmeldung mit Name und E-Mail, wirkt eine Übersicht dagegen überladen. Daher empfehlen wir sie für Formulare ab etwa fünf oder sechs Feldern und für mehrstufige Abläufe.

Welche guten und schlechten Beispiele für Fehlermeldungen in Formularen gibt es?

Die folgende Tabelle zeigt schwache Meldungen, die uns in der Praxis oft begegnen, und bessere Alternativen. Es handelt sich um allgemeine Muster. Passen Sie diese also an Ihre eigenen Feldnamen und Regeln an.

Die Zahlen in der Tabelle (8 Zeichen, 5 MB) sind lediglich ein Beispielszenario. Schreiben Sie stattdessen die echten Grenzen Ihres Systems. Stimmen die Regel in der Meldung und die Regel auf dem Server nicht überein, erhalten Nutzer sonst Fehler, obwohl ihre Eingabe korrekt ist.

Wie formulieren Sie Meldungen, ohne Nutzern die Schuld zu geben?

Der Tonfall ist die unsichtbare Hälfte jeder Fehlermeldung. Sätze wie "Sie haben etwas falsch eingegeben" schieben das Problem dem Nutzer zu. Dabei liegt es meist am Formular, das die Regel vorher nicht erklärt hat. Richten Sie den Satz deshalb auf die Situation, nicht auf die Person.

• Schreiben Sie "Die Telefonnummer braucht eine Vorwahl" statt "Sie haben eine falsche Nummer eingegeben".
• Verzichten Sie auf Großbuchstaben und Ausrufezeichen. "FEHLER!" schreit und hilft nicht.
• Streichen Sie zudem Fachbegriffe. "Regex stimmt nicht überein" sagt den meisten Menschen nichts.
• Bleiben Sie kurz. Ein oder zwei Sätze genügen in den meisten Fällen.
• Lassen Sie Witze weg. Für frustrierte Nutzer geht Humor meist nach hinten los.

Andererseits sind übertriebene Entschuldigungen ebenso unnötig. Eine lange Meldung, die mit "Es tut uns sehr leid, leider..." beginnt, verzögert die Lösung. Am besten wirkt ein höflicher, aber direkter Ton. Anders gesagt: Schreiben Sie, was eine hilfsbereite Servicekraft in einem Satz sagen würde.

Achten Sie schließlich auf Konsistenz. Ein Formular, das in einem Feld siezt und im nächsten duzt, verspielt Vertrauen. Binden Sie Ihre Meldungen daher an einen einheitlichen Styleguide und nutzen Sie in allen Formularen dieselben Muster.

Welche Textmuster passen zu welchem Feldtyp?

Jeder Feldtyp hat seine typischen Fehlerursachen. Die folgenden Muster eignen sich als Ausgangspunkt. Danach passen Sie diese an Ihre eigenen Regeln an.

• E-Mail: Fehlendes @ Zeichen, fehlende Domain oder Leerzeichen. Zeigen Sie das erwartete Format in der Meldung.
• Telefon: Anzahl der Ziffern und Vorwahl. Entfernen Sie Leerzeichen und Striche nach Möglichkeit automatisch.
• Datum: Vergangene Tage, Ruhetage oder falsches Format. Nutzen Sie eine Datumsauswahl, deaktivieren Sie nicht verfügbare Tage von Anfang an.
• Passwort: Listen Sie die Regeln vorab unter dem Feld und markieren Sie jede erfüllte Regel.
• Datei: Größenlimit und erlaubte Formate. Nennen Sie beides schon neben der Upload Schaltfläche.
• Steuernummer oder Kennziffer: Nennen Sie die Anzahl der Stellen. Den Prüfalgorithmus erklären Sie allerdings nicht im Detail.

NN/g empfiehlt zudem, erfolgreiche Eingaben bei komplexen Feldern zu bestätigen, etwa mit einer Anzeige der Passwortstärke oder einer Prüfung, ob ein Benutzername frei ist. Bei einfachen Feldern wie dem Namen erzeugt ein grünes Häkchen nach jedem Buchstaben dagegen nur visuelles Rauschen.

Bei Terminformularen erzeugt zum Beispiel das Datumsfeld oft die meisten Fehler. Den Aufbau solcher Formulare beschreiben wir im Beitrag Formulare für Termin, Angebot und Demo optimieren.

Wie erklären Sie Server und Systemfehler?

Manche Fehler entstehen nicht durch die Eingabe, sondern im System: eine abgebrochene Verbindung, eine abgelaufene Sitzung, ein Zahlungsanbieter ohne Antwort oder ein Serverfehler. Der Nutzer hat in diesen Fällen nichts falsch gemacht. Die Meldung sollte das folglich auch deutlich sagen.

Eine gute Systemmeldung beantwortet deshalb drei Dinge. Was ist passiert? Sind meine Angaben verloren? Was kann ich jetzt tun? Konkret könnte sie lauten: "Die Verbindung ist abgebrochen. Ihre Angaben stehen noch auf dieser Seite; prüfen Sie Ihre Internetverbindung und senden Sie das Formular erneut." Dieser Text verhindert Panik und zeigt den nächsten Schritt.

Bieten Sie außerdem einen alternativen Kontaktweg an. Scheitert das Formular wiederholt, zeigen Sie eine Telefonnummer oder eine E-Mail Adresse. So kostet Sie ein technisches Problem keinen potenziellen Kunden.

Fehlercodes müssen Sie nicht vollständig verstecken. Damit Ihr Support das Problem schneller findet, können Sie klein unter der Meldung einen Referenzcode ergänzen. Der Hauptsatz bleibt trotzdem in verständlicher Sprache.

Warum sollten Eingaben nach einem Fehler erhalten bleiben?

Der schnellste Weg, einen Nutzer zu verlieren: das ganze Formular wegen eines einzigen Fehlers leeren. Wer zehn Felder ausgefüllt hat und danach alles gelöscht sieht, schließt sehr wahrscheinlich den Tab. Behalten Sie die Werte deshalb in den Feldern, auch wenn die Seite neu lädt.

Allerdings gibt es Felder, die Sie aus Sicherheitsgründen leeren müssen. Passwörter und Kartenprüfnummern füllen Sie nicht erneut aus. Erklären Sie dann kurz den Grund: "Bitte geben Sie Ihr Passwort zu Ihrer Sicherheit erneut ein."

Löschen Sie auch den fehlerhaften Wert nicht. Sieht der Nutzer, was er geschrieben hat, korrigiert er schneller. Bleibt etwa "anna@gmial.com" im Feld stehen, fällt der Tippfehler sofort auf. Wer den Wert löscht und nur "ungültige E-Mail" schreibt, zwingt die Person dagegen zum Neuanfang.

Bei mehrstufigen Formularen ist diese Regel noch wichtiger. Drückt der Nutzer auf Zurück, müssen die Daten des vorherigen Schritts noch da sein. In den Formularen, die wir bauen, testen wir deshalb immer, ob die Daten den Wechsel zwischen den Schritten überstehen.

Wie verhindern Sie Fehler, bevor sie entstehen?

Die beste Fehlermeldung ist die, die Sie nie zeigen müssen. Erklären Sie die Regel vor dem Fehler statt danach, sinkt die Fehlerzahl ganz von selbst. Auch web.dev empfiehlt, Prüfregeln vorab zu kommunizieren und die Erklärung per aria-describedby mit dem Feld zu verbinden.

• Sichtbares Label: Nutzen Sie den Platzhaltertext nicht als Label, denn er verschwindet beim Tippen.
• Formathinweis: Zeigen Sie Beispiele wie "TT.MM.JJJJ" oder "030 1234567" unter dem Feld.
• Passender Eingabetyp: Wählen Sie den richtigen Typ für E-Mail, Telefon und Zahlen; so öffnet das Handy die passende Tastatur.
• Tolerante Eingabe: Leerzeichen, Striche oder Klammern entfernt das System selbst, statt Nutzer zu warnen.
• Weniger Felder: Fragen Sie keine Daten ab, die Sie nicht brauchen.

Der letzte Punkt wirkt tatsächlich am stärksten. Jedes zusätzliche Feld ist eine neue Fehlerquelle. Wie die Feldanzahl das Arbeitsgedächtnis belastet, zeigt unser Beitrag zur kognitiven Belastung durch Formularfelder.

Die eingebaute Browservalidierung können Sie als Basis nutzen. Das W3C weist allerdings darauf hin, dass eingebaute Meldungen allgemein bleiben, verschwinden und beim Zoomen nicht mitwachsen können. Daher empfehlen wir, den Meldungstext selbst zu schreiben.

Wie sollten Fehlermeldungen in Formularen auf dem Handy aussehen?

Auf dem Handy ist der Bildschirm schmal, und die Tastatur verdeckt zudem die Hälfte. Eine Meldung, die am Desktop gut aussieht, verschwindet dann womöglich unter der Tastatur. Für Fehlermeldungen in Formularen auf Mobilgeräten gilt deshalb zuerst: Die Meldung steht direkt unter dem Feld, und die Seite scrollt sie beim Fokus in den sichtbaren Bereich.

Schlägt das Absenden fehl, führen Sie den Nutzer zum ersten fehlerhaften Feld. Sonst tippt die Person auf den Button, glaubt, nichts sei passiert, und tippt immer wieder. Eine Übersicht ganz oben bleibt für jemanden, der unten auf den Button schaut, schlicht unsichtbar.

• Wählen Sie eine gut lesbare Schriftgröße und vermeiden Sie sehr kleine Schrift.
• Lassen Sie genug Abstand zwischen Meldung und nächstem Feld.
• Zeigen Sie Fehler nicht in einem Modal, denn mobil lässt es sich schwer schließen.
• Deaktivieren Sie den Senden Button bei Fehlern, erklären Sie den Grund in sichtbarem Text.

Beispielszenario: Eine Nutzerin füllt das Angebotsformular eines Dienstleisters am Handy aus und lässt das Feld für den Ort leer. Die Meldung erscheint oben auf der Seite, während sie unten am Button steht. Sie hält das Formular für defekt und geht. Steht die Meldung dagegen unter dem Feld und springt der Fokus dorthin, bleibt dieser Verlust aus.

Was verraten wiederholte Fehler?

Erhält ein Nutzer im selben Feld immer wieder einen Fehler, liegt das Problem meist im Design, nicht beim Nutzer. NN/g wertet drei oder mehr wiederholte Fehler in einem Durchgang als Zeichen für ein Designproblem und empfiehlt zusätzliche Hilfe.

Diese Hilfe kann verschiedene Formen annehmen. Nach dem zweiten Fehler zeigen Sie etwa eine ausführlichere Erklärung, schlagen einen Beispielwert vor oder blenden Kontaktdaten des Supports ein. Bei einem Feld für die Umsatzsteuer ID könnte zum Beispiel der Hinweis "Kleinunternehmer ohne USt ID lassen das Feld leer" das eigentliche Problem lösen.

Trotzdem sollte die echte Lösung dauerhaft sein. Finden Sie zunächst heraus, welches Feld die meisten Fehler erzeugt. Entscheiden Sie dann, ob Sie die Regel, das Label oder den Hinweis ändern. Zusammengefasst: Wiederholte Fehler sind eine Datenquelle, also nutzen Sie diese, um das Formular zu verbessern.

Wie testen und messen Sie Fehlermeldungen in Formularen?

Ob Fehlermeldungen in Formularen wirklich gut sind, wissen Sie erst nach einem Test. Füllen Sie vor dem Start jedes Feld absichtlich falsch aus: leer lassen, falsches Format, Grenze überschreiten. Prüfen Sie dann jedes Mal, ob eine Meldung erscheint und ob sie die drei Fragen beantwortet.

1. Füllen Sie das Formular nur mit der Tastatur aus und lösen Sie einen Fehler aus. Wohin springt der Fokus?
2. Testen Sie dann denselben Ablauf mit einem Screenreader. Hören Sie die Meldung?
3. Schalten Sie den Bildschirm auf Graustufen. Erkennen Sie das fehlerhafte Feld noch?
4. Zoomen Sie die Seite auf 200 Prozent. Bleibt die Meldung vollständig?
5. Lösen Sie den Fehler am Handy bei geöffneter Tastatur aus. Sehen Sie die Meldung?

Nach dem Start zählen Verhaltensdaten. Konkret zeigen Sitzungsaufzeichnungen und Heatmaps, wo Nutzer hängen bleiben. Die Einrichtung erklären wir in unserem Beitrag zu Microsoft Clarity, Heatmaps und Sitzungsaufzeichnungen. Zudem können Sie Validierungsfehler als eigenes Ereignis an Ihr Analysetool senden und so das schwierigste Feld in Zahlen sehen.

Vergessen Sie außerdem den Moment des Erfolgs nicht. Positive Rückmeldung zählt genauso wie die Fehlermeldung. Dazu passt unser Leitfaden, wie Sie eine Danke Seite nach dem Formular gestalten.

Was gehört auf die Checkliste vor dem Start?

Die folgende Liste können Sie für jedes neue Formular und jede Änderung nutzen. Vor der Übergabe hakt unser Team zudem jeden Punkt einzeln ab.

1. Jede Prüfregel hat einen sichtbaren Fehlertext.
2. Die Meldung steht beim Feld und nennt es.
3. Die Meldung benennt das Problem und schlägt eine Lösung vor (WCAG 3.3.1 und 3.3.3).
4. Text und Icon kennzeichnen den Fehler, nicht nur Farbe (WCAG 1.4.1).
5. Der Kontrast zwischen Meldungstext und Hintergrund reicht aus.
6. Die Prüfung startet beim Verlassen des Feldes, nicht beim Tippen.
7. Nach der Korrektur verschwinden Meldung und aria-invalid Status.
8. Nach einem gescheiterten Absenden springt der Fokus zum ersten Fehler oder zur Übersicht.
9. Eingaben bleiben erhalten, außer bei sensiblen Feldern.
10. Serverfehler zeigen eine verständliche Meldung und einen alternativen Kontaktweg.
11. Die Regeln in der Meldung entsprechen exakt den Regeln auf dem Server.
12. Auf dem Handy verdeckt die Tastatur die Meldung nicht.
13. Anrede und Tonfall sind in allen Formularen einheitlich.

Ein Formular, das diese Liste besteht, lässt Nutzer nie im Fehler stehen. Nach jedem Fehler zeigt es ihnen den nächsten Schritt.

Wie handhaben Sie Fehlermeldungen auf mehrsprachigen Websites?

Läuft Ihre Website in mehreren Sprachen, brauchen Sie für jede Sprache eigene Fehlermeldungen. Denn maschinell übersetzte Meldungen treffen oft den Sinn, aber nicht den Ton. Ein Satz, der auf Türkisch höflich klingt, wirkt auf Deutsch womöglich zu steif oder auf Englisch zu lang.

Wir empfehlen deshalb, alle Meldungen in einer Textdatei mit eigenen Schlüsseln pro Sprache zu verwalten. So aktualisieren Sie bei einer Regeländerung alle Sprachen auf einmal. Datums, Telefon und Postleitzahlformate unterscheiden sich zudem je nach Land. Passen Sie den Formathinweis also an Sprache und Region an.

Achten Sie schließlich auf die Standardmeldungen des Browsers. Weicht die Browsersprache des Besuchers von Ihrer Seitensprache ab, sieht er auf derselben Seite womöglich Hinweise in zwei Sprachen. Eigene Meldungen beseitigen auch dieses Durcheinander.

Welche Fehler sehen wir am häufigsten?

Wenn wir Formulare auf Unternehmenswebsites prüfen, tauchen bestimmte Schwächen immer wieder auf. Diese zu kennen, hilft Ihnen also, das eigene Formular schnell einzuschätzen.

• Eine einzige allgemeine Meldung für alle Felder: "Bitte prüfen Sie das Formular."
• Rote Rahmen überall, sobald die Seite lädt.
• Komplett geleerte Felder nach dem Absenden.
• Nur die Standardblasen des Browsers, deren Wortlaut je nach Browser und Sprache wechselt.
• Werte, die das Frontend annimmt, der Server aber ablehnt.
• Systemmeldungen in einer anderen Sprache als die Website.

Die meisten dieser Schwächen beheben Sie also mit wenigen Zeilen. Manchmal steckt das Problem allerdings im Fundament. Das Formularplugin erlaubt zum Beispiel gar keine eigenen Meldungen. In solchen Fällen kostet ein Neuaufbau oft weniger als ständiges Flicken.

Wer setzt Fehlermeldungen in Formularen auf Ihrer Website um?

Fehlermeldungen in Formularen wirken zunächst wie ein kleines Detail. Dennoch treffen hier Design, Text, Barrierefreiheit und Entwicklung aufeinander. Den Text zu schreiben ist leicht. Ihn zur richtigen Zeit, am richtigen Ort, mit Screenreader Anbindung und passend zu den Serverregeln auszuspielen, ist Teamarbeit.

Wir, Talha Aslan und Team, bauen Formulare in unserem Webdesign Service zusammen mit ihren Fehlerzuständen, nicht nur als Oberfläche. Für jedes Feld schreiben wir Regel, Hinweis und Fehlertext gemeinsam und testen anschließend am Handy und mit der Tastatur. Bestehende Formulare prüfen wir mit derselben Checkliste.

Vermuten Sie, dass Ihr Angebots, Kontakt oder Bestellformular Besucher kostet? Dann fordern Sie über unsere Webdesign Seite ein Angebot an, das Umfang und Zeitplan klärt. So stützt sich Ihr Formular auf geprüfte Regeln statt auf Vermutungen.