-
5 Allgemeine Anforderungen
-
6 Zwei-Wege-Sprachkommunikation
- 6.1
- Audiobandbreite für Sprache
- 6.2.1.1
- Textkommunikation in Echtzeit
- 6.2.1.2
- Gleichzeitige Sprache und Text
- 6.2.2.1
- Visuell unterscheidbare Anzeige von Textnachrichten
- 6.2.2.2
- Programmatisch unterscheidbare Anzeige von Textnachrichten
- 6.2.2.3
- Sprecheridentifizierung
- 6.2.2.4
- Echtzeitindikation von Sprachkommunikation
- 6.2.3
- Interoperabilität von Echtzeit-Textkommunikation
- 6.2.4
- Reaktionsgeschwindigkeit der Echtzeit-Textkommunikation
- 6.3
- Anrufer-Identifizierung
- 6.4
- Alternativen zu sprachbasierten Diensten
- 6.5.2
- Auflösung bei Videotelefonie
- 6.5.3
- Bildwiederholfrequenz bei Videotelefonie
- 6.5.4
- Synchronität bei Videotelefonie
- 6.5.5
- Visuelle Anzeige von Audio-Aktivität
- 6.5.6
- Sprecher-Anzeige für Gebärdensprachen-Kommunikation
-
7 Videofähigkeiten
- 7.1.1
- Wiedergabe von Untertiteln
- 7.1.2
- Synchrone Untertitel
- 7.1.3
- Erhaltung von Untertiteln
- 7.1.4
- Untertitel-Anpassungen
- 7.1.5
- Gesprochene Untertitel
- 7.2.1
- Wiedergabe von Audiodeskription
- 7.2.2
- Synchrone Audiodeskription
- 7.2.3
- Erhaltung von Audiodeskription
- 7.3
- Bedienelemente für Untertitel und Audiodeskription
-
9.1.1 Textalternativen
- 9.1.1.1a
- Alternativtexte für Bedienelemente
- 9.1.1.1b
- Alternativtexte für Grafiken und Objekte
- 9.1.1.1c
- Leere alt-Attribute für Layoutgrafiken
- 9.1.1.1d
- Alternativen für CAPTCHAs
-
9.1.2 Zeitbasierte Medien
-
9.1.3 Anpassbar
- 9.1.3.1a
- HTML-Strukturelemente für Überschriften
- 9.1.3.1b
- HTML-Strukturelemente für Listen
- 9.1.3.1c
- HTML-Strukturelemente für Zitate
- 9.1.3.1d
- Inhalt gegliedert
- 9.1.3.1e
- Datentabellen richtig aufgebaut
- 9.1.3.1f
- Zuordnung von Tabellenzellen
- 9.1.3.1g
- Kein Strukturmarkup für Layouttabellen
- 9.1.3.1h
- Beschriftung von Formularelementen programmatisch ermittelbar
- 9.1.3.2
- Sinnvolle Reihenfolge
- 9.1.3.3
- Ohne Bezug auf sensorische Merkmale nutzbar
- 9.1.3.4
- Keine Beschränkung der Bildschirmausrichtung
- 9.1.3.5
- Eingabefelder zu Nutzerdaten vermitteln den Zweck
-
9.1.4 Unterscheidbar
- 9.1.4.1
- Ohne Farben nutzbar
- 9.1.4.2
- Ton abschaltbar
- 9.1.4.3
- Kontraste von Texten ausreichend
- 9.1.4.4
- Text auf 200% vergrößerbar
- 9.1.4.5
- Schriftgrafiken
- 9.1.4.10
- Inhalte brechen um
- 9.1.4.11
- Kontraste von Grafiken und grafischen Bedienelementen ausreichend
- 9.1.4.12
- Textabstände anpassbar
- 9.1.4.13
- Eingeblendete Inhalte bedienbar
-
9.2.1 Tastaturbedienbar
- 9.2.1.1
- Ohne Maus nutzbar
- 9.2.1.2
- Keine Tastaturfalle
- 9.2.1.4
- Tastatur-Kurzbefehle abschaltbar oder anpassbar
-
9.2.2 Ausreichend Zeit
- 9.2.2.1
- Zeitbegrenzungen anpassbar
- 9.2.2.2
- Bewegte Inhalte abschaltbar
-
9.2.3 Anfälle
- 9.2.3.1
- Verzicht auf Flackern
-
9.2.4 Navigierbar
- 9.2.4.1
- Bereiche überspringbar
- 9.2.4.2
- Sinnvolle Dokumenttitel
- 9.2.4.3
- Schlüssige Reihenfolge bei der Tastaturbedienung
- 9.2.4.4
- Aussagekräftige Linktexte
- 9.2.4.5
- Alternative Zugangswege
- 9.2.4.6
- Aussagekräftige Überschriften und Beschriftungen
- 9.2.4.7
- Aktuelle Position des Fokus deutlich
-
9.2.5 Eingabemodalitäten
-
9.3.1 Lesbar
-
9.3.2 Vorhersehbar
- 9.3.2.1
- Keine unerwartete Kontextänderung bei Fokus
- 9.3.2.2
- Keine unerwartete Kontextänderung bei Eingabe
- 9.3.2.3
- Konsistente Navigation
- 9.3.2.4
- Konsistente Bezeichnung
-
9.3.3 Eingabeunterstützung
- 9.3.3.1
- Fehlererkennung
- 9.3.3.2
- Beschriftungen von Formularelementen vorhanden
- 9.3.3.3
- Hilfe bei Fehlern
- 9.3.3.4
- Fehlervermeidung wird unterstützt
-
9.4.1 Kompatibel
- 9.4.1.1
- Korrekte Syntax
- 9.4.1.2
- Name, Rolle, Wert verfügbar
- 9.4.1.3
- Statusmeldungen programmatisch verfügbar
-
11.7 Benutzerpräferenzen
-
11.8 Autorenwerkzeuge
-
12 Dokumentation und Support
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-labelledby
oderaria-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
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.1 Spec) ist bislang noch nicht ausreichend von Browsern unterstützt, um Fehlermeldungen ausreichend zugänglich für Screenreader-Nutzende zu verknüpfen.
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.1
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.