WCAG 3.3.1: Foutidentificatie

Wat Deze Regel Betekent

WCAG 3.3.1 Foutidentificatie is een succescriterium op Niveau A onder het principe Begrijpelijk. Het stelt: "If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text." In praktische termen: telkens wanneer je website of applicatie gebruikersinvoer automatisch valideert — bij het verzenden van een formulier, bij het verlaten van een veld (blur) of in real time — moeten er twee dingen gebeuren als er een fout wordt gedetecteerd: het specifieke veld of de specifieke bediening met de fout moet duidelijk worden geïdentificeerd, en de aard van de fout moet worden gecommuniceerd met echte tekstinhoud (niet uitsluitend kleur, pictogram of geluid).

Het criterium is van toepassing op elke situatie waarin invoer van gebruikers wordt verzameld en validatie automatisch plaatsvindt. Dit omvat HTML-formulierelementen zoals <input>, <select>, <textarea>, evenals aangepaste interactieve widgets die met ARIA zijn gebouwd. Het dekt client-side validatie die door JavaScript wordt geactiveerd, native browser-constraintvalidatie met behulp van attributen zoals required, pattern, minlength en type, evenals server-side validatieresultaten die na een paginaherlading worden weergegeven of dynamisch in de DOM worden geïnjecteerd.

Een pass vereist dat: (1) elk veld met een fout programmatisch is gekoppeld aan een foutmelding — meestal via aria-describedby of aria-errormessage — zodat ondersteunende technologieën deze kunnen aankondigen; (2) de foutmelding in platte tekst zichtbaar is in de UI (niet verborgen voor ziende gebruikers); en (3) de tekst duidelijk beschrijft wat er misging, niet alleen dát er iets misging. Bijvoorbeeld, "E-mailadres is verplicht" is een geldige foutbeschrijving, terwijl alleen een rode rand of een uitroeptekenpictogram zonder tekstalternatief tonen een fail is.

Een fail treedt op wanneer: fouten uitsluitend worden aangegeven via kleurveranderingen (rode rand zonder tekst), fouten alleen worden aangekondigd via role="alert" zonder aan te geven welk veld is getroffen, de tekst van de foutmelding leeg of generiek is (bijv. "Ongeldige invoer"), of foutmeldingen wel in de DOM bestaan maar niet programmatisch zijn gekoppeld aan het bijbehorende veld, zodat schermlezers ze niet kunnen associëren.

WCAG 3.3.1 is niet van toepassing wanneer er geen automatische detectie plaatsvindt — bijvoorbeeld, als een formulier wordt verzonden en de server de pagina simpelweg herlaadt zonder enige aanwijzing wat er misging, is dat een afzonderlijk bruikbaarheidsprobleem maar valt het buiten de strikte reikwijdte van dit criterium. Als je systeem echter wel automatische detectie uitvoert (wat vrijwel alle moderne formulieren doen), valt het criterium volledig binnen de scope. Er zijn binnen het criterium zelf geen uitzonderingen gedefinieerd voor specifieke invoertypen of gebruikssituaties.

Waarom Het Belangrijk Is

Foutidentificatie heeft directe en aanzienlijke impact op meerdere groepen mensen met een beperking. Voor blinde en slechtziende gebruikers die vertrouwen op schermlezers zoals NVDA, JAWS of VoiceOver, communiceert een rode rand of een waarschuwingspictogram niets. Als een foutmelding niet als echte tekst aanwezig is en niet programmatisch is gekoppeld aan het veld met de fout, zal de schermlezer deze niet aankondigen, en kan de gebruiker een formulier herhaaldelijk verzenden zonder te begrijpen waarom het mislukt. Volgens de Wereldgezondheidsorganisatie hebben wereldwijd ongeveer 2,2 miljard mensen een vorm van visuele beperking, en miljoenen vertrouwen dagelijks op ondersteunende technologie om met webcontent te communiceren.

Voor gebruikers met cognitieve beperkingen — waaronder dyslexie, aandachtsstoornissen en geheugenstoornissen — vormen vage foutmeldingen zoals "Er is iets misgegaan" aanzienlijke barrières. Deze gebruikers hebben enorm veel baat bij precieze, beschrijvende fouttekst die exact aangeeft welk veld moet worden gecorrigeerd en wat het juiste formaat of de juiste waarde moet zijn. Bijvoorbeeld, in plaats van "Ongeldige datum" is een melding als "Geboortedatum moet in DD/MM/JJJJ-formaat zijn" veel beter bruikbaar.

