Was wird geprüft?
Wenn ein Formular Fehlermeldungen erzeugt, sollen die fehlerhaft ausgefüllten Felder identifiziert und der Fehler in Textform beschrieben werden.
Warum wird das geprüft?
Bei Formulareingaben kommt es öfters zu Fehlern: Nutzer verschreiben sich oder überspringen benötigte Eingaben.
Wenn das Angebot Nutzereingaben überprüft, sollen die Felder mit fehlerhaften oder fehlenden Eingaben identifiziert werden. Dies erleichtert den Nutzern, Eingaben zu korrigieren.
Wie wird geprüft?
1. Anwendbarkeit des Prüfschritts
Der Prüfschritt ist anwendbar, wenn die Seite Formulare enthält, welche bei inkorrektem Ausfüllen Fehlermeldungen erzeugen. Dies kann schon während der Eingabe oder erst nach dem Abschicken des Formulars geschehen.
2. Prüfung
Formular unvollständig oder fehlerhaft ausfüllen, etwa durch das Leerlassen von Pflichtfeldern oder das Eingeben syntaktisch nicht korrekter E-Mail-Adressen.
Falls das Abschicken des Formulars eine Fehlermeldung erzeugt: Prüfen, ob die betroffenen Felder identifiziert werden und der Fehler mit Hilfe von Text beschrieben wird. Die Identifizierung der betroffenen Felder kann, auch abhängig von der Länge des Formulars, auf verschiedene Arten geschehen:
Bei Neuanzeige des Formulars werden am Seitenbeginn fehlerhaft ausgefüllte Felder identifiziert.
Fehlerhaft ausgefüllte Felder werden zusätzlich deutlich hervorgehoben.
Die Labeltexte fehlerhaft ausgefüllter Felder ändern sich, um auf die Fehler darstellungsunabhängig hinzuweisen.
Fehlermeldungen, die nahe am Formularfeld positioniert sind, aber nicht Teil des Labels sind, sind programmatisch ermittelbar, etwa durch die Verknüpfung mittels
aria-labelledbyoderaria-describedby.Fehlermeldungen werden mit Hilfe von Live-Regionen oder Benachrichtigungen (
alertdialog) bereitgestellt.
Prüfen, ob nach Korrektur der Eingaben und erneutem Abschicken des Formulars zuvor angezeigte Fehlermeldungen verschwinden.
3. Hinweise
3.1 Allgmeine Hinweise
Wenn serverseitig eine Fehlermeldung auf neuer Seite ausgegeben wird, wird diese wie ein Seitenzustand unter der Ausgangsseite mitgeprüft. Geprüft wird auch die Erfüllung anderer relevanter Prüfkriterien.
Wenn Formulare keine Fehlermeldungen erzeugen, ist dies nicht negativ zu bewerten.
Die Verknüpfung von Fehlermeldungen mit
aria-errormessage(siehe WAI-ARIA 1.2 Spec) ist bislang noch nicht ausreichend von Browsern unterstützt, um Fehlermeldungen ausreichend zugänglich für Screenreader-Nutzende zu verknüpfen.
3.2 HTML5 Fehlervalidierung
Bei der nativen HTML-Formularvalidierung sorgt beispielsweise das Attribut required dafür, dass beim Absenden automatisch eine Validierung stattfindet, eine generische Fehlermeldung angezeigt wird (z.B. bei leergelassenem Pflichtfeld oder bei Eingabe eine nicht semantischen E-Mail-Adresse in Feldern mit type="email"), und der Fokus auf das erste fehlerhafte Feld gesetzt wird.
In den meisten gängigen Kombinationen von Browser und Screenreadern wird der Screenreader die generische Fehlermeldung und den programmatischen Namen des Pflichtfelds vorlesen. Während dies grundsätzlich die Anforderungen dieses Erfolgskriteriums erfüllt, gibt es einige Nachteile bei diesem Ansatz:
Je nach eingesetzem Browser ist die Meldung nicht dauerhaft sichtbar oder sie bewegt sich beim Scrollen der Seite nicht mit.
Je nach eingesetzem Browser wird die Fehlermeldung bei vergrößertem (gezoomtem) Inhalt nicht vergrößert angezeigt.
Die Fehlermeldungen für Felder mit
type="text"sind unspezifisch, d.h. sie liefern gegenenenfalls keine hilfreichen Hinweise.Bei mehreren Fehlern wird jeweils nur der erste angezeigt. Nach jeder Korrektur und erneutem Absenden erscheint der nächste Fehler, was mehrere Durchläufen erforderlich macht.
Die Bewertung der nativen HTML5 Feldvalidierung bleibt aufgrund technischer Einschränkungen und offener Diskussionen in der Accessibility Guidelines Working Group (AGWG) unscharf und kontextabhängig. Eine normative Festlegung ist derzeit nicht möglich; stattdessen sind Einzelfallbewertung und Augenmaß gefragt. Bei kurzen Formularen, zum Beispiel bei einem Login-Formular oder einem Kontakt-Formular mit wenigen Feldern, kann eine HTML5-Validierung für die Fehlererkennung ausreichend sein.
4. Bewertung
Nicht voll erfüllt
Die Fehlermeldung nach Formularüberprüfung benennt Felder mit fehlender oder fehlerhafter Eingabe nicht klar oder verweist nicht deutlich darauf (etwa durch Änderung des dem Feld zugeordneten Labels, semantische Hervorhebung, oder Links).
Unspezifische Fehlermeldung, Felder mit Eingabefehlern oder fehlenden Eingaben werden lediglich grafisch hervorgehoben.
Nicht erfüllt
Die Fehlermeldung gibt keinen Aufschluss darüber, welche Eingabe den Fehler erzeugt hat.
Bei fehlerhafter Eingabe wird das Formular neu angezeigt. Bereits gemachte korrekte Eingaben sind gelöscht, die Felder sind wieder leer und müssen erneut ausgefüllt werden. Ausnahme: Das Löschen bereits gemachter Eingaben ist sinnvoll bei sicherheitsrelevanten Daten wie Passwörtern oder Benutzernamen.
Einordnung des Prüfschritts
Abgrenzung von anderen Prüfschritten
Ob infolge von Fehleingaben generierte oder eingeblendete Fehlermeldungen an der richtigen Stelle im Quelltext stehen, ist Gegenstand des Prüfschritts 9.1.3.2 "Sinnvolle Reihenfolge".
Einordnung des Prüfschritts nach WCAG 2.2
Guideline
Success criteria
3.3.1 Error Identification (Level A)
Techniques
General Techniques
Scripting Techniques
ARIATechniques
Quellen
DOM Scripting und WAI ARIA zur Erzeugung von Fehlermeldungen während der Formular-Eingabe
Marco’s accessibility blog: Easy ARIA tip #3: aria-invalid and role "alert" (Juli 2008, englischer Text)
Fragen zu diesem Prüfschritt
Warum wird nicht grundsätzlich bei allen Formularen eine Fehlerüberprüfung verlangt?
Eine Fehlerbehandlung ist oft sinnvoll, aber nicht grundsätzlich bei allen Formularen. Das hängt ab vom Zweck des Formulars und der Art des Angebots. So kann es unter Umständen sinnvoll sein, grundsätzlich alle Eingaben, auch solche mit Fehlern, zu verwerten.
Wenn jedoch irgendwelche Fehlermeldungen generiert werden, müssen diese brauchbar sein. Das wird in diesem Prüfschritt überprüft.