WCAG 3.3.3: Fehlervorschlag

Erkennt das System einen Eingabefehler und kennt es mögliche Korrekturen, müssen diese dem Nutzer vorgeschlagen werden – außer der Vorschlag würde Sicherheit oder Zweck gefährden (Passwörter, Prüfungsantworten). (Englisch: Error Suggestion.)

Was verlangt das Kriterium?

3.3.1 sagt, dass und wo etwas falsch ist – 3.3.3 verlangt den nächsten Schritt: wie es richtig wäre. Beispiele:

• Datum im falschen Format → das erwartete Format samt Beispiel nennen („24.06.1985“) statt nur „ungültiges Datum“.
• E-Mail ohne @ → „Eine E-Mail-Adresse enthält ein @, z. B. name@beispiel.de“.
• Tippfehler in der Domain → „Meinten Sie gmail.com?“
• Stadt nicht gefunden → nächstliegende Treffer als Auswahl anbieten.
• Pflichtfeld leer → benennen, welche Angabe fehlt.

Die Grenze: Wo der Vorschlag das Sicherheitskonzept aushebeln würde („Falsches Passwort – meinten Sie ‚Sommer2026!’?“), gilt die Ausnahme.

Wen betrifft es besonders?

Menschen mit kognitiven Einschränkungen, Legasthenie oder Konzentrationsproblemen, die aus „Eingabe ungültig“ keinen nächsten Schritt ableiten können; blinde Nutzer, die ihre Eingabe nicht „auf einen Blick“ mit dem Erwarteten vergleichen können – und am Ende jeder, der ein Formular im zweiten Anlauf schaffen will.

Richtig & falsch im Code

<!-- Falsch: Diagnose ohne Therapie -->
<p id="datum-error">Ungültige Eingabe.</p>

<!-- Richtig: Fehler + konkreter Vorschlag -->
<label for="datum">Reisedatum (TT.MM.JJJJ)</label>
<input id="datum" aria-invalid="true" aria-describedby="datum-error" />
<p id="datum-error">
  <strong>Fehler:</strong> „31.02.2026" gibt es nicht.
  Bitte ein gültiges Datum im Format TT.MM.JJJJ eingeben, z. B. 28.02.2026.
</p>

Noch besser ist, den Fehler unmöglich zu machen: passende Input-Typen, großzügige Eingabe-Toleranz (Leerzeichen in IBAN akzeptieren!) und verständliche Anweisungen vorab – der beste Fehlervorschlag ist der, der nie nötig wird.

So testest du es

1. Formulare systematisch falsch ausfüllen (Format-Fehler, Tippfehler, leere Pflichtfelder): Sagt jede Meldung, wie es richtig geht?
2. Meldungen auf Verständlichkeit lesen: Versteht sie jemand ohne technisches Vokabular? („Feld PLZ_VALIDATION fehlgeschlagen“ ist keine Hilfe.)
3. Prüfen, ob Vorschläge verknüpft und ansagbar sind.

Verwandte Themen

• 3.3.1 Fehlererkennung – die Stufe davor
• 3.3.4 Fehlervermeidung – die Stufe danach für kritische Vorgänge
• Fehlermeldungen barrierefrei – Formulierungen und Muster