WCAG 3.3.5: Hulp

Wat Deze Regel Betekent

\n

WCAG Succescriterium 3.3.5 Help (Niveau AAA) stelt: \"Contextgevoelige hulp is beschikbaar.\" Dit betekent dat overal waar een webpagina of applicatie gebruikers vraagt om informatie in te voeren, passende hulp moet worden geboden om te verduidelijken wat er wordt verwacht. De hulp moet contextueel zijn — dat wil zeggen, ze moet direct verband houden met het veld, de taak of het proces waarmee de gebruiker op dat moment bezig is, in plaats van een algemene helppagina te zijn die ergens diep in de navigatie verborgen zit.

\n

Het criterium is van toepassing op elke gebruikersinterfacecomponent die invoer vereist: tekstvelden, keuzelijsten, datumkiezers, bestandsuploadbesturingselementen, selectievakjes, keuzerondjes en meerstapsformulieren. Contextgevoelige hulp kan vele vormen aannemen, waaronder inline-instructies, beschrijvende labels, placeholder-tekst met aanwijzingen, tooltips, help-iconen die uitleg uitklappen, links naar relevante helpartikelen of zelfs livechatondersteuning — zolang de hulp maar beschikbaar is in de nabijheid van de invoer waarvoor ze nodig is.

\n

Een pass wordt behaald wanneer ten minste één van de volgende elementen aanwezig is voor elke invoer die verwarring bij gebruikers kan veroorzaken: een duidelijk geschreven label dat volledig uitlegt welke invoer wordt verwacht; aanvullende beschrijvende tekst naast het veld (niet alleen een placeholder, die verdwijnt zodra je begint te typen); een zichtbare helplink of uitklapbare tooltip die verdere uitleg biedt; of een gemakkelijk toegankelijke hulpmechanisme (zoals een vraagtekenpictogram) dat begeleiding toont die specifiek is voor de huidige context. De hulp hoeft niet identiek te zijn voor alle velden — de belangrijkste eis is dat overal waar een gebruiker onzeker kan zijn over wat hij of zij moet invoeren, er daadwerkelijk hulp beschikbaar en toegankelijk is.

\n

Een fail treedt op wanneer velden geen uitleg geven over wat er wordt verwacht, wanneer hulp pas beschikbaar is na het verzenden en er een fout optreedt, wanneer tooltips of helptekst ontoegankelijk zijn voor toetsenbord- of schermlezers, of wanneer helplinks leiden naar een algemene FAQ-pagina in plaats van naar inhoud die relevant is voor de specifieke invoer. Cruciaal is dat uitsluitend vertrouwen op foutmeldingen achteraf dit criterium niet vervult — hulp moet beschikbaar zijn vóór of tijdens de invoer, niet alleen nadat er een fout is gemaakt.

\n

WCAG 3.3.5 definieert geen strikte, enkele implementatiemethode. Het erkent dat contextgevoelige hulp op veel geldige manieren kan worden geïmplementeerd en geeft ontwikkelaars flexibiliteit, maar de intentie is ondubbelzinnig: gebruikers mogen nooit hoeven te raden wat er in een formulier veld moet worden ingevuld. Er zijn geen officiële uitzonderingen op dit criterium — het is universeel van toepassing overal waar gebruikersinvoer wordt gevraagd.

\n\n

Waarom Het Belangrijk Is

\n

Formulieren behoren tot de meest uitdagende onderdelen van elke digitale interface. Voor gebruikers met cognitieve beperkingen — waaronder mensen met dyslexie, aandachtsstoornissen, verstandelijke beperkingen of geheugenstoornissen — kunnen onduidelijke formuliervelden een onoverkomelijke barrière vormen. Zonder duidelijke, contextuele hulp kunnen deze gebruikers herhaaldelijk falen bij het voltooien van taken, aanzienlijke frustratie ervaren of het proces volledig afbreken. Volgens de Wereldgezondheidsorganisatie leeft ongeveer 1 op de 6 mensen wereldwijd met een vorm van significante beperking, en cognitieve beperkingen vormen een substantieel deel van deze populatie.

