Hilfestellung bei der Eingabe – "Zur Fehlervermeidung und -korrektur sind unterstützende Funktionen für die Eingabe bereitzustellen."

Obwohl jeder Nutzer Fehler bei der Eingabe in Formularen macht, fällt es manchen Menschen mit Behinderungen schwerer, fehlerfreie Eingaben vorzunehmen oder fehlerhafte Eingaben zu erkennen. Deswegen müssen Nutzer bei der Formulareingabe unterstützt werden, fehlerhafte Eingaben zu vermeiden; sollten Fehler gemacht worden sein, dann sollten Nutzer dabei unterstützt werden, die Fehleingaben zu erkennen und Korrekturen vorzunehmen.

Accessibility-Checkliste: Hilfestellung bei der Eingabe

Diese Accessibility Checkliste hilft bei der Überprüfung einer Webseite auf Konformität zu den Erfolgskriterien der Richtlinie 3.3 (Konformitätsstufe AA) der Web Content Accessibility Guidelines (WCAG) 2.0 bzw. den Bedingungen der Anforderung 3.3 (Priorität I) der Barrierefreien Informationstechnik-Verordnung – BITV 2.0.

Um Fehleingaben in Formularen zu vermeiden, müssen
- für alle Eingabefelder eine textliche Anweisung vorhanden sein,
- Pflichtfelder durch eine Anweisung (z.B. im <label>) gekennzeichnet und
- vorgegebene Wertebereiche wie etwa Formate in Datumsfeldern oder Länge einer Nummer durch eine Anweisung (z.B. im <label>) angegeben werden.
Eingaben müssen dann vor dem Abschicken geprüft oder bestätigt werden bzw. nach dem Abschicken rückgängig gemacht werden können, wenn
- Nutzer durch das Abschicken des Formulars eine rechtliche oder finanzielle Verpflichtung eingehen,
- Daten (z.B. Profildaten) vom Nutzer gelöscht oder geändert werden oder
- Antworten in einem Test abgeschickt werden.
Wenn Fehler beim Ausfüllen/Abschicken des Formulars festgestellt werden und Nutzer die Fehleingaben korrigieren können, müssen
- die Fehler in Textform angegeben werden (farbliche Markierungen reichen nicht aus).
- Hinweise oder Vorschläge die Korrektur erleichtern, wenn der Fehler ermittelt werden kann (z.B. PLZ in .de ist 5-stellig).
Hinweis: Korrekturvorschläge sind für CAPTCHAs oder für Antworten in anderen Tests nicht erforderlich.

Weitere Accessibility-Checklisten

Graue Haare

Dieser Beitrag ist Teil der Serie "Accessibility-Checkliste gegen graue Haare". Zuletzt musste ich mich mit der Barrierefreien Informationstechnik-Verordnung (BITV) 2.0 auseinandersetzen, die gerne als deutsche Fassung der Web Content Accessibility Guidelines (WCAG) 2.0 angesehen wird. Die BITV 2.0 weicht allerdings erstaunlich oft von den WCAG 2.0 ab.

Im Zuge der Untersuchung musste ich mich auch mit dem sogenannten "BITV-Test" der DIAS GmbH - eine Prüfanleitung für barrierefreies Webdesign - auseinandersetzen, um seine Zuverlässigkeit zu bewerten. Auffällig war insbesondere die deutliche Abweichung des "BITV-Tests" von der BITV 2.0 (und den WCAG 2.0).

Diese beiden Umstände haben mich dazu veranlasst, graue Haare für die BITV 2.0 und den "BITV-Test" wie folgt zu vergeben:

Ein graues Haar gibt es für die BITV 2.0, wenn eine Anforderung oder eine Bedingung inhaltlich von den WCAG 2.0 abweicht. Ein graues Haar gibt es auch für einzelne Prüfschritte im "BITV-Test", wenn
1. im Prüfschritt die Bedingung aus der BITV 2.0 nicht geprüft werden kann (z.B. weil nur eine Best-Practice-Technik geprüft wird),
2. im Prüfschritt etwas geprüft wird, das nicht in der BITV 2.0 verlangt wird und
3. der Prüfschritt so allgemein gehalten wird, dass er nicht zuverlässig eingesetzt werden kann.
Für solche Anforderungen und Bedingungen der BITV 2.0, die im Einklang mit den Richtlinien und Erfolgskriterien aus den WCAG 2.0 sind, und solche Prüfschritte im "BITV-Test", die eine Überprüfung der BITV 2.0 zulassen, gibt es drei farbige Haare und ein "OK".

BITV 2.0 (Anlage 1) und WCAG 2.0

Die Anforderung der BITV 2.0 ist im Einklang mit der Richtlinie aus den WCAG 2.0.

Auf Priorität I der BITV 2.0 werden vier Bedingungen zur Hilfestellung bei der Eingabe formuliert:

Wenn Fehleingaben bei der Eingabe oder beim Abschicken eines Formulars aufgezeigt werden, dann dürfen sie nach Bedingung 3.3.1 Fehleridentifizierung nicht alleine mit Farbe oder einer Grafik gekennzeichnet werden, sondern der Fehler muss in Textform angegeben werden. Die textlichen Hinweise können in unterschiedlicher Form bereitgestellt werden (z.B. im <label>, vor dem Formular, Dialogfenster usw.).

Hinweis: Wenn keine Fehlerbehandlung stattfindet, dann entfällt diese Bedingung.

In Bedingung 3.3.2 Beschriftungen geht es darum, dass Nutzer ausreichende Informationen erhalten, um ein Formular fehlerfrei auszufüllen. Insbesondere gilt:

der Nutzer erfährt, was in jedem einzelnen Formularfeld eingetragen werden soll,
Der Nutzer erfährt, welche Eingabefelder ausgefüllt werden müssen (Pflichtfelder), und
welche Wertebereiche für Eingabefelder vorgegeben werden.

Anweisungen sind am besten zugänglich, wenn sie Teil der Formularbeschriftung sind, aber nach dieser Bedingung ist entscheidend, dass es auf der Webseite ausreichende Informationen gibt, um eine Eingabe fehlerfrei vorzunehmen. Insbesondere für Screenreadernutzer ist es aber wichtig, dass solche Anweisungen mit dem auszufüllenden Steuerelement verknüpft werden (vgl. Bedingung 1.3.1 und Bedingung 4.1.2). Wenn also die Anweisung nicht im <label> steht, dann sollten andere Techniken (mit ARIA) zur Verknüpfung der Anweisung mit dem Steuerelement in Erwägung gezogen werden.

Die Bezeichnung der Bedingung 3.3.2 („Beschriftungen“) ist in der BITV 2.0 irreführend, denn in der Bedingung geht es um Anweisungen. In der WCAG 2.0 lautet das Erfolgskriterium „Beschriftungen (Labels) und Anweisungen“. Beschriftungen identifizieren eine Komponente während Anweisungen vor oder zwischen Komponenten stehen können (aber selbstverständlich auch als Beschriftung genutzt werden dürfen).

Wenn Fehleingaben bei der Eingabe oder beim Abschicken eines Formulars festgestellt werden, sind nach Bedingung 3.3.3 Korrekturvorschläge den Nutzern Empfehlungen für die Fehlerkorrektur bereitzustellen.

Wenn Nutzer auf Fehleingaben hingewiesen werden, sind vor allem nicht ausgefüllte Pflichtfelder und ungültige Werte für Felder mit einem vorgegebenem Wertebereich genauer zu beschreiben. I.d.R. wird eine Formularvalidierung auf der Grundlage bestimmter Algorithmen erfolgen; wenn ein Fehler festgestellt wird, so kann der Grund für den Fehler meist auch als Texthinweis formuliert werden. In vielen Situationen kann daraus sogar ein Korrekturvorschlag abgeleitet werden.

