Fehlererkennung
Wenn das System einen Fehler in einer Formulareingabe automatisch erkennt, muss dieser Fehler in Textform identifiziert und beschrieben werden — nicht allein durch Farbe, nicht allein durch ein Symbol, nicht durch Schweigen.
Was gefordert wird
Wenn eine Formulareingabe ungültig ist — falsches Format, fehlender Pflichtfeldwert, Wert außerhalb des erlaubten Bereichs — und das System dies automatisch erkennt, muss der Fehler dem Nutzer in Textform mitgeteilt werden. Die Fehlermeldung muss angeben, welches Feld fehlerhaft ist und worin der Fehler besteht — nicht nur, dass „etwas“ schiefgelaufen ist.
Das Erfolgskriterium verlangt nicht, dass das System jeden denkbaren Fehler erkennt; es verlangt, dass erkannte Fehler als Text an den Nutzer zurückgemeldet werden.
Wie die Anforderung erfüllt wird
- Jedes Formularfeld erhält eine sichtbare Fehlermeldung, die das Problem beschreibt und unmittelbar neben oder unter dem Feld platziert ist.
- Die fehlerhafte Eingabe wird namentlich benannt: „Die E-Mail-Adresse muss ein @-Zeichen enthalten.“
- Der Fehler wird mit dem Eingabefeld über
aria-describedbyverknüpft, damit Screenreader ihn beim Fokuserhalt vorlesen. - Das fehlerhafte Eingabefeld erhält das Attribut
aria-invalid="true". - Bei serverseitiger Validierung wird eine Zusammenfassung als Liste am Anfang des Formulars eingeblendet; jeder Eintrag verlinkt auf das betroffene Feld.
- Dynamisch eingeblendete Fehlermeldungen werden über eine Live-Region (
aria-live="polite"oderrole="alert") angekündigt, sodass Screenreader den Fehler ausgeben, ohne dass der Nutzer ihn aktiv suchen muss.
Häufige Fehler
- Rote Rahmen um ungültige Felder ohne jegliche Texterklärung.
- Ein allgemeines Banner mit der Meldung „Formular ungültig“, ohne anzugeben, welche Felder betroffen sind.
- Fehlerhinweise ausschließlich in Tooltips, die beim Verlassen des Feldes verschwinden.
- Ausschließliche Nutzung der nativen Browser-Validierung (
required,pattern) — die Browser-Sprechblase ist für Screenreader unzuverlässig und verschwindet zu schnell. - Inline-Fehlerindikatoren, die nur aus einem Symbol bestehen (rotes Ausrufezeichen), ohne zugänglichen Namen.
Warum das wichtig ist
Dies ist der am häufigsten genannte Mangel bei der Eingabeunterstützung in Barrierefreiheits-Audits. Für sehende Nutzer ist ein roter Rahmen zumindest ein Hinweis; für Screenreader-Nutzer existiert er schlicht nicht. Für Menschen mit Farbsehschwäche ist ein roter Rahmen allein nicht erkennbar. Hat ein Nutzer ein langes Formular ausgefüllt und die Absendung schlägt still fehl, bricht er den Vorgang wahrscheinlich ab — und Barrierefreiheit ist der Grund, warum er konkret gescheitert ist.
Erfolgskriterium 3.3.1 sollte gemeinsam mit 3.3.3 (Fehlerkorrektur) und 4.1.3 (Statusmeldungen) umgesetzt werden — zusammen bilden sie das moderne Muster für Formularfehler.