WCAG 3.3.6: Fehlervermeidung (Alle)

WCAG 3.3.6 verlangt, dass bei jeder Webseite, die eine Nutzereingabe erfordert, Eingaben entweder rückgängig gemacht werden können, auf Fehler überprüft werden und Korrekturhinweise enthalten oder vor der endgültigen Übermittlung bestätigt werden können. Dieses AAA-Kriterium erweitert 3.3.4 auf alle Formulare – nicht nur auf rechtliche oder finanzielle – und schützt Nutzer in jeder Interaktion vor irreversiblen Fehlern.

Was diese Regel bedeutet

WCAG 3.3.6 — Fehlervermeidung (alle) ist ein Erfolgskriterium der Stufe AAA unter dem Prinzip „Verständlich“. Es erweitert die Anforderungen von 3.3.4 (Fehlervermeidung: Rechtliches, Finanzielles, Daten) auf alle Seiten, auf denen ein Benutzer Informationen übermitteln muss, unabhängig davon, ob diese Übermittlung rechtliche Verpflichtungen, finanzielle Transaktionen oder personenbezogene Daten umfasst.

Im Kern verlangt das Kriterium, dass für jede Webseite, auf der ein Benutzer Informationen übermittelt, mindestens eine der folgenden drei Bedingungen erfüllt sein muss:

Reversibel: Übermittlungen sind nachträglich umkehrbar. Der Benutzer kann eine Aktion innerhalb eines angemessenen Zeitraums rückgängig machen, abbrechen oder widerrufen. Beispielsweise kann eine gesendete Nachricht zurückgerufen oder ein übermitteltes Formular aus einer Bestätigungswarteschlange heraus storniert werden.
Geprüft: Vom Benutzer eingegebene Daten werden vor der endgültigen Übermittlung auf Eingabefehler geprüft, und der Benutzer erhält die Möglichkeit, diese Fehler zu korrigieren. Dies umfasst Inline-Validierung, Zusammenfassungen vor der Übermittlung oder schrittweise Prüfabläufe.
Bestätigt: Es wird ein Mechanismus bereitgestellt, um Informationen vor der endgültigen Übermittlung zu überprüfen, zu bestätigen und zu korrigieren. Dies kann ein Überprüfungsbildschirm, ein Bestätigungsdialog oder ein mehrstufiger Assistent mit einem abschließenden Prüfschritt sein.

Der entscheidende Unterschied zwischen 3.3.4 und 3.3.6 ist der Umfang. Kriterium 3.3.4 gilt nur für rechtliche Vereinbarungen, finanzielle Transaktionen, Testantworten und das Löschen von benutzerkontrollierten Daten. Kriterium 3.3.6 erweitert dies auf jede Seite, die irgendeine Form der Übermittlung von Benutzereingaben erfordert – einschließlich Kontaktformularen, Newsletter-Anmeldungen, Kommentarbereichen, Umfrageantworten, Profilaktualisierungen, Sucheinstellungen und jeder anderen benutzerkontrollierten Dateneingabe.

Was als bestanden gilt: Ein Formular besteht, wenn es mindestens einen der drei oben genannten Mechanismen konsistent implementiert. Eine Bestätigungsseite vor der endgültigen Übermittlung, ein Übersichtsbildschirm mit einer „Bearbeiten“-Option, Client- oder Server-seitige Validierung mit Möglichkeiten zur Fehlerkorrektur oder ein klar kommuniziertes Zeitfenster zum Rückgängig machen erfüllen alle das Kriterium.

Was als nicht bestanden gilt: Ein einstufiges Formular, das Daten unmittelbar beim Klicken auf die Schaltfläche übermittelt, ohne Validierung, ohne Übersichtsbildschirm und ohne Rückgängig-Mechanismus, erfüllt dieses Kriterium nicht. Ebenso besteht ein Formular nicht, das zwar validiert, aber keine Möglichkeit bietet, Fehler vor einer erneuten Übermittlung zu korrigieren.

Die WCAG-Spezifikation verlangt nicht alle drei Mechanismen gleichzeitig – die Erfüllung eines beliebigen ist ausreichend. Die Kombination von zwei oder drei Mechanismen bietet jedoch eine mehrschichtige Absicherung und dient einem breiteren Spektrum von Benutzern und Kontexten.

