WCAG 3.3.4: Fehlervermeidung (rechtlich, finanziell, Daten)

WCAG 3.3.4 verlangt bei Vorgängen mit rechtlichen oder finanziellen Folgen und bei Änderungen an nutzerkontrollierten Daten mindestens eine von drei Sicherungen: Der Vorgang ist widerrufbar, die Eingaben werden geprüft und lassen sich korrigieren, oder alle Angaben werden vor dem verbindlichen Klick zum Prüfen und Bestätigen angezeigt. Eine Bestätigungs-Checkbox über dem Absenden-Knopf genügt dem deutschen Prüfschritt ausdrücklich nicht.

(Englisch: Error Prevention (Legal, Financial, Data). Im BIK-BITV-Test heißt der Prüfschritt „3.3.4 Fehlervermeidung wird unterstützt“.)

Das Wichtigste in Kürze

• Drei Sicherungen, eine genügt: widerrufbar, geprüft mit Korrekturmöglichkeit, oder prüfbar und zu bestätigen vor dem Abschluss.
• Die Checkbox reicht nicht. Der Prüfschritt bewertet sie als schwache Umsetzung, weil sie routinemäßig gesetzt und selten wahrgenommen wird.
• Betroffen sind drei Fallgruppen: rechtlich bindende Vorgänge, finanzielle Transaktionen und Änderungen oder Löschungen an gespeicherten Nutzerdaten.
• Ändern-Links ohne Datenverlust sind der Kern der Umsetzung – wer zurückgeht, darf die anderen Eingaben nicht verlieren.
• Erfolgreiche Eingaben gehören bestätigt. Fehlt die Rückmeldung nach dem Absenden, ist der Prüfschritt nicht voll erfüllt.
• Geleerte Formulare beim erneuten Aufruf bewertet der Prüfschritt als nicht erfüllt – das trifft überraschend viele Antragsstrecken.
• Die deutsche Bestellübersicht vor dem „Zahlungspflichtig bestellen“ erfüllt das Kriterium bereits – sie muss nur für alle nutzbar sein.
• Stufe AA, seit WCAG 2.0 unverändert und über die EN 301 549 verbindlich.

Was gilt bei Bestellungen und Verträgen?

3.3.4 setzt dort an, wo ein Eingabefehler nicht nur ärgerlich, sondern teuer ist. Der Normtext benennt drei Fallgruppen: Vorgänge mit rechtlichen Folgen (Vertragsabschluss, Anmeldung, Antrag), Vorgänge mit finanziellen Folgen (Bestellung, Überweisung, Buchung) und Änderungen oder Löschungen an Daten, die Nutzende selbst kontrollieren (Profil, gespeicherte Dokumente, Konto).

Für diese Vorgänge muss mindestens eine von drei Sicherungen greifen:

1. Reversibel. Der Vorgang lässt sich rückgängig machen – stornieren, widerrufen, aus dem Papierkorb zurückholen. Die Rücknahme muss auffindbar sein, nicht in einem Hilfetext versteckt.
2. Geprüft. Die Eingaben werden auf Fehler kontrolliert, und es gibt Gelegenheit zur Korrektur, bevor der Vorgang abschließt.
3. Bestätigt. Eine Übersicht zeigt alle Angaben zum Prüfen, bevor der verbindliche Klick fällt.

Die deutsche Prüfpraxis fügt zwei Punkte hinzu, die im Normtext so nicht stehen und im Audit den Unterschied machen:

Die Bestätigungs-Checkbox ist keine ausreichende Sicherung. Der Prüfschritt warnt ausdrücklich vor dieser schwachen Umsetzung: Eine Checkbox über dem Absenden-Knopf wird von vielen Menschen nicht richtig wahrgenommen und routinemäßig gesetzt. Wer sie als einzige Maßnahme einsetzt, erfüllt das Kriterium nicht voll.

Die Rückmeldung nach dem Absenden gehört dazu. Erfolgreiche Eingaben sollten bestätigt werden. Fehlt diese Bestätigung, bewertet der Prüfschritt das als nicht voll erfüllt – der Vorgang endet dann im Ungewissen, und niemand weiß, ob er wiederholt werden muss.

