WCAG 3.3.1 Fehlererkennung

Das Erfolgskriterium 3.3.1 sorgt dafür, dass Menschen bemerken, wenn ein Formular nicht angenommen wurde, und wissen, welches Feld falsch ist. Blinde Nutzer sehen keinen roten Rahmen, Menschen mit Farbsehschwäche bemerken ihn vielleicht nicht, und Menschen mit kognitiven Beeinträchtigungen verstehen ein Icon womöglich nicht. In einem Shop ist das oft der Unterschied zwischen einem abgeschlossenen Checkout und einem abgebrochenen Warenkorb. Es gehört zur Konformitätsstufe A und steht in EN 301 549 als Abschnitt 9.3.3.1. Das BFSG verweist über die harmonisierte Norm EN 301 549 auf diese Anforderungen.

Was das Erfolgskriterium verlangt

Wenn ein Eingabefehler automatisch erkannt wird, dann:

1. wird das fehlerhafte Element gekennzeichnet, und
2. wird der Fehler dem Nutzer als Text beschrieben.

Ein Eingabefehler ist eine Angabe des Nutzers, die nicht angenommen wird. Dazu gehören ausgelassene Pflichtangaben und Angaben außerhalb des geforderten Formats oder der zulässigen Werte. Die WCAG schreiben nicht vor, wie Fehler angezeigt werden. Dem Nutzer zu sagen, wie er den Fehler behebt, regelt gesondert 3.3.3 Fehlerempfehlung.

Typische Fehler in Onlineshops

• ein ungültiges Feld wird nur mit rotem Rahmen oder rotem Icon angezeigt, ohne Text;
• der Checkout lädt nach „Bestellung aufgeben“ neu, ohne Meldung oder nur mit einem allgemeinen „Etwas ist schiefgelaufen“;
• oben auf der Seite erscheint eine Meldung, die aber nicht sagt, welches Feld betroffen ist;
• Kartenfehler aus dem Zahlungs-Widget werden als Bild angezeigt oder verschwinden nach einigen Sekunden;
• der Fehlertext ist sichtbar vorhanden, aber nicht mit dem Feld verbunden, sodass ein Screenreader-Nutzer im Feld ihn nicht hört.

So prüfen Sie es

Automatisch: Unser Checker hat für dieses Kriterium keine Regel. Ein automatischer Scan sendet Ihre Formulare nicht mit falschen Daten ab, deshalb ist eine manuelle Prüfung nötig.

Manuell: Senden Sie jedes wichtige Formular — Registrierung, Login, Newsletter, Kontakt, Checkout, Adressbuch — einmal mit leeren Pflichtfeldern und dann mit falschen Formaten ab (E-Mail ohne @, zu kurze Postleitzahl, abgelaufenes Ablaufdatum). Stellen Sie sicher, dass jeder Fehler als Text angezeigt wird, das Feld nennt oder darauf verweist und von einem Screenreader vorgelesen wird, wenn Sie zum Feld wechseln.

So beheben Sie es

• Zeigen Sie neben jedem ungültigen Feld eine Textmeldung, zum Beispiel „E-Mail-Adresse: Geben Sie eine Adresse wie [email protected] ein“.
• Verbinden Sie die Meldung mit aria-describedby mit dem Feld und setzen Sie am Feld aria-invalid="true".
• Ergänzen Sie lange Formulare um eine Fehlerzusammenfassung oben mit Links zu den Feldern und setzen Sie den Fokus nach dem Absenden darauf.
• Lassen Sie Meldungen sichtbar, bis der Fehler behoben ist; verlassen Sie sich nicht allein auf Farbe oder Icons.

Verwandte Kriterien

• 3.3.3 Fehlerempfehlung — Nutzern sagen, wie sie den Fehler beheben.
• 4.1.3 Statusmeldungen — Fehler ansagen, die erscheinen, ohne dass der Fokus wandert.
• 1.4.1 Benutzung von Farbe — Farbe darf nicht das einzige Signal sein.

Häufige Fragen

Reicht ein roter Rahmen, um einen Formularfehler anzuzeigen?

Nein. WCAG 3.3.1 verlangt, dass der Fehler als Text beschrieben wird. Farbe allein verstößt außerdem gegen 1.4.1 Benutzung von Farbe. Ergänzen Sie neben dem Feld eine Meldung wie „Geben Sie Ihre Postleitzahl ein“.

Gilt 3.3.1 für leere Pflichtfelder?

Ja. Informationen, die die Seite verlangt, die der Nutzer aber weglässt, zählen als Eingabefehler; ein leeres Pflichtfeld muss also gekennzeichnet und als Text beschrieben werden.

Sagen die WCAG, wo Fehlermeldungen erscheinen müssen?

Eine bestimmte Darstellung ist nicht vorgeschrieben. Übliche gute Praxis ist eine Meldung neben dem Feld, mit aria-describedby damit verbunden, und bei langen Formularen eine Zusammenfassung oben im Formular.