Gebruikers met motorische beperkingen die met toetsenbord of schakelapparaten navigeren, moeten veel moeite doen om door een formulier te gaan. Wanneer een fout onduidelijk of niet geïdentificeerd is, moeten zij het hele formulier opnieuw doorlopen om het probleem te vinden, wat de cognitieve en fysieke belasting van het invullen sterk vergroot. Duidelijke foutidentificatie stelt deze gebruikers in staat direct naar het problematische veld te springen.

Beschouw dit scenario uit de echte wereld: een Turkse burger die probeert zich te registreren op een overheids-e-serviceportaal om een uitkering voor een beperking aan te vragen. Het formulier vereist een nationaal ID-nummer in een specifiek formaat. De gebruiker, die blind is, voert zijn ID-nummer in. Na verzending wordt het formulier opnieuw geladen met rood gemarkeerde velden maar zonder bijbehorende tekstfout. De schermlezer kondigt alleen de veldlabels opnieuw aan — de gebruiker heeft geen idee wat er misging of welk veld het probleem is. Hij breekt het proces volledig af en verliest de toegang tot een cruciale publieke dienst. Dit is precies de situatie die WCAG 3.3.1 wil voorkomen.

Naast toegankelijkheid verbetert duidelijke foutidentificatie de conversieratio’s en bruikbaarheid voor alle gebruikers. UX-onderzoek toont consequent aan dat beschrijvende inline foutmeldingen het afbreken van formulieren verminderen. Vanuit SEO-perspectief hebben verbeterde gebruikersbetrokkenheidssignalen — waaronder langere tijd op de site en succesvolle formulierverzendingen — op termijn een positieve invloed op de zoekrangschikking.

Gerelateerde Axe-core-regels

WCAG 3.3.1 vereist handmatige tests voor volledige verificatie. Dit komt doordat geautomatiseerde tools de aanwezigheid of afwezigheid van structurele patronen kunnen detecteren (zoals aria-describedby of aria-errormessage), maar niet kunnen beoordelen of de tekstinhoud van een foutmelding betekenisvol, accuraat of voldoende is om de gebruiker te helpen de fout te begrijpen en te corrigeren. Een geautomatiseerde tool ziet dat er een element met role="alert" bestaat; hij kan niet beoordelen of de melding "Fout op regel 4" een validatiefout voldoende beschrijft voor een schermlezergebruiker.

• aria-required-attr: Deze axe-core-regel controleert of elementen met bepaalde ARIA-rollen alle vereiste ARIA-attributen hebben. Hoewel het niet exclusief een foutidentificatieregel is, is hij relevant omdat een formulierveld in een foutstatus dat role="textbox" of iets dergelijks gebruikt zonder de vereiste attributen mogelijk geen statusinformatie aan ondersteunende technologieën doorgeeft, waardoor foutcommunicatie wordt ondermijnd.
• aria-valid-attr-value: Deze regel markeert gevallen waarin ARIA-attributen verwijzen naar ID’s die niet in de DOM bestaan. Als een veld bijvoorbeeld aria-describedby="email-error" gebruikt maar er geen element met id="email-error" bestaat, is de koppeling verbroken en wordt de foutmelding niet door schermlezers voorgelezen. Dit is een veelvoorkomend patroon van falen voor 3.3.1.
• Vereiste handmatige evaluatie: Testers moeten validatiefouten handmatig uitlokken en vervolgens een schermlezer gebruiken om te bevestigen dat: het veld met de fout wordt geïdentificeerd bij naam of label, de foutbeschrijving wordt aangekondigd, de melding betekenisvol en bruikbaar is, en de fout niet uitsluitend via niet-tekstuele middelen wordt gecommuniceerd. Geautomatiseerde scans kunnen geen gebruikersinteractiesequenties simuleren of de semantische kwaliteit van berichttekst beoordelen, waardoor menselijk oordeel onmisbaar is voor dit criterium.

