WCAG 3.3.3: Foutvoorstel

Wat Deze Regel Betekent

WCAG 3.3.3 Error Suggestion is een criterium op niveau AA onder het principe Begrijpelijk (Understandable). Het bouwt direct voort op 3.3.1 (Error Identification), dat vereist dat fouten in tekst worden geïdentificeerd. Error Suggestion gaat een stap verder: wanneer een invoerfout automatisch wordt gedetecteerd, moet de interface ook voorstellen hoe de gebruiker deze kan corrigeren, mits die suggestie de veiligheid of het doel van de content niet in gevaar brengt.

Het belangrijkste onderscheid hier is tussen foutidentificatie en foutsuggestie. Een gebruiker vertellen: "Your date of birth is invalid" is identificatie. Een gebruiker vertellen: "Your date of birth is invalid — please enter a date in DD/MM/YYYY format" is een suggestie. Beide zijn vereist onder hun respectieve criteria, maar Error Suggestion vereist dat uitvoerbare, corrigerende begeleiding de foutmelding vergezelt waar dat haalbaar is.

Het criterium is van toepassing wanneer een invoerfout automatisch wordt gedetecteerd — dat wil zeggen, wanneer client-side of server-side validatielogica bepaalt dat een ingediende of ingevoerde waarde niet aan de verwachte criteria voldoet. Het is van toepassing op alle formulierelementen: tekstvelden, selecties, selectievakjes, keuzerondjes, datumkiezers, velden voor het uploaden van bestanden en elk interactief component dat gebruikersgegevens verzamelt.

Wat telt als een voldoende implementatie: De foutmelding wordt in tekst gepresenteerd (niet alleen via kleur of pictogram), identificeert duidelijk het veld met de fout en geeft specifieke aanwijzingen over hoe deze te corrigeren. Bijvoorbeeld: "Password must be at least 8 characters and include one uppercase letter" in plaats van alleen "Invalid password." De suggestie moet in de nabijheid van het veld verschijnen, er programmatisch mee geassocieerd zijn (via aria-describedby of iets dergelijks) en waarneembaar zijn voor ondersteunende technologieën.

Wat telt als een onvoldoende implementatie: Elke foutmelding die alleen aangeeft dat er een fout is opgetreden zonder uit te leggen wat er mis is of hoe dit kan worden opgelost. Algemene meldingen zoals "Error," "Invalid input," of "Required field" zonder verdere context voldoen niet aan dit criterium. Fouten die alleen via een rode rand of waarschuwingspictogram worden gecommuniceerd, zonder beschrijvende tekst, voldoen evenmin.

Gedefinieerde uitzonderingen: Het criterium bevat twee expliciete uitzonderingen waarbij een suggestie niet vereist is. Ten eerste, als het geven van de suggestie de veiligheid in gevaar zou brengen — bijvoorbeeld op een inlogformulier waar het precies uitleggen waarom een wachtwoord is afgekeurd (verkeerd wachtwoord vs. verkeerde gebruikersnaam) brute-force-aanvallen zou kunnen helpen. Ten tweede, als het geven van de suggestie het doel van de content in gevaar zou brengen — bijvoorbeeld bij een educatieve quiz waar het onthullen van het juiste antwoord het beoordelingsdoel ondermijnt. Deze uitzonderingen zijn beperkt en mogen niet worden gebruikt om de eis in standaard formuliercontexten te omzeilen.

Waarom Het Belangrijk Is

Error Suggestion bestaat omdat het invullen van formulieren een van de meest cognitief veeleisende activiteiten is die gebruikers op het web uitvoeren, en ook een van de meest ingrijpende — fouten in checkoutformulieren, aanvragen voor overheidsuitkeringen, medische intakeformulieren of bankportalen kunnen reële gevolgen hebben voor gebruikers die niet kunnen begrijpen wat er misging of hoe ze kunnen herstellen.

Cognitieve beperkingen: Gebruikers met dyslexie, ADHD, leerstoornissen of beperkte geletterdheid kunnen moeite hebben om vage foutmeldingen te ontcijferen en deze te koppelen aan het specifieke veld of het vereiste formaat. Zonder een duidelijke corrigerende suggestie kunnen zij het formulier volledig verlaten of onjuiste informatie indienen. Volgens de Wereldgezondheidsorganisatie leeft ongeveer 1 op de 6 mensen wereldwijd — meer dan 1,3 miljard — met een vorm van beperking, en cognitieve beperkingen behoren tot de meest voorkomende maar minst geaccommodeerde categorieën.