Ein dritter Punkt ist für Formularstrecken entscheidend: Werden ausgefüllte Formulare beim erneuten Aufruf geleert, gilt der Prüfschritt als nicht erfüllt. Das trifft viele mehrstufige Anträge, bei denen ein Zurück im Browser die halbe Arbeit vernichtet – und verbindet 3.3.4 direkt mit 3.3.7 Redundante Eingabe.

Im deutschen E-Commerce ist die dritte Sicherung ohnehin gelebte Praxis: Die Bestellübersicht vor dem Knopf „Zahlungspflichtig bestellen“ ist hierzulande gesetzlicher Standard. 3.3.4 verlangt nichts Zusätzliches – es verlangt, dass diese Übersicht für alle nutzbar ist. Mehr dazu unter Barrierefreiheit in Onlineshops. Das ist keine Rechtsberatung; für die vertragsrechtliche Seite gilt der jeweilige Gesetzestext.

Der Normtext steht im Understanding-Dokument des W3C zu 3.3.4, das deutsche Prüfvorgehen im Prüfschritt „3.3.4 Fehlervermeidung wird unterstützt“.

Wen betrifft es besonders?

Der Prüfschritt begründet das Kriterium mit einem Satz, der es genau trifft: Fehler passieren allen, aber für manche Menschen ist das Risiko höher. Menschen mit Legasthenie verwechseln Ziffern häufiger – bei einer IBAN oder einer Kontonummer entscheidet das über den Empfänger. Menschen mit motorischen Einschränkungen drücken leichter die falsche Taste oder klicken daneben, gerade bei kleinen Bedienelementen.

Blinde Nutzende haben den beiläufigen Kontrollblick nicht, mit dem Sehende ein Formular vor dem Absenden überfliegen. Sie müssen jedes Feld einzeln abfragen – oder sie bekommen eine Übersichtsseite, die alles auf einmal liefert. Genau deshalb ist die dritte Sicherung für diese Gruppe die wertvollste.

Menschen mit Gedächtnis- und Konzentrationsschwierigkeiten verlieren bei langen Strecken den Überblick darüber, was sie in Schritt zwei eingetragen haben. Für sie ist die Zusammenfassung am Ende oft die einzige Möglichkeit, die eigene Eingabe zu überprüfen.

Und dann alle anderen: um 23 Uhr, mit dem Telefon in der einen und dem Kind auf dem anderen Arm. Der Curb-Cut-Effekt ist hier besonders leicht messbar – Bestellübersichten senken Retouren und Support-Anfragen für alle.

Richtig & falsch im Code

Die dritte Sicherung, sauber gebaut, sieht so aus – und ihr Kern sind die Ändern-Links:

<!-- Falsch: nur eine Checkbox als Sicherung -->
<label>
  <input type="checkbox" name="bestaetigt" required />
  Ich habe meine Angaben geprüft.
</label>
<button type="submit">Zahlungspflichtig bestellen</button>

<!-- Richtig: vollständige Übersicht mit Korrekturwegen -->
<h1>Bestellung prüfen</h1>

<h2>Lieferadresse</h2>
<p>Anna Beispiel, Musterweg 1, 50667 Köln</p>
<p><a href="/checkout/adresse.html">Lieferadresse ändern</a></p>

<h2>Zahlungsart</h2>
<p>Rechnung, fällig 14 Tage nach Erhalt</p>
<p><a href="/checkout/zahlung.html">Zahlungsart ändern</a></p>

<h2>Ihre Artikel</h2>
<table>
  <caption>Bestellte Artikel und Preise</caption>
  <thead>
    <tr><th scope="col">Artikel</th><th scope="col">Menge</th><th scope="col">Preis</th></tr>
  </thead>
  <tbody>
    <tr><td>Ergonomische Tastatur</td><td>1</td><td>89,00 €</td></tr>
  </tbody>
