Inline-Validierung: wann und wie?

Kurz gesagt

Inline-Validierung (inline validation) sagt direkt am Feld, ob ein Wert stimmt. Der Nutzer muss das Formular nicht erst abschicken und den Fehler dann oben auf der Seite suchen.

Die eigentliche Frage ist der Zeitpunkt. Es gibt drei Möglichkeiten: beim Tippen, beim Verlassen des Felds und beim Absenden. Ein falscher Zeitpunkt macht selbst eine gut formulierte Fehlermeldung lästig.

Diese Seite behandelt den Zeitpunkt und wie der Fehler auf dem Screen angekündigt wird. Wie Sie die Meldung selbst formulieren, steht im Muster Fehlermeldungen, den allgemeinen Aufbau eines Formulars beschreibe ich auf der Seite zum Formulardesign.

Wann validieren: drei Zeitpunkte

Abbildung: Drei Zeitpunkte für dasselbe Feld. Die Kästen sind die Schritte des Nutzers, der dick umrandete Kasten ist der Moment, in dem der Fehler zuerst erscheint.

Beim Tippen

Geprüft wird bei jedem Tastendruck. Auf dem Papier ist das die schnellste Rückmeldung. In der Praxis sieht der Nutzer schon nach dem ersten Buchstaben der Adresse die Warnung „ungültige E-Mail“.

Beim Verlassen des Felds

Geprüft wird, wenn der Nutzer das Feld fertig ausgefüllt hat und zum nächsten wechselt. Technisch heißt das blur-Ereignis. Laut Rachel Krause von NN/g sollte ein Fehler in den meisten Fällen erst erscheinen, wenn der Nutzer mit dem Feld fertig ist und zum nächsten geht.

Edward Scott von Baymard sagt dasselbe: Die Gültigkeit eines Felds sollte geprüft werden, wenn der Nutzer es verlässt. Für Felder wie Postleitzahl, Telefon und Kartennummer schlägt er einen zusätzlichen Weg vor. Sie können auch geprüft werden, sobald der Wert die richtige Länge erreicht.

Beim Absenden

Das GOV.UK Design System sieht das anders. Das Validation-Muster rät davon ab, beim Verlassen des Felds zu validieren. Geprüft wird, wenn der Nutzer auf Weiter oder Absenden klickt.

Validierung beim Tippen erlaubt GOV.UK nur unter einer Bedingung: Nutzerforschung muss zeigen, dass sie mehr Probleme löst als sie schafft. Das Beispiel ist ein Zeichenzähler, der warnt, wenn eine Antwort zu lang wird.

Die bekannte 22-%-Studie

Die meistzitierte Zahl zur Inline-Validierung stammt von Luke Wroblewski. In seinem Artikel auf A List Apart vom 1. September 2009 beschreibt er einen Test mit Etre in London. 22 Nutzer zwischen 21 und 49 Jahren probierten sechs Varianten eines Registrierungsformulars aus.

Die Kontrollvariante prüfte erst nach dem Klick auf „Konto erstellen“. In der besten Inline-Variante stieg die Erfolgsquote um 22 %, die Fehler sanken um 22 %. Die Zufriedenheit stieg um 31 %, die Bearbeitungszeit sank um 42 %.

Behalten Sie beim Lesen dieser Zahlen den Kontext im Blick. Es geht um ein einziges Registrierungsformular, 22 Personen und die Oberflächen von 2009. Das Ergebnis verspricht in Ihrem Formular nicht denselben Zuwachs, es zeigt nur die Richtung.

Wertvoller als die Zahlen finde ich den Befund zum Zeitpunkt. In der Variante, die beim Verlassen des Felds prüfte, waren die Teilnehmenden 7 bis 10 Sekunden schneller als in der Variante, die beim Tippen prüfte. Beim Tippen-Prüfen sahen sie einen Fehler, tippten einen weiteren Buchstaben und warteten, ob die Meldung sich ändert. Blieb der Fehler, ging das Spiel von vorn los.

Ausprobieren: ein Formular, drei Zeitpunkte

Das Formular unten hat ein E-Mail- und ein Passwortfeld. Wenn Sie den Zeitpunkt wechseln, ändert sich das Verhalten beider Felder. Die Fehlermeldungen sind in jedem Modus gleich, nur der Moment, in dem sie erscheinen, ist anders.

Im Modus „Beim Tippen“ sehen Sie den Fehler schon beim ersten Buchstaben der E-Mail. Im Modus „Beim Verlassen des Felds“ tippen Sie dieselbe Adresse in Ruhe. Und selbst wenn ein Fehler erscheint, verschwindet er bei dem Buchstaben, mit dem Sie ihn korrigieren.

Im Modus „Beim Absenden“ sehen Sie beide Fehler zusammen in der Übersicht über dem Formular. Ein Klick auf einen Link in der Übersicht setzt den Cursor ins betreffende Feld.

Das Problem mit zu frühen Fehlern

