WCAG 1.3.5: Identificeer invoerdoel

Wat Deze Regel Betekent

WCAG 1.3.5 — Identify Input Purpose is een criterium op niveau AA dat is geïntroduceerd in WCAG 2.1 en overgenomen in WCAG 2.2. Het vereist dat elk <input>-, <select>- of <textarea>-element dat informatie over de gebruiker verzamelt, zijn doel programmatisch gecommuniceerd krijgt, zodat browsers en ondersteunende technologieën dat doel automatisch kunnen identificeren en erop kunnen reageren.

Het mechanisme om aan dit criterium te voldoen is het autocomplete-attribuut, gecombineerd met de juiste tokenwaarde uit de officiële lijst die is gedefinieerd in de HTML-specificatie. Wanneer een veld de naam, het e-mailadres, telefoonnummer, postadres, creditcardnummer of vergelijkbare persoonlijke gegevens van een gebruiker verzamelt, moet het autocomplete-attribuut een waarde bevatten die het doel van dat veld nauwkeurig beschrijft — bijvoorbeeld autocomplete="given-name" voor een voornaamveld, of autocomplete="email" voor een e-mailveld.

Het criterium is specifiek van toepassing op invoervelden die informatie over de gebruiker zelf verzamelen. Het is niet van toepassing op velden waarin een gebruiker gegevens invoert over iemand anders (bijvoorbeeld een reisboekingsformulier dat vraagt naar de naam van een passagier wanneer de gebruiker boekt namens een andere persoon), en ook niet op velden waarbij autocomplete een beveiligingsrisico zou creëren — zoals eenmalige wachtwoorden of CAPTCHA-achtige uitdagingen, die legitiem autocomplete="off" of autocomplete="one-time-code" kunnen gebruiken.

Een voldoende beoordeling vereist dat: (1) elk invoerveld binnen de scope een autocomplete-attribuut heeft; en (2) de waarde van dat attribuut een geldige, erkende token is uit de HTML-autofill-specificatie — geen willekeurige string, geen lege waarde waar een betekenisvolle waarde vereist is, en geen verkeerd gespelde token. Een onvoldoende beoordeling treedt op wanneer een invoerveld binnen de scope geen autocomplete-attribuut heeft, autocomplete="off" heeft zonder rechtvaardiging, of een ongeldige token heeft zoals autocomplete="firstname" (de juiste token is given-name) of autocomplete="phone" (de juiste token is tel).

De volledige lijst met geldige autocomplete-tokens wordt beheerd door de WHATWG HTML Living Standard en omvat waarden voor namen (given-name, family-name, additional-name), adressen (street-address, address-line1, postal-code, country-name), contactinformatie (email, tel, tel-national), inloggegevens (username, current-password, new-password), betalingsgegevens (cc-name, cc-number, cc-exp, cc-csc) en meer. Tokens kunnen ook worden voorafgegaan door sectie-identificaties (bijv. section-billing) en verzend- of factureringssleutelwoorden om meerdere adresgroepen op één pagina te ondersteunen.

Waarom Het Belangrijk Is

Dit criterium bestaat in de eerste plaats om gebruikers met cognitieve beperkingen te ondersteunen, waaronder mensen met dyslexie, geheugenstoornissen, aandachtsstoornissen en leerstoornissen. Voor deze gebruikers kan het correct invullen van een complex afrekenformulier — met aparte velden voor voornaam, achternaam, straatadres, stad, postcode, telefoon en betalingsgegevens — een aanzienlijke cognitieve belasting vormen. Wanneer autocomplete-tokens correct zijn, kunnen browsers velden vooraf invullen vanuit het opgeslagen profiel van de gebruiker met één enkele interactie, waardoor de wrijving en de kans op fouten drastisch afnemen.