</table>
<p><a href="/warenkorb.html">Artikel ändern</a></p>

<p><strong>Gesamt: 94,90 € inkl. Versand</strong></p>
<button type="submit">Zahlungspflichtig bestellen</button>

Drei Dinge an diesem Muster sind prüfrelevant. Der Ankertext benennt jeweils, was sich ändert – „Lieferadresse ändern“ statt „Ändern“; alles andere verstößt gegen 2.4.4 Linkzweck im Kontext. Die Artikelliste ist eine echte Tabelle mit Spaltenköpfen, damit sie sich zellenweise erschließen lässt. Und die Ändern-Links führen zurück in den jeweiligen Schritt, ohne die übrigen Eingaben zu verwerfen.

Für Löschvorgänge ist der Papierkorb die bessere Sicherung als jeder Dialog:

<!-- Vertretbar: Bestätigungsdialog vor der Löschung -->
<dialog id="loeschen-bestaetigen">
  <h2>Konto wirklich löschen?</h2>
  <p>Alle 47 gespeicherten Vorgänge werden entfernt.
     Dieser Schritt lässt sich nicht rückgängig machen.</p>
  <button type="button" value="abbrechen">Abbrechen</button>
  <button type="submit" value="loeschen">Konto endgültig löschen</button>
</dialog>

<!-- Besser: reversibel statt bestätigt -->
<p>Ihr Konto wurde deaktiviert und wird in 30 Tagen gelöscht.
   <a href="/konto/wiederherstellen.html">Löschung abbrechen</a></p>

Die reversible Variante ist der zuverlässigere Weg: Ein Bestätigungsdialog wird weggeklickt, eine Dreißig-Tage-Frist nicht. Die Muster für den Dialog selbst und für mehrstufige Formulare stehen in den Komponentenseiten.

Und die Bestätigung nach dem Absenden gehört als Statusmeldung ausgezeichnet, damit sie auch ohne Blick auf den Bildschirm ankommt:

<!-- Richtig: Erfolg wird angesagt, nicht nur angezeigt -->
<div role="status">
  <h2>Bestellung eingegangen</h2>
  <p>Bestellnummer 2026-8842. Eine Bestätigung ist unterwegs
     an anna@example.org.</p>
</div>

So testest du es

1. Kritische Vorgänge auflisten: alles mit Geld, Vertrag, Anmeldung, Antrag, Terminbuchung, Datenänderung oder Löschung.
2. Jeden Vorgang mit Beispieldaten durchspielen – vollständig bis zum Abschluss. Der Prüfschritt sieht genau das vor; aus der Codeansicht allein lässt sich das nicht bewerten.
3. Nach einer der drei Sicherungen suchen. Widerruf? Prüfung mit Korrektur? Übersicht vor dem Abschluss? Eine genügt, aber eine muss da sein.
4. Die Checkbox-Frage stellen: Ist die einzige Sicherung ein Häkchen „Ich habe geprüft“? Dann ist der Prüfschritt allenfalls teilweise erfüllt.
5. Die Ändern-Links testen. Zurück in Schritt eins gehen, etwas ändern, wieder vorgehen: Sind die übrigen Angaben noch da?
6. Zurück im Browser drücken und das Formular erneut aufrufen. Ist alles geleert, ist das ein Befund.
7. Die Sicherung selbst auf Barrierefreiheit prüfen: Ist die Übersicht per Screenreader verständlich? Sind die Links per Tastatur erreichbar?
8. Nach dem Absenden auf die Bestätigung achten – und darauf, ob sie angesagt wird oder nur sichtbar ist.

Häufiger Fehler in der Praxis

Der häufigste Fehler ist die Checkbox als Feigenblatt. Über dem Absenden-Knopf steht „Ich habe meine Angaben geprüft“, und damit gilt die Sache als erledigt. Der deutsche Prüfschritt widerspricht ausdrücklich: Solche Häkchen werden routinemäßig gesetzt und häufig gar nicht wahrgenommen. Sie sind zusätzlich in Ordnung, als einzige Sicherung nicht.