Ein zu früher Fehler sagt dem Nutzer, dass er etwas falsch macht, bevor er fertig ist. Krause schreibt das deutlich: Eine Fehlermeldung zu sehen, bevor man fertig tippen konnte, ist frustrierend.

In Baymards Tests reagierte ein Teilnehmer darauf, dass seine E-Mail als falsch markiert wurde, bevor er sie zu Ende getippt hatte. Laut Scott schadet zu frühe Validierung dem ganzen Erlebnis. Nutzer hörten auf zu tippen, lasen die Meldung und hielten manchmal eine richtige Eingabe für falsch.

Auch in Wroblewskis Test schnitt die Variante am schlechtesten ab, die schon vor und während des Tippens prüfte. Sie hatte die höchste Fehlerquote und die niedrigste Zufriedenheit. Wroblewskis Empfehlung: Offene Antworten erst prüfen, wenn der Nutzer fertig ist.

Bei Feldern mit strengen Regeln wie dem Passwort kann frühe Hilfe sinnvoll sein. Im Test wurden Benutzername und Passwort in jeder Variante beim Tippen mit kurzer Verzögerung geprüft. Wroblewski empfiehlt für solche Fälle Rückmeldung beim Tippen mit einer passenden Verzögerung.

Ich gestalte das lieber nicht als Fehler, sondern als Fortschrittsanzeige neben der Regel.

Ein korrigierter Fehler muss sofort verschwinden

Zur Validierung beim Verlassen des Felds gehört auch, wann der Fehler wieder verschwindet. Laut Scott sollte sich die Fehlermeldung bei jedem Tastendruck aktualisieren und verschwinden, sobald ein gültiger Wert eingegeben ist.

Bei verknüpften Feldern ist diese Regel noch wichtiger. In einem Beispiel aus Baymards Test korrigierte ein Teilnehmer das erste Passwort, aber der Fehler „Passwörter stimmen nicht überein“ blieb, bis er erneut ins Bestätigungsfeld klickte. Laut Scott kann der Nutzer dann glauben, dass sein korrigierter Wert immer noch falsch ist.

Erfolgsmeldungen

Eine Erfolgsmeldung ist die Bestätigung neben einem korrekt eingegebenen Wert: ein Häkchen oder ein kurzer Text wie „Das Format der Adresse stimmt“. In Baymards Tests gaben diese Zeichen den Nutzern ein Gefühl von Fortschritt. Sie mussten auch das ganze Formular nicht noch einmal prüfen.

Krause empfiehlt dagegen Maß zu halten. Für ein Feld, dessen einzige Regel ist, nicht leer zu bleiben, ist eine Erfolgsmeldung überflüssig. Nützlich ist sie, wenn sie Information trägt, etwa ob ein Benutzername frei ist oder wie stark ein Passwort ist.

Aus Wroblewskis Test kamen zwei weitere Lehren. Erfolgsmeldungen, die wieder verschwanden, schnitten schlechter ab als solche, die stehen blieben. Und ein grünes Häkchen allein verwirrte die Teilnehmenden: Heißt es „richtig“ oder „gültig“?

Deshalb kommen die Bestätigungen in der Demo mit Text und erscheinen nur in den zwei Feldern mit Regel. Bei einem einfachen Feld wie dem Namen setze ich keine Bestätigung. Einer von Wroblewskis Teilnehmenden fragte, ob das Häkchen am Namensfeld einen gültigen oder einen richtig geschriebenen Namen bedeutet.

Die Fehlerübersicht

Die Fehlerübersicht ist der Kasten, der sich beim Absenden über dem Formular öffnet und alle Fehler auflistet. Egal welcher Zeitpunkt, beim Absenden zeige ich immer eine Übersicht. Der Nutzer kann auch auf Absenden klicken, ohne die Fehler vom Verlassen der Felder gesehen zu haben.

Die Error-summary-Komponente von GOV.UK legt für diesen Kasten diese Regeln fest:

• Die Übersicht steht ganz oben im Hauptinhalt, vor der Hauptüberschrift (h1) der Seite. Der Tastaturfokus springt zur Übersicht.
• Jeder Eintrag ist ein Link zum fehlerhaften Feld. Bei einer mehrteiligen Frage wie einem Datum führt der Link zum ersten Feld mit Fehler.
• Der Text in der Übersicht ist genau derselbe wie die Fehlermeldung am Feld.
• Die Übersicht erscheint auch bei nur einem einzigen Fehler.

Die Übersicht allein reicht nicht. Krause will, dass sie nicht der einzige Fehlerhinweis ist. Der Nutzer muss das Feld sonst suchen und vergisst die Meldung vielleicht, bis er dort ankommt. Auch GOV.UK verlangt Übersicht und Meldung am Feld zusammen.

Das Validation-Muster ergänzt noch etwas: Bei Fehlern wird dem Seitentitel „Error: “ vorangestellt, damit der Screenreader es möglichst früh vorliest. Auf einer deutschen Seite verwende ich „Fehler: “. Die Eingaben des Nutzers werden auch nicht gelöscht. Wird die Seite neu geladen, stehen seine Werte noch in den Feldern.

