WCAG 3.3.6: Foutpreventie (Alle)

Wat Deze Regel Betekent

WCAG 3.3.6 — Foutpreventie (Alle) is een succescriterium op niveau AAA onder het principe Begrijpelijk. Het breidt de vereisten van 3.3.4 (Foutpreventie: Juridisch, Financieel, Gegevens) uit naar alle pagina’s die van een gebruiker vereisen dat hij informatie indient, ongeacht of die indiening juridische verplichtingen, financiële transacties of persoonlijk identificeerbare gegevens omvat.

In de kern vereist het criterium dat voor elke webpagina waarop een gebruiker informatie indient, ten minste aan één van de volgende drie voorwaarden wordt voldaan:

• Omkeerbaar: Inzendingen zijn achteraf omkeerbaar. De gebruiker kan een actie ongedaan maken, annuleren of intrekken binnen een redelijke termijn. Bijvoorbeeld: een verzonden bericht kan worden teruggehaald, of een ingediend formulier kan worden geannuleerd vanuit een bevestigingswachtrij.
• Gecontroleerd: Door de gebruiker ingevoerde gegevens worden vóór de definitieve indiening gecontroleerd op invoerfouten, en de gebruiker krijgt de gelegenheid om die fouten te corrigeren. Dit omvat inline validatie, overzichten vóór indiening of stapsgewijze beoordelingsflows.
• Bevestigd: Er wordt een mechanisme geboden om informatie te bekijken, te bevestigen en te corrigeren voordat de indiening wordt afgerond. Dit kan een beoordelingsscherm zijn, een bevestigingsdialoog of een meerstapswizard met een laatste beoordelingsstap.

Het belangrijkste onderscheid tussen 3.3.4 en 3.3.6 is de reikwijdte. Criterium 3.3.4 is alleen van toepassing op juridische overeenkomsten, financiële transacties, toetsantwoorden en het verwijderen van door de gebruiker beheerde gegevens. Criterium 3.3.6 breidt dit uit naar elke pagina die een vorm van indiening van gebruikersinvoer vereist—waaronder contactformulieren, nieuwsbriefinschrijvingen, reactierubrieken, enquête-antwoorden, profielupdates, zoekinstellingen en elke andere door de gebruiker beheerde gegevensinvoer.

Wat telt als een voldoende resultaat: Een formulier voldoet als het consequent ten minste één van de drie bovenstaande mechanismen implementeert. Een bevestigingspagina vóór de definitieve indiening, een overzichtsscherm met een optie "Bewerken", client-side of server-side validatie met mogelijkheden om fouten te corrigeren, of een duidelijk gecommuniceerd tijdsvenster om ongedaan te maken voldoen allemaal aan het criterium.

Wat telt als een onvoldoende resultaat: Een eenstapsformulier dat gegevens onmiddellijk indient bij een klik op de knop, zonder validatie, zonder beoordelingsscherm en zonder ongedaan-maakmechanisme, voldoet niet aan dit criterium. Evenzo voldoet een formulier dat wel valideert maar geen mogelijkheid biedt om fouten te corrigeren vóór herindiening ook niet.

De WCAG-specificatie vereist niet dat alle drie de mechanismen gelijktijdig aanwezig zijn—het voldoen aan één ervan is voldoende. Het combineren van twee of drie mechanismen biedt echter defense-in-depth en bedient een breder scala aan gebruikers en contexten.

Waarom Het Belangrijk Is

Foutpreventie is niet slechts een gebruiksvriendelijkheids-extra—het is een fundamentele toegankelijkheidseis voor gebruikers die een verhoogd risico op invoerfouten hebben door een beperking of situationele belemmeringen.

Cognitieve en leerstoornissen: Gebruikers met dyslexie, ADHD of geheugenstoornissen maken vaak typfouten, draaien cijfers om of raken de draad kwijt bij complexe formulieren met meerdere velden. Zonder beoordelingsmechanisme kan een verkeerd getypt e-mailadres in een contactformulier een gemiste reactie betekenen, of een onjuist ingevoerd adres in een bezorgformulier tot zoekgeraakte pakketten leiden. Dit zijn geen randgevallen—volgens de Wereldgezondheidsorganisatie leven wereldwijd ongeveer 1 miljard mensen met een vorm van cognitieve of neurologische aandoening die het dagelijks functioneren beïnvloedt.