Warum es wichtig ist

Fehlervermeidung ist nicht nur eine Frage der Benutzerfreundlichkeit – sie ist eine grundlegende Anforderung an die Barrierefreiheit für Benutzer, die aufgrund einer Behinderung oder situativer Beeinträchtigungen einem erhöhten Risiko für Eingabefehler ausgesetzt sind.

Kognitive Beeinträchtigungen und Lernbehinderungen: Benutzer mit Dyslexie, ADHS oder Gedächtnisbeeinträchtigungen machen häufig Tippfehler, vertauschen Ziffern oder verlieren bei komplexen Formularen mit vielen Feldern den Überblick. Ohne einen Überprüfungsmechanismus kann eine falsch eingegebene E-Mail-Adresse in einem Kontaktformular eine verpasste Antwort bedeuten, oder eine falsch eingegebene Adresse in einem Lieferformular kann zu verlorenen Paketen führen. Dies sind keine Randfälle – laut Weltgesundheitsorganisation leben weltweit etwa 1 Milliarde Menschen mit einer Form kognitiver oder neurologischer Beeinträchtigung, die das tägliche Funktionieren beeinflusst.

Motorische Beeinträchtigungen: Benutzer mit Tremor, eingeschränkter Feinmotorik oder solche, die auf Schaltersteuerung oder Spracherkennungssoftware angewiesen sind, lösen Formularübermittlungen häufig versehentlich aus oder geben unbeabsichtigte Zeichen ein. Ein Benutzer mit Parkinson, der ein komplexes Formular mit einer Schaltersteuerung ausfüllt, kann versehentlich ein unvollständiges oder falsches Formular absenden. Ohne Reversibilität oder Bestätigungsschritte werden diese Fehler dauerhaft.

Screenreader-Nutzer: Blinde Benutzer, die mit JAWS, NVDA oder VoiceOver navigieren, haben nicht denselben visuellen Überblick über ein ausgefülltes Formular, den sehende Benutzer vor dem Absenden haben. Ein Bestätigungsbildschirm oder eine Zusammenfassung, die von einem Screenreader vorgelesen wird, gibt diesen Benutzern eine letzte Chance, ihre Daten zu überprüfen, bevor sie unwiderruflich übermittelt werden.

Niedrige digitale Kompetenz und ältere Menschen: Ältere Erwachsene und Benutzer, die neu im Umgang mit digitalen Oberflächen sind, sind besonders anfällig für versehentliche Übermittlungen. Ein Bestätigungsschritt mit leicht verständlichen Zusammenfassungen bietet ein Sicherheitsnetz, das Supportkosten und Benutzerfrustration deutlich reduziert.

Praxisbeispiel: Stellen Sie sich ein türkisches E-Government-Portal vor, auf dem eine Bürgerin oder ein Bürger ein langes bürokratisches Formular ausfüllt, um ein Unternehmen zu registrieren. Wenn die Person versehentlich ein Pflichtfeld auslässt oder ihre Steueridentifikationsnummer falsch eingibt und das Formular sofort ohne Prüfschritt übermittelt wird, bemerkt sie den Fehler möglicherweise erst, wenn sie Tage später einen formellen Ablehnungsbescheid erhält. Ein einfacher Bestätigungsbildschirm, der vor der endgültigen Übermittlung alle eingegebenen Daten anzeigt, hätte dies vollständig verhindert.

SEO- und Usability-Vorteile: Seiten, die eine robuste Fehlervermeidung implementieren, weisen tendenziell geringere Abbruchraten bei Formularen, höhere Konversionsraten und bessere Werte bei der Benutzerzufriedenheit auf. Suchmaschinen berücksichtigen zunehmend Signale zur Nutzererfahrung in ihren Rankings, und Seiten mit hohen Absprungraten aufgrund von Formularfehlern leiden indirekt in ihrer organischen Sichtbarkeit.

Wie man testet

