Barrierefreie Formulare ohne doppelte Eingaben (WCAG 3.3.7)

Du gibst Deine Lieferadresse ein und klickst auf „Weiter“. Im nächsten Schritt fragt der Shop nach der Rechnungsadresse. Sie ist identisch mit der Lieferadresse, doch Du musst sie erneut eintippen. Fehlt die Postleitzahl, löscht das Formular auch die Straße, die Du schon eingetragen hast.

Das WCAG-Kriterium 3.3.7 „Redundante Eingabe“ (Stufe A) gilt für Angaben, die jemand im selben Vorgang schon eingegeben oder erhalten hat. Wenn das Formular dieselbe Angabe erneut braucht, muss die Website sie vorbelegen oder zur Auswahl anbieten, sofern keine der drei Ausnahmen greift. Eine Möglichkeit ist das Kontrollkästchen „Lieferadresse als Rechnungsadresse verwenden“. Erhalte diese Auswahl und die eingegebenen Werte auch dann, wenn jemand einen Schritt zurückgeht oder einen Fehler korrigiert.

Wann fragt ein Formular dieselben Daten erneut ab?

Geh den gesamten Vorgang durch. Achte auf Angaben, die jemand bereits eingegeben oder von der Website erhalten hat. Im Checkout kann das die Lieferadresse sein, die bei der Rechnung noch einmal abgefragt wird. In einem Antrag kann es ein Aktenzeichen sein, das die Website anzeigt und im nächsten Schritt als Eingabe verlangt. Eine erneute Eingabe kann auch nötig werden, wenn das Formular nach einem Fehler gültige Angaben löscht.

Das Kriterium gilt innerhalb desselben Vorgangs. Auch eine Zahlungsseite auf einer anderen Domain kann zum selben Checkout gehören. Eine Speicherung über Sitzungen hinweg verlangt das Kriterium nicht. Erneute Eingabe ist zulässig, wenn sie unerlässlich oder für die Sicherheit der Inhalte erforderlich ist oder wenn die frühere Angabe nicht mehr gültig ist. Das W3C erläutert den Geltungsbereich und die Ausnahmen.

Die Lieferadresse für die Rechnung übernehmen

Biete ein beschriftetes Kontrollkästchen an, wenn die Lieferadresse häufig auch die Rechnungsadresse ist. Zeig im Prüfschritt, welche Adresse verwendet wird und wie man sie ändern kann. Wenn jemand den Haken entfernt, blende die separaten Rechnungsfelder direkt nach dem Kontrollkästchen ein. Lass den Fokus auf dem Kästchen, damit die Person mit Tab zu den Feldern kommt. Hat sie bereits eine andere Rechnungsadresse eingetragen, stell diese wieder her.

Gibt es einen naheliegenden Wert, kannst Du ein bearbeitbares Feld vorbelegen. Gibt es mehrere Adressen, eignet sich eine Auswahlliste. Die Optionen sollten unterscheidbar sein. Zeig, welche Adresse ausgewählt ist. Das W3C zeigt verschiedene Wege, frühere Angaben bereitzustellen.

Die Ausfüllhilfe des Browsers kann bei der ersten Eingabe helfen. Ein Wert wie autocomplete="shipping postal-code" beschreibt den Zweck des Felds. Für die Wiederverwendung im Checkout muss die Website die dort bereits eingegebene Adresse bereitstellen oder auf die erneute Abfrage verzichten. Welche Rolle autocomplete bei WCAG 1.3.5 spielt, erklärt der Leitfaden zu Beschriftungen und Eingabezweck.

Gültige Eingaben bei „Zurück“ und nach Fehlern behalten

Speichere die Werte und die Auswahl zur Rechnungsadresse für den laufenden Checkout. Solange die Übernahme aktiv ist, gilt die aktuelle Lieferadresse auch für die Rechnung. Prüfe, was passiert, wenn jemand zurückgeht und die Lieferadresse ändert. Hat die Person eine separate Rechnungsadresse gewählt, sollte diese dabei erhalten bleiben.

Leite die Adresse für den Prüfschritt und das Absenden aus dieser Auswahl ab:

const billingAddress = useDeliveryAddress ? deliveryAddress : separateBillingAddress;

Bei der E-Mail-Adresse gilt dasselbe Prinzip. Zeig sie im Prüfschritt mit der Aktion „E-Mail-Adresse ändern“. Fehlt eine Postleitzahl, erhalte die Straße, damit die Person nur das fehlende Feld ergänzen muss. Das GOV.UK Design System zeigt einen Prüfschritt, in dem sich einzelne Angaben gezielt ändern lassen.

Probiere beide Versionen dieses fiktiven Checkouts mit drei Schritten aus. Starte mit „Beispieldaten eintragen“. Übernimm im Rechnungsschritt die Lieferadresse oder gib eine andere Straße ein und lass die Postleitzahl leer.