Motorische beperkingen: Gebruikers met tremoren, beperkte fijne motoriek, of die afhankelijk zijn van switch-toegang of spraak-invoersoftware, activeren vaak per ongeluk formulierindieningen of voeren onbedoelde tekens in. Een gebruiker met de ziekte van Parkinson die met een switch-interface een complex formulier doorloopt, kan onbedoeld een onvolledig of onjuist formulier indienen. Zonder omkeerbaarheid of bevestigingsstappen worden deze fouten permanent.

Schermlezersgebruikers: Blinde gebruikers die navigeren met JAWS, NVDA of VoiceOver hebben niet hetzelfde visuele overzicht van een ingevuld formulier als ziende gebruikers vóór het indienen. Een bevestigingsscherm of samenvatting die door een schermlezer wordt voorgelezen, geeft deze gebruikers een laatste kans om hun gegevens te verifiëren voordat deze onomkeerbaar worden ingediend.

Lage digitale geletterdheid en oudere bevolkingsgroepen: Oudere volwassenen en gebruikers die nieuw zijn met digitale interfaces zijn bijzonder kwetsbaar voor onbedoelde indieningen. Een bevestigingsstap met samenvattingen in eenvoudige taal biedt een vangnet dat de ondersteuningskosten en gebruikersfrustratie drastisch vermindert.

Praktijkscenario: Stel een Turks e-overheidsportaal voor waar een burger een lang bureaucratisch formulier invult om een bedrijf te registreren. Als de burger per ongeluk een verplicht veld overslaat of zijn belastingidentificatienummer onjuist invoert en het formulier wordt onmiddellijk ingediend zonder beoordelingsstap, merkt hij de fout mogelijk pas op wanneer hij dagen later een formele afwijzingsbrief ontvangt. Een eenvoudig bevestigingsscherm met alle ingevoerde gegevens vóór de definitieve indiening had dit volledig kunnen voorkomen.

SEO- en gebruiksvriendelijkheidsvoordelen: Pagina’s die robuuste foutpreventie implementeren, hebben doorgaans lagere uitvalpercentages bij formulieren, hogere conversieratio’s en betere gebruikerswaarderingen. Zoekmachines nemen in toenemende mate gebruikservaringssignalen mee in hun rankings, en pagina’s met hoge bouncepercentages door formulierfouten lijden indirect onder een lagere organische zichtbaarheid.

Gerelateerde Axe-core Regels

WCAG 3.3.6 vereist handmatige tests omdat geen enkele geautomatiseerde tool kan bepalen of een bepaalde formulierindieningsflow voldoet aan de vereisten voor omkeerbaarheid, foutcontrole of bevestiging van dit criterium. Geautomatiseerde toegankelijkheidsscanners zoals axe-core kunnen de aanwezigheid van individuele ARIA-attributen, labels en foutmeldingen verifiëren, maar ze kunnen de algehele logica van de indieningsflow, het bestaan van een bevestigingsstap of de daadwerkelijke functionaliteit van een ongedaan-maakmechanisme niet beoordelen. Het criterium gaat in de kern over interactieontwerp en de gebruikerservaringflow—niet over statische markup.

