WCAG 3.3.3: Fehlervorschlag

WCAG 3.3.3 verlangt, dass ein Formular nicht nur meldet, dass eine Eingabe falsch ist, sondern auch sagt, wie sie richtig wäre – vorausgesetzt, das System kennt die Korrektur. Ausgenommen sind Fälle, in denen ein Vorschlag die Sicherheit oder den Zweck des Inhalts gefährden würde, etwa bei Passwörtern oder Prüfungsantworten.

(Englisch: Error Suggestion. Der BIK-BITV-Test nennt den Prüfschritt „Hilfe bei Fehlern“.)

Das Wichtigste in Kürze

• Die Auslösebedingung ist eng: Das Kriterium greift nur, wenn das System den Fehler automatisch erkennt und eine Korrektur kennt.
• Drei Stufen bauen aufeinander auf: 3.3.1 sagt dass und wo, 3.3.3 sagt wie es richtig geht, 3.3.4 verhindert den Schaden bei kritischen Vorgängen.
• Ein erwartetes Format ist immer eine bekannte Korrektur. „Ungültiges Datum“ ohne Formatangabe ist damit praktisch nie zulässig.
• Der Sicherheitsvorbehalt ist die einzige Ausnahme – bei der Anmeldung darf und soll die Meldung unspezifisch bleiben.
• Fehlt jede Validierung, ist 3.3.3 nicht verletzt. Der BITV-Test bewertet das Ausbleiben von Fehlermeldungen nicht negativ – dafür ist 3.3.1 zuständig.
• Der Vorschlag muss ankommen: Er gehört mit aria-describedby an das Feld gebunden und bei dynamischer Prüfung in eine Live-Region.
• Der häufigste Verstoß ist die Meldung „Ungültige Eingabe“ – Diagnose ohne Therapie.
• Großzügige Eingabetoleranz ist die bessere Lösung als jeder Vorschlag: Leerzeichen in der IBAN einfach entfernen, statt sie zu bemängeln.

Muss ich sagen, wie der Fehler zu beheben ist?

Ja, sofern das System die Korrektur kennt. Dann muss die Meldung nicht nur benennen, dass etwas falsch ist, sondern auch, wie es richtig wäre.

Der Normtext hat zwei Bedingungen, die beide erfüllt sein müssen: Der Fehler wird automatisch erkannt, und eine Korrektur ist bekannt. Erst dann entsteht die Pflicht, den Vorschlag auch zu nennen. Das Kriterium verlangt also keine Wundertechnik – es verlangt, dass vorhandenes Wissen weitergegeben wird.

Und dieses Wissen ist in der Regel da. Wenn das System weiß, dass ein Datum ungültig ist, kennt es das erwartete Format. Wenn es weiß, dass eine E-Mail-Adresse kein „@“ enthält, kennt es die Regel. Wenn es weiß, dass ein Pflichtfeld leer ist, kennt es den Namen des Feldes. Genau deshalb ist „Ungültige Eingabe“ so gut wie immer ein Verstoß: Die Information war vorhanden und wurde nicht ausgegeben.

Typische Fälle und was jeweils dazugehört:

Die Grenze zieht der Sicherheitsvorbehalt. Bei der Anmeldung darf die Meldung nicht verraten, ob Benutzername oder Passwort falsch war – und schon gar nicht, wie das Passwort aussehen müsste. Der BITV-Test hält dazu ausdrücklich fest, dass sicherheitskritische Meldungen keine spezifischen Korrekturhinweise enthalten müssen. Dasselbe gilt für Prüfungen und Quiz: Ein Vorschlag würde den Zweck zerstören.

Ein Detail, das in Prüfberichten regelmäßig falsch landet: Wenn ein Formular überhaupt keine Fehlermeldungen ausgibt, ist 3.3.3 nicht verletzt. Der BITV-Test bewertet das Ausbleiben nicht negativ. Der Befund gehört dann zu 3.3.1 Fehlererkennung, weil dort die Erkennung selbst verlangt wird.

Der vollständige Wortlaut steht im Understanding-Dokument des W3C zu 3.3.3; das deutsche Prüfvorgehen beschreibt der Prüfschritt 3.3.3 des BIK BITV-Tests.

Wen betrifft es besonders?

Menschen mit kognitiven Einschränkungen, Legasthenie oder Konzentrationsschwierigkeiten können aus „Eingabe ungültig“ keinen nächsten Schritt ableiten. Sie probieren dann Varianten durch – und mit jedem Fehlversuch steigt die Anspannung, was die Fehlerquote weiter erhöht. Das ist die Gruppe, für die das Kriterium 2008 geschrieben wurde.