Gebruikers met motorische beperkingen — waaronder mensen met beperkte handfunctie die gebruikmaken van switch-toegang, oogvolgsoftware of sip-and-puff-apparaten — profiteren in gelijke mate. Typen is voor deze gebruikers traag, inspannend en soms pijnlijk. Autofill die betrouwbaar werkt, kan een beproeving van tien minuten veranderen in een vrijwel onmiddellijke taak. Volgens de Wereldgezondheidsorganisatie leven wereldwijd ongeveer 1,3 miljard mensen met een vorm van significante beperking, en motorische beperkingen die de fijne handmotoriek beïnvloeden behoren tot de meest voorkomende.

Naast autofill maken correcte autocomplete-tokens het mogelijk dat browsers en ondersteunende technologieën aangepaste pictogrammen, labels of verrijkte invoerinterfaces tonen — bijvoorbeeld automatisch een telefoon­toetsenblok weergeven voor een tel-veld op een mobiel apparaat, of een creditcardafbeelding tonen voor een cc-number-veld. Wachtwoordmanagers, die cruciale toegankelijkheidshulpmiddelen zijn voor gebruikers met geheugenstoornissen, vertrouwen ook op deze tokens om inlogvelden correct te identificeren en in te vullen.

Denk aan een scenario uit de praktijk: een gebruiker met cerebrale parese vult een aanvraag voor overheidsuitkeringen in. Het formulier heeft twaalf velden voor naam, adres, nationaal ID en contactgegevens. Zonder correcte autocomplete-waarden moet elk veld handmatig worden getypt. Eén verkeerd gespelde token — bijvoorbeeld autocomplete="surname" in plaats van autocomplete="family-name" — is al genoeg om te voorkomen dat de browser het veld herkent, waardoor de gebruiker de achternaam letter voor letter moet typen. Met correcte tokens kan het hele formulier in enkele seconden automatisch worden ingevuld, wat zowel de inspanning als het aantal fouten vermindert.

Er zijn ook voordelen op het gebied van gebruiksvriendelijkheid en conversieratio voor organisaties: onderzoek laat consequent zien dat formulieren die compatibel zijn met autofill lagere uitvalpercentages en hogere voltooiingspercentages hebben, wat betekent dat het corrigeren van autocomplete-tokens niet alleen een toegankelijkheidsverbetering is, maar ook een directe zakelijke verbetering.

Gerelateerde Axe-core-regels

• autocomplete-valid — Dit is de primaire axe-core-regel voor WCAG 1.3.5. Deze inspecteert elk <input>-, <select>- en <textarea>-element dat een autocomplete-attribuut heeft en controleert of de waarde van het attribuut een erkende, geldige token is uit de HTML-autofill-specificatie. De regel markeert elementen waarbij de token verkeerd is gespeld (bijv. given name met een spatie in plaats van een koppelteken), waarbij een niet-standaard, propriëtaire waarde is gebruikt (bijv. autocomplete="first-name"), of waarbij de tokenvolgorde in een waarde met meerdere tokens onjuist is (bijv. een veldnaam vóór een vereiste sectieprefix plaatsen). De regel markeert velden niet die helemaal geen autocomplete-attribuut hebben — die situatie vereist handmatige beoordeling — omdat axe-core niet programmatisch kan bepalen of een bepaald veld binnen de scope van het criterium valt (d.w.z. of het informatie over de gebruiker verzamelt).
• Waarom handmatig testen ook nodig is — Geautomatiseerde tools zoals axe-core kunnen alleen valideren dat een aanwezig autocomplete-attribuut syntactisch correct is; ze kunnen niet bepalen of de gekozen token het doel van het veld nauwkeurig beschrijft. Een facturatie-telefoonveld met autocomplete="email" zou bijvoorbeeld slagen voor de geautomatiseerde regel (omdat email een geldige token is), maar zou niet aan het criterium voldoen omdat de token niet overeenkomt met het werkelijke doel van het veld. Evenzo kunnen geautomatiseerde tools geen velden identificeren die een autocomplete-attribuut missen maar er wel een zouden moeten hebben, omdat bepalen of een veld persoonlijke informatie over de gebruiker verzamelt menselijk oordeel vereist op basis van context. Handmatige beoordeling van elk formulierveld dat gebruikersspecifieke gegevens verzamelt is daarom essentieel voor volledige naleving van 1.3.5.