Hinweis: Wenn keine Korrekturempfehlungen bekannt sind, dann entfällt diese Bedingung; gleiches gilt, wenn eine Korrekturempfehlung die Sicherheit (z.B. in CAPTCHAs) oder einen anderen Zweck (z.B. in einem Test) gefährdet.

Nach Bedingung 3.3.4 Fehlervermeidung müssen Formulare vor dem Abschicken bestätigt oder geprüft werden oder nach dem Abschicken rückgängig gemacht werden können. Das gilt für folgende Situationen:

wenn durch das Abschicken des Formulars eine rechtliche Verpflichtung oder eine finanzielle Transaktion ausgelöst wird,
wenn nutzerkontrollierte Daten (z.B. Profildaten) gelöscht oder geändert werden) und
wenn in einem Test eine Antwort abgeschickt wird.

„BITV-Test“ und BITV 2.0

Der „BITV-Test“ bietet drei Prüfschritte zu Anforderung 3.3 (Hilfestellung bei der Eingabe) an:

In Prüfschritt 3.3.1a Fehlermeldungen hilfreich werden sowohl Bedingung 3.3.1 als auch Bedingung 3.3.3 geprüft. Die Ausrichtung des Prüfschritts ist weitgehend im Einklang mit den beiden Bedingungen. Unklar ist lediglich, warum die Identifizierung eines fehlerhaft ausgefüllten Feldes durch deutliche Hervorhebungen zulässig ist, denn Bedingung 3.3.1 verlangt eindeutig Text.

Prüfschritt 3.3.2a Formularfelder richtig beschriftet behandelt verschiedene Aspekte von Formularbeschriftungen. Einerseits werden die logischen Verknüpfungen von Beschriftungen mit ihren zugehörigen Steuerelementen (Bedingung 1.3.1) und andererseits beschreibende Beschriftungen (Bedingung 2.4.6) geprüft. Die Bedingung 3.3.2 wird grundsätzlich auch geprüft. Hinweis: Der Prüfschritt lehnt sich teilweise sehr stark an ganz bestimmte Techniken an (und weniger an die Bedingungen aus der BITV 2.0).

Der Prüfschritt 3.3.4a Fehlervermeidung wird unterstützt deckt die Bedingung 3.3.4 nur teilweise ab. Bei Abschicken eines Formulars mit rechtlichen oder finanziellen Konsequenzen für den Nutzer wird darauf geprüft, ob der Nutzer den Vorgang explizit zustimmen kann. Weitere Aspekte der Bedingung aus der BITV 2.0 (z.B. Löschvorgänge) fehlen im Prüfschritt.

Zur Serie "Accessibility-Checkliste gegen graue Haare

Den Anlass für diese Serie finden Sie im einleitenden Beitrag Accessibility-Checkliste gegen graue Haare beschrieben.

Es ist wichtig, dass es in Deutschland Regelungen zur Barrierefreiheit im Web gibt. Allerdings steht die BITV 2.0 in Widerspruch zu internationalen Webstandards und weiteren Industrienormen, was in der Praxis durchaus ein Problem darstellt. Dass der "BITV-Test" diese Differenzen nicht relativiert, sondern verstärkt, hat zur Folge, dass barrierefreies Webdesign in Deutschland missverstanden wird. Die WCAG 2.0 sind stabile und international anerkannte Standards, die in den erläuternden Dokumenten laufend auf den aktuellen Stand der Technik gehalten werden. Die BITV 2.0 ist hingegen starr, und der "BITV-Test" bietet keinesfalls eine geeignete Basis, eine Konformität zu der BITV 2.0 (oder den WCAG 2.0) reliabel zu überprüfen.

Die Serie besteht aus einer Reihe von Checklisten, die jeweils die einzelnen Anforderungen der BITV 2.0 abbilden. Ergänzt werden die Checklisten mit Kritik an einzelne Bedingungen der BITV 2.0 und Kritik an einzelne Prüfschritte im "BITV-Test". Insgesamt handelt es sich bei dieser Serie um 12 Accessibility-Checklisten, die bei Bedarf auch aktualisiert werden: