BITV 2.0 – Priorität I BITV 2.0 – Priorität II WCAG 2.2: 3.3 EN 301 549: 9.3.3

Anforderung 3.3: Eingabeunterstützung

Anforderung 3.3 der BITV 2.0 betrifft Fehlermeldungen, barrierefreie Formulare, Eingabevalidierung und Authentifizierung, damit Nutzerinnen und Nutzer Eingaben sicher und nachvollziehbar abschließen können. Wenn Pflichtfelder unklar sind, Fehler nur farblich markiert werden oder Login-Verfahren unnötig kompliziert sind, kann das Menschen ausschließen, die mit Tastatur, Screenreader oder kognitiven Einschränkungen arbeiten. WCAG 3.3 und EN 301 549 geben deshalb konkrete Regeln für Fehlererkennung, Hilfestellung, redundante Eingaben und zugängliche Authentifizierung vor. Das ist für öffentliche Stellen ebenso relevant wie für bestimmte Produkte und Dienstleistungen für Verbraucherinnen und Verbraucher im BFSG.

Geltungsbereich: BITV 2.0 gilt für öffentliche Stellen. Das BFSG gilt seit dem 28. Juni 2025 für bestimmte Produkte und Dienstleistungen für Verbraucherinnen und Verbraucher. 3.3.1–3.3.4, 3.3.7 und 3.3.8 sind verpflichtend; 3.3.5, 3.3.6 und 3.3.9 sind Priorität II und in EN 301 549 V3.2.1 nur informativ in Tabelle 9.1 gelistet.

Normtext – BITV 2.0 Anlage 1, Anforderung 3.3

Benutzerinnen und Benutzern ist zu helfen, Fehler zu vermeiden und zu korrigieren.

Quelle: BITV 2.0, Anlage 1 (gesetze-im-internet.de) · Einzelkriterien nach WCAG 2.2 Richtlinie 3.3 (w3.org)

Was wird bei Anforderung 3.3 gefordert?

  • 3.3.1 Fehlererkennung: Eingabefehler müssen klar benannt und an das betroffene Feld gebunden sein.
  • 3.3.2 Beschriftungen oder Anweisungen: Nutzerinnen und Nutzer sollen wissen, was in ein Feld gehört und welche Pflichten gelten.
  • 3.3.3 Fehlerempfehlung: Bei Fehlern sollen verständliche Korrekturvorschläge angezeigt werden.
  • 3.3.4 Fehlervermeidung bei wichtigen Aktionen: Bei rechtlichen, finanziellen oder datenrelevanten Aktionen braucht es Sicherungen wie Prüfung oder Rückfrage.
  • 3.3.5 Hilfe (Priorität II): Hilfe muss leicht auffindbar sein; in EN 301 549 V3.2.1 nur informativ in Tabelle 9.1 gelistet.
  • 3.3.6 Fehlervermeidung allgemein (Priorität II): Inhalte sollen Fehler generell vorbeugen; in EN 301 549 V3.2.1 nur informativ in Tabelle 9.1 gelistet.
  • 3.3.7 Redundante Eingabe: Bereits eingegebene Informationen sollen möglichst nicht erneut verlangt werden.
  • 3.3.8 Zugängliche Authentifizierung Minimum: Login und Verifikation sollen ohne unnötige kognitive Hürden möglich sein.
  • 3.3.9 Zugängliche Authentifizierung Erweitert (Priorität II): Noch stärker vereinfachte Authentifizierung; in EN 301 549 V3.2.1 nur informativ in Tabelle 9.1 gelistet.

3.3.1 Fehlererkennung bei Formulareingaben

BITV 2.0 – Priorität I WCAG A EN 301 549: 9.3.3.1

Wenn ein Formularfehler auftritt, muss klar erkennbar sein, welches Feld betroffen ist und was falsch ist. Eine bloße rote Markierung reicht nicht aus, weil sie für viele Nutzerinnen und Nutzer nicht eindeutig genug ist. Die Anforderung hilft besonders bei Formularen mit Datum, E-Mail, IBAN oder anderen prüfpflichtigen Feldern. Klare Fehlermeldungen geben Orientierung statt Rätselraten.

Umsetzung: Bei falschem Datumsformat nicht nur einen roten Rand zeigen, sondern eine konkrete Meldung wie „Bitte Datum im Format TT.MM.JJJJ eingeben". Die Fehlermeldung mit dem Eingabefeld verknüpfen, damit Screenreader sie mit ausgeben. Wenn mehrere Felder betroffen sind, jedes Feld einzeln nennen.

3.3.2 Beschriftungen oder Anweisungen für Eingaben

BITV 2.0 – Priorität I WCAG A EN 301 549: 9.3.3.2