Automatisierten Scan als Grundlage durchführen: Verwenden Sie axe DevTools, Lighthouse oder den integrierten Audit-Modus des Accsible-Widgets, um alle Seiten mit Formularen zu scannen. Auch wenn diese Tools Verstöße gegen 3.3.6 nicht direkt kennzeichnen, schaffen sie eine Grundlage, indem sie fehlende Beschriftungen, fehlende Fehlermeldungen oder falsch zugeordnete Validierungsrückmeldungen identifizieren. Beheben Sie alle automatisiert gefundenen Probleme, bevor Sie mit manuellen Tests fortfahren.
Alle Übermittlungsformulare auf der Website identifizieren: Erstellen Sie ein vollständiges Verzeichnis jeder Seite, die Benutzereingaben entgegennimmt und übermittelt – Kontaktformulare, Registrierungsformulare, Login-Formulare, Formulare für Sucheinstellungen, Seiten zur Profilaktualisierung, Kommentarbereiche, Newsletter-Anmeldungen und alle mehrstufigen Assistenten. Jedes einzelne muss separat getestet werden.
Den Happy Path mit absichtlichen Fehlern testen: Geben Sie in jedem Formular absichtlich falsche, unvollständige oder fehlerhafte Daten ein (z. B. eine ungültige E-Mail-Adresse, eine Telefonnummer mit Buchstaben, leere Pflichtfelder). Senden Sie das Formular ab und beobachten Sie: Verhindert die Seite die Übermittlung und zeigt sie Fehlermeldungen an? Sind Fehlermeldungen den richtigen Feldern zugeordnet? Hat der Benutzer eine klare Möglichkeit, zu korrigieren und erneut zu übermitteln?
Auf Bestätigungs- oder Prüfschritte testen: Füllen Sie für Formulare, die die Validierung bestehen, das Formular mit gültigen Daten aus und senden Sie es ab. Beobachten Sie, ob ein Bestätigungsbildschirm, ein Zusammenfassungsdialog oder ein Prüfschritt erscheint, bevor die Daten unwiderruflich übermittelt werden. Vergewissern Sie sich, dass der Prüfschritt dem Benutzer erlaubt, zurückzugehen und Eingaben zu bearbeiten.
Reversibilität nach der Übermittlung testen: Prüfen Sie nach einer erfolgreichen Übermittlung, ob ein Mechanismus zum Abbrechen, Rückgängig machen oder Widerrufen existiert. Dies kann ein „Übermittlung abbrechen“-Link in einer Bestätigungs-E-Mail, ein Warteschlangenverwaltungsbildschirm in einem Admin-Bereich oder eine In-App-Benachrichtigung mit einer Rückgängig-Aktion sein. Vergewissern Sie sich, dass der Mechanismus funktioniert und den Benutzern klar kommuniziert wird.
Screenreader-Tests mit NVDA + Firefox: Navigieren Sie mit NVDA und Firefox zu jedem Formular. Durchlaufen Sie alle Felder mit der Tabulatortaste, geben Sie Daten ein und senden Sie das Formular ab. Vergewissern Sie sich, dass Fehlermeldungen beim Erscheinen angesagt werden, dass der Prüfbildschirm (falls vorhanden) in Dokumentreihenfolge vollständig lesbar ist und dass alle interaktiven Steuerelemente (Bearbeiten-, Bestätigen-, Abbrechen-Schaltflächen) auf dem Bestätigungsbildschirm per Tastatur zugänglich und korrekt beschriftet sind.
Screenreader-Tests mit VoiceOver + Safari (macOS/iOS): Wiederholen Sie den oben beschriebenen Prozess mit VoiceOver in Safari. Achten Sie besonders auf dynamische Inhaltsaktualisierungen – wenn Validierungsfehler dynamisch per JavaScript ohne Seitenneuladen erscheinen, stellen Sie sicher, dass sie über Live-Regionen (aria-live) ausgegeben werden, damit VoiceOver sie ankündigt, ohne dass der Benutzer die Seite manuell erkunden muss.
Nur-Tastatur-Tests: Navigieren Sie ohne Maus durch den gesamten Formularübermittlungsablauf, nur mit Tab, Shift+Tab, Enter und Leertaste. Vergewissern Sie sich, dass jedes interaktive Element – einschließlich Bearbeiten-, Zurück-, Bestätigen- und Abbrechen-Schaltflächen auf Prüfbildschirmen – ohne Zeigegerät erreichbar und bedienbar ist.

Wie man es behebt

