WCAG 3.3.1: Fehlererkennung

WCAG 3.3.1 verlangt, dass ein automatisch erkannter Eingabefehler zwei Dinge liefert: Das betroffene Feld muss identifiziert und der Fehler in Textform beschrieben werden. Ein roter Rahmen erfüllt weder das eine noch das andere – er sagt weder wo der Fehler steckt noch was falsch ist.

(Englisch: Error Identification.)

Das Wichtigste in Kürze

• Zwei Pflichten, nicht eine: Feld benennen und Fehler im Text beschreiben. Wer nur eines davon tut, erfüllt das Kriterium nicht.
• 3.3.1 gilt nur für automatisch erkannte Fehler. Eine falsch geschriebene Straße, die das System nicht prüfen kann, ist kein Fall für dieses Kriterium.
• Die Beschreibung braucht keinen Lösungsvorschlag – das verlangt erst 3.3.3 auf Stufe AA. Für 3.3.1 genügt „Die Postleitzahl muss fünf Ziffern haben“.
• Programmatische Verknüpfung über aria-describedby und aria-invalid ist der Weg, auf dem die Meldung bei Screenreadern ankommt.
• Bei Prüfung ohne Neuladen kommt 4.1.3 dazu: Die Meldung muss zusätzlich angesagt werden.
• Eine Fehlerzusammenfassung am Formularanfang ist nicht vorgeschrieben, aber das wirksamste Mittel – vor allem bei langen Formularen.
• Stufe A und über die EN 301 549 verbindlich; im BIK-BITV-Test heißt der Prüfschritt schlicht „3.3.1 Fehlererkennung“.

Reicht ein roter Rahmen als Fehlermeldung?

Nein. Ein erkannter Eingabefehler muss das betroffene Feld benennen und den Fehler in Textform beschreiben.

Der Normtext ist knapp: Wird ein Eingabefehler automatisch erkannt, dann wird das fehlerhafte Element identifiziert und der Fehler dem Nutzer in Textform beschrieben. Daraus ergeben sich drei Bausteine, die eine konforme Meldung zusammenhalten:

1. Welches Feld ist betroffen? Der Feldname muss in der Meldung vorkommen oder die Meldung muss unmittelbar am Feld stehen und programmatisch damit verbunden sein.
2. Was ist falsch? „Die Postleitzahl muss aus fünf Ziffern bestehen“ statt „Ungültige Eingabe“. Der Text muss den Fehler beschreiben, nicht nur melden, dass einer vorliegt.
3. In Textform. Farbe, Symbol und Position dürfen dazukommen und sollten es auch – 1.4.1 verlangt ohnehin ein zweites Merkmal. Sie ersetzen den Text aber nicht.

Wichtig ist der Zuschnitt: 3.3.1 greift nur bei Fehlern, die das System automatisch erkennt. Ein Pflichtfeld, das leer bleibt, ein Datum im falschen Format, eine E-Mail-Adresse ohne @ – all das wird erkannt und muss gemeldet werden. Ein Tippfehler im Straßennamen, den keine Prüfung bemerkt, fällt nicht darunter. Das entlastet in Audits häufig: Nicht jede denkbare Falscheingabe muss abgefangen werden, aber jede erkannte muss sauber gemeldet sein.

Der Normtext steht im Understanding-Dokument des W3C zu 3.3.1, das deutsche Prüfvorgehen im Prüfschritt „3.3.1 Fehlererkennung“ des BIK-BITV-Tests.

Wen betrifft es besonders?

Screenreader-Nutzerinnen und -Nutzer stehen vor einem Formular, das sich schlicht nicht absenden lässt, ohne dass sie den Grund erfahren. Eine Meldung, die optisch neben dem Feld steht, aber nicht mit ihm verknüpft ist, existiert für sie nicht. Sie hören nur „Postleitzahl, Eingabefeld“, mehr nicht.

Menschen mit Farbsinnstörungen sehen den roten Rahmen nicht als Signal. Ein Feld mit rotem Rand wirkt für sie wie ein Feld mit etwas dunklerem Rand.

Nutzer von Bildschirmvergrößerung haben ein anderes Problem: Die Meldung erscheint am oberen Seitenrand, ihr Ausschnitt liegt aber unten beim Absenden-Knopf. Ohne Fokuswechsel merken sie gar nicht, dass überhaupt etwas gemeldet wurde.

Und Menschen mit kognitiven Einschränkungen kommen mit „Fehler!“ nicht weiter. Für sie entscheidet die Formulierung darüber, ob das Formular abgeschlossen wird oder nicht – gerade bei Behördenformularen mit zwanzig Feldern.

Richtig & falsch im Code

<!-- Falsch: nur rote Umrandung über eine Klasse -->
<label for="plz">Postleitzahl</label>
<input id="plz" class="error" />

<!-- Richtig: identifiziert, beschrieben, programmatisch verknüpft -->
<label for="plz">Postleitzahl</label>
<input id="plz" name="plz" inputmode="numeric"
       aria-invalid="true" aria-describedby="plz-fehler" />
<p id="plz-fehler" class="feld-fehler">
  <span aria-hidden="true">⚠</span>
  <strong>Fehler:</strong> Die Postleitzahl muss aus genau fünf Ziffern
  bestehen, zum Beispiel 50667.
</p>

aria-invalid="true" markiert den Zustand, aria-describedby hängt den Meldungstext an den Accessible Name des Feldes. Beides zusammen sorgt dafür, dass beim Anspringen des Feldes die Meldung mitgelesen wird. Wird der Fehler behoben, muss aria-invalid wieder auf false gesetzt oder entfernt werden – sonst bleibt das Feld dauerhaft als fehlerhaft angesagt.

<!-- Richtig: Fehlerzusammenfassung am Formularanfang, bekommt nach dem
     Absenden den Fokus -->
<div class="fehler-uebersicht" tabindex="-1" id="fehler" role="alert">
  <h2>Zwei Angaben fehlen oder sind unvollständig</h2>
  <ul>
    <li><a href="#plz">Postleitzahl: muss aus fünf Ziffern bestehen</a></li>
    <li><a href="#mail">E-Mail-Adresse: bitte im Format name@beispiel.de</a></li>
  </ul>
</div>

Die Zusammenfassung ist in der Norm nicht vorgeschrieben, in der Praxis aber das Mittel, das am meisten bringt: Sie sagt auf einen Blick, wie viele Fehler es gibt, und führt per Sprunglink direkt zum Feld. Bei mehrstufigen Formularen ist sie fast unverzichtbar.

Zur Formulierung: Die Meldung soll den Fehler beschreiben, nicht die nutzende Person belehren. „Bitte geben Sie eine gültige E-Mail-Adresse ein“ ist in Ordnung, „Ungültige Eingabe“ nicht, und „Sie haben einen Fehler gemacht“ hilft niemandem. Das vollständige Muster steht unter Fehlermeldungen barrierefrei.

So testest du es

1. Formular bewusst falsch absenden – leer, mit falschem Format, mit zu langen Werten. Jeder Weg, auf dem das System einen Fehler erkennt, gehört durchgespielt.
2. Prüfen, ob jeder Fehler am Feld benannt wird und ob der Text den Fehler tatsächlich beschreibt. „Pflichtfeld“ allein reicht bei einem Formatfehler nicht.
3. Screenreader-Probe mit NVDA: Das fehlerhafte Feld anspringen – wird die Meldung mitgelesen? Wenn nicht, fehlt die Verknüpfung über aria-describedby.
4. Nach dem Absenden auf den Fokus achten. Erfährt man ohne eigenes Suchen, dass Fehler vorliegen? Bei Prüfung ohne Neuladen muss die Meldung über eine Live-Region ankommen.
5. Graustufen-Blick: Ist in den DevTools unter „Emulate vision deficiencies“ die Fehleranzeige noch erkennbar, wenn Farbe wegfällt?
6. Korrekturlauf: Fehler beheben und prüfen, ob aria-invalid zurückgesetzt und die Meldung entfernt wird. Stehenbleibende Meldungen sind ein eigener Befund.

