WCAG 3.3.7: Redundante Eingabe

WCAG 3.3.7 verlangt, dass Informationen, die Nutzer bereits in einem mehrstufigen Prozess angegeben haben, entweder automatisch ausgefüllt oder zur Auswahl bereitgestellt werden, sodass Nutzer dieselben Daten niemals zweimal eingeben müssen. Dies verhindert Frustration und Fehler bei Nutzern mit kognitiven, motorischen oder anderen Beeinträchtigungen.

Was diese Regel bedeutet

WCAG 3.3.7 Redundant Entry ist ein Erfolgskriterium der Stufe A, das in WCAG 2.2 eingeführt wurde. Es besagt: „Informationen, die zuvor vom Nutzer eingegeben oder bereitgestellt wurden und die im selben Prozess erneut eingegeben werden müssen, werden entweder automatisch ausgefüllt oder stehen dem Nutzer zur Auswahl zur Verfügung.“ Einfach ausgedrückt: Wenn ein Nutzer während einer Sitzung seine E‑Mail‑Adresse, Lieferadresse, sein Geburtsdatum oder irgendeine andere Information bereits eingegeben hat, darf Ihre Oberfläche ihn nicht dazu zwingen, diese innerhalb desselben Prozesses oder Ablaufs erneut einzugeben.

Das Kriterium gilt allgemein für alle mehrstufigen Formulare, Checkout‑Prozesse, Registrierungs‑Assistenten, Terminbuchungs‑Abläufe oder ähnliche Sequenzen, bei denen Daten, die in einem Schritt erhoben werden, in einem späteren Schritt erneut benötigt werden können. Betroffen sind Verhaltensweisen wie Texteingabefelder, Dropdowns, Kontrollkästchen, Optionsfelder und alle anderen Formularelemente, die vom Nutzer bereitgestellte Daten erfassen. Wenn dieselbe Information erneut benötigt wird, muss sie entweder automatisch mit dem zuvor angegebenen Wert vorausgefüllt werden oder als auswählbare Option angeboten werden, sodass der Nutzer sie bestätigen statt erneut eingeben kann.

Ein Bestehen für dieses Kriterium sieht so aus: ein Rechnungsadressformular, das mit der Lieferadresse vorausgefüllt ist, die der Nutzer auf dem vorherigen Bildschirm eingegeben hat, oder ein Bestätigungsschritt, der die zuvor eingegebene E‑Mail‑Adresse des Nutzers in einem schreibgeschützten Feld anzeigt. Ein weiteres Muster, das besteht, ist ein Kontrollkästchen mit der Beschriftung „Meine Rechnungsadresse ist identisch mit meiner Lieferadresse“, das beim Aktivieren die Werte automatisch übernimmt. Ein Nichtbestehen sieht so aus: ein mehrstufiger Registrierungsablauf, der in Schritt 1 nach einer E‑Mail‑Adresse fragt und in Schritt 3 erneut, ohne das zweite Feld vorab zu befüllen, oder ein Versicherungsformular, das auf mehreren separaten Bildschirmen nach Name und Policennummer des Anspruchstellers fragt, ohne eine automatische Ausfüllfunktion.

WCAG 3.3.7 definiert zwei offizielle Ausnahmen. Die erste Ausnahme greift, wenn das erneute Eingeben der Information wesentlich für den Prozess ist – zum Beispiel fragt ein Feld „Bestätigen Sie Ihr neues Passwort“ Nutzer absichtlich, dasselbe Passwort zweimal einzugeben, um Tippfehler zu vermeiden; dies gilt als wesentliche Sicherheitsprüfung. Die zweite Ausnahme greift, wenn die zuvor eingegebenen Informationen nicht mehr gültig sind – etwa wenn eine Sitzung abgelaufen ist oder ein Produkt nicht mehr vorrätig ist und der Nutzer den Prozess mit aktuellen Daten neu starten muss. Außerhalb dieser Ausnahmen stellt redundante Eingabe einen Konformitätsverstoß dar.

Warum das wichtig ist

Redundante Eingabe belastet Nutzer unverhältnismäßig stark, deren Einschränkungen das Tippen langsam, schmerzhaft, fehleranfällig oder kognitiv anstrengend machen. Zu verstehen, wer betroffen ist, hilft Entwicklern und Designern zu erkennen, dass dieses Kriterium mehr als eine Komfortfunktion ist – es ist für viele Menschen eine echte Barriere.

Nutzer mit motorischen Beeinträchtigungen, etwa mit Tremor, Rückenmarksverletzungen oder Erkrankungen wie ALS oder Multipler Sklerose, können auf Schaltersteuerung, Mundstäbe, Blickverfolgungssoftware oder Sprachsteuerung angewiesen sein, um Text einzugeben. Für diese Nutzer kann das Tippen selbst einer kurzen Adresse mehrere Minuten und erheblichen körperlichen Aufwand erfordern. Wenn sie diese Eingabe wiederholen müssen, ist das nicht nur lästig – es kann körperliche Schmerzen verursachen oder die Aufgabe in einer einzigen Sitzung praktisch unmöglich machen.

Nutzer mit kognitiven Beeinträchtigungen, darunter Legasthenie, Aufmerksamkeitsstörungen, traumatische Hirnverletzungen und demenzbedingte Erkrankungen, können Schwierigkeiten haben, sich daran zu erinnern, was sie vor drei Schritten eingegeben haben. Informationen mehrfach korrekt aus dem Gedächtnis oder von einem Papierdokument zu übertragen, erhöht die Fehlerquote und Abbruchrate erheblich. Laut Weltgesundheitsorganisation leben weltweit über 1 Milliarde Menschen mit irgendeiner Form von Behinderung, und kognitive Beeinträchtigungen gehören zu den größten und am wenigsten berücksichtigten Gruppen in der Barrierefreiheitsplanung.

Nutzer mit Unterschieden an den oberen Gliedmaßen, einschließlich derjenigen, die mit Gliedmaßenunterschieden geboren wurden oder diese erworben haben, tippen deutlich langsamer und verwenden möglicherweise alternative Eingabegeräte. Jeder zusätzliche erforderliche Tastendruck vervielfacht die Belastung für diese Nutzer.

Betrachten Sie ein Szenario aus der Praxis: Eine Nutzerin mit rheumatoider Arthritis bucht einen Arzttermin über das Online‑Portal eines Krankenhauses. Auf Bildschirm 1 gibt sie ihre nationale Ausweisnummer, ihren Namen, ihr Geburtsdatum und ihre Telefonnummer ein. Auf Bildschirm 3 fragt das Portal erneut nach ihrem Namen und Geburtsdatum, um den Patientendatensatz zu bestätigen. Diese Nutzerin muss mühsam Informationen erneut eingeben, die sie erst zwei Bildschirme zuvor bereitgestellt hat, riskiert Tippfehler, die zu nicht übereinstimmenden Datensätzen führen können, und erlebt unnötige körperliche Belastung. Ein einfaches Vorausfüllen oder automatisches Ausfüllen dieser Felder würde die Barriere vollständig beseitigen.

Über die Barrierefreiheit hinaus verbessert die Beseitigung redundanter Eingaben die Konversionsraten, reduziert Formularabbrüche und verringert Support‑Tickets, die durch Dateneingabefehler verursacht werden – und liefert damit messbaren geschäftlichen Mehrwert neben inklusivem Design.

Wie man testet

Automatisierter Scan als Ausgangspunkt: Führen Sie axe DevTools, Lighthouse oder den Accsible‑Auditor auf jedem einzelnen Schritt Ihres mehrstufigen Prozesses aus. Auch wenn diese Tools Verstöße gegen 3.3.7 nicht direkt kennzeichnen, machen sie auf verwandte Probleme aufmerksam, etwa fehlende Autocomplete‑Attribute, nicht beschriftete Formularfelder und andere 3.3.x‑Kriteriumsverstöße, die häufig gemeinsam auftreten. Dokumentieren Sie jedes Formularfeld, das Sie in jedem Schritt finden.
Datenanforderungen über die Schritte hinweg abbilden: Erstellen Sie vor dem manuellen Testen eine einfache Tabelle oder ein Spreadsheet, in dem Sie jeden Schritt im Prozess und alle Datenfelder, die er erfasst, auflisten. Identifizieren Sie dann alle Feldbeschriftungen oder Datentypen, die in mehr als einem Schritt vorkommen. Diese Mapping‑Übung bringt potenzielle Verstöße zutage, noch bevor Sie einen Browser öffnen.
Manueller Durchlauf – Desktop: Schließen Sie mit einer Standard‑Maus und Tastatur den gesamten mehrstufigen Prozess ab (z. B. Checkout, Registrierung, Anspruchseinreichung). Geben Sie in jedes Feld realistische Werte ein. Wenn Sie zu einem Schritt gelangen, der in Ihrer Karte als doppeltes Feld erscheint, prüfen Sie, ob das Feld mit Ihrer früheren Eingabe vorausgefüllt ist oder ob eine auswählbare Option mit Ihrer früheren Eingabe verfügbar ist. Wenn beides nicht der Fall ist, dokumentieren Sie einen Fehler. Wiederholen Sie diesen Test mit einem Screenreader (NVDA mit Firefox, JAWS mit Chrome, VoiceOver mit Safari), um zu bestätigen, dass vorausgefüllte Werte korrekt angesagt werden und dass Auswahlsteuerelemente für zuvor eingegebene Werte per Tastatur erreichbar sind.
Manueller Durchlauf – Mobil: Durchlaufen Sie denselben Ablauf auf iOS (VoiceOver + Safari) und Android (TalkBack + Chrome). Achten Sie darauf, ob native Autocomplete‑ oder Autofill‑Funktionen von der Anwendung unterdrückt werden, was unbeabsichtigt Barrieren durch redundante Eingaben schaffen kann, selbst wenn der Entwickler Autocomplete als Hilfe vorgesehen hat.
Die Ausnahmen testen: Identifizieren Sie alle Felder, die absichtlich eine doppelte Eingabe verlangen (z. B. Passwortbestätigung, E‑Mail erneut eingeben). Prüfen Sie, ob diese als wesentliche Sicherheits‑ oder Validierungsprüfungen unter die WCAG‑Ausnahme fallen und nicht einfach redundante Felder sind, die entfernt oder vorausgefüllt werden sollten.
Mit deaktiviertem Autocomplete testen: Einige Nutzer deaktivieren das Autocomplete des Browsers aus Datenschutzgründen. Testen Sie, ob der eigene Vorausfüllmechanismus der Anwendung (serverseitig oder JavaScript‑gesteuert) weiterhin korrekt funktioniert, wenn das Autocomplete des Browsers ausgeschaltet ist, sodass das Kriterium unabhängig vom Browserverhalten erfüllt wird.

Wie man es behebt

Mehrstufiger Checkout – dieselbe Adresse auf zwei Bildschirmen erforderlich – Falsch

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

Mehrstufiger Checkout – dieselbe Adresse auf zwei Bildschirmen erforderlich – Richtig

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

Registrierungsassistent fragt ohne Begründung zweimal nach E-Mail – Falsch

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

Registrierungsassistent – E-Mail aus Sitzungsdaten vorausgefüllt – Richtig

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

Terminbuchung – Patientendaten im Zusammenfassungsschritt erneut abgefragt – Falsch

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

Terminbuchung – Geburtsdatum als schreibgeschützte Bestätigung angezeigt – Richtig

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

Häufige Fehler

Mehrstufige Formulare als unabhängige Seiten ohne gemeinsamen Sitzungszustand zu entwickeln, sodass es keinen Mechanismus gibt, um Werte aus früheren Schritten zu übernehmen – der grundlegendste Architekturfehler, der zu 3.3.7‑Verstößen führt.
Ein Kontrollkästchen „identisch mit Lieferadresse“ bereitzustellen, ohne die Rechnungsfelder tatsächlich zu befüllen, wenn es aktiviert ist, sodass Nutzer Adressdetails trotzdem manuell eingeben müssen, obwohl sie angegeben haben, dass sie übereinstimmen sollen.
Felder beim Laden der Seite vorauszufüllen, sie aber bei einem Validierungsfehler zu leeren, sodass ein Nutzer, der in einem späteren Schritt einen Fehler macht, alle zuvor bereitgestellten Daten erneut eingeben muss, wenn er zurückkehrt, um ihn zu korrigieren.
Sitzungsdaten unsicher zu speichern und sich dafür zu entscheiden, sie zu deaktivieren, statt das Sicherheitsproblem zu beheben, was zu einer fehlerhaften Vorausfüllerfahrung führt, die technisch einen 3.3.7‑Verstoß darstellt.
Die Ausnahme zur Passwortbestätigung als Begründung zu verwenden, Nutzer E‑Mail‑Adressen erneut eingeben zu lassen, obwohl die Bestätigung der E‑Mail kein wesentlicher Sicherheitscheck ist und nicht unter die WCAG‑Ausnahme fällt.
Übernommene Werte in serverseitig gerenderten Formularen nicht über versteckte Eingabefelder weiterzugeben, wodurch vorausgefüllte Werte verloren gehen, wenn ein Nutzer mit den Browser‑Zurück‑ und Vorwärts‑Buttons durch die Schritte navigiert.
Sich ausschließlich auf das Autofill des Browsers zu verlassen, um dieses Kriterium zu erfüllen, ohne eine anwendungsseitige Vorausfüllung zu implementieren – Nutzer, die Autofill aus Datenschutzgründen deaktivieren, haben dann keinen konformen Weg durch den Prozess.
Ein Feld vorauszufüllen, es aber als disabled statt als readonly zu setzen, wodurch der Wert in den meisten Browsern nicht mit dem Formular übermittelt wird, den Prozess unterbricht und möglicherweise eine erneute Eingabe erzwingt.
Den vollständigen End‑to‑End‑Ablauf nicht mit Nutzern zu testen, die Sprachsoftware wie Dragon NaturallySpeaking verwenden, wobei redundante Felder dazu führen können, dass derselbe Diktierbefehl mehrfach wiederholt werden muss – eine erhebliche Belastung, die in Entwicklertests leicht übersehen wird.
Dieses Kriterium nur auf Adressfelder zu beziehen, obwohl es gleichermaßen für alle wiederholten Daten gilt, einschließlich Namen, Telefonnummern, nationaler Ausweisnummern, Policennummern, Daten und aller anderen vom Nutzer bereitgestellten Informationen, die mehr als einmal im selben Prozess angefordert werden.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, schreibt die Einhaltung der Web‑Barrierefreiheit für eine breite Palette öffentlicher und privater Einrichtungen vor, die in der Türkei tätig sind. WCAG 3.3.7 Redundant Entry ist ein Kriterium der Stufe A unter WCAG 2.2, und die Konformität der Stufe A ist die verpflichtende Basislinie unter dieser Verfügung. Das bedeutet, dass jede erfasste Einrichtung, die eine Website, Webanwendung oder einen digitalen Dienst betreibt, Nutzer nicht dazu zwingen darf, Informationen, die sie bereits innerhalb desselben Prozesses bereitgestellt haben, erneut einzugeben – ohne Ausnahme – oder sie riskiert Nichtkonformität.

Die Verfügung legt einen gestaffelten Implementierungszeitplan fest: öffentliche Institutionen müssen innerhalb von einem Jahr nach Veröffentlichung der Verfügung Konformität erreichen, während private Unternehmen in den erfassten Kategorien zwei Jahre Zeit haben, um die Anforderungen zu erfüllen.

Die von der Verfügung erfassten Einrichtungstypen sind umfangreich und umfassen E‑Commerce‑Plattformen und Marktplätze, alle öffentlichen Institutionen und Regierungsbehörden, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitsportale (öffentlich und privat), Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, lizenzierte Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind. Für all diese Einrichtungen müssen mehrstufige digitale Prozesse – Checkout‑Abläufe auf E‑Commerce‑Websites, Patientenregistrierung auf Krankenhausportalen, Kontoeröffnung auf Bankplattformen, Anmeldeformulare auf Schulwebsites – geprüft und korrigiert werden, um jede Form redundanter Eingaben zu beseitigen.

In der Praxis rückt diese Regelung die Einhaltung von WCAG 3.3.7 klar in den Verantwortungsbereich von Beschaffungs‑, Produkt‑ und Rechtsteams in der digitalen Wirtschaft der Türkei. Beispielsweise verstößt eine türkische E‑Commerce‑Plattform, die einen mehrstufigen Checkout betreibt, bei dem auf einem Bildschirm nach einer Lieferadresse und auf dem nächsten nach einer Rechnungsadresse gefragt wird, ohne eine Vorausfüll‑ oder Kopieroption anzubieten, direkt gegen WCAG 2.2 Stufe A und die Präsidialverfügung. Ebenso ist ein Terminbuchungsportal eines staatlichen Krankenhauses, das Patienten auffordert, ihre Ausweisnummer oder ihr Geburtsdatum auf mehreren Bildschirmen erneut einzugeben, nicht konform. Organisationen, die der Verfügung unterliegen, sollten eine End‑to‑End‑Prüfung aller mehrstufigen Prozesse als Teil ihres Konformitätsfahrplans priorisieren und die Beseitigung redundanter Eingaben als erforderliche Entwicklungsaufgabe behandeln, nicht als optionale Verbesserung.