Blinde Nutzer können ihre Eingabe nicht auf einen Blick mit dem Erwarteten vergleichen. Was ein sehender Nutzer durch Hinschauen korrigiert – „ach, da fehlt ein Punkt“ –, muss hier zeichenweise erhört werden. Ein Vorschlag ersetzt diesen ganzen Vorgang.

Für Menschen mit motorischen Einschränkungen ist jeder zusätzliche Anlauf teuer bezahlte Zeit. Wenn dann noch ein Session-Timeout mitläuft, entscheidet die Qualität der Fehlermeldung darüber, ob der Vorgang überhaupt zu Ende geht.

Und schließlich alle anderen: Abbruchquoten in Formularen hängen unmittelbar an der Frage, ob ein Fehler beim zweiten Versuch behoben werden kann. Das ist eines der Kriterien, bei denen sich Barrierefreiheit direkt in Zahlen niederschlägt.

Richtig & falsch im Code

<!-- Falsch: Diagnose ohne Therapie, nicht verknüpft -->
<label for="datum">Reisedatum</label>
<input id="datum" name="datum" />
<p class="error">Ungültige Eingabe.</p>

<!-- Richtig: Format vorher, Fehler mit Vorschlag, sauber verknüpft -->
<label for="datum">Reisedatum (TT.MM.JJJJ)</label>
<input id="datum" name="datum" inputmode="numeric"
       aria-invalid="true" aria-describedby="datum-fehler" />
<p id="datum-fehler" class="error">
  <strong>Fehler:</strong> Den 31. Februar gibt es nicht.
  Bitte ein gültiges Datum im Format TT.MM.JJJJ eingeben, z. B. 28.02.2026.
</p>

Bei dynamischer Prüfung muss die Meldung auch angesagt werden. Ohne Live-Region erscheint sie nur optisch:

<p id="datum-fehler" class="error" role="alert"></p>

Die nativen Meldungen des Browsers sind ein guter Ausgangspunkt, aber oft zu allgemein. setCustomValidity ersetzt sie durch eine Meldung mit Vorschlag:

const feld = document.getElementById('plz');

feld.addEventListener('input', () => {
  feld.setCustomValidity(''); // erst zurücksetzen
  if (feld.validity.patternMismatch) {
    feld.setCustomValidity(
      'Eine deutsche Postleitzahl besteht aus 5 Ziffern, z. B. 50667.',
    );
  }
});

Und beim Sammelfehler nach dem Absenden gehört eine Zusammenfassung an den Seitenanfang, deren Einträge direkt zum jeweiligen Feld springen:

<!-- Richtig: Fehlerübersicht mit Sprungzielen -->
<div role="alert" tabindex="-1" id="fehleruebersicht">
  <h2>3 Angaben müssen korrigiert werden</h2>
  <ul>
    <li><a href="#datum">Reisedatum: Den 31. Februar gibt es nicht – bitte
      TT.MM.JJJJ verwenden.</a></li>
    <li><a href="#mail">E-Mail-Adresse: Es fehlt ein @ – z. B.
      name@beispiel.de</a></li>
    <li><a href="#plz">Postleitzahl: 5 Ziffern erwartet, eingegeben wurden 4.</a></li>
  </ul>
</div>

Der stärkste Hebel ist allerdings, den Fehler gar nicht erst entstehen zu lassen: passende Eingabetypen und autocomplete, großzügige Toleranz beim Auswerten – Leerzeichen in der IBAN entfernen statt bemängeln, +49 und 0049 beide annehmen – und verständliche Hinweise vorab. Der beste Fehlervorschlag ist der, der nie gebraucht wird.

So testest du es

1. Formulare systematisch falsch ausfüllen. Vier Sorten Fehler durchspielen: Pflichtfeld leer, falsches Format, Wert außerhalb des zulässigen Bereichs, plausibler Tippfehler (etwa gmial.com).
2. Bei jeder Meldung dieselbe Frage stellen: Sagt sie, wie es richtig geht? Ein Format ohne Beispiel ist knapp ausreichend, ein Format mit Beispiel ist gut, gar kein Format ist ein Befund.
3. Auf Verständlichkeit lesen. „Feld PLZ_VALIDATION fehlgeschlagen“ oder „Constraint violation“ ist keine Hilfe. Der BITV-Test bewertet unklare oder irreführende Meldungen als nicht erfüllt.
4. Die Verknüpfung prüfen. Zeigt aria-describedby vom Feld auf die Meldung? Steht aria-invalid="true"? Wird die Meldung bei dynamischer Prüfung über role="alert" oder eine Live-Region angesagt?
5. Mit dem Screenreader gegenhören. Beim Betreten des fehlerhaften Feldes muss die Meldung mitkommen – nicht nur beim Absenden. Anleitung unter Mit NVDA testen.
6. Die Sicherheitsfälle getrennt bewerten. Bei Anmeldung, Passwortabfrage und Zwei-Faktor-Codes ist eine unspezifische Meldung korrekt und kein Mangel.