Kontaktformular ohne Validierung oder Prüfschritt — falsch

<!-- Fails 3.3.6: submits immediately with no validation, no review, no undo -->
<form action='/submit-contact' method='post'>
  <label for='name'>Name</label>
  <input type='text' id='name' name='name'>

  <label for='email'>Email</label>
  <input type='text' id='email' name='email'>

  <label for='message'>Message</label>
  <textarea id='message' name='message'></textarea>

  <button type='submit'>Send</button>
</form>

Kontaktformular mit Validierung und Bestätigungsschritt — korrekt

<!-- Step 1: Form with client-side validation before submission -->
<form id='contact-form' novalidate>
  <div role='group' aria-labelledby='form-heading'>
    <h2 id='form-heading'>Contact Us</h2>

    <div class='field-group'>
      <label for='name'>Full Name <span aria-hidden='true'>*</span></label>
      <input
        type='text'
        id='name'
        name='name'
        required
        aria-required='true'
        aria-describedby='name-error'
        autocomplete='name'
      >
      <span id='name-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='email'>Email Address <span aria-hidden='true'>*</span></label>
      <input
        type='email'
        id='email'
        name='email'
        required
        aria-required='true'
        aria-describedby='email-error'
        autocomplete='email'
      >
      <span id='email-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='message'>Message <span aria-hidden='true'>*</span></label>
      <textarea
        id='message'
        name='message'
        required
        aria-required='true'
        aria-describedby='message-error'
      ></textarea>
      <span id='message-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <!-- Review button triggers a confirmation summary before final submission -->
    <button type='button' onclick='showReviewScreen()'>Review &amp; Send</button>
  </div>
</form>

<!-- Step 2: Confirmation/review screen (shown after validation passes) -->
<section id='review-screen' hidden aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Message</h2>
  <p>Please review your details before sending. You can go back to make changes.</p>

  <dl>
    <dt>Full Name</dt>
    <dd id='review-name'></dd>
    <dt>Email</dt>
    <dd id='review-email'></dd>
    <dt>Message</dt>
    <dd id='review-message'></dd>
  </dl>

  <!-- Edit option satisfies the 'reversible/correctable before final commit' requirement -->
  <button type='button' onclick='goBackToForm()'>Edit My Details</button>
  <button type='button' onclick='submitFinalForm()'>Confirm and Send</button>
</section>

Mehrstufiger Assistent ohne Zusammenfassungs-Schritt — falsch

<!-- Fails 3.3.6: final step submits directly without allowing user to review previous steps -->
<form action='/register' method='post'>
  <!-- Step 3 of 3 — no ability to review steps 1 and 2 -->
  <h2>Step 3: Payment</h2>
  <label for='card'>Card Number</label>
  <input type='text' id='card' name='card'>
  <button type='submit'>Complete Registration</button>
</form>

Mehrstufiger Assistent mit abschließendem Prüfschritt — korrekt

<!-- Step 4 of 4: Summary review before final submission -->
<section aria-labelledby='summary-heading'>
  <h2 id='summary-heading'>Step 4 of 4: Review Your Registration</h2>
  <p>Please confirm the information below before completing your registration. Use the edit links to correct any errors.</p>

  <h3>Personal Details
    <a href='/register/step-1' aria-label='Edit personal details'>Edit</a>
  </h3>
  <dl>
    <dt>Full Name</dt><dd>Ayşe Kaya</dd>
    <dt>Date of Birth</dt><dd>15/04/1988</dd>
  </dl>

  <h3>Contact Information
    <a href='/register/step-2' aria-label='Edit contact information'>Edit</a>
  </h3>
  <dl>
    <dt>Email</dt><dd>[email protected]</dd>
    <dt>Phone</dt><dd>+90 532 000 0000</dd>
  </dl>

  <h3>Payment
    <a href='/register/step-3' aria-label='Edit payment details'>Edit</a>
  </h3>
  <dl>
    <dt>Card ending</dt><dd>**** 4242</dd>
  </dl>

  <!-- Final submit only after user has reviewed all data -->
  <form action='/register/complete' method='post'>
    <button type='submit'>Confirm and Complete Registration</button>
  </form>
</section>

Formular mit sofortiger Übermittlung und ohne Rückgängig — falsch