Barrierefreiheit: aria-invalid, aria-describedby, WCAG

Für sehende Nutzer funktioniert Inline-Validierung leicht. Für jemanden mit Screenreader muss der Fehler aber mit dem Feld verbunden sein. Ich baue drei Teile zusammen.

1. aria-invalid="true" kommt an das fehlerhafte Feld. Die W3C-Technik ARIA21 schreibt, dass das Attribut nicht vor der Validierung gesetzt werden sollte. Markieren Sie ein leeres Feld beim Laden der Seite nicht als fehlerhaft.

2. aria-describedby verbindet das Feld mit dem Fehlertext. Dieselbe Technik zeigt ein Beispiel, in dem das Feld mit diesem Attribut auf die Fehlermeldung verweist. Kommt der Screenreader zum Feld, liest er nach dem Label auch Hinweis und Fehler vor.

3. Eine Live-Region (aria-live) kündigt den Fehler an, ohne den Fokus vom Feld zu nehmen. Das W3C führt die Technik ARIA19 für 3.3.1 bei Formatfehlern auf. Der Kasten „Was ist passiert?“ in der Demo funktioniert so.

Das stützt sich auf zwei Erfolgskriterien der WCAG 2.2. 3.3.1 Fehlererkennung (Stufe A) verlangt, dass bei automatisch erkannten Fehlern das fehlerhafte Feld benannt und der Fehler in Textform beschrieben wird. Farbe darf helfen, aber nur zusätzlich zum Text.

3.3.3 Hilfe bei Fehlern (Stufe AA) geht einen Schritt weiter. Ist ein Fehler erkannt und ein Korrekturvorschlag bekannt, wird er dem Nutzer gezeigt. Würde das die Sicherheit oder den Zweck des Inhalts gefährden, entfällt die Pflicht.

Die Meldung „Geben Sie die E-Mail-Adresse im Format [email protected] ein“ in der Demo ist so ein Vorschlag, wie 3.3.3 ihn verlangt. Im Passwortfeld wiederhole ich das eingegebene Passwort dagegen nicht in der Meldung, das schwächt meiner Meinung nach die Sicherheit. Dort reicht es, die Regel zu nennen.

Einen ersten Schritt habe ich in der Demo auch umgesetzt: Wie GOV.UK empfiehlt, hat das Formular novalidate, damit die Browser-eigenen Sprechblasen nicht erscheinen. GOV.UK verlangt außerdem immer eine Validierung auf dem Server, weil die Prüfung im Browser ausfallen kann. Auf dem Handy die richtige Tastatur zu öffnen, verringert Fehler ebenfalls von Anfang an. Das beschreibe ich im Muster Tastatur in mobilen Formularen.

Checkliste

Bevor ein Formular mit Inline-Validierung live geht, gehe ich diese Liste durch.

• Beim Tippen erscheint kein Fehler.
• Der Fehler erscheint beim Verlassen des Felds oder beim Absenden.
• Ein korrigierter Fehler verschwindet, sobald ein gültiger Wert eingegeben ist.
• Verknüpfte Felder werden neu geprüft, wenn sich das erste Feld ändert.
• Erfolgsmeldungen gibt es nur bei Feldern mit Regel und immer mit Text.
• Beim Absenden öffnet sich oben eine Übersicht, der Fokus springt dorthin.
• Jeder Eintrag der Übersicht verlinkt das Feld und hat denselben Text.
• Das fehlerhafte Feld hat aria-invalid und aria-describedby.
• Der Fehler wird in Textform beschrieben, nicht nur mit Farbe.
• Es gibt auch eine Validierung auf dem Server.

Meine Notiz

Der Validierungsfehler, den ich in Audits am häufigsten sehe, ist die rote Warnung beim ersten Buchstaben. Das Team baut sie als schnelle Rückmeldung ein. Der Nutzer fühlt sich dagegen gerügt, bevor er überhaupt angefangen hat.

Ich gehe einen Weg zwischen den Quellen. Einen eingegebenen, aber falsch formatierten Wert zeige ich beim Verlassen des Felds. Ein leeres Feld überlasse ich dem Absenden, weil der Nutzer gleich dorthin zurückkehren kann.

Die Entscheidung von GOV.UK für die Validierung beim Absenden nehme ich ebenfalls ernst. In einem kurzen Formular aus Seiten mit je einer Frage funktioniert dieser schlichte Weg gut. In einem langen Checkout- oder Registrierungsformular spart die Validierung beim Verlassen des Felds mehr Zeit.

Wenn Sie nicht wissen, wann Ihr Formular Fehler zeigt, füllen Sie es einmal langsam selbst aus. Wiederholen Sie die Runde dann nur mit der Tastatur und mit einem Screenreader. Im UX Audit übernehme ich diese Prüfung in Ihrem Ablauf.