3.3.3 Fehlerempfehlung

Erkennt ein Formular einen Fehler und weiß, wie er sich beheben lässt, muss es das sagen, außer dies würde die Sicherheit oder den Zweck des Inhalts gefährden.

/ Was es verlangt

3.3.1 sorgt dafür, dass Menschen erfahren, dass etwas nicht stimmt. Dieses Kriterium sorgt dafür, dass sie erfahren, wie sie es richtigstellen. Erkennt das System einen Eingabefehler automatisch und kennt es eine Korrektur, muss es sie anbieten: das erwartete Format, die erlaubten Werte oder den Wert, der vermutlich gemeint war. Ein Eingabefehler ist eine Angabe der Nutzenden, die nicht akzeptiert wird, einschließlich eines leer gelassenen Pflichtfelds. Ohne Vorschlag finden Menschen mit kognitiven Beeinträchtigungen die Korrektur oft nicht, blinde Nutzende stoßen nie auf das Beispiel unter dem Feld, und viele brechen das Formular ab.

Die Anforderung hat zwei Bedingungen und eine Ausnahme. Sie gilt nur, wenn der Fehler automatisch erkannt wird und ein Vorschlag bekannt ist; ein System, das die richtige Antwort nicht kennen kann, hat nichts vorzuschlagen. Sie gilt nicht, wo ein Vorschlag die Sicherheit oder den Zweck des Inhalts gefährden würde: Ein Anmeldeformular verrät nicht das richtige Passwort, ein Test nicht die richtige Antwort. Der Vorschlag darf vom Autor oder vom Benutzeragenten kommen, eine Browsermeldung, die sagt, was fehlt, kann das Kriterium also erfüllen.

/ Woran Seiten scheitern

Ein Datumsfeld weist 5/11/2026 mit der Meldung „Ungültiges Datum“ zurück und nennt nirgends das Format, das es annimmt.
Ein Postleitzahlfeld meldet „Falsche Postleitzahl“, obwohl das System weiß, dass fünf Ziffern erwartet werden.
Ein leer gelassenes Pflichtfeld färbt sich rot und zeigt „Fehler“, aber nichts sagt, was hineingehört.
Ein neues Passwort wird gegen Regeln wie Mindestlänge und eine Ziffer geprüft, und die Meldung lautet nur „Passwort nicht akzeptiert“.
Ein Feld, das nur Werte aus einer festen Liste annimmt, etwa einen Monat oder ein Land, weist einen Tippfehler zurück, ohne den nächstliegenden Wert oder die Liste anzubieten.

/ So prüfen Sie es selbst

Senden Sie jedes Formular mit typischen Fehlern ab: leere Pflichtfelder, falsche Formate, Werte außerhalb des Bereichs und Tippfehler. Nutzen Sie ein Testkonto oder eine Testumgebung, wo ein echtes Absenden eine Bestellung auslösen würde.
Fragen Sie bei jeder Meldung, ob sie sagt, wie die Eingabe zu korrigieren ist, und nicht nur, dass sie falsch ist.
Schlägt eine Meldung nichts vor, entscheiden Sie, ob das System eine Korrektur kennen könnte. Ein vorgegebenes Format, ein Wertebereich oder eine Liste erlaubter Werte heißt: ja.
Wo ein Hinweis zurückgehalten wird, prüfen Sie, ob Sicherheit oder der Zweck des Inhalts der Grund ist, wie bei einem Passwort oder der Antwort in einem Quiz.
Wiederholen Sie den Test mit einem Screenreader wie NVDA und prüfen Sie, ob der Vorschlag mit der Fehlermeldung oder beim Fokussieren des Feldes vorgelesen wird.

/ So beheben Sie es

Formulieren Sie die Meldung als Korrektur: „Geben Sie das Datum als TT.MM.JJJJ ein, zum Beispiel 05.11.2026“ statt „Ungültiges Datum“.
Nennen Sie bei einem Feld mit begrenzter Wertemenge die erlaubten Werte oder bieten Sie den nächstliegenden an, etwa „Meinten Sie Dezember?“.
Verwenden Sie in der Fehlermeldung denselben Formathinweis wie unter dem Feld und verbinden Sie beide mit aria-describedby mit dem input-Element.
Nutzt ein Feld das Attribut pattern, kann der Browser nur sagen, dass das Format nicht passt. Nennen Sie das erwartete Format im Hinweis oder in einer eigenen Meldung.
Nutzen Sie die Sicherheitsausnahme nur, wo ein Hinweis einem Angreifer helfen würde, etwa beim richtigen Passwort. Die Regeln für ein neues Passwort sind kein Geheimnis und gehören in die Meldung.

/ Was unser Scanner prüft

Keine automatische Prüfung in unserem Scan beurteilt, ob eine Fehlermeldung eine Korrektur vorschlägt, denn das ist eine Frage der Worte. In der Browsererweiterung bemerkt der Formulartest Meldungen, die beim Verlassen eines Feldes erscheinen, und meldet sie unter 3.3.1 und 4.1.3, wenn sie nicht verknüpft oder nicht angesagt sind, liest aber nicht, was sie sagen. Er sendet nichts ab, vom Server erzeugte Fehler sieht er also ebenfalls nicht. Die Meldungen liest ein Mensch in der manuellen Prüfung.

/ Wer es verletzt, nach unseren eigenen Messungen

Der wöchentliche Index hat für dieses Kriterium keine Zahlen, weil keine Prüfung des Website-Scans es testen kann. Ein Mensch beurteilt es, und genau dafür gibt es ein manuelles Audit.

Eine Seite je Stelle, automatisch im Wochenrhythmus gemessen. Behebungen seit dem letzten Durchlauf erscheinen beim nächsten, und jede Eintragsseite bietet ein Recht auf Gegendarstellung.

/ Fragen zu diesem Kriterium

Gilt Fehlerempfehlung auch für Anmeldeformulare?

Ja, mit der Ausnahme, die das Kriterium selbst nennt. Es verlangt keinen Vorschlag, der die Sicherheit gefährden würde, ein Anmeldeformular muss also nicht auf das richtige Passwort hinweisen. Es muss aber sagen, was sich gefahrlos sagen lässt, etwa dass ein Feld leer ist oder dass der E-Mail-Adresse das At-Zeichen fehlt.

Reicht die eingebaute Validierungsmeldung des Browsers?

Sie kann reichen. W3C schreibt, dass die Beschreibung des Fehlers vom Autor oder vom Benutzeragenten stammen darf. Die Browsermeldung zu einem E-Mail-Feld ohne At-Zeichen sagt, was fehlt, und das ist ein Vorschlag. Beim Attribut pattern kann der Browser nur sagen, dass das Format nicht passt, das erwartete Format muss also die Seite zeigen.

Welche Stufe hat 3.3.3 Fehlerempfehlung?

Stufe AA, seit WCAG 2.0 und in 2.1 und 2.2 unverändert. Das Kriterium gilt nur, wenn ein Fehler automatisch erkannt wird und eine Korrektur bekannt ist, und nicht, wenn der Vorschlag die Sicherheit oder den Zweck des Inhalts gefährden würde, wie bei der Antwort auf eine Testfrage.

Eigene Seite messen Alle gemessenen Barrieren