Blinde en slechtziende gebruikers: Screenreader-gebruikers zijn volledig afhankelijk van tekstbeschrijvingen om validatiefouten te begrijpen. Wanneer een foutmelding alleen "Invalid" zegt en geen suggestie geeft, heeft de gebruiker geen mechanisme om te bepalen wat "invalid" voor dat veld betekent. Zij kunnen niet even naar aangrenzende labels, placeholdertekst of visuele opmaak kijken om het verwachte formaat af te leiden. Een duidelijke suggestie, programmatisch geassocieerd met de invoer via aria-describedby, is het enige betrouwbare informatiekanaal.

Motorisch beperkte gebruikers: Gebruikers die afhankelijk zijn van switch access, spraakbesturing of alternatieve invoerapparaten leveren aanzienlijke fysieke inspanning bij het invullen van formulieren. Opnieuw naar een formulier moeten navigeren na een mislukte verzending — zonder te begrijpen wat er moet worden aangepast — legt een onevenredige belasting op. Duidelijke suggesties verminderen de herinvoerinspanning en het aantal mislukte verzendcycli.

Niet-moedertaalsprekers en oudere gebruikers: Gebruikers die de taal van het formulier niet vloeiend beheersen, of die minder ervaring hebben met webconventies, profiteren ook aanzienlijk van expliciete corrigerende suggesties. Een bericht als "Enter your phone number without spaces or dashes, e.g. 05321234567" neemt de ambiguïteit weg voor gebruikers die het formulier anders misschien nooit succesvol zouden afronden.

Praktijkscenario: Stel een Turkse burger die via een e-governmentportaal een aanvraag voor sociale bijstand indient. De aanvraag vereist een TR Identity Number (TC Kimlik Numarası), een specifiek formaat van 11 cijfers. Als de gebruiker 10 cijfers invoert en alleen het bericht "TC Kimlik Numarası hatalı" (TC Identity Number is incorrect) ontvangt, weet een gebruiker met een cognitieve beperking, een oudere gebruiker of een screenreader-gebruiker mogelijk niet of het nummer te kort is, een ongeldig teken bevat of een opmaakprobleem heeft. Door toe te voegen: "TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901" (TC Identity Number must be 11 digits, e.g., 12345678901) wordt de ambiguïteit direct weggenomen en kan de gebruiker zichzelf corrigeren.

Voordelen voor bruikbaarheid en conversie: Naast toegankelijkheid is het afbreken van formulieren een cruciale zakelijke metric. Onderzoek toont consequent aan dat onduidelijke foutmeldingen een van de belangrijkste redenen zijn waarom gebruikers e-commerce-checkouts en registratieflows verlaten. Specifieke, uitvoerbare foutsuggesties verlagen de uitvalpercentages bij formulieren en verbeteren de voltooiingspercentages voor alle gebruikers — waardoor dit criterium zowel een sterke zakelijke case als een toegankelijkheidseis is.

Gerelateerde Axe-core-regels

WCAG 3.3.3 vereist handmatige tests omdat geautomatiseerde tools de kwaliteit of volledigheid van de tekst van foutmeldingen niet kunnen beoordelen. Een geautomatiseerde scanner kan detecteren dat er een foutmelding bestaat en dat deze programmatisch is geassocieerd met een formulierveld, maar kan niet bepalen of het bericht daadwerkelijk een bruikbare corrigerende suggestie biedt. Dit vereist menselijk oordeel om te beoordelen of de tekst specifiek, uitvoerbaar en voldoende is om de gebruiker naar een geldige invoer te begeleiden.