Hoe te Testen

1. Voer een geautomatiseerde scan uit met axe DevTools of Lighthouse. Open de pagina met het formulier in Chrome of Firefox. Klik in axe DevTools op "Analyze" en filter de resultaten op de regel-ID autocomplete-valid. Voer in Lighthouse een toegankelijkheidsaudit uit en zoek naar overtredingen die naar autocomplete verwijzen. Noteer elk gemarkeerd element en leg de gerapporteerde ongeldige tokenwaarden vast. Los elk gemarkeerd element op en scan opnieuw om de oplossing te bevestigen.
2. Identificeer handmatig alle invoervelden binnen de scope. Bekijk het formulier en maak een lijst van elk veld dat informatie over de huidige gebruiker verzamelt — naamvelden, adresvelden, e-mail, telefoon, betalingsgegevens, inloggegevens. Controleer voor elk veld of er een autocomplete-attribuut aanwezig is en of de token overeenkomt met het werkelijke doel van het veld volgens de HTML-autofill-tokenlijst. Velden die informatie over andere personen verzamelen, vallen buiten de scope en kunnen worden uitgesloten.
3. Test het autofill-gedrag van de browser. Zorg er in Chrome of Firefox voor dat de browser een opgeslagen profiel heeft (Settings > Autofill). Navigeer naar de formulierpagina en klik in het eerste veld met persoonlijke informatie. Bevestig dat de browser een autofill-suggestie toont en dat het selecteren daarvan de juiste velden met de juiste waarden invult. Herhaal dit voor adresvelden, betalingsvelden en inlogvelden. Als autofill geen waarden voorstelt of de verkeerde velden invult, zijn de autocomplete-tokens waarschijnlijk onjuist.
4. Test met een combinatie van schermlezer en browser. Navigeer met NVDA en Firefox naar elk formulierveld met de Tab-toets. NVDA zou het label en het doel van het veld moeten aankondigen; sommige combinaties van schermlezer en browser kondigen ook het autocomplete-doel aan. Navigeer met VoiceOver op macOS (Safari) door velden met Tab en luister of VoiceOver de beschikbaarheid van autofill aankondigt. Tab met JAWS en Chrome op dezelfde manier door de velden en bevestig dat JAWS de verwachte veldcontext aankondigt. Hoewel schermlezers niet altijd expliciet autocomplete-tokens aankondigen, bevestigt het controleren dat autofill correct werkt in combinatie met toetsenbordnavigatie dat het programmatische doel wordt blootgelegd.
5. Inspecteer autocomplete-attributen in de DevTools van de browser. Klik met de rechtermuisknop op elk formulierveld en selecteer "Inspect." Bevestig in het Elements-paneel dat het autocomplete-attribuut aanwezig is en dat de waarde exact overeenkomt met een geldige token. Let in het bijzonder op waarden met meerdere tokens — bijvoorbeeld autocomplete="shipping street-address" — en controleer of de tokenvolgorde de specificatie volgt (sectienaam, vervolgens "shipping" of "billing", vervolgens veldnaam).

Hoe te Herstellen

Naamvelden — Onjuist

<!-- Invalid: uses non-standard token 'firstname' instead of 'given-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='firstname'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='surname'>

Naamvelden — Correct

<!-- Valid: uses the exact WHATWG-specified tokens 'given-name' and 'family-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='given-name'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='family-name'>

Adresformulier met factuur- en verzendsecties — Onjuist

<!-- Invalid: missing autocomplete attributes entirely on address fields -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' placeholder='Street Address'>
  <input type='text' name='bill_city' placeholder='City'>
  <input type='text' name='bill_postal' placeholder='Postal Code'>
</fieldset>

Adresformulier met factuur- en verzendsecties — Correct