Häufiger Fehler in der Praxis

Der häufigste Befund ist die Meldung ohne Verknüpfung. Optisch steht sie direkt unter dem Feld, im Markup ist sie ein <span> ohne id, und das Feld weiß nichts davon. Visuell perfekt, für Screenreader nicht vorhanden. Zwei Attribute lösen das – und sie werden fast immer vergessen, weil im Sehtest ja alles stimmt.

Der zweite ist die native Browser-Validierung als einzige Prüfung. required und type="email" erzeugen eine Sprechblase, die nach wenigen Sekunden verschwindet, sich nicht gestalten lässt und in manchen Browser-Screenreader-Kombinationen nicht zuverlässig angesagt wird. Als Zusatz ist sie nützlich, als alleiniger Mechanismus zu wackelig. Meine Empfehlung: novalidate am Formular setzen und die Prüfung selbst übernehmen, dabei aber type und required im Markup lassen – die brauchen 1.3.5 und die Tastaturbelegung auf dem Handy.

Der dritte ist die Meldung, die zu früh kommt. Eine Prüfung bei jedem Tastendruck meldet „E-Mail-Adresse ungültig“, während man noch tippt. Mit Live-Region wird daraus eine Ansage pro Zeichen – der Screenreader kommt nicht mehr zum Vorlesen. Ich würd dir raten, erst beim Verlassen des Feldes zu prüfen und beim Absenden zusammenzufassen.

Häufige Fragen

Reicht es, das fehlerhafte Feld rot zu umranden?

Nein, und zwar aus zwei Gründen: Der rote Rahmen benennt weder das Feld noch den Fehler, und er ist ein reines Farbsignal. 3.3.1 verlangt Text, und 1.4.1 verlangt ein zweites Merkmal neben der Farbe. Die Umrandung darf bleiben – sie muss nur Begleitung sein, nicht die ganze Meldung.

Muss die Meldung sagen, wie man den Fehler behebt?

Für 3.3.1 nicht. Dieses Kriterium verlangt nur, den Fehler zu benennen und zu beschreiben. Ein Korrekturvorschlag ist Gegenstand von 3.3.3 Fehlervorschlag auf Stufe AA. In der Praxis schreibt man beides in einen Satz, weil es kaum Mehraufwand bedeutet.

Wohin gehört der Fokus nach einem Fehler?

Auf die Fehlerzusammenfassung am Formularanfang, wenn es eine gibt – sie braucht dafür tabindex="-1". Bei einem einzelnen Fehler kann der Fokus auch direkt ins betroffene Feld wandern. Der Fokus darf jedenfalls nicht dort bleiben, wo er war, sonst bemerkt niemand ohne Blick auf den Bildschirm, dass etwas passiert ist.

Gilt 3.3.1 auch für Fehler, die erst der Server erkennt?

Ja. Ob die Prüfung im Browser oder auf dem Server läuft, spielt keine Rolle – entscheidend ist, dass der Fehler automatisch erkannt wird. Bei serverseitiger Prüfung mit Neuladen greift 4.1.3 nicht, dafür müssen Seitentitel und Fokusposition die Information transportieren.

Was ist der Unterschied zu 3.3.2 und 3.3.4?

3.3.2 Beschriftungen oder Anweisungen wirkt vor der Eingabe: Formatangaben und Pflichtfeldkennzeichnung sollen Fehler gar nicht erst entstehen lassen. 3.3.1 wirkt nach der Eingabe. 3.3.4 Fehlervermeidung betrifft folgenreiche Vorgänge – rechtsverbindliche Erklärungen, Zahlungen – und verlangt Prüfen, Bestätigen oder Rückgängigmachen.

Verwandte Themen

• Fehlermeldungen barrierefrei – das vollständige Muster
• Validierung & Pflichtfelder – wann geprüft wird und wie
• 3.3.3 Fehlervorschlag – die nächste Stufe: Korrektur anbieten
• 4.1.3 Statusmeldungen – Meldungen ohne Neuladen ansagen
• Mehrstufige Formulare – Fehler über mehrere Schritte hinweg