• Handmatige beoordeling — kwaliteit van de foutmelding: Testers moeten elke validatievoorwaarde handmatig activeren (een verplicht veld leeg indienen, gegevens in het verkeerde formaat invoeren, tekenlimieten overschrijden, enz.) en elke resulterende foutmelding evalueren. De tester vraagt: vertelt dit bericht de gebruiker niet alleen dat er een fout is opgetreden, maar ook specifiek wat hij of zij moet doen om deze te corrigeren? Als het bericht algemeen is ("Invalid," "Error," "Please check this field"), voldoet het niet aan 3.3.3, ongeacht of het programmatisch wordt blootgesteld.
• Handmatige beoordeling — programmatische associatie: Testers moeten verifiëren dat de tekst van de foutsuggestie programmatisch is gekoppeld aan het relevante invoerveld met behulp van aria-describedby, aria-live-regio's of inline associatie, zodat screenreaders deze aankondigen zonder extra navigatie te vereisen. Dit overlapt gedeeltelijk met axe-regels zoals label en aria-input-field-name, maar de suggestietekst zelf wordt door deze regels niet gecontroleerd.
• Handmatige beoordeling — geldigheid van de veiligheidsuitzondering: Testers moeten verifiëren dat elk formulier dat corrigerende suggesties om veiligheidsredenen weglaat (bijv. inlogformulieren) daadwerkelijk onder de veiligheidsuitzondering valt, en dat deze uitzondering niet wordt gebruikt om de eis voor niet-gevoelige velden te omzeilen.
• Gedeeltelijk geautomatiseerd — label-regel: Hoewel de label-regel van axe-core controleert of formulierinvoervelden toegankelijke namen hebben, controleert deze niet of foutmeldingen corrigerende suggesties bieden. De regel kan ontbrekende labels aan het licht brengen die het probleem met foutsuggesties zouden verergeren, en het oplossen van labelfouten is een vereiste voor een effectieve implementatie van foutsuggesties.

Hoe te Testen

1. Geautomatiseerde scan als basislijn: Voer axe DevTools of Lighthouse uit op de pagina met het formulier. Noteer eventuele bestaande overtredingen met betrekking tot formulierlabels, ARIA-rollen of foutidentificatie (3.3.1). Deze moeten eerst worden opgelost, omdat ze een voorwaarde zijn voor effectieve foutsuggesties. Geautomatiseerde scans zullen ontbrekende suggesties niet markeren — ze leggen alleen de structurele basis vast.
2. Activeer elke validatievoorwaarde: Lok voor elk formulierveld bewust elke mogelijke foutstatus uit: dien een verplicht veld leeg in, voer gegevens in een onjuist formaat in (verkeerd datumformaat, ongeldig e-mailadres, te kort wachtwoord, niet-numerieke waarde in een numeriek veld) en overschrijd eventuele tekenlimieten. Documenteer elke foutmelding die verschijnt.
3. Beoordeel de kwaliteit van de suggestie: Vraag voor elke foutmelding: (a) Identificeert deze het specifieke veld? (b) Legt deze uit wat er mis is? (c) Biedt deze uitvoerbare aanwijzingen over hoe de invoer te corrigeren? Een bericht dat alle drie beantwoordt, voldoet aan 3.3.3. Een bericht dat alleen (a) beantwoordt, voldoet aan 3.3.1 maar niet aan 3.3.3.
4. Screenreader-testen met NVDA + Firefox: Navigeer met Tab naar het formulier. Vul een ongeldige waarde in. Verstuur het formulier of verplaats de focus. Luister naar wat NVDA aankondigt. Controleer of de tekst van de foutsuggestie automatisch wordt voorgelezen (via een aria-live-regio of focusbeheer naar de fout) zonder dat de gebruiker deze handmatig hoeft op te zoeken.
5. Screenreader-testen met VoiceOver + Safari (macOS/iOS): Voer dezelfde stappen uit. Gebruik VO+Rechter pijltje om het veld en de bijbehorende beschrijving te lezen. Bevestig dat de suggestietekst wordt aangekondigd als onderdeel van de toegankelijke beschrijving van het veld, en niet alleen als nabijgelegen tekst die kan worden overgeslagen.
6. Screenreader-testen met JAWS + Chrome: Bevestig na het verzenden van een formulier met fouten dat JAWS de foutsuggestie voorleest via focusbeheer (focus verplaatst naar de foutsamenvatting) of via updates in een aria-live-regio. Gebruik de virtuele cursor van JAWS om naar het veld te navigeren en bevestig dat de suggestie deel uitmaakt van de beschrijving van het veld.
7. Alleen toetsenbordnavigatie: Navigeer zonder screenreader door het formulier met alleen Tab, Shift+Tab en Enter. Controleer of foutsuggesties zichtbaar zijn in de viewport, niet buiten beeld verborgen of door andere elementen bedekt, wanneer het veld na een mislukte verzending focus krijgt.
8. Controleer veiligheidsuitzonderingen: Bevestig voor inlog- en authenticatieformulieren dat het weglaten van specifieke suggesties opzettelijk en gedocumenteerd is, en dat de veiligheidsuitzondering beperkt blijft tot de minimaal noodzakelijke velden.