<!-- Fails 3.3.6: deletes comment immediately with no undo or confirmation -->
<form action='/comments/42/delete' method='post'>
  <button type='submit'>Delete Comment</button>
</form>

Destruktive Aktion mit Bestätigungsdialog — korrekt

<!-- Passes 3.3.6: user must confirm before destructive action is executed -->
<button
  type='button'
  aria-haspopup='dialog'
  onclick='openConfirmDialog(42)'
>
  Delete Comment
</button>

<dialog
  id='confirm-delete-dialog'
  aria-labelledby='dialog-title'
  aria-describedby='dialog-desc'
>
  <h2 id='dialog-title'>Delete this comment?</h2>
  <p id='dialog-desc'>
    This action cannot be undone. The comment will be permanently removed.
  </p>
  <form action='/comments/42/delete' method='post'>
    <button type='submit'>Yes, Delete</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Häufige Fehler

Validierung implementieren, sie aber nicht für Screenreader verfügbar machen: Fehlermeldungen nur visuell über CSS-Farbänderungen oder Icons anzuzeigen, ohne sie mit der Eingabe über aria-describedby zu verknüpfen oder in eine aria-live-Region einzuspeisen, bedeutet, dass blinde Benutzer den Fehler nie hören – das Formular scheint erfolgreich übermittelt worden zu sein, obwohl es tatsächlich unvollständig bleibt.
3.3.4-Konformität als ausreichend für AAA betrachten: Teams implementieren häufig Fehlervermeidung nur für finanzielle oder rechtliche Formulare (Erfüllung von 3.3.4) und gehen davon aus, dass damit alle Formulare abgedeckt sind. Kriterium 3.3.6 verlangt denselben Schutz für jedes Formular auf der Website, einschließlich Newsletter-Anmeldungen, Kommentare und Profilaktualisierungen.
Einen Bestätigungsbildschirm bereitstellen, der schreibgeschützt ist und keinen Bearbeitungspfad bietet: Eine Übersichtsseite, die übermittelte Daten anzeigt, aber nur eine „Bestätigen“-Schaltfläche bietet – ohne Möglichkeit, zurückzukehren und Fehler zu korrigieren – erfüllt nicht vollständig den Sinn des Kriteriums und lässt Benutzer ohne Handlungsoption, wenn sie während der Überprüfung einen Fehler entdecken.
window.confirm() als einzigen Bestätigungsmechanismus verwenden: Browser-eigene Bestätigungsdialoge sind nicht für alle Benutzer zugänglich und können nicht für Klarheit gestaltet oder strukturiert werden. Sie verhalten sich zudem inkonsistent über verschiedene unterstützende Technologien hinweg. Verwenden Sie stattdessen ein richtiges <dialog>-Element mit geeigneten ARIA-Attributen.
Das gesamte Formular bei Validierungsfehlern zurücksetzen, statt gültige Eingaben zu erhalten: Wenn ein Benutzer ein Formular mit 10 Feldern mit einem Fehler übermittelt und das Formular alle Felder leert, muss der Benutzer alle Daten erneut eingeben. Dies ist besonders belastend für Benutzer mit motorischen Beeinträchtigungen oder kognitiver Ermüdung. Erhalten Sie immer gültige Daten und richten Sie die Aufmerksamkeit nur auf die fehlerhaften Felder.
Fehlerzusammenfassungen außerhalb des Viewports oder der Tastaturfokus-Reihenfolge platzieren: Ein Fehlerzusammenfassungsbanner, das nach einer fehlgeschlagenen Übermittlung oben auf der Seite eingefügt wird, nützt Benutzern nichts, die sich mitten im Formular befinden. Verwenden Sie aria-live='assertive' für den Zusammenfassungscontainer und verschieben Sie den Fokus bei einer fehlgeschlagenen Übermittlung programmatisch dorthin.
Bestätigungsschaltflächen mit vagen Beschriftungen wie „OK“ oder „Ja“ versehen: Auf einem Prüfbildschirm müssen Schaltflächen klar kommunizieren, was passieren wird. „Confirm and Send Message“ ist eindeutig; „OK“ ist es nicht – insbesondere für Screenreader-Nutzer, die den umgebenden visuellen Kontext möglicherweise nicht haben.
Annehmen, dass serverseitige Validierung allein das Kriterium erfüllt: Wenn Client-seitige Validierung fehlt, erfordert jede Übermittlung eine vollständige Server-Rundreise, bevor der Benutzer von einem Fehler erfährt. Benutzer mit langsamen Verbindungen oder Verbindungsverlust während der Übermittlung können in einem unklaren Zustand ohne eindeutige Fehlerrückmeldung zurückbleiben.
Den Reversibilitätsmechanismus nicht unter realistischen Bedingungen testen: Teams implementieren manchmal eine „Abbrechen“-Option in einer Bestätigungs-E-Mail, testen aber nie, ob der Abbruchlink zugänglich ist, ob er nach Ablauf des Zeitfensters funktioniert oder ob der Link für Screenreader nutzbar ist. Ein unzugänglicher Rückgängig-Mechanismus erfüllt das Kriterium nicht.
Auto-Fill-Randfälle auf Prüfbildschirmen nicht berücksichtigen: Wenn Browser oder Passwortmanager Formularfelder automatisch ausfüllen, stimmen die auf einem Prüfbildschirm angezeigten Werte möglicherweise nicht mit den tatsächlich übermittelten überein, wenn das JavaScript für die Zusammenfassung die Werte aus dem DOM zieht, bevor Auto-Fill abgeschlossen ist. Lesen Sie Werte immer unmittelbar vor dem Rendern des Prüfbildschirms aus, nicht beim initialen Laden der Seite.

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, legt verbindliche digitale Barrierefreiheitsverpflichtungen für eine breite Palette von in der Türkei tätigen Einrichtungen fest. Die Verfügung verlangt von den betroffenen Organisationen, dass sie sich mindestens an WCAG 2.2 auf Stufe AA halten. Zu den ausdrücklich erfassten Einrichtungen gehören öffentliche Institutionen und Behörden, E-Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, lizenzierte Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) zugelassen sind.