Hoe te Testen

1. Geautomatiseerde scan met axe DevTools of Lighthouse: Voer een axe DevTools-scan uit op de pagina met het formulier, vóór en na het uitlokken van validatiefouten. Let specifiek op overtredingen met betrekking tot kapotte verwijzingen naar aria-describedby of aria-errormessage, ontbrekende role="alert"- of aria-live-regio’s die worden gebruikt voor dynamische foutinjectie, en formuliervelden zonder labels (wat ook correcte foutkoppeling verhindert). Controleer in Lighthouse de Accessibility-audit op formuliergerelateerde overtredingen. Let op dat een schone geautomatiseerde rapportage 3.3.1-naleving niet bevestigt — het sluit alleen bepaalde structurele fouten uit.
2. Handmatige toetsenbordnavigatietest: Gebruik uitsluitend een toetsenbord (Tab, Shift+Tab, Enter, Spatie) en probeer het formulier te verzenden met opzettelijk onjuiste of ontbrekende waarden. Controleer of: de focus naar of in de buurt van het eerste veld met een fout verplaatst, elke foutmelding zichtbaar is in de viewport, en de foutmeldingen het specifieke veld bij naam identificeren en het probleem in platte tekst beschrijven.
3. Schermlezertest met NVDA + Firefox: Open het formulier in Firefox met NVDA actief. Verstuur het formulier met fouten. Luister aandachtig: kondigt NVDA aan welk veld een fout heeft? Wordt de foutbeschrijving voorgelezen? Tab naar het foutieve veld — leest NVDA de bijbehorende foutmelding als onderdeel van de toegankelijke beschrijving van het veld? Als aria-live-regio’s worden gebruikt, controleer dan of de aankondiging niet vertraagd of onderdrukt wordt.
4. Schermlezertest met VoiceOver + Safari (macOS/iOS): Herhaal hetzelfde proces met VoiceOver op Safari. Gebruik VO+Pijl rechts om na verzending door het formulier te lezen. Bevestig dat elk veld met een fout de fouttekst in zijn toegankelijke naam of beschrijving bevat. Test op iOS met aanraaknavigatie en veeggebaren.
5. Schermlezertest met JAWS + Chrome: Verstuur met JAWS actief in Chrome het formulier met fouten. Gebruik de virtuele cursor van JAWS om naar elk formulierveld met een fout te navigeren. Bevestig dat de tekst van de foutmelding wordt opgenomen in wat JAWS voor het veld voorleest. Controleer ook het gedrag van de JAWS-formuliersmodus, aangezien de formuliersmodus sommige live-regioaankondigingen onderdrukt.
6. Audit van kleur- en niet-tekstuele aanwijzingen: Inspecteer elke foutstatus visueel. Verwijder of schakel CSS tijdelijk uit (met browserontwikkeltools of een bookmarklet) en controleer of foutidentificatie nog steeds als tekst in de DOM aanwezig is. Dit verifieert dat foutcommunicatie niet uitsluitend afhankelijk is van kleur of iconografie.
7. Controle van dynamische injectie: Gebruik voor single-page-applicaties of formulieren met real-time validatie de browserontwikkeltools om de DOM te inspecteren nadat een fout is geactiveerd. Bevestig dat het foutmeldingselement in de DOM bestaat, niet-lege tekst bevat en wordt verwezen door de bijbehorende invoer via aria-describedby of aria-errormessage.

Hoe te Herstellen

Scenario 1: Fout alleen aangegeven door kleur — Onjuist

<!-- Fail: red border added via class, no error text associated -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' class='input-error'>
<!-- CSS sets border: 2px solid red on .input-error -->
<!-- No error message text is rendered in the DOM -->

Scenario 1: Fout alleen aangegeven door kleur — Juist

<!-- Pass: error text is present, visible, and linked to the input -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-describedby='email-error'
  aria-invalid='true'
>
<!-- aria-invalid signals the error state to assistive technologies -->
<!-- aria-describedby links the input to its error message by ID -->
<p id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</p>

Scenario 2: Generieke foutsamenvatting zonder veldidentificatie — Onjuist

<!-- Fail: a summary alert exists but does not identify which fields failed -->
<div role='alert'>
  <p>There are errors in the form. Please correct them and try again.</p>