<!-- Valid: autocomplete tokens include 'billing' prefix and correct field names -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' autocomplete='billing street-address' placeholder='Street Address'>
  <input type='text' name='bill_city' autocomplete='billing address-level2' placeholder='City'>
  <input type='text' name='bill_postal' autocomplete='billing postal-code' placeholder='Postal Code'>
</fieldset>

Telefoonveld — Onjuist

<!-- Invalid: uses 'phone' which is not a recognized autocomplete token -->
<label for='tel'>Phone Number</label>
<input type='text' id='tel' name='telephone' autocomplete='phone'>

Telefoonveld — Correct

<!-- Valid: 'tel' is the correct autocomplete token for a full phone number -->
<label for='tel'>Phone Number</label>
<input type='tel' id='tel' name='telephone' autocomplete='tel'>

Inloggegevens — Onjuist

<!-- Invalid: autocomplete='off' prevents password managers and autofill from working -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='off'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='off'>

Inloggegevens — Correct

<!-- Valid: 'username' and 'current-password' allow password managers to function correctly -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='username'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='current-password'>

Veelvoorkomende Fouten

• autocomplete="firstname" of autocomplete="first-name" gebruiken in plaats van de juiste token given-name". Deze niet-standaardwaarden worden niet herkend door browsers of ondersteunende technologieën, ook al lijken ze logisch. Gebruik altijd de exacte tokens uit de HTML-autofill-specificatie.
• autocomplete="phone" gebruiken in plaats van autocomplete="tel". Het woord "phone" is geen geldige token. De specificatie gebruikt tel voor een volledig telefoonnummer, en tel-national, tel-area-code, tel-local voor subdelen van een telefoonnummer.
• autocomplete="off" instellen op inlogvelden als een misplaatste beveiligingsmaatregel. Moderne browsers en de WCAG-specificatie erkennen beide dat het voorkomen van autofill op inlogformulieren echte barrières creëert voor gebruikers met beperkingen en de beveiliging niet wezenlijk verbetert. Gebruik in plaats daarvan autocomplete="username" en autocomplete="current-password".
• Het autocomplete-attribuut volledig weglaten op velden met persoonlijke gegevens, in de veronderstelling dat de browser het doel zal afleiden uit de veldnaam of het label. Browsers gebruiken heuristieken om het velddoel te raden, maar die zijn onbetrouwbaar en inconsistent tussen browsers. Expliciete tokens zijn vereist voor een gegarandeerde, toegankelijke ervaring.
• autocomplete="address" gebruiken in plaats van de specifieke adres-subtokens. Er is geen address-token in de specificatie. U moet afzonderlijk street-address, address-line1, address-line2, address-level1 (staat/provincie), address-level2 (stad) en postal-code gebruiken.
• Verzend- of factureringssleutelwoorden in de verkeerde volgorde plaatsen in waarden met meerdere tokens. De juiste volgorde is: optionele sectieprefix (bijv. section-billing), vervolgens optioneel shipping/billing-sleutelwoord, vervolgens de veldnaamtoken. autocomplete="street-address billing" schrijven is ongeldig; de juiste vorm is autocomplete="billing street-address".
• autocomplete alleen toepassen op zichtbare velden en verborgen of dynamisch getoonde velden negeren. Velden die aanvankelijk verborgen zijn maar via gebruikersinteractie worden getoond (zoals extra adresregels of optionele velden) moeten ook de juiste autocomplete-tokens hebben wanneer ze actief worden.
• JavaScript gebruiken om het autocomplete-attribuut dynamisch te verwijderen of te overschrijven na het laden van de pagina. Sommige formulierbibliotheken of UI-frameworks resetten invoerattributen wanneer componenten mounten of opnieuw renderen, waardoor autocomplete-tokens onbedoeld worden verwijderd. Controleer altijd dat het attribuut aanwezig blijft in de live DOM nadat alle JavaScript is uitgevoerd.
• Aannemen dat type="email" of type="tel" op een input voldoende is om het doel te communiceren zonder autocomplete. Hoewel type enige informatie biedt, is het autocomplete-attribuut een afzonderlijk, expliciet signaal dat vereist is door WCAG 1.3.5 en op een andere manier wordt gebruikt door browsers en ondersteunende technologieën.
• Dezelfde autocomplete-token gebruiken op twee verschillende velden die verschillende gegevens verzamelen. Het labelen van zowel een werk-e-mailveld als een persoonlijk e-mailveld met autocomplete="email" bijvoorbeeld, verwart browsers en kan leiden tot onjuiste autofill. Gebruik sectieprefixen (bijv. section-work email vs. section-personal email) om onderscheid te maken.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt bindende toegankelijkheidseisen vast voor een breed scala aan organisaties die in Turkije actief zijn. De circulaire verplicht conformiteit met WCAG 2.2 op niveau AA als basisnorm voor digitale diensten, wat WCAG 1.3.5 — Identify Input Purpose — rechtstreeks omvat.

