WCAG 3.3.7: Redundante Eingabe

WCAG 3.3.7 verlangt, dass Angaben, die jemand innerhalb eines Vorgangs bereits gemacht hat, nicht ein zweites Mal eingetippt werden müssen – sie werden automatisch übernommen oder stehen zur Auswahl bereit. Ausgenommen sind Fälle, in denen die erneute Eingabe unverzichtbar oder aus Sicherheitsgründen nötig ist oder die frühere Angabe nicht mehr gültig ist.

(Englisch: Redundant Entry. Der BIK-BITV-Test nennt den Prüfschritt „Redundanter Eintrag“.)

Das Wichtigste in Kürze

• Die Grenze ist der Vorgang, nicht die Website. Innerhalb eines Checkouts, einer Registrierung oder eines Antrags gilt das Kriterium; ein neuer Besuch nächste Woche ist ein neuer Vorgang.
• Zwei Wege sind zulässig: die Angabe automatisch vorbefüllen oder sie zur Auswahl anbieten – Auswahlliste, Kontrollkästchen „wie oben“, Kopierfunktion.
• Drei Ausnahmen stehen im Normtext: die Wiederholung ist unverzichtbar (die Passwortbestätigung), sie dient der Sicherheit, oder der frühere Wert ist nicht mehr gültig.
• Die E-Mail-Adresse zweimal abzufragen ist keine Sicherheitsmaßnahme, sondern Gewohnheit – und damit ein Befund.
• Der „Zurück“-Test entscheidet oft. Wer einen Schritt zurückgeht und wieder vorwärts, muss seine Eingaben vorfinden.
• autocomplete hilft, reicht aber nicht. 3.3.7 nimmt die Website in die Pflicht, nicht den Browser des Nutzers.
• Das Kriterium steht auf Stufe A – der niedrigsten Hürde. Es ist eines der wenigen 2.2-Kriterien, das ohne CSS oder ARIA auskommt und rein in der Prozesslogik liegt.
• Häufigste Fundstellen: Rechnungs- und Lieferadresse, mehrstufige Anträge nach dem Zurückspringen, Support-Formulare im eingeloggten Zustand, Terminbuchungen mit vorgeschalteter Registrierung.

Darf ich dieselbe Angabe zweimal abfragen?

Nein. Innerhalb eines Vorgangs bereits gemachte Angaben werden automatisch übernommen oder zur Auswahl angeboten.

Der Normtext ist eine Prozessregel: Informationen, die der Nutzer im selben Vorgang schon eingegeben oder erhalten hat, werden ihm entweder automatisch eingetragen oder zur Auswahl gestellt. Es geht nicht darum, ob das Formular schön ist, sondern ob dieselbe Information zweimal aus dem Kopf abgerufen und getippt werden muss.

Die entscheidende Vokabel ist „derselbe Vorgang“. Der BITV-Prüfschritt stellt klar: Die Anforderung bezieht sich auf eine einzelne Sitzung, nicht auf mehrere Besuche. Du musst also nichts dauerhaft speichern. Innerhalb einer Bestellstrecke, eines Antragsformulars oder einer Registrierung gilt sie aber vollständig – auch über Seitenwechsel hinweg und auch nach dem Zurückspringen.

Erlaubt sind zwei Umsetzungen, und die zweite ist die unterschätzte:

Automatisch vorbefüllen. Was in Schritt 1 stand, steht in Schritt 3 schon im Feld. Der Nutzer kann es ändern, muss es aber nicht neu tippen.

Zur Auswahl anbieten. Der Prüfschritt nennt Auswahllisten, Kontrollkästchen und die Möglichkeit, den früheren Wert zu markieren und zu kopieren. Ein Kästchen „Rechnungsadresse entspricht der Lieferadresse“ erfüllt das Kriterium vollständig – es ist sogar die klarere Lösung, weil sie sichtbar macht, was passiert.

Die drei Ausnahmen sind eng gefasst:

• Unverzichtbar: Die klassische Passwortbestätigung. Der Zweck der Wiederholung ist gerade, dass sie unabhängig eingegeben wird.
• Sicherheit: Eine Transaktions-PIN vor der Freigabe einer Überweisung.
• Nicht mehr gültig: Ein Ausweisdatum, das zwischenzeitlich abgelaufen ist, oder ein Termin, der inzwischen belegt wurde.

Was keine Ausnahme ist: die doppelte Abfrage der E-Mail-Adresse „zur Sicherheit“. Sie verhindert keinen Tippfehler zuverlässig (viele Menschen kopieren das erste Feld) und dient keinem Sicherheitszweck im Sinne des Normtexts. Ein Bestätigungslink an die eingegebene Adresse leistet dasselbe, ohne jemanden zum zweiten Tippen zu zwingen.

Der vollständige Wortlaut steht im Understanding-Dokument des W3C zu 3.3.7; das deutsche Prüfvorgehen beschreibt der Prüfschritt 3.3.7 des BIK BITV-Tests.

Wen betrifft es besonders?

Menschen mit Einschränkungen des Kurzzeitgedächtnisses trifft es am härtesten. Eine Kundennummer, die vier Schritte vorher stand, ist nach zwei Seitenwechseln weg. Sie erneut abzurufen heißt: zurückblättern, notieren, wieder vorspringen – und dabei die Position im Formular verlieren. Bei ADHS kommt hinzu, dass jede Wiederholung ein neuer Punkt ist, an dem der Faden reißt.

Für Menschen mit motorischen Einschränkungen ist es schlicht eine Rechenaufgabe. Wer per Switch-Scanning tippt, wählt jeden Buchstaben aus einer durchlaufenden Matrix aus. Eine Adresse kostet so je nach Scangeschwindigkeit mehrere Minuten. Drei doppelte Felder sind kein Ärgernis, sondern ein abgebrochener Kauf.

Screenreader-Nutzer müssen sich Werte merken, die sie nicht überfliegen können. Um eine früher eingegebene Angabe nachzuschlagen, navigiert man Feld für Feld dorthin zurück und wieder vor – falls die Daten den Rückweg überhaupt überleben.

Und die situative Gruppe, in der wir alle irgendwann landen: Antragsformulare am Handy, unterwegs, mit einer Hand. Jedes doppelte Feld erhöht die Wahrscheinlichkeit, dass der Vorgang nicht zu Ende gebracht wird.

Richtig & falsch im Code

Der häufigste Fall ist die Rechnungsadresse. Das Kontrollkästchen ist die etablierte Lösung – es sollte standardmäßig aktiviert sein:

<!-- Falsch: dasselbe Adressformular ein zweites Mal -->
<fieldset>
  <legend>Rechnungsadresse</legend>
  <label for="r-name">Name</label>
  <input id="r-name" name="rechnung_name" autocomplete="billing name" />
  <label for="r-strasse">Straße und Hausnummer</label>
  <input id="r-strasse" name="rechnung_strasse" autocomplete="billing street-address" />
  …
</fieldset>

<!-- Richtig: Auswahl statt Wiederholung -->
<fieldset>
  <legend>Rechnungsadresse</legend>
  <label>
    <input type="checkbox" name="rechnung_wie_lieferung" checked
           aria-controls="rechnung-felder" aria-expanded="false" />
    Entspricht der Lieferadresse
  </label>
  <div id="rechnung-felder" hidden>
    <!-- erscheint nur, wenn das Kästchen abgewählt wird -->
  </div>
</fieldset>

In mehrstufigen Strecken kommt es auf den Rückweg an. Serverseitig gehaltener Zustand ist der zuverlässige Weg – die Werte werden beim Rendern des Schritts eingesetzt:

<!-- Richtig: Schritt 3 zeigt, was in Schritt 1 eingegeben wurde -->
<label for="mail">E-Mail-Adresse</label>
<input type="email" id="mail" name="mail"
       value="{{ vorgang.mail }}" autocomplete="email" />