\n

Gebruikers met lage digitale vaardigheden of beperkte ervaring met webinterfaces profiteren ook enorm van contextgevoelige hulp. Een eerste gebruiker van een overheidsportaal voor e-diensten, een oudere persoon die online een gezondheidsuitkering aanvraagt, of een kleine ondernemer die een belastingformulier invult, weet mogelijk niet welk formaat wordt verwacht voor een belastingidentificatienummer, welke bestandstypen worden geaccepteerd voor documentuploads, of wat het verschil is tussen twee vergelijkbaar benoemde velden. Zonder begeleiding in de context zijn deze gebruikers kwetsbaar voor fouten en de angst om niet te weten wat ze verkeerd hebben gedaan.

\n

Neem een concreet scenario: een gebruiker met een cognitieve beperking vraagt via het webportaal van een gemeentelijke vervoersautoriteit een gesubsidieerde reispas aan. Het formulier vraagt om een \"Referentienummer\" zonder uitleg. De gebruiker heeft meerdere documenten — hun nationale ID, hun vervoerskaart en een eerdere aanvraagbevestiging — elk met verschillende numerieke identificatoren. Zonder contextgevoelige hulp die aangeeft welk specifiek document of formaat wordt verwacht, is de kans groot dat de gebruiker het verkeerde nummer invoert, een validatiefout activeert en mogelijk opgeeft. Als er een eenvoudig help-icoon of een inline-beschrijving aanwezig was geweest — \"Voer het 10-cijferige nummer in de rechterbovenhoek van uw vervoerskaart in\" — dan was de hele interactie al bij de eerste poging geslaagd.

\n

Voor gebruikers die blind zijn of een beperkt gezichtsvermogen hebben, is contextgevoelige hulp ook belangrijk. Schermlezers kunnen geassocieerde helptekst, aria-describedby-beschrijvingen of gekoppelde helpinhoud voorlezen, maar alleen als deze correct zijn geïmplementeerd. Wanneer hulp uitsluitend visueel wordt overgebracht (zoals een kleurindicator of een pictogram zonder toegankelijke tekst), worden schermlezergebruikers uitgesloten. Zorgen dat hulp zowel aanwezig als toegankelijk is, versterkt de inclusiviteit voor alle groepen met een beperking.

\n

Naast toegankelijkheid verbetert contextgevoelige hulp de algemene bruikbaarheid en conversieratio’s. Websites met duidelijke formulierbegeleiding kennen lagere uitvalpercentages, minder ondersteuningsverzoeken en hogere voltooiingspercentages van formulieren. Vooral voor e-commercesites heeft elk procentpunt verbetering in het afronden van de checkout een directe impact op de omzet. Zoekmachines belonen ook pagina’s met duidelijke, gestructureerde inhoud, en goed gelabelde, goed beschreven formulieren dragen positief bij aan kwaliteitsindicatoren van pagina’s.

\n\n

Gerelateerde Axe-core-regels

\n

WCAG 3.3.5 vereist handmatige tests omdat de naleving afhangt van de kwaliteit, relevantie en contextuele geschiktheid van de helpinhoud — factoren die geautomatiseerde tools niet kunnen beoordelen. Een geautomatiseerde scanner kan bevestigen dat er een label bestaat of dat een aria-describedby-attribuut naar een echt element verwijst, maar kan niet bepalen of de inhoud van dat label of die beschrijving daadwerkelijk nuttig, accuraat of voldoende is voor een bepaalde invoer.

\n

\n
• Handmatige beoordeling — Aanwezigheid van contextgevoelige hulp: Geautomatiseerde tools kunnen niet beoordelen of helptekst daadwerkelijk de waarschijnlijke vragen van de gebruiker over een specifiek veld beantwoordt. Een tool kan detecteren dat er een <label>-element bestaat, maar kan niet beoordelen of \"Voer uw nummer in\" voldoende beschrijvend is voor een veld dat een geformatteerd btw-registratienummer verwacht. Handmatige testers moeten beoordelen of elke invoer die verwarring kan veroorzaken, wordt vergezeld van begeleiding die die verwarring daadwerkelijk vermindert.
\n
• Handmatige beoordeling — Toegankelijkheid van hulp: Zelfs als hulp visueel aanwezig is, signaleren geautomatiseerde tools mogelijk niet wanneer die hulp ontoegankelijk is voor ondersteunende technologie. Een tooltip die alleen wordt geactiveerd bij muis-hover, zonder toetsenbordtoegankelijke tegenhanger, slaagt voor veel geautomatiseerde controles maar faalt voor echte gebruikers. Testers moeten verifiëren dat alle hulpmechanismen — tooltips, uitklapbare secties, helplinks — bereikbaar en bedienbaar zijn via het toetsenbord en correct worden aangekondigd door schermlezers.
\n
• Handmatige beoordeling — Plaatsing en nabijheid van hulp: Geautomatiseerde scans kunnen niet beoordelen of helptekst dicht genoeg bij het relevante veld is geplaatst om er betekenisvol mee geassocieerd te worden. Een helpparagraaf onderaan de pagina, of in een modal die meerdere interacties vereist om te openen, kan technisch gezien bestaan maar faalt de bedoeling van contextgevoelige hulp. Handmatige beoordeling moet bevestigen dat hulp beschikbaar is op het moment dat deze nodig is.
\n
• Handmatige beoordeling — Volledigheid bij complexe formulieren: Complexe, meerstapsformulieren brengen extra uitdagingen met zich mee. Geautomatiseerde tools controleren individuele velden geïsoleerd, maar kunnen niet beoordelen of de cumulatieve hulp die in een meerstapswizard wordt geboden voldoende is om een gebruiker door een complex proces te leiden. Handmatige walkthroughs zijn nodig om hiaten in de begeleiding te identificeren die alleen duidelijk worden wanneer je het formulier als geheel ervaart.
\n

\n\n

Hoe te Testen

\n

\n
1. Voer een geautomatiseerde toegankelijkheidsscan uit als basislijn. Gebruik axe DevTools (browserextensie of CLI), Lighthouse in Chrome DevTools of IBM Equal Access Checker op de pagina met het formulier. Hoewel deze tools niet direct 3.3.5-overtredingen zullen signaleren, brengen ze gerelateerde problemen aan het licht, zoals ontbrekende labels (een label-element dat niet aan een invoer is gekoppeld), ontbrekende aria-describedby-doelen of ontoegankelijke tooltip-implementaties. Door deze basisproblemen eerst op te lossen, zorg je ervoor dat wanneer contextgevoelige hulp wordt toegevoegd, deze ook technisch toegankelijk is.
\n
2. Controleer elk formulierveld handmatig op de beschikbaarheid van hulp. Stel voor elk invoerveld de vragen: (a) Legt het label op zichzelf volledig uit welke invoer vereist is, inclusief eventuele formaatvereisten? (b) Is er aanvullende helptekst zichtbaar naast het veld? (c) Is er een help-icoon, tooltip of uitklapbare sectie die verdere begeleiding biedt? (d) Is er een link naar relevante helpinhoud? Als het antwoord op al deze vragen nee is, en het veld enige ambiguïteit heeft, is dit een schending van 3.3.5.
\n
3. Test de toetsenbordtoegankelijkheid van alle hulpmechanismen. Doorloop het formulier met alleen een toetsenbord (geen muis). Controleer of elke tooltip, help-icoon, uitklapbare beschrijving of helplink bereikbaar en activeerbaar is via het toetsenbord. Tooltips moeten verschijnen bij focus én bij hover. Helpknoppen moeten met Enter of Spatie kunnen worden geactiveerd. Elk hulpmechanisme dat alleen met een muis bereikbaar is, faalt deze test.
\n
4. Test met NVDA + Firefox. Navigeer naar elk formulierveld met Tab. Luister naar wat NVDA aankondigt voor elk veld — kondigt het het label aan? Kondigt het een geassocieerde beschrijving aan (via aria-describedby)? Activeer eventuele help-iconen of tooltips en controleer of de inhoud wordt aangekondigd. Probeer gekoppelde helpinhoud te bereiken en verifieer dat deze betrekking heeft op het huidige veld.
\n
5. Test met VoiceOver + Safari (macOS of iOS). Gebruik VoiceOver om door het formulier te navigeren. Gebruik op macOS Tab om tussen velden te bewegen en luister naar de volledige aankondiging voor elk veld. Gebruik op iOS veegnavigatie. Controleer of alle met invoer geassocieerde helpinhoud wordt voorgelezen en of hulpactiveringen (knoppen, links) toegankelijk en correct gelabeld zijn door VoiceOver.
\n
6. Test met JAWS + Chrome. Gebruik de formuliermodus van JAWS (activeer met Enter wanneer je op een formulierelement staat). Navigeer tussen velden met Tab en controleer of JAWS geassocieerde instructies en beschrijvingen voorleest. Gebruik de virtuele cursor van JAWS om te controleren of helpinhoud die buiten standaard labelassociaties is geplaatst ook bereikbaar is.
\n
7. Voer een cognitieve walkthrough uit. Vraag een persoon die niet bekend is met het formulier (of simuleer dit door het formulier na een pauze opnieuw te bekijken) om te proberen het zonder externe begeleiding in te vullen. Noteer elk moment waarop diegene aarzelt, een vraag stelt of een fout maakt door onduidelijke verwachtingen. Elk van deze punten is een kandidaat voor verbeterde contextgevoelige hulp onder 3.3.5.
\n

