WCAG 3.3.4: Fehlervermeidung (Rechtliches, Finanzielles, Daten)

WCAG 3.3.4 verlangt, dass Web-Eingaben, die rechtliche Verpflichtungen, finanzielle Transaktionen oder sensible Daten betreffen, vor der Finalisierung überprüft, korrigiert oder rückgängig gemacht werden können. Dies schützt alle Nutzer – insbesondere Menschen mit kognitiven und motorischen Beeinträchtigungen – vor irreversiblen Fehlern mit hohen Konsequenzen.

Was diese Regel bedeutet

Das WCAG-Erfolgskriterium 3.3.4 mit dem Titel Fehlervermeidung (Rechtlich, Finanziell, Daten) ist eine Anforderung der Stufe AA unter Prinzip 3 (Verständlich) und Richtlinie 3.3 (Eingabeunterstützung). Es gilt speziell für Webseiten, auf denen Nutzer rechtliche Verpflichtungen oder finanzielle Transaktionen auslösen können oder bei denen der Nutzer nutzerkontrollierte Daten in einem Datenspeichersystem ändert oder löscht.

Das Kriterium schreibt vor, dass für jede solche Übermittlung mindestens eine der folgenden drei Schutzmaßnahmen bereitgestellt wird:

Umkehrbar: Die Übermittlung kann rückgängig gemacht werden, nachdem sie gesendet wurde. Beispielsweise kann eine Bestellung innerhalb eines definierten Zeitfensters storniert oder ein gelöschter Datensatz wiederhergestellt werden.
Geprüft: Die vom Nutzer eingegebenen Daten werden auf Eingabefehler überprüft, und der Nutzer erhält die Möglichkeit, diese Fehler zu korrigieren, bevor die Übermittlung abgeschlossen wird.
Bestätigt: Es wird ein Mechanismus bereitgestellt, um Informationen vor der endgültigen Übermittlung zu überprüfen, zu bestätigen und zu korrigieren. Dies erfolgt typischerweise in Form eines Zusammenfassungs- oder Prüfschritts, bevor eine Senden-Schaltfläche die Transaktion abschließt.

Es ist wichtig zu beachten, dass nur eine dieser drei Bedingungen erfüllt sein muss, um zu bestehen. Allein ein Schritt zum Überprüfen und Bestätigen ist ausreichend, ebenso wie ein Stornierungsfenster nach der Übermittlung oder eine robuste Echtzeitvalidierung mit Korrekturmöglichkeit. Best Practice ist jedoch, mehrere Schutzmaßnahmen zu kombinieren.

Geltungsbereich des Kriteriums: Die Regel gilt für drei Kategorien von Transaktionen. Erstens umfasst sie rechtliche Verpflichtungen wie das Abschließen eines Abonnements, das Zustimmen zu einem Vertrag oder das Einreichen eines rechtsverbindlichen Formulars. Zweitens umfasst sie finanzielle Transaktionen einschließlich Käufen, Überweisungen, Kreditanträgen und Rechnungszahlungen. Drittens umfasst sie jede Aktion, die nutzerkontrollierte Daten in einem Datenspeichersystem ändert oder löscht – zum Beispiel das Aktualisieren von Profilinformationen, das Löschen von Dateien aus einem Cloud-Dienst oder das Bearbeiten von Datensätzen in einem Administrationsbereich.

Ein Bestehen sieht so aus: ein E‑Commerce-Checkout, der als letzten Schritt eine Bestellübersicht mit einem „Bearbeiten“-Link und einer „Bestellung aufgeben“-Schaltfläche anzeigt. Ein Nichtbestehen sieht so aus: ein einseitiges Bestellformular, bei dem ein Klick auf „Jetzt kaufen“ die Karte sofort belastet – ohne Übersichtsseite, ohne Stornierungsoption und ohne Validierungsschritt.

Das Kriterium hat eine definierte Ausnahme: Es gilt nicht für Formulare, bei denen das Absenden falscher Informationen keine Konsequenzen hat und die Übermittlung trivial wiederholt werden kann. Einfache Kontaktformulare oder Newsletter-Anmeldungen fallen im Allgemeinen nicht in den Geltungsbereich, obwohl gute Praxis dennoch zur Validierung dieser Formulare rät.