Hoe te Herstellen

Algemene foutmelding — Onjuist

<!-- Error message provides no suggestion on how to fix the problem -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

Algemene foutmelding — Juist

<!-- aria-describedby links the suggestion text to the input;
     the suggestion explains exactly what format is expected -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

Wachtwoordvalidatie zonder formaatbegeleiding — Onjuist

<!-- User is told the password is wrong but not why or how to fix it -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

Wachtwoordvalidatie zonder formaatbegeleiding — Juist

<!-- The suggestion lists exactly what the password must contain,
     enabling the user to self-correct without guessing -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

Datumveld met onduidelijke formaatfout — Onjuist

<!-- No indication of which date format is expected -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

Datumveld met onduidelijke formaatfout — Juist

<!-- The suggestion states the required format and provides
     a concrete example, removing all ambiguity -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

Formulier met meerdere velden en server-side foutsamenvatting — Onjuist

<!-- Error summary exists but links do not associate suggestions
     with individual fields, and messages are vague -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

Formulier met meerdere velden en server-side foutsamenvatting — Juist

<!-- Error summary includes linked, specific suggestions;
     each list item links to the relevant field;
     inline errors also appear adjacent to each field -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

Veelvoorkomende Fouten

• placeholder gebruiken als vervanging voor foutsuggesties: Placeholdertekst verdwijnt zodra de gebruiker begint te typen en wordt door screenreaders niet betrouwbaar als fout aangekondigd. Vertrouw nooit alleen op placeholdertekst om te communiceren welk formaat vereist is nadat een fout is opgetreden.
• Foutmeldingen alleen tonen in een toast-notificatie die na enkele seconden verdwijnt: Tijdelijke notificaties zijn niet voor alle gebruikers waarneembaar — screenreader-gebruikers kunnen de aankondiging missen, en het bericht is verdwenen voordat een langzame lezer het kan verwerken. Foutsuggesties moeten blijven staan totdat de fout is gecorrigeerd.
• aria-invalid='true' gebruiken zonder aria-describedby dat naar de suggestietekst verwijst: Het instellen van aria-invalid geeft aan dat een veld een fout bevat, maar zonder aria-describedby dat naar het suggestie-element verwijst, zullen screenreaders de suggestietekst niet voorlezen wanneer het veld focus krijgt.
• De suggestie alleen in het visuele ontwerp aanbieden (bijv. een tooltip bij hover) en niet in de DOM: Tooltips die alleen bij hover verschijnen, zijn niet toegankelijk voor toetsenbordgebruikers en screenreader-gebruikers. De suggestietekst moet in de DOM aanwezig zijn en programmatisch met het veld worden geassocieerd.
• Alleen kleur of iconografie gebruiken om aan te geven welk veld een fout heeft: Een rode rand of waarschuwingspictogram vormt geen foutsuggestie. De suggestie moet een tekstuele beschrijving zijn die de corrigerende actie uitlegt, niet een visuele indicator.
• Suggesties schrijven die het probleem identificeren maar niet de oplossing: "Your password is too short" identificeert de fout maar suggereert geen oplossing. "Your password must be at least 8 characters" biedt de noodzakelijke corrigerende begeleiding. Beide onderdelen zijn vereist voor naleving van 3.3.3.
• De veiligheidsuitzondering te ruim toepassen: De veiligheidsuitzondering is beperkt tot situaties waarin het geven van een suggestie de veiligheid daadwerkelijk in gevaar zou brengen — doorgaans beperkt tot authenticatievelden. Zij is niet van toepassing op standaard formuliervelden zoals namen, adressen of telefoonnummers, waar algemene fouten niet te rechtvaardigen zijn.
• De foutsuggestie na de verzendknop of ver van het veld plaatsen: Foutsuggesties moeten visueel en programmatisch dicht bij het veld staan dat zij beschrijven. Alle fouten onderaan een lang formulier plaatsen, zonder ook inline suggesties bij elk veld op te nemen, dwingt gebruikers tot contextwisselingen en tot het onthouden welke suggestie bij welk veld hoort.
• Verzuimen de focus naar de foutsamenvatting te verplaatsen na een mislukte server-side verzending: Wanneer een pagina na een mislukte verzending opnieuw wordt geladen, keert de focus meestal terug naar de bovenkant van de pagina. Zonder programmatisch focusbeheer naar de foutsamenvatting of het eerste veld met een fout, moeten screenreader-gebruikers de hele pagina doorlopen om te ontdekken wat er misging.
• Vage taal gebruiken zoals "Please check your input" of "Something went wrong": Deze berichten geven geen informatie over wat er mis is of hoe dit kan worden opgelost. Elke foutsuggestie moet specifiek zijn voor het veld en de specifieke validatieregel die is geschonden.