<p class="hinweis">Aus Schritt 1 übernommen. Änderungen sind möglich.</p>

Wo eine automatische Übernahme nicht passt, genügt eine Auswahl. Der Prüfschritt akzeptiert das ausdrücklich:

<!-- Richtig: frühere Angaben zur Auswahl anbieten -->
<label for="vorgang">Worum geht es?</label>
<select id="vorgang" name="vorgang">
  <option value="">Bitte wählen</option>
  <option value="4711">Bestellung 4711 vom 12.07.2026</option>
  <option value="4698">Bestellung 4698 vom 03.07.2026</option>
  <option value="neu">Ein anderes Anliegen</option>
</select>

Und die Ausnahme, damit sie nicht überdehnt wird:

<!-- Zulässig: Wiederholung ist hier der Zweck -->
<label for="pw">Neues Passwort</label>
<input type="password" id="pw" autocomplete="new-password" />
<label for="pw2">Passwort wiederholen</label>
<input type="password" id="pw2" autocomplete="new-password" />

<!-- Nicht zulässig: doppelte E-Mail „zur Sicherheit“ -->
<label for="mail2">E-Mail-Adresse wiederholen</label>
<input type="email" id="mail2" />

Flankierend gehört autocomplete an jedes Feld – das erfüllt 1.3.5 und hilft nebenbei. Es ersetzt die Prozesslösung aber nicht: Der Browser kennt Name und Adresse, nicht deine Vorgangsnummer. Die vollständigen Muster für Zustandserhalt stehen unter Mehrstufige Formulare & Wizards.

So testest du es

1. Die längsten Prozessstrecken auswählen. Checkout, Registrierung, Antrag, Terminbuchung, Reklamation. Kurze Kontaktformulare sind selten betroffen.
2. Einmal komplett durchspielen und mitschreiben. Jede Angabe notieren, sobald sie zum ersten Mal verlangt wird. Taucht dieselbe Information später erneut auf, ist das der Befund.
3. Den Zurück-Test machen. Einen Schritt zurückgehen und wieder vorwärts: Sind die Eingaben noch da? Gleiches mit der Zurück-Schaltfläche des Browsers – viele Wizards verlieren dort ihren Zustand.
4. Im eingeloggten Zustand prüfen. Wenn Kundennummer, Adresse und Geburtsdatum im Konto hinterlegt sind, dürfen sie im Support-Formular nicht neu erfragt werden. Sie anzubieten reicht.
5. Jede Wiederholung gegen die drei Ausnahmen halten. Unverzichtbar? Sicherheit? Nicht mehr gültig? Wenn keine davon greift, ist es ein Verstoß – auch wenn es sich eingebürgert hat.
6. Mit Fehlermeldungen gegenprüfen. Nach einem Validierungsfehler wird gern das halbe Formular geleert. Passwortfelder dürfen leer sein, alles andere nicht – das berührt zusätzlich 3.3.1.
7. Auf dem Handy wiederholen. Manche Strecken springen dort in eine Sonderansicht, die den Zustand nicht mitnimmt.

Häufiger Fehler in der Praxis

Der teuerste Fall ist der Zustandsverlust nach der Fehlermeldung. Ein Nutzer füllt sechs Felder aus, vergisst das Häkchen bei den AGB, drückt Absenden – und bekommt ein leeres Formular zurück. Formal ist das ein Verstoß gegen 3.3.7, weil die Angaben im selben Vorgang schon gemacht wurden. Praktisch ist es der Punkt, an dem die meisten Menschen abbrechen. Ich sag’s mal so: Wenn ein Formular Daten verliert, ist die Barrierefreiheit nur das erste Problem.