Vergleiche, was in den beiden Versionen passiert:

• Rechnungsadresse. Vorher fehlte die Möglichkeit zur Übernahme. Danach ließ sich das Kontrollkästchen mit der Leertaste bedienen und die Lieferadresse erschien im Prüfschritt. Nach „Zurück zur Lieferadresse“ und einer Adressänderung erschien dort die aktualisierte Adresse.
• Validierung. Vorher löschte eine fehlende Rechnungs-PLZ auch die Straße. Danach blieb die Straße erhalten und der Fehlerlink führte den Fokus zur Postleitzahl.
• E-Mail. Vorher verlangte der Prüfschritt die E-Mail-Adresse ein zweites Mal. Danach zeigte er die vorhandene Adresse mit einer Änderungsmöglichkeit. Der Abschluss war ohne erneute Eingabe möglich.

Bei einer manuellen Prüfung des deutschen Lehrbeispiels las VoiceOver nach einem leeren Absendeversuch im Rechnungsschritt die Fehlerübersicht „Prüfe die Rechnungsadresse“ und die Hinweise zu Straße, Hausnummer und Postleitzahl vor. Beim Navigieren waren die Schaltflächen erkennbar und der Fokus folgte dem Ablauf wie erwartet. Beim Lesen der Schrittliste sagte VoiceOver den aktuellen Schritt an.

Nach „Weiter“ einen sinnvollen Fokus setzen

Wenn „Weiter“ den nächsten Schritt auf derselben Seite einblendet, probiere die Überschrift des neuen Schritts als Fokusziel aus. Gib ihr tabindex="-1" und setze den Fokus nach dem Rendern per Code darauf. So lässt sich die Überschrift gezielt fokussieren, ohne einen zusätzlichen Tabstopp zu erzeugen. Prüfe, wohin Tab als Nächstes führt und ob die Überschrift sichtbar bleibt. WCAG 2.4.3 beschreibt die Anforderungen an die Fokusreihenfolge.

Bleibt die Person wegen eines Fehlers im selben Schritt, kann der Fokus auf eine Fehlerübersicht wechseln. Deren Links führen zu den betroffenen Feldern. Im Beitrag zu Fehlermeldungen in Formularen kannst Du dieses Verhalten ausprobieren.

Den aktuellen Schritt und den Fortschritt zeigen

Nenne den Fortschritt in der Überschrift, etwa „Rechnungsadresse (Schritt 2 von 3)“. Gib den Schritt bei einem mehrseitigen Formular auch im Seitentitel an. Wenn Du eine Liste der Schritte zeigst, nutze eine geordnete Liste und markiere den aktuellen Eintrag mit aria-current="step".

<ol aria-label="Schritte im Checkout">
  <li>Lieferadresse</li>
  <li aria-current="step">Rechnungsadresse</li>
  <li>Angaben prüfen</li>
</ol>

Das W3C erklärt den Fortschritt im Leitfaden zu mehrseitigen Formularen und definiert die Markierung des aktuellen Schritts in WAI-ARIA. Wenn jemand die Liste mit einem Screenreader liest, kann die Markierung den aktuellen Schritt kenntlich machen. Prüfe beim Schrittwechsel, welche Information die fokussierte Überschrift vermittelt. Bleibt der Fokus an Ort und Stelle und erscheint eine separate Fortschrittsmeldung, prüfe, ob sie als Statusmeldung ausgegeben wird. Das Vorgehen zeigt der Beitrag zu Toasts und Statusmeldungen.

Den Weg von der Lieferadresse bis zur Prüfung testen

1. Beginne einen neuen Checkout. Notiere, welche Angaben die Website verlangt und welche sie Dir bereitstellt.
2. Nutze einmal die Lieferadresse für die Rechnung und gib einmal eine andere Rechnungsadresse ein. Prüfe jeweils, welche Adresse im letzten Schritt erscheint.
3. Löse einen Validierungsfehler aus. Folge dem Fehlerlink mit der Tastatur, korrigiere das Feld und prüfe, welche anderen Eingaben erhalten bleiben.
4. Nutze „Zurück“ im Formular und, falls unterstützt, im Browser. Ändere die Lieferadresse und prüfe die Angaben erneut.
5. Wiederhole den Ablauf mit einem Screenreader. Notiere, wo der Fokus landet, was Du nach „Weiter“ hörst und wie der aktuelle Schritt beim Lesen der Liste ausgegeben wird.

Scanne den Einstieg und die Zustände nach „Weiter“, „Zurück“ und einem Fehler. Halte fest, welche Zustände der Scan tatsächlich erreicht hat. So lassen sich beispielsweise fehlende Beschriftungen in späteren Schritten finden. Für 3.3.7 gehst Du den Ablauf selbst durch und prüfst, welche Angaben erneut verlangt und wie sie bereitgestellt werden. Mehr dazu bei navable Audit und im Leitfaden zum Testen von Websites.