Nutzerinnen und Nutzer müssen wissen, was sie eingeben sollen und welche Regeln gelten. Das ist besonders wichtig bei Pflichtfeldern, komplexen Formaten oder Formularen mit Sonderregeln. Ohne klare Beschriftungen kann ein Formular unnötig fehleranfällig werden. Gute Anweisungen sparen Zeit und verhindern Frust bei der Eingabe.

Umsetzung: Pflichtfelder eindeutig kennzeichnen und Formate erklären – etwa „Telefonnummer ohne Leerzeichen" oder „Passwort mindestens zwölf Zeichen". Wenn ein Feld nur für bestimmte Angaben gedacht ist, sollte das direkt am Label stehen. Ein Formular zur Adressangabe wird so deutlich verständlicher.

3.3.3 Fehlerempfehlung bei ungültigen Eingaben

BITV 2.0 – Priorität I WCAG AA EN 301 549: 9.3.3.3

Wenn ein Fehler erkannt wird, sollte möglichst auch eine hilfreiche Korrektur vorgeschlagen werden. Das ist besonders nützlich bei Formaten wie Datum, Postleitzahl oder E-Mail, bei denen die richtige Form oft klar benennbar ist. Nutzerinnen und Nutzer müssen so nicht selbst herausfinden, wie die Eingabe aussehen soll. Die Empfehlung sollte freundlich, konkret und umsetzbar sein.

Umsetzung: Bei einer ungültigen E-Mail-Adresse zum Beispiel „Bitte eine Adresse wie name@beispiel.de eingeben" schreiben. Bei einem Datumsfehler sollte das korrekte Format genannt werden. Wenn mehrere Lösungen möglich sind, die naheliegendste Option erklären.

3.3.4 Fehlervermeidung bei wichtigen Aktionen

BITV 2.0 – Priorität I WCAG AA EN 301 549: 9.3.3.4

Bei rechtlichen, finanziellen oder datenrelevanten Aktionen braucht es besondere Sicherungen. Das betrifft etwa Bestellungen, Überweisungen, Datenlöschungen oder verbindliche Anträge. Ein zusätzlicher Prüfschritt, eine Bestätigung oder die Möglichkeit zur Korrektur schützt vor teuren Fehlbedienungen. So bleibt eine wichtige Handlung kontrollierbar.

Umsetzung: Vor einem Kaufabschluss die Daten noch einmal anzeigen und eine Korrekturmöglichkeit anbieten. Ein Bestätigungsschritt vor dem endgültigen Absenden ist sinnvoll, wenn die Aktion verbindlich ist. Bei Löschvorgängen sollte klar sein, was endgültig passiert.

3.3.5 Hilfe leicht auffindbar machen (Priorität II)

BITV 2.0 – Priorität II WCAG AAA EN 301 549: Tabelle 9.1 (informativ)

Diese Priorität-II-Anforderung ist in EN 301 549 V3.2.1 nur informativ in Tabelle 9.1 gelistet. Hilfe soll leicht auffindbar sein, wenn Nutzerinnen und Nutzer bei einer Eingabe Unterstützung brauchen. Das betrifft etwa Kontaktmöglichkeiten, Hilfetexte, FAQ oder kontextbezogene Unterstützung. Gerade bei komplexen Formularen kann das den Unterschied zwischen Abbruch und erfolgreichem Abschluss machen.

Umsetzung: Hilfe-Links oder Kontext-Hinweise sichtbar in der Nähe des Formulars platzieren. Ein Formular mit vielen Pflichtfeldern sollte nicht nur auf eine allgemeine Kontaktseite verweisen. Eine kurze Hilfeseite oder ein erklärender Text direkt am Feld ist oft hilfreicher.

3.3.6 Fehlervermeidung allgemein (Priorität II)

BITV 2.0 – Priorität II WCAG AAA EN 301 549: Tabelle 9.1 (informativ)

Diese Priorität-II-Anforderung ist in EN 301 549 V3.2.1 nur informativ in Tabelle 9.1 gelistet. Sie verlangt, dass Seiten allgemein darauf ausgelegt sind, Fehler zu vermeiden. Das ist besonders sinnvoll bei Formularen, Konfigurationen oder Prozessen mit mehreren Schritten. Gute Vorbeugung ist oft besser als spätere Korrektur.

Umsetzung: Klare Feldlogik, sinnvolle Standardwerte und verständliche Schritte verwenden. Ein mehrstufiges Formular sollte Zwischenspeichern oder Prüfen ermöglichen, bevor die letzte Aktion verbindlich wird. So sinkt die Fehlerwahrscheinlichkeit deutlich.