Der zweite ist der Ändern-Link, der alles verwirft. Die Bestellübersicht ist da, die Links sind da – und wer auf „Adresse ändern“ klickt, landet in einem leeren Formular und darf von vorn anfangen. Für Menschen, die für das Ausfüllen ohnehin länger brauchen, ist das der Punkt, an dem der Vorgang abgebrochen wird. Ich hab mir angewöhnt, in Audits genau diesen Weg als Erstes zu gehen; er findet mehr Probleme als jede Codeansicht.

Der dritte ist die Löschung ohne Rückweg. Ein Klick, ein knapper Dialog, weg sind die Daten. Bei einem Nutzerkonto ist das nicht nur ein Kriterienverstoß, sondern ein Support-Fall mit Ansage. Die Papierkorb-Lösung mit Frist kostet wenig und erfüllt die erste Sicherung dauerhaft.

Der vierte fällt in Selbstchecks nie auf: die fehlende Bestätigung am Ende. Das Formular wird abgeschickt, die Seite lädt neu, und irgendwo oben steht klein „Danke“ – ohne Fokusverschiebung, ohne Ansage. Wer mit einem Screenreader arbeitet, hört davon nichts und schickt das Formular vorsichtshalber noch einmal ab. Ein role="status" an der Meldung löst das in einer Zeile.

Häufige Fragen

Reicht eine Bestätigungs-Checkbox vor dem Absenden?

Nein. Der BIK-BITV-Test bewertet die Checkbox als schwache Umsetzung, weil sie von vielen Menschen nicht wahrgenommen und routinemäßig gesetzt wird. Verlangt ist eine der drei echten Sicherungen: Widerrufbarkeit, Prüfung mit Korrekturmöglichkeit oder eine vollständige Übersicht vor dem verbindlichen Klick.

Welche Vorgänge fallen unter 3.3.4?

Alles mit rechtlichen oder finanziellen Folgen und alle Änderungen an Daten, die Nutzende selbst kontrollieren: Bestellungen, Verträge, Überweisungen, Buchungen, Anträge, Anmeldungen, das Löschen des Kontos oder gespeicherter Dokumente. Ein Newsletter-Formular fällt nicht darunter, eine Kündigung sehr wohl.

Genügt die deutsche Bestellübersicht im Shop?

Ja, sie erfüllt die dritte Sicherung – vorausgesetzt, sie ist für alle nutzbar. Das heißt: strukturierte Überschriften, echte Tabellen, benannte Ändern-Links, Tastaturbedienbarkeit und erhaltene Eingaben beim Zurückgehen. Der gesetzliche Standard und das WCAG-Kriterium decken sich hier weitgehend.

Muss jede Aktion widerrufbar sein?

Nein. Es genügt eine der drei Sicherungen. Wenn eine Bestellung vor dem Abschluss vollständig geprüft werden kann, muss sie nicht zusätzlich stornierbar sein. Bei Löschvorgängen ist die reversible Variante trotzdem meist die praktikablere – Bestätigungsdialoge werden weggeklickt.

Was ist der Unterschied zu 3.3.1 und 3.3.3?

3.3.1 Fehlererkennung verlangt, dass Fehler benannt werden, wenn sie auftreten. 3.3.3 Fehlervorschlag verlangt konkrete Korrekturhinweise. 3.3.4 geht einen Schritt weiter und verlangt, dass folgenreiche Vorgänge gar nicht erst falsch abgeschlossen werden können.

Verwandte Themen

• Barrierefreiheit in Onlineshops – der Checkout im Ganzen
• Mehrstufige Formulare & Wizards – das Umsetzungsmuster für Strecken
• 3.3.7 Redundante Eingabe – Eingaben dürfen beim Zurückgehen nicht verschwinden
• 3.3.3 Fehlervorschlag – Korrekturhilfe eine Stufe früher
• Dialoge & Modals – Bestätigungen, die auch ankommen
• 4.1.3 Statusmeldungen – die Erfolgsmeldung nach dem Absenden