• Er bestaat geen specifieke axe-core regel voor 3.3.6. Axe-core en vergelijkbare engines testen individuele DOM-elementen op specifieke attribuut- of rolvereisten. Bepalen of een meerstapsformulier een beoordelingsstap vóór de definitieve indiening bevat, vereist inzicht in de navigatieflow van de applicatie en het server-side gedrag—informatie waar statische analysetools geen toegang toe hebben. Een menselijke tester moet het volledige indieningstraject doorlopen om de naleving te beoordelen.
• Gerelateerde regels die de algehele kwaliteit van formulieren ondersteunen (hoewel niet specifiek 3.3.6): Regels zoals label (elke invoer heeft een gekoppeld label), aria-required-attr (vereiste ARIA-attributen zijn aanwezig) en form-field-multiple-labels (invoervelden hebben geen conflicterende labels) dragen bij aan de basis van toegankelijke formulieren. Zorgen dat deze slagen is een voorwaarde voor zinvolle foutpreventie, maar het slagen hiervoor garandeert geen naleving van 3.3.6.
• Waarom automatisering tekortschiet: Een geautomatiseerde scan van een afrekenpagina kan bevestigen dat alle invoervelden labels hebben en dat foutmeldingen programmatisch aan invoervelden zijn gekoppeld. Maar hij kan niet bepalen of klikken op "Verzenden" de gebruiker naar een beoordelingsscherm brengt, of er een optie "Annuleren" bestaat, of dat het systeem een bevestigingsmail stuurt met een annuleringslink. Dit zijn vragen over gedrag en proces die alleen door menselijke evaluatie kunnen worden beantwoord.

Hoe te Testen

1. Voer een geautomatiseerde scan uit als basislijn: Gebruik axe DevTools, Lighthouse of de ingebouwde auditmodus van de Accsible-widget om alle pagina’s met formulieren te scannen. Hoewel deze tools geen 3.3.6-overtredingen direct zullen markeren, leggen ze een basis door ontbrekende labels, afwezige foutmeldingen of onjuist gekoppelde validatiefeedback te identificeren. Los alle geautomatiseerde bevindingen op voordat u met handmatig testen verdergaat.
2. Identificeer alle indieningsformulieren op de site: Maak een volledige inventaris van elke pagina die gebruikersinvoer accepteert en indient—contactformulieren, registratieformulieren, inlogformulieren, formulieren voor zoekvoorkeuren, pagina’s voor profielupdates, reactierubrieken, nieuwsbriefinschrijvingen en eventuele meerstapswizards. Elk daarvan moet afzonderlijk worden getest.
3. Test het happy path met opzettelijke fouten: Voer in elk formulier opzettelijk onjuiste, onvolledige of onjuist gevormde gegevens in (bijv. een ongeldig e-mailadres, een telefoonnummer met letters, verplichte velden leeg laten). Dien het formulier in en observeer: Voorkomt de pagina de indiening en geeft zij foutmeldingen? Zijn foutmeldingen gekoppeld aan de juiste velden? Heeft de gebruiker een duidelijke mogelijkheid om te corrigeren en opnieuw in te dienen?
4. Test op bevestigings- of beoordelingsmechanismen: Vul voor formulieren die de validatie doorstaan het formulier met geldige gegevens in en dien het in. Observeer of er een bevestigingsscherm, samenvattingsdialoog of beoordelingsstap verschijnt voordat de gegevens onherroepelijk worden ingediend. Controleer of de beoordelingsstap de gebruiker in staat stelt terug te gaan en invoer te bewerken.
5. Test omkeerbaarheid na indiening: Controleer na een succesvolle indiening of er een mechanisme voor annulering, ongedaan maken of intrekking bestaat. Dit kan een link "Indiening annuleren" zijn in een bevestigingsmail, een scherm voor wachtrijbeheer in een beheerdersomgeving of een in-appmelding met een ongedaan-maakactie. Controleer of het mechanisme werkt en duidelijk aan gebruikers wordt gecommuniceerd.
6. Schermlezertests met NVDA + Firefox: Navigeer naar elk formulier met NVDA en Firefox. Tab door alle velden, voer gegevens in en dien het formulier in. Controleer of foutmeldingen worden aangekondigd wanneer ze verschijnen, of het beoordelingsscherm (indien aanwezig) volledig leesbaar is in documentvolgorde, en of alle interactieve bedieningselementen (bewerkknoppen, bevestigingsknoppen, annuleerknoppen) op het bevestigingsscherm via het toetsenbord toegankelijk en correct gelabeld zijn.
7. Schermlezertests met VoiceOver + Safari (macOS/iOS): Herhaal het bovenstaande proces met VoiceOver in Safari. Let in het bijzonder op dynamische inhoudsupdates—als validatiefouten dynamisch via JavaScript verschijnen zonder paginavernieuwing, controleer dan of ze via live-regio’s (aria-live) worden getoond zodat VoiceOver ze aankondigt zonder dat de gebruiker de pagina handmatig hoeft te verkennen.
8. Alleen-toetsenbordtesten: Navigeer zonder muis door de volledige formulierindieningsflow met alleen de toetsen Tab, Shift+Tab, Enter en Spatie. Controleer of elk interactief element—waaronder bewerk-, terug-, bevestig- en annuleerknoppen op beoordelingsschermen—bereikbaar en bedienbaar is zonder aanwijsapparaat.

Hoe te Herstellen

Contactformulier zonder validatie of beoordeling — Onjuist

<!-- 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>

Contactformulier met validatie en bevestigingsstap — Juist

<!-- 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>

Meerstapswizard zonder samenvattingsstap — Onjuist

<!-- 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>

Meerstapswizard met laatste beoordelingsstap — Juist

<!-- 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>

Formulier met onmiddellijke indiening en geen ongedaan maken — Onjuist

<!-- 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>

Destructieve actie met bevestigingsdialoog — Juist

<!-- 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>

Veelvoorkomende Fouten

• Validatie implementeren maar deze niet beschikbaar maken voor schermlezers: Foutmeldingen alleen visueel tonen via CSS-kleurwijzigingen of pictogrammen zonder ze te koppelen aan de invoer met aria-describedby of ze in een aria-live-regio te plaatsen, betekent dat blinde gebruikers de fout nooit horen—het formulier lijkt succesvol te zijn ingediend terwijl het in werkelijkheid onvolledig blijft.
• 3.3.4-naleving als voldoende beschouwen voor AAA: Teams implementeren vaak foutpreventie alleen voor financiële of juridische formulieren (voldoen aan 3.3.4) en gaan ervan uit dat alle formulieren daarmee gedekt zijn. Criterium 3.3.6 vereist dezelfde bescherming voor elk formulier op de site, inclusief nieuwsbriefinschrijvingen, reacties en profielupdates.
• Een bevestigingsscherm bieden dat alleen-lezen is zonder bewerkingsmogelijkheid: Een beoordelingspagina die ingediende gegevens toont maar alleen een knop "Bevestigen" biedt—zonder mogelijkheid om terug te keren en fouten te corrigeren—voldoet niet volledig aan de geest van het criterium en laat gebruikers zonder uitweg als ze tijdens de beoordeling een fout ontdekken.
• window.confirm() als enig bevestigingsmechanisme gebruiken: Browser-eigen bevestigingsdialogen zijn niet voor alle gebruikers toegankelijk en kunnen niet worden gestileerd of gestructureerd voor duidelijkheid. Ze gedragen zich ook inconsistent tussen ondersteunende technologieën. Gebruik in plaats daarvan een correct element <dialog> met passende ARIA-attributen.
• Het volledige formulier resetten bij validatiefouten in plaats van geldige invoer te behouden: Wanneer een gebruiker een formulier met 10 velden indient met één fout en het formulier alle velden wist, moet de gebruiker alle gegevens opnieuw invoeren. Dit is bijzonder belastend voor gebruikers met motorische beperkingen of cognitieve vermoeidheid. Bewaar altijd geldige gegevens en richt de aandacht alleen op de foutieve velden.
• Foutoverzichtsberichten buiten de viewport of toetsenbordfocusvolgorde plaatsen: Een foutoverzichtsbanner die na een mislukte indiening bovenaan de pagina wordt ingevoegd, helpt gebruikers niet die zich midden in het formulier bevinden. Gebruik aria-live='assertive' op de container van het overzicht en verplaats de focus programmatisch naar deze container bij een mislukte indiening.
• Bevestigingsknoppen markeren met vage labels zoals "OK" of "Yes": Op een beoordelingsscherm moeten knoppen duidelijk communiceren wat er zal gebeuren. "Confirm and Send Message" is ondubbelzinnig; "OK" is dat niet—vooral niet voor schermlezersgebruikers die mogelijk niet over de omringende visuele context beschikken.
• Aannemen dat alleen server-side validatie aan het criterium voldoet: Als client-side validatie ontbreekt, is voor elke indiening een volledige round-trip naar de server nodig voordat de gebruiker over een fout wordt geïnformeerd. Gebruikers met trage verbindingen of die hun netwerk verliezen tijdens de indiening kunnen in een onzekere toestand achterblijven zonder duidelijke foutfeedback.
• Het omkeerbaarheidsmechanisme niet onder realistische omstandigheden testen: Teams implementeren soms een optie "annuleren" in een bevestigingsmail, maar testen nooit of de annuleringslink toegankelijk is, of hij werkt nadat het tijdsvenster is verlopen, of dat de link bruikbaar is voor schermlezers. Een ontoegankelijk ongedaan-maakmechanisme voldoet niet aan het criterium.
• Edge-cases met automatisch invullen op beoordelingsschermen niet afhandelen: Wanneer de browser of een wachtwoordmanager formuliervelden automatisch invult, komen de waarden die op een beoordelingsscherm worden weergegeven mogelijk niet overeen met wat daadwerkelijk is ingediend als de JavaScript die de beoordeling vult, waarden uit de DOM haalt voordat automatisch invullen is voltooid. Haal waarden altijd op vlak vóór het renderen van het beoordelingsscherm, niet bij het eerste laden van de pagina.

Relatie met de Toegankelijkheidsregelgeving van Turkije

Het presidentieel circulaire 2025/10 van Turkije, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt verplichte digitale toegankelijkheidsverplichtingen vast voor een breed scala aan entiteiten die in Turkije actief zijn. De circulaire vereist dat betrokken organisaties zich als basislijn conformeren aan WCAG 2.2 op niveau AA. De entiteiten die expliciet worden genoemd, omvatten overheidsinstellingen en -agentschappen, e-commerceplatforms, banken en financiële instellingen, ziekenhuizen en zorgaanbieders, telecommunicatiebedrijven met 200,000 of meer abonnees, erkende reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (MoNE).

WCAG 3.3.6 is een criterium op niveau AAA en is daarom geen directe wettelijke vereiste onder circulaire 2025/10. De betekenis ervan in de Turkse regelgevingscontext mag echter niet worden onderschat. Verschillende van de betrokken entiteitstypen—met name banken, e-commerceplatforms en zorgaanbieders—werken met transactievormen met hoge inzet, waar foutpreventie niet slechts een best practice is, maar een juridische en ethische noodzaak. Een online geldoverschrijvingsformulier van een Turkse bank, een afsprakensysteem van een zorgportaal of een e-commerce-checkoutflow zonder bevestigingsstappen of foutcorrectiemechanismen schendt 3.3.6 mogelijk niet op een juridisch afdwingbare manier, maar creëert een aanzienlijk risico op schade voor gebruikers met een beperking en stelt de organisatie bloot aan reputatie- en operationeel risico.

Bovendien geeft de circulaire een duidelijke koers aan richting toenemende toegankelijkheidseisen in de loop van de tijd, in lijn met het kader van de European Accessibility Act (EAA) waarmee Turkije zich heeft afgestemd. Organisaties die vandaag al criteria op niveau AAA zoals 3.3.6 implementeren, zijn proactief gepositioneerd voor toekomstige aanscherping van regelgeving en tonen een inzet voor inclusief ontwerp die verder gaat dan minimale naleving. Voor entiteiten zoals particuliere ziekenhuizen en financiële instellingen die in onevenredig hoge mate oudere bevolkingsgroepen of gebruikers met cognitieve en motorische beperkingen bedienen, is het implementeren van 3.3.6 in alle formulieren een verstandige risicobeheersingsbeslissing, los van de juridische status ervan. De overlay-SDK van Accsible kan helpen bij het zichtbaar maken van foutmeldingen, het versterken van validatiestatussen en het bieden van aanvullende bevestigingsprompts als extra beschermingslaag voor Turkse organisaties die willen vooroplopen op het gebied van toegankelijkheid.