Warum es wichtig ist

Fehler bei Transaktionen mit hohen Einsätzen können schwerwiegende, manchmal irreversible Folgen haben: Geld, das auf das falsche Konto überwiesen wird, ein unter falschen Voraussetzungen unterzeichneter Rechtsvertrag, mit falschen Informationen aktualisierte medizinische Unterlagen oder ein Abonnement, das in der falschen Stufe gekauft wird. Für Nutzer ohne Behinderungen ist es oft unkompliziert, diese Fehler zu erkennen und zu korrigieren. Für viele Gruppen von Menschen mit Behinderungen kann dies ohne die in diesem Kriterium geforderten Schutzmaßnahmen äußerst schwierig oder sogar unmöglich sein.

Nutzer mit kognitiven Beeinträchtigungen – einschließlich Menschen mit Dyslexie, ADHS, Gedächtnisbeeinträchtigungen oder intellektuellen Beeinträchtigungen – machen mit höherer Wahrscheinlichkeit Eingabefehler und bemerken sie mit geringerer Wahrscheinlichkeit, bevor sie auf „Senden“ klicken. Eine Übersichtsseite gibt ihnen die Zeit und Klarheit, die sie benötigen, um Fehler zu erkennen. Laut der Weltgesundheitsorganisation leben weltweit etwa 1 Milliarde Menschen mit einer Form von kognitiver, neurologischer oder psychischer Beeinträchtigung, die das tägliche Funktionieren beeinflusst.

Nutzer mit motorischen Beeinträchtigungen, die auf Schaltersteuerung, Blickverfolgungsgeräte oder alternative Tastaturen angewiesen sind, sind anfällig für versehentliche Aktivierungen und unbeabsichtigte Tasteneingaben. Ein Bestätigungsschritt fungiert als kritischer Puffer: Selbst wenn „Senden“ versehentlich aktiviert wird, hat der Nutzer eine weitere Möglichkeit, abzubrechen, bevor die Transaktion abgeschlossen wird. Ohne diese Schutzmaßnahme könnte ein einziger versehentlicher Tipp eine finanzielle Transaktion auslösen, die der Nutzer nicht rückgängig machen kann.

Screenreader-Nutzer, die lange Formulare linear durchlaufen, haben möglicherweise keinen ganzheitlichen Überblick darüber, was sie eingegeben haben. Eine gesprochene Zusammenfassung in der Bestätigungsphase – die die eingegebenen Werte vorliest – ermöglicht es ihnen, Fehler zu erkennen, nach denen sie nicht visuell scannen konnten.

Nutzer mit Angststörungen oder Aufmerksamkeitsproblemen profitieren enorm davon zu wissen, dass es ein Sicherheitsnetz gibt. Forschungsergebnisse zeigen konsistent, dass Nutzer, wenn sie einen Prozess als fehlertolerant wahrnehmen, mit mehr Vertrauen interagieren und Transaktionen seltener abbrechen. Dies wirkt sich direkt positiv auf Konversionsraten und Nutzerzufriedenheit aus und macht die Einhaltung von 3.3.4 zu einem geschäftlichen Vorteil ebenso wie zu einer ethischen Verpflichtung.

Praxisbeispiel: Eine sehbehinderte Nutzerin in Istanbul bucht mit einem Screenreader einen Inlandsflug. Sie wählt ein Datum aus, navigiert aber versehentlich am Feld für die Passagieranzahl vorbei, sodass es auf dem Standardwert von zwei Passagieren statt einem bleibt. Wenn die Buchungsseite ihre Karte in dem Moment belastet, in dem sie „Bestätigen“ aktiviert, hat sie zwei Tickets gekauft und muss möglicherweise nicht erstattungsfähige Tarifstrafen hinnehmen. Eine Übersichtsseite, die laut vorliest „1 Passagier: Ayşe Yılmaz, Ankara nach Istanbul, 14. März, Economy – Gesamt: ₺850“, würde ihr ermöglichen, den Fehler sofort zu erkennen.

Wie man testet