</div>
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' name='phone' class='is-invalid'>
<!-- No per-field error message; user cannot determine which field failed -->

Scenario 2: Generieke foutsamenvatting zonder veldidentificatie — Juist

<!-- Pass: summary lists specific fields in error, and each field has inline error text -->
<div role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>2 errors found. Please fix the following:</h2>
  <ul>
    <li><a href='#phone'>Phone Number: must contain only digits and be 10 characters long</a></li>
    <li><a href='#dob'>Date of Birth: required field — please enter your date of birth</a></li>
  </ul>
</div>
<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-error'
  aria-invalid='true'
>
<!-- Inline error linked via aria-describedby -->
<p id='phone-error'>Phone Number must contain only digits and be 10 characters long.</p>

Scenario 3: Kapotte aria-describedby-verwijzing — Onjuist

<!-- Fail: aria-describedby references an ID that does not exist in the DOM -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- The element with id='username-msg' was never rendered or was removed -->
<!-- Screen readers find no target and announce nothing for the description -->

Scenario 3: Kapotte aria-describedby-verwijzing — Juist

<!-- Pass: the referenced element exists in the DOM with matching ID -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- Element with matching id is present and contains descriptive text -->
<span id='username-msg'>
  Username must be between 4 and 20 characters and contain only letters and numbers.
</span>

Scenario 4: Real-time validatiefout dynamisch geïnjecteerd — Onjuist

<!-- Fail: error injected into DOM but not associated with input; no live region -->
<label for='password'>Password</label>
<input type='password' id='password' name='password'>
<!-- After blur, JavaScript appends this element, but no aria-describedby on input -->
<div class='error-text'>Password is too short.</div>

Scenario 4: Real-time validatiefout dynamisch geïnjecteerd — Juist

<!-- Pass: error container pre-exists in DOM (empty), input references it; aria-live announces changes -->
<label for='password'>Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-describedby='password-error'
  aria-invalid='false'
>
<!-- Empty span present at page load; JavaScript populates text and sets aria-invalid='true' on error -->
<span id='password-error' aria-live='polite'></span>
<!-- JavaScript on blur: -->
<!-- document.getElementById('password-error').textContent = 'Password must be at least 8 characters.'; -->
<!-- document.getElementById('password').setAttribute('aria-invalid', 'true'); -->

Veelvoorkomende Fouten

• Alleen CSS-klassetoewijzingen gebruiken (bijv. border-color: red toevoegen) om fouten aan te geven zonder bijbehorende tekst in de DOM. Kleur alleen is niet waarneembaar voor blinde gebruikers of gebruikers met kleurenblindheid en voldoet niet aan 3.3.1 en 1.4.1.
• aria-describedby op de invoer schrijven maar verwijzen naar een ID die voorwaardelijk wordt gerenderd of bij het resetten van validatie uit de DOM wordt verwijderd. De kapotte verwijzing betekent dat de schermlezer geen gekoppelde inhoud vindt en de fout voor gebruikers van ondersteunende technologie feitelijk onzichtbaar is.
• Placeholdertekst gebruiken als enige foutmelding. Placeholdertekst verdwijnt wanneer de gebruiker begint te typen, is vaak laag in contrast en wordt niet door alle schermlezers betrouwbaar als onderdeel van de veldbeschrijving in foutstatussen aangekondigd.
• Foutmeldingen dynamisch in de DOM injecteren zonder ervoor te zorgen dat ze via aria-describedby aan hun bovenliggende veld zijn gekoppeld. Een visueel aangrenzende foutmelding is niet automatisch gekoppeld aan een invoer — de programmatische koppeling moet expliciet zijn.
• Een foutsamenvatting op paginaniveau tonen zonder elk samenvattingsitem te koppelen aan het specifieke veld met de fout. Gebruikers van schermlezers of toetsenbordnavigatie moeten direct van de foutbeschrijving naar het veld kunnen gaan dat correctie vereist.
• aria-invalid='true' op een veld zetten maar geen foutmeldingstekst geven. Het attribuut aria-invalid geeft aan dat een veld in een foutstatus is, maar beschrijft de fout niet — het moet worden gecombineerd met een beschrijvende melding.
• Foutmeldingen geven die te generiek zijn, zoals "Ongeldige invoer" of "Fout in veld". Deze beschrijvingen leggen niet uit wat er mis is of hoe het kan worden opgelost, voldoen niet aan de beschrijvende eis van 3.3.1 en maken foutcorrectie onnodig moeilijk voor alle gebruikers.
• aria-live-regio’s of role='alert' uit foutcontainers verwijderen bij het resetten van een formulier, waardoor de containers verdwijnen voordat schermlezers hun inhoud volledig hebben aangekondigd. Foutmeldingen kunnen worden afgebroken, waardoor de gebruiker zich niet bewust is van het validatieresultaat.
• Vertrouwen op native browservalidatieballonnen (de standaard tooltip-pop-ups van de browser) zonder aanpassing. Native browservalidatie-UI’s zijn inconsistent tussen browsers en combinaties van ondersteunende technologie, en voldoen vaak niet aan de WCAG-eisen voor identificatie en beschrijving in complexe formsituaties.
• Foutmeldingen visueel ver van hun bijbehorende velden plaatsen — zoals alleen in een header-waarschuwingsvak — zonder ook inline meldingen bij elk veld te geven. Gebruikers met een beperkt gezichtsvermogen die het scherm vergroten, zien mogelijk de waarschuwing op headerniveau niet terwijl ze zich op het invoergebied concentreren, en toetsenbordgebruikers moeten een grote afstand afleggen om de fout te lezen.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt verplichte webtoegankelijkheidseisen vast voor een breed scala aan entiteiten die in Turkije actief zijn. De circulaire neemt WCAG 2.2 over als technische standaard, waardoor alle succescriteria op Niveau A — waaronder WCAG 3.3.1 Foutidentificatie — wettelijk verplicht zijn voor de betrokken organisaties.