Häufiger Fehler in der Praxis

Der häufigste Befund ist die Formatprüfung ohne Formatangabe. Ein Telefonnummernfeld akzeptiert nur Ziffern, sagt das aber nirgends – weder im Label noch in der Fehlermeldung, die lautet: „Bitte gültige Telefonnummer eingeben.“ Der Nutzer hat eine gültige Telefonnummer eingegeben, nur mit Leerzeichen und Vorwahlklammern. Ich würd dir raten, in solchen Fällen gar nicht erst zu bemängeln, sondern die Eingabe zu normalisieren – das ist weniger Code als die Fehlerbehandlung und für alle angenehmer.

Der zweite ist die generische Sammelmeldung oben im Formular: „Bitte überprüfen Sie Ihre Eingaben.“ Sie sagt weder, welche Felder betroffen sind, noch was daran falsch ist. Wer mit einem Screenreader arbeitet, muss danach das ganze Formular erneut durchgehen, um die markierten Felder zu finden. Eine Übersicht mit Sprungzielen kostet ein paar Zeilen und ersetzt diese Suche vollständig.

Der dritte ist der gelöschte Feldinhalt. Nach einem Fehler wird das Feld geleert – häufig sogar das ganze Formular, etwa aus Sicherheitsgründen beim Passwort. Dann steht zwar ein Vorschlag da, aber der Bezugspunkt ist weg: Man weiß nicht mehr, was man eingegeben hatte. Das ist für sich genommen kein 3.3.3-Verstoß, macht den Vorschlag aber wertlos – und fällt in Verbindung mit kritischen Vorgängen unter 3.3.4 Fehlervermeidung.

Häufige Fragen

Muss ich bei jedem Fehler einen Vorschlag machen?

Nein, nur wenn eine Korrektur bekannt ist. Bei einer Postleitzahl, die es nicht gibt, kennt das System die Regel (fünf Ziffern) und muss sie nennen. Bei einem Freitextfeld, dessen Inhalt fachlich unplausibel ist, kann es keinen Vorschlag geben – dann reicht die Meldung, dass etwas nicht stimmt. Die Pflicht entsteht mit dem Wissen.

Gilt das auch für Anmeldeformulare?

Dort greift die Ausnahme. Eine Meldung wie „Benutzername oder Passwort ist falsch“ ist korrekt und sogar geboten, weil eine genauere Auskunft verraten würde, welche Konten existieren. Bei der Registrierung dagegen gilt das Kriterium voll: Wenn ein Passwort abgelehnt wird, müssen die Regeln genannt werden – am besten schon vor der Eingabe.

Reicht die Fehlermeldung des Browsers?

Meistens nicht ganz. Die eingebauten Meldungen sind zwar in der Systemsprache und korrekt formuliert, aber allgemein: „Bitte füllen Sie dieses Feld aus“ nennt weder das Feld noch ein Format. Für type="email" liefert der Browser bereits einen brauchbaren Hinweis, für Muster über pattern gar keinen – dort ist setCustomValidity nötig.

Wo muss der Vorschlag stehen – am Feld oder oben?

Am besten an beiden Stellen. Der BITV-Test akzeptiert beides: Korrekturhinweise am Seitenanfang oder nahe am betroffenen Feld. In der Praxis hat sich die Kombination bewährt – eine Übersicht oben mit Sprungzielen für den Überblick, und die konkrete Meldung direkt unter dem Feld für die Korrektur.

Was ist der Unterschied zu 3.3.1 und 3.3.4?

3.3.1 Fehlererkennung (A) verlangt, dass der Fehler erkannt, beschrieben und dem Feld zugeordnet wird. 3.3.3 (AA) verlangt zusätzlich den Korrekturvorschlag. 3.3.4 Fehlervermeidung (AA) geht darüber hinaus und verlangt bei rechtlichen, finanziellen und datenbezogenen Vorgängen eine Möglichkeit zum Rückgängigmachen, Prüfen oder Bestätigen.

Verwandte Themen

• 3.3.1 Fehlererkennung – die Stufe davor
• 3.3.2 Beschriftungen oder Anweisungen – Formate nennen, bevor getippt wird
• 3.3.4 Fehlervermeidung – die Stufe danach für kritische Vorgänge
• Fehlermeldungen barrierefrei – Formulierungen und Muster
• Validierung & Pflichtfelder – wann geprüft wird und wie