3.3.7 Redundante Eingabe vermeiden

BITV 2.0 – Priorität I WCAG A EN 301 549: 9.3.3.7

Bereits eingegebene Informationen sollen möglichst nicht erneut verlangt werden. Wenn Nutzerinnen und Nutzer Daten schon einmal eingetragen haben, kann eine Wiederholung unnötig und fehleranfällig sein. Das ist besonders bei längeren Prozessen, Anträgen oder Kontoanlagen relevant. Redundanz kostet Zeit und kann Menschen mit Gedächtnis- oder Konzentrationsschwierigkeiten stärker belasten.

Umsetzung: Vorhandene Angaben übernehmen, wenn sie bereits bekannt sind, statt sie erneut abzufragen. Eine Adresse, die im ersten Schritt erfasst wurde, sollte nicht im nächsten Schritt wieder vollständig eingegeben werden müssen. Wenn eine erneute Eingabe nötig ist, sollte sie klar begründet sein.

3.3.8 Zugängliche Authentifizierung Minimum

BITV 2.0 – Priorität I WCAG AA EN 301 549: 9.3.3.8

Login- und Verifikationsverfahren sollen ohne unnötige kognitive Hürden funktionieren. CAPTCHA-Hürden, Merkaufgaben oder komplizierte Schrittfolgen können Menschen ausschließen, die auf einfache und klare Authentifizierung angewiesen sind. Die Mindestanforderung zielt darauf, dass eine Anmeldung nicht an Gedächtnisaufgaben oder schwierigen Rätseln scheitert. Das ist besonders wichtig bei sensiblen Portalen und Formularen.

Umsetzung: Mehrere Wege zur Anmeldung anbieten – etwa E-Mail-Links, Passkeys oder andere zugängliche Verfahren. Wenn ein CAPTCHA vorkommt, sollte eine gleichwertige barrierearme Alternative vorhanden sein. Eine Authentifizierung darf nicht allein auf das Erinnern von Details oder das Lösen visueller Rätsel setzen.

3.3.9 Zugängliche Authentifizierung Erweitert (Priorität II)

BITV 2.0 – Priorität II WCAG AAA EN 301 549: Tabelle 9.1 (informativ)

Diese Priorität-II-Anforderung ist in EN 301 549 V3.2.1 nur informativ in Tabelle 9.1 gelistet. Sie geht über das Minimum hinaus und verlangt noch stärker vereinfachte Zugänge zur Authentifizierung. Das ist besonders hilfreich, wenn eine Anmeldung regelmäßig genutzt wird oder sehr wichtige Inhalte betrifft. Je weniger kognitive Hürden, desto besser die Nutzbarkeit.

Umsetzung: Auf unnötige Gedächtnisaufgaben und auf komplizierte, mehrstufige Prüfungen ohne Alternative verzichten. Wenn Sicherheitsfragen oder Codes notwendig sind, sollten sie möglichst einfach und gut handhabbar sein. Für kritische Prozesse kann eine zugänglichere Ersatzmethode oft die bessere Wahl sein.

Häufige Fragen zu Anforderung 3.3

Wie muss eine barrierefreie Fehlermeldung aussehen?

Sie sollte klar sagen, welches Feld betroffen ist und wie der Fehler behoben werden kann. Eine bloße farbliche Markierung reicht nicht aus. Gut sind konkrete Hinweise wie das richtige Datumsformat oder ein verständlicher Korrekturvorschlag.

Was bedeutet zugängliche Authentifizierung?

Das heißt, dass Login- und Prüfverfahren ohne unnötige kognitive Hürden nutzbar sein sollen. Nutzerinnen und Nutzer sollen nicht an Rätseln, unklaren Aufgaben oder schwer handhabbaren Alternativen scheitern. Wenn ein CAPTCHA vorkommt, braucht es eine barrierearme Alternative.

Was ist redundante Eingabe und warum ist sie ein Problem?

Redundante Eingabe bedeutet, dass Nutzerinnen und Nutzer dieselben Informationen mehrfach eingeben müssen. Das kostet Zeit und erhöht die Fehlerwahrscheinlichkeit, besonders in längeren Formularen. Besser ist es, bereits bekannte Daten zu übernehmen oder automatisch vorzubelegen.

Einordnung in weitere Normen

Anforderung 3.3 basiert auf WCAG 2.2 Richtlinie 3.3. Im europäischen Standard EN 301 549 sind die normativen Anforderungen unter Abschnitt 9.3.3 verankert. Die Priorität-II-Anforderungen 3.3.5, 3.3.6 und 3.3.9 (WCAG AAA) sind dort nur informativ in Tabelle 9.1 gelistet.

Offizielle Quellen