Bestandsaufnahme von Formularen mit hohen Einsätzen: Erstellen Sie vor Beginn der Tests eine Liste aller Formulare oder interaktiven Workflows auf der Website, die finanzielle Transaktionen (Checkout, Zahlung, Rechnungsstellung), rechtliche Verpflichtungen (Vertragsunterzeichnung, Abonnementanmeldung, Einwilligungsformulare) oder Datenänderung/-löschung (Profilbearbeitung, Dateilöschung, Kontolöschung) umfassen. Nur diese Abläufe fallen in den Geltungsbereich von 3.3.4.
Automatisierten Scan auf verwandte Probleme ausführen: Verwenden Sie axe DevTools oder Lighthouse, um auf jeder in den Geltungsbereich fallenden Seite Zugänglichkeitsfehler auf Formularebene zu identifizieren. Auch wenn diese Tools 3.3.4 nicht direkt kennzeichnen, schafft die Behebung von Problemen wie fehlenden Beschriftungen, fehlenden Autocomplete-Attributen und fehlenden Fehlerankündigungen eine Basisqualität der Formulare, bevor die Schutzmaßnahme zur Fehlervermeidung bewertet wird.
Die Schutzmaßnahme „Geprüft“ testen: Senden Sie jedes Formular im Geltungsbereich absichtlich mit Fehlern – vertauschte Ziffern in einer Kartennummer, ein ungültiges Datum, ein nicht übereinstimmendes E‑Mail-Bestätigungsfeld. Beobachten Sie, ob das System die Übermittlung stoppt, den spezifischen Fehler identifiziert, beschreibt, wie er behoben werden kann (gemäß 3.3.3), und den Nutzer im Formular hält, um Korrekturen vorzunehmen. Wenn das Formular stillschweigend übermittelt oder nur eine generische Fehlermeldung anzeigt, ohne anzugeben, welches Feld fehlerhaft ist, ist diese Schutzmaßnahme nicht erfüllt.
Die Schutzmaßnahme „Bestätigt“ testen: Füllen Sie jedes Formular im Geltungsbereich mit gültigen Daten aus und durchlaufen Sie den vollständigen Ablauf. Prüfen Sie, ob vor der endgültigen Übermittlung ein Prüfschritt angezeigt wird. Vergewissern Sie sich, dass der Prüfschritt alle eingegebenen Daten in einem lesbaren Format anzeigt, einen Mechanismus zum Zurückgehen und Bearbeiten enthält und eine bewusste abschließende Aktion erfordert, um die Übermittlung abzuschließen. Navigieren Sie mit NVDA und Firefox sowie JAWS und Chrome diesen Prüfschritt mit einem Screenreader, um zu bestätigen, dass alle Werte angesagt werden und dass die Bearbeiten- und Bestätigen-Steuerelemente per Tastatur erreichbar sind.
Die Schutzmaßnahme „Umkehrbar“ testen: Schließen Sie eine Übermittlung ab und versuchen Sie dann, sie rückgängig zu machen. Suchen Sie im E‑Commerce-Bereich nach einem Stornierungslink in der Bestätigungs-E‑Mail oder auf der Bestellhistorienseite. Suchen Sie bei Datenlöschung nach einer Wiederherstellungs- oder Papierkorb-Funktion. Bewerten Sie, ob das Zeitfenster für die Rückgängigmachung dem Nutzer vor der Übermittlung klar kommuniziert wird, nicht erst danach.
Screenreader-Durchlauf (VoiceOver + Safari auf macOS/iOS): Navigieren Sie den gesamten Checkout- oder Übermittlungsablauf ausschließlich mit Tastatur und VoiceOver. Bestätigen Sie, dass die Übersichtsseite alle eingegebenen Werte in einer logischen Reihenfolge vorliest, dass Bearbeiten-Links mit ausreichendem Kontext angekündigt werden (z. B. „Lieferadresse bearbeiten“ statt nur „Bearbeiten“) und dass der Zweck der abschließenden Bestätigungsschaltfläche eindeutig ist.
Prüfung der kognitiven Belastung: Bewerten Sie, ob der Prüfschritt in klarer, verständlicher Sprache präsentiert wird. Eine Zusammenfassung, die rohe Datenbankfeldnamen auflistet oder juristische Fachsprache ohne Erklärung verwendet, mag technisch als Übersichtsseite gelten, scheitert in der Praxis aber für Nutzer mit kognitiven Beeinträchtigungen.