WCAG 3.3.6 ist ein Kriterium der Stufe AAA und daher keine direkte gesetzliche Anforderung nach der Verfügung 2025/10. Dennoch sollte seine Bedeutung im türkischen Regulierungskontext nicht unterschätzt werden. Mehrere der erfassten Einrichtungstypen – insbesondere Banken, E-Commerce-Plattformen und Gesundheitsdienstleister – betreiben hochkritische transaktionale Formulare, bei denen Fehlervermeidung nicht nur eine Best Practice, sondern eine rechtliche und ethische Notwendigkeit ist. Ein Online-Geldüberweisungsformular einer türkischen Bank, ein Terminbuchungssystem eines Gesundheitsportals oder ein E-Commerce-Checkout-Prozess ohne Bestätigungsschritte oder Fehlerkorrekturmechanismen verstößt möglicherweise nicht in rechtlich durchsetzbarer Weise gegen 3.3.6, schafft aber ein erhebliches Schadensrisiko für Benutzer mit Behinderungen und setzt die Organisation Reputations- und Betriebsrisiken aus.

Darüber hinaus signalisiert die Verfügung eine klare Entwicklung hin zu steigenden Barrierefreiheitsanforderungen im Laufe der Zeit, im Einklang mit dem Rahmen des European Accessibility Act (EAA), an den sich die Türkei anlehnt. Organisationen, die heute AAA-Kriterien wie 3.3.6 umsetzen, sind proaktiv auf zukünftige regulatorische Verschärfungen vorbereitet und demonstrieren ein Engagement für inklusives Design, das über die Mindestanforderungen hinausgeht. Für Einrichtungen wie private Krankenhäuser und Finanzinstitute, die überproportional viele ältere Menschen oder Benutzer mit kognitiven und motorischen Beeinträchtigungen betreuen, ist die Umsetzung von 3.3.6 in allen Formularen eine sinnvolle risikopolitische Entscheidung, unabhängig von seinem rechtlichen Status. Das Overlay-SDK von Accsible kann dabei helfen, Fehlermeldungen sichtbar zu machen, Validierungszustände zu verstärken und zusätzliche Bestätigungsaufforderungen bereitzustellen – als zusätzliche Schutzschicht für türkische Organisationen, die bei der Barrierefreiheit eine Vorreiterrolle einnehmen wollen.