De typen entiteiten die onder de circulaire vallen, zijn zeer uiteenlopend. Overheidsinstellingen en -organen moeten aan deze normen voldoen voor alle digitale diensten die op burgers zijn gericht. Tot de particuliere organisaties die onder de circulaire vallen, behoren e-commerceplatforms, banken en financiële dienstverleners, ziekenhuizen en zorgaanbieders, telecomoperators met 200,000 of meer abonnees, erkende reisbureaus, particuliere personenvervoerders en particuliere onderwijsinstellingen die zijn gemachtigd door het Ministry of National Education (MoNE). De praktische implicatie is dat vrijwel elk belangrijk consumentgericht digitaal product in Turkije — van bankapps tot online retail-afrekenprocessen tot portalen voor zorgafspraken — correct geïmplementeerde autocomplete-tokens moet hebben op alle invoervelden voor persoonlijke gegevens.

Voor WCAG 1.3.5 specifiek betekent dit dat elk Turks e-commerce-afrekenformulier, formulier voor het openen van een bankrekening, ziekenhuisformulier voor patiëntenregistratie of telecom-abonnementsformulier dat gebruikersinformatie verzamelt zoals naam, adres, telefoonnummer of betalingsgegevens, geldige autocomplete-attribuutwaarden moet bevatten op elk relevant invoerveld. Het niet doen hiervan vormt een non-conformiteit op niveau AA en kan voorkomen dat een organisatie het Accessibility Logo (Erişilebilirlik Logosu) verkrijgt of behoudt, het officiële keurmerk dat wordt uitgegeven door het Ministry of Family and Social Services en dat certificeert dat de digitale diensten van een organisatie aan de toegankelijkheidsnormen voldoen.

Het Accessibility Logo heeft zowel reputatie- als regelgevingsgewicht, en organisaties in concurrerende consumentenmarkten — zoals e-commerce en bankwezen — hebben sterke prikkels om het te behalen en te behouden. Omdat WCAG 1.3.5 eenvoudig te implementeren is (het toevoegen of corrigeren van autocomplete-attribuutwaarden vereist geen architecturale wijzigingen) en toch aanzienlijke voordelen biedt voor gebruikers met cognitieve en motorische beperkingen, vertegenwoordigt het een van de toegankelijkheidsverbeteringen met de hoogste waarde en de laagste inspanning die een organisatie kan doorvoeren in de zoektocht naar volledige conformiteit op niveau AA onder de circulaire 2025/10.

Organisaties zouden alle formulieren op hun digitale eigendommen — inclusief mobiele webinterfaces en responsieve lay-outs — moeten auditen en een ontwikkelbeleid moeten opstellen dat correcte autocomplete-tokens vereist als standaardonderdeel van elke formulierimplementatie. Dit moet worden afgedwongen via geautomatiseerd testen in CI/CD-pijplijnen met tools zoals axe-core, zodat regressies worden onderschept voordat ze in productie terechtkomen.