Wie man es behebt

Ein-Schritt-Checkout ohne Überprüfung – Falsch

<!-- Problematisch: Ein Klick auf "Complete Purchase" belastet die Karte sofort -->
<form action='/checkout/complete' method='post'>
  <input type='hidden' name='cart_id' value='abc123'>
  <input type='hidden' name='payment_token' value='tok_xyz'>
  <button type='submit'>Complete Purchase</button>
</form>

Ein-Schritt-Checkout mit hinzugefügtem Prüfschritt – Richtig

<!-- Schritt 1: Formular sammelt Daten und sendet an Übersichtsseite (nicht final) -->
<form action='/checkout/review' method='post'>
  <!-- Zahlungs- und Lieferfelder -->
  <button type='submit'>Review Order</button>
</form>

<!-- Schritt 2: Übersichtsseite fasst alle eingegebenen Daten zusammen und bietet Bearbeiten-Links -->
<section aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Order</h2>
  <dl>
    <dt>Delivery address</dt>
    <dd>Atatürk Cad. No:5, Kadıköy, Istanbul</dd>
    <dd><a href='/checkout/edit-address'>Edit delivery address</a></dd>
    <dt>Total</dt>
    <dd>₺1,249.00</dd>
  </dl>
  <form action='/checkout/complete' method='post'>
    <input type='hidden' name='order_token' value='tok_abc'>
    <!-- Die finale Schaltfläche ist eindeutig als verbindliche Aktion gekennzeichnet -->
    <button type='submit'>Place Order and Pay ₺1,249.00</button>
  </form>
</section>

Irreversible Datenlöschung ohne Bestätigung – Falsch

<!-- Problematisch: Löschen-Schaltfläche sendet direkt ohne Bestätigungsdialog -->
<form action='/account/delete-profile' method='post'>
  <button type='submit'>Delete My Account</button>
</form>

Irreversible Datenlöschung mit Bestätigungsdialog – Richtig

<!-- Auslöseschaltfläche öffnet einen Bestätigungsdialog, nicht die destruktive Aktion -->
<button type='button' aria-haspopup='dialog' aria-controls='confirm-delete-dialog'>
  Delete My Account
</button>

<dialog id='confirm-delete-dialog' aria-labelledby='dialog-title' aria-describedby='dialog-desc'>
  <h2 id='dialog-title'>Permanently Delete Account?</h2>
  <p id='dialog-desc'>
    This will permanently remove all your data. This action cannot be undone.
    Your subscription will be cancelled immediately.
  </p>
  <form action='/account/delete-profile' method='post'>
    <button type='submit'>Yes, permanently delete my account</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Finanzformular ohne Inline-Validierung – Falsch

<!-- Problematisch: keine Validierung, falsche IBAN wird stillschweigend akzeptiert -->
<form action='/transfer/submit' method='post'>
  <label for='iban'>Recipient IBAN</label>
  <input type='text' id='iban' name='iban'>
  <label for='amount'>Amount (TRY)</label>
  <input type='number' id='amount' name='amount'>
  <button type='submit'>Transfer</button>
</form>

Finanzformular mit Validierung und Überprüfung – Richtig

<!-- Inline-Validierung mit aria-describedby zur Fehlerzuordnung -->
<form action='/transfer/review' method='post' novalidate>
  <div>
    <label for='iban'>Recipient IBAN</label>
    <input
      type='text'
      id='iban'
      name='iban'
      aria-describedby='iban-hint iban-error'
      aria-required='true'
      autocomplete='off'
      pattern='[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}'
    >
    <p id='iban-hint'>Enter a valid TR IBAN starting with TR followed by 24 digits.</p>
    <p id='iban-error' role='alert' aria-live='assertive' hidden>
      Invalid IBAN format. Please check the number and try again.
    </p>
  </div>
  <!-- Sendet an Übersichtsseite, nicht direkte Ausführung -->
  <button type='submit'>Review Transfer</button>