De nalevingstermijn die in de circulaire is vastgesteld, is één jaar voor overheidsinstellingen en twee jaar voor entiteiten in de private sector vanaf de publicatiedatum. Dit betekent dat overheidsinstellingen uiterlijk in juni 2026 WCAG 2.2-conformiteit op Niveau A moeten bereiken, en betrokken entiteiten in de private sector uiterlijk in juni 2027.

De entiteiten die onder de circulaire vallen, omvatten een brede doorsnede van Turkse digitale diensten. Overheidsinstellingen — waaronder alle centrale ministeries, gemeenten, staatsuniversiteiten en publieke agentschappen — moeten ervoor zorgen dat hun digitale diensten toegankelijk zijn. In de private sector omvat de circulaire e-commerceplatforms, banken en financiële instellingen, ziekenhuizen en particuliere zorgaanbieders, telecombedrijven met 200.000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (MoNE).

Voor al deze entiteiten is WCAG 3.3.1 direct relevant overal waar online formulieren worden gebruikt — wat in de praktijk bijna elk digitaal contactmoment betekent. E-commerce-afrekenformulieren, processen voor het openen van bankrekeningen, patiëntregistratieportalen van ziekenhuizen, aanvraagformulieren voor overheidsuitkeringen, boekingssystemen voor luchtvaart en busvervoer en inschrijfpagina’s van scholen zijn allemaal afhankelijk van formulier­validatie. Als een van deze systemen een invoerfout automatisch detecteert en nalaat het veld te identificeren of de fout in tekst te beschrijven, is dat een directe schending van de vereisten van de circulaire.

Niet-naleving van de circulaire kan betrokken entiteiten blootstellen aan toezicht door toezichthouders, reputatierisico en mogelijke sancties naarmate het handhavingskader voor digitale toegankelijkheid in Turkije zich verder ontwikkelt. Los van juridische naleving toont het voldoen aan 3.3.1 een inzet voor inclusieve dienstverlening — zodat alle burgers, inclusief de ongeveer 8,5 miljoen mensen met een beperking in Turkije (volgens TÜİK-gegevens), zonder barrières toegang hebben tot essentiële online diensten. Organisaties die werken met het SDK-framework van Accsible moeten zowel geautomatiseerde structurele naleving als grondige handmatige tests prioriteren om ervoor te zorgen dat hun foutafhandeling volledig voldoet aan dit fundamentele criterium.