\n\n

Hoe te Herstellen

\n

Onduidelijk tekstveld zonder uitleg — Onjuist

\n

<!-- No help provided for an ambiguous field expecting a specific format -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input type='text' id='tc-kimlik' name='tc-kimlik'>

\n

Onduidelijk tekstveld met inline-hulp — Juist

\n

<!-- Inline description associated via aria-describedby gives format guidance before the user types -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input\n  type='text'\n  id='tc-kimlik'\n  name='tc-kimlik'\n  aria-describedby='tc-kimlik-help'\n  autocomplete='off'\n  maxlength='11'\n>\n<p id='tc-kimlik-help'>\n  Nüfus cüzdanınızda yer alan 11 haneli TC Kimlik Numaranızı giriniz.\n  (Enter your 11-digit Turkish National ID number as shown on your ID card.)\n</p>

\n\n

Help-icoon-tooltip niet toegankelijk voor toetsenbordgebruikers — Onjuist

\n

<!-- Tooltip only shown on mouseover; keyboard users and screen reader users cannot access it -->\n<label for='iban'>IBAN <span class='help-icon' title='What is IBAN?'>?</span></label>\n<input type='text' id='iban' name='iban'>

\n

Help-icoon-tooltip toegankelijk voor alle gebruikers — Juist

\n

<!-- Button with aria-expanded controls a help panel; accessible via keyboard and screen readers -->\n<label for='iban'>IBAN</label>\n<button\n  type='button'\n  aria-expanded='false'\n  aria-controls='iban-help'\n  class='help-toggle'\n  aria-label='Help: What is an IBAN?'\n>\n  ?\n</button>\n<input type='text' id='iban' name='iban' aria-describedby='iban-help'>\n<div id='iban-help' hidden>\n  <p>\n    IBAN (International Bank Account Number) is a 26-character code starting\n    with "TR" used to identify your Turkish bank account. You can find it\n    in your bank's mobile app under Account Details.\n  </p>\n</div>\n<!-- JavaScript toggles aria-expanded and the hidden attribute on button click/keypress -->

\n\n

Complex meerstapsformulier zonder stapsgewijze begeleiding — Onjuist

\n

<!-- Step 2 of a 4-step application with no explanation of what documents are needed -->\n<h2>Step 2: Upload Documents</h2>\n<label for='doc-upload'>Upload File</label>\n<input type='file' id='doc-upload' name='doc-upload'>

\n

Complex meerstapsformulier met contextuele staphulp — Juist

\n\n

(Content truncated due to token limit — please retry this article.)