</form>

Häufige Fehler

Verwendung eines Tooltips als „Überprüfungs“-Mechanismus: Die Anzeige eingegebener Werte in einem Tooltip beim Hover vor der Senden-Schaltfläche stellt keinen Prüfschritt dar, da Tooltips für reine Tastaturnutzer oder Screenreader-Nutzer nicht zugänglich sind und verschwinden, bevor der Nutzer handeln kann.
Die finale Schaltfläche mit „Weiter“ statt mit einer Aktionsbeschreibung beschriften: Eine Schaltfläche mit der Aufschrift „Weiter“ auf einer Übersichtsseite macht nicht deutlich, dass ein Klick darauf eine finanzielle Transaktion abschließt. Die Schaltfläche muss die verbindliche Aktion unmissverständlich beschreiben, etwa „Bestellung aufgeben und ₺850 bezahlen“ oder „Vertrag unterzeichnen“.
Bereitstellung einer Stornierungsrichtlinie nur in den Nutzungsbedingungen: Die Verankerung des Rückgängig-Mechanismus in einem verlinkten juristischen Dokument, das die meisten Nutzer nicht lesen, erfüllt die Anforderung der Umkehrbarkeit nicht. Die Möglichkeit zur Stornierung und das Zeitfenster, in dem sie verfügbar ist, müssen im Transaktionsablauf selbst kommuniziert werden.
Verwendung von window.confirm() als einzigem Bestätigungsmechanismus: Browser-eigene Bestätigungsdialoge werden von einigen Hilfstechnologien schlecht unterstützt, können nicht für bessere Lesbarkeit gestaltet werden und werden in bestimmten Browserkonfigurationen blockiert. Sie sollten nicht als einzige Schutzmaßnahme für Übermittlungen mit hohen Einsätzen verwendet werden.
Zurücksetzen des Formulars bei Validierungsfehlern ohne Beibehaltung gültiger Feldwerte: Wenn ein Formular bei der Validierung scheitert und alle Felder geleert werden, zwingt dies Nutzer – insbesondere solche mit motorischen Beeinträchtigungen – dazu, alle Daten erneut einzugeben. Nur das ungültige Feld sollte geleert oder hervorgehoben werden; alle gültigen Eingaben müssen erhalten bleiben.
Platzierung des „Bearbeiten“-Links auf der Übersichtsseite ohne programmatische Zuordnung: Ein „Bearbeiten“-Link neben jeder Datengruppe muss einen beschreibenden zugänglichen Namen haben (z. B. aria-label='Edit billing address'). Ein nacktes „Bearbeiten“, das mehrfach wiederholt wird, ist für Screenreader-Nutzer, die per Linknavigation arbeiten, mehrdeutig.
Die Übersichtsseite nicht für Screenreader ankündigen: Wenn die Übersichtsseite geladen wird, ohne den Fokus auf die Überschrift oder einen Zusammenfassungsbereich zu verschieben, bemerken Screenreader-Nutzer möglicherweise gar nicht, dass sie sich auf einer Übersichtsseite befinden, und aktivieren die Senden-Schaltfläche, ohne die Zusammenfassung zu lesen.
Das Kriterium nur auf Zahlungsseiten anwenden: Der Geltungsbereich umfasst jede rechtliche Verpflichtung (Abonnementanmeldung, Einwilligungsformulare, Vertragsannahme) und jede Änderung von Nutzerdaten (Löschen von Dateien, Aktualisieren medizinischer Unterlagen, Ändern von Kontoeinstellungen). Entwickler übersehen häufig Administrationsbereiche und Einstellungsseiten.
Rückgängigmachen nur per Telefon oder E‑Mail anbieten: Wenn eine Stornierung das Anrufen einer Support-Hotline erfordert, können Nutzer mit Sprach- oder Hörbeeinträchtigungen möglicherweise nicht auf den Rückgängig-Mechanismus zugreifen. Der Weg zur Rückgängigmachung muss selbst barrierefrei sein – vorzugsweise ein In-App-Stornierungsablauf.
Das Kriterium für mobile Web-Views auslassen: Einige Teams implementieren einen Prüfschritt auf dem Desktop, verwenden aber auf Mobilgeräten einen komprimierten Ein-Schritt-Ablauf, um Platz zu sparen. Das Kriterium gilt gleichermaßen für alle Viewport-Größen und darf in responsiven oder mobilen Web-Implementierungen nicht weggelassen werden.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, etabliert einen umfassenden nationalen Barrierefreiheitsrahmen, der sich auf WCAG 2.2 als technischen Standard bezieht. Die Verfügung schreibt vor, dass digitale Dienste mindestens die Konformität mit WCAG 2.2 Stufe AA erreichen müssen, was WCAG 3.3.4 Fehlervermeidung (Rechtlich, Finanziell, Daten) einschließt.