Der zweite ist die doppelte E-Mail-Abfrage. Sie steht in unzähligen Anmeldeformularen und wird mit „zur Sicherheit“ begründet. Der Normtext kennt Sicherheit als Ausnahme – gemeint ist damit aber der Schutz der Inhalte, nicht die Vermeidung von Tippfehlern. Wer Tippfehler abfangen will, schickt eine Bestätigungsmail; das prüft die Adresse tatsächlich, statt nur die Eingabe zu verdoppeln.

Der dritte ist das Support-Formular im eingeloggten Bereich. Kundennummer, Vertragsnummer, Rechnungsanschrift – alles im Konto vorhanden, alles nochmal abgefragt. Das ist der Fall, den 3.3.7 mit dem Wort „zur Verfügung gestellt“ meint: Wenn dir die Information vorliegt, biete sie an. Eine Auswahlliste mit den letzten drei Bestellungen genügt.

Und ein Fall, der falsch bewertet wird: Ein Antragsformular, das nach vier Wochen erneut ausgefüllt werden muss, weil der Nutzer den Vorgang unterbrochen hat, ist kein 3.3.7-Verstoß. Das Kriterium gilt innerhalb einer Sitzung. Ein Zwischenspeichern ist eine gute Idee – verlangt wird es hier nicht.

Häufige Fragen

Gilt 3.3.7 auch über mehrere Besuche hinweg?

Nein. Der Prüfschritt stellt klar, dass sich die Anforderung auf eine einzelne Sitzung bzw. einen zusammenhängenden Vorgang bezieht. Wer die Bestellung abbricht und eine Woche später neu beginnt, darf seine Daten wieder eingeben müssen. Innerhalb der Strecke – inklusive Seitenwechseln und Zurückspringen – gilt das Kriterium vollständig.

Ist die Passwortbestätigung ein Verstoß?

Nein. Sie fällt unter die Ausnahme „unverzichtbar“: Der Zweck des zweiten Feldes ist gerade, dass es unabhängig eingegeben wird. Dasselbe gilt für eine Transaktions-PIN vor einer Überweisung. Die doppelte E-Mail-Abfrage ist dagegen keine Ausnahme – sie dient weder der Sicherheit noch ist sie unverzichtbar.

Reicht autocomplete an den Feldern aus?

Nein. autocomplete erfüllt 1.3.5 Eingabezweck bestimmen und hilft im Alltag, verlagert die Aufgabe aber auf den Browser des Nutzers – und der kennt weder deine Vorgangsnummer noch das, was zwei Schritte vorher im Formular stand. 3.3.7 nimmt die Website in die Pflicht.

Muss ich Daten vorbefüllen oder darf ich sie nur anbieten?

Beides ist zulässig. Der Normtext nennt „automatisch eingetragen“ oder „zur Auswahl verfügbar“. Ein Kontrollkästchen „Entspricht der Lieferadresse“, eine Auswahlliste mit früheren Angaben oder eine Schaltfläche „Daten aus Schritt 1 übernehmen“ erfüllen das Kriterium genauso wie ein vorausgefülltes Feld.

Zählt eine Bestätigungsseite, auf der alle Angaben noch einmal stehen?

Ja, das ist sogar der Idealfall – solange die Angaben dort nur angezeigt und nicht erneut eingetippt werden müssen. Eine Zusammenfassung mit Bearbeiten-Links pro Abschnitt erfüllt 3.3.7 und hilft zusätzlich bei 3.3.4 Fehlervermeidung, das für rechtsverbindliche Vorgänge eine Prüfmöglichkeit verlangt.

Verwandte Themen

• Mehrstufige Formulare & Wizards – Zustandserhalt über Schritte hinweg
• 1.3.5 Eingabezweck bestimmen – Autofill als Verbündeter
• 3.3.4 Fehlervermeidung – Prüfen und Korrigieren vor dem Absenden
• 3.3.1 Fehlererkennung – warum Formulare nach Fehlern nichts löschen dürfen
• Barrierefreiheit in Onlineshops – der Checkout als Prüfstrecke
• Die neuen WCAG-2.2-Kriterien – alle Neuerungen im Überblick