Relatie met de Toegankelijkheidsregelgeving van Turkije

Het toegankelijkheidslandschap van Turkije is aanzienlijk gevorderd met de Presidentiële Circulaire 2025/10, gepubliceerd in Staatsblad nr. 32933 op 21 juni 2025. Deze circulaire stelt verplichte toegankelijkheidseisen voor web en mobiel vast die zijn afgestemd op WCAG 2.2, met vereiste conformiteit op niveau AA voor entiteiten die het Erişilebilirlik Logosu (Toegankelijkheidslogo) willen verkrijgen dat wordt uitgegeven door het Ministerie van Gezin en Sociale Diensten (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.3.3 Error Suggestion, als criterium op niveau AA, valt binnen de reikwijdte van deze verplichte eis. Elke betrokken entiteit die formulieren gebruikt — voor registratie, betaling, dienstaanvragen of accountbeheer — moet ervoor zorgen dat hun foutmeldingen niet alleen fouten identificeren, maar ook uitvoerbare corrigerende suggesties bieden, zoals in dit criterium beschreven.

De entiteiten die onder de Presidentiële Circulaire 2025/10 vallen, bestrijken een breed scala aan sectoren. Publieke instellingen en overheidsinstanties moeten voldoen, wat betekent dat alle e-governmentportalen (bijv. e-Devlet-diensten, gemeentelijke portalen, systemen voor uitkeringsaanvragen) conforme implementaties van foutsuggesties moeten bieden. Aangezien veel overheidsdiensten vereisen dat burgers complexe persoonlijke gegevens indienen — identiteitsnummers, adrescodes, belastingnummers — zijn duidelijke foutsuggesties in deze context bijzonder cruciaal.

Banken en financiële instellingen vallen er ook onder, inclusief onlinebankierplatforms, registratieformulieren voor beleggingsrekeningen en portalen voor leningaanvragen. Deze formulieren verzamelen routinematig gevoelige en nauwkeurig geformatteerde gegevens, en het ontbreken van corrigerende suggesties creëert reële barrières voor klanten met een beperking en potentiële juridische risico's.

Ziekenhuizen en zorgaanbieders moeten eveneens voldoen, waaronder systemen voor patiëntenregistratie, formulieren voor het maken van afspraken en portalen voor verzekeringsclaims. Medische formulieren bevatten vaak complexe veldvereisten (diagnosecodes, verzekeringspolisnummers, precieze datumformaten), waardoor duidelijke foutsuggesties vooral belangrijk zijn voor oudere en cognitief beperkte patiënten.

Telecommunicatiebedrijven met 200,000 of meer abonnees vallen eronder, waaronder de klantenportalen van grote aanbieders, formulieren voor SIM-registratie en interfaces voor accountbeheer. E-commerceplatforms — inclusief checkoutflows en accountregistratie — moeten voldoen, waardoor Error Suggestion direct relevant is voor product- en winkelwagenbeheerformulieren die centraal staan in hun bedrijfsvoering.

Reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (MoNE) vallen eveneens binnen de reikwijdte. Boekingsformulieren, inschrijvingsaanvragen en betaalinterfaces die door deze entiteiten worden beheerd, moeten voldoen aan de normen van niveau AA, inclusief 3.3.3.

Vanuit praktisch nalevingsperspectief moeten organisaties die het Erişilebilirlik Logosu nastreven, WCAG 3.3.3 als een belangrijk auditpunt behandelen tijdens elke toegankelijkheidsbeoordeling. Handmatige tests van alle formulier-validatiestromen — inclusief zowel client-side als server-side foutstatussen — zijn vereist, en documentatie van de onderbouwing voor veiligheidsuitzonderingen moet worden bijgehouden voor alle velden waar corrigerende suggesties opzettelijk worden weggelaten. Het niet voldoen aan de vereisten van niveau AA, inclusief Error Suggestion, zal de toekenning van het logo verhinderen en kan betrokken entiteiten blootstellen aan administratieve gevolgen onder de circulaire.