Die von der Verfügung ausdrücklich erfassten Stellen umfassen ein breites Spektrum von Sektoren. Öffentliche Institutionen und Behörden sind verpflichtet, alle bürgerorientierten digitalen Dienste barrierefrei zu gestalten, einschließlich Online-Anträgen, E‑Government-Portalen und digitalen Identitätsdiensten – die häufig rechtliche Verpflichtungen und Datenänderungen beinhalten. Banken und Finanzinstitute, die von der BDDK (Banking Regulation and Supervision Agency) reguliert werden, müssen die Vorgaben einhalten, wodurch 3.3.4 direkt für jede von ihnen angebotene Online-Banking-Transaktion, Überweisung und jeden Kreditantrag relevant ist. Krankenhäuser und Gesundheitseinrichtungen, die digitale Patientenportale, Terminbuchungssysteme und elektronische Gesundheitsakten betreiben, müssen sicherstellen, dass jede Dateneingabe oder -änderung in diesen Systemen den Standards zur Fehlervermeidung entspricht. Telekommunikationsanbieter mit 200.000 oder mehr Abonnenten – darunter Turkcell, Vodafone TR und Türk Telekom – müssen sicherstellen, dass Abonnementverwaltung, Tarifwechsel und Zahlungsabläufe abgedeckt sind. E‑Commerce-Plattformen, Reisebüros, private Transportunternehmen und private Schulen, die vom Bildungsministerium (MoNE) autorisiert sind, fallen ebenfalls in den Geltungsbereich und decken einen erheblichen Anteil der transaktionsstarken Webdienste auf dem türkischen Markt ab.

Die Einhaltung von 3.3.4 ist in diesem Rahmen nicht nur ein technisches Kontrollkästchen. Organisationen, die das vom Ministerium für Familie und Soziales vergebene Erişilebilirlik Logosu (Barrierefreiheitslogo) erhalten möchten, müssen die vollständige Konformität mit WCAG 2.2 AA nachweisen. Das Logo dient als öffentliches Vertrauenssignal und wird zunehmend von Verbrauchern und Beschaffungsstellen erwartet. Die Nichtimplementierung von Schutzmaßnahmen zur Fehlervermeidung in finanziellen oder rechtlichen Workflows kann sowohl zur Verweigerung des Logos als auch zu möglichen Verwaltungsmaßnahmen im Rahmen der Durchsetzungsbestimmungen der Verfügung führen.

Für türkische Organisationen insbesondere im E‑Commerce- und Fintech-Sektor steht 3.3.4 in engem Einklang mit bestehenden verbraucherschutzrechtlichen Anforderungen nach türkischem Recht. Das Verbraucherschutzgesetz (Nr. 6502) und die dazugehörigen E‑Commerce-Vorschriften verlangen bereits klare vorvertragliche Informationen und Widerrufsrechte für Fernabsatzverträge. Die Implementierung eines WCAG-3.3.4-konformen Schritts zum Überprüfen und Bestätigen erfüllt gleichzeitig sowohl die Barrierefreiheitsanforderung als auch die verbraucherrechtliche Verpflichtung, Bestellübersichten zu präsentieren, bevor ein Käufer verbindlich gebunden wird. Diese doppelte Konformität macht Investitionen in eine ordnungsgemäße UX zur Fehlervermeidung zu einer wertvollen, wenig redundanten Maßnahme für türkische digitale Dienstanbieter.