WCAG 3.3.7: Redundante invoer

Wat Deze Regel Betekent

WCAG 3.3.7 Redundant Entry is een succescriterium op Niveau A dat is geïntroduceerd in WCAG 2.2. Het stelt: "Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated or available for the user to select." In eenvoudige bewoordingen: als een gebruiker tijdens een sessie zijn e‑mailadres, verzendadres, geboortedatum of een ander stuk informatie al heeft ingevoerd, mag je interface hen niet dwingen dit opnieuw te typen binnen hetzelfde proces of dezelfde flow.

Het criterium is breed van toepassing op elke meerstapsformulieren, checkoutproces, registratie‑wizard, afspraakboekingsflow of vergelijkbare sequentie waarin gegevens die in de ene stap worden verzameld later opnieuw nodig kunnen zijn. De betrokken interacties omvatten tekstvelden, dropdowns, selectievakjes, keuzerondjes en elke andere formulierelement dat door de gebruiker aangeleverde gegevens verzamelt. Wanneer hetzelfde stuk informatie opnieuw vereist is, moet het ofwel automatisch worden vooraf ingevuld met de eerder opgegeven waarde, of het moet worden aangeboden als een selecteerbare optie zodat de gebruiker kan bevestigen in plaats van opnieuw in te voeren.

Een pass voor dit criterium ziet er als volgt uit: een factuuradresformulier dat vooraf is ingevuld met het verzendadres dat de gebruiker op het vorige scherm heeft ingevoerd, of een bevestigingsstap die het eerder ingevoerde e‑mailadres van de gebruiker weergeeft in een alleen‑lezen veld. Een ander patroon dat voldoet is een selectievakje met het label "Mijn factuuradres is hetzelfde als mijn verzendadres" dat, wanneer aangevinkt, de waarden automatisch overneemt. Een fail ziet er als volgt uit: een meerstapsregistratieflow die in stap 1 om een e‑mailadres vraagt en in stap 3 opnieuw, zonder het tweede veld vooraf in te vullen, of een verzekeringsclaimformulier dat op meerdere afzonderlijke schermen om de naam en polisnummer van de aanvrager vraagt zonder automatische invulling.

WCAG 3.3.7 definieert twee officiële uitzonderingen. De eerste uitzondering is van toepassing wanneer het opnieuw invoeren van de informatie essentieel is voor het proces — bijvoorbeeld, een veld "Bevestig je nieuwe wachtwoord" vraagt gebruikers bewust om hetzelfde wachtwoord twee keer te typen als beveiliging tegen typefouten, en dit wordt beschouwd als een essentiële veiligheidscontrole. De tweede uitzondering is van toepassing wanneer de eerder ingevoerde informatie niet langer geldig is — bijvoorbeeld, als een sessie is verlopen of een product niet meer op voorraad is en de gebruiker een proces met nieuwe gegevens opnieuw moet starten. Buiten deze uitzonderingen is redundante invoer een conformiteitsfout.

Waarom Het Belangrijk Is

Redundante invoer legt een onevenredig zware last op gebruikers voor wie typen traag, pijnlijk, foutgevoelig of cognitief belastend is. Begrijpen wie wordt getroffen helpt ontwikkelaars en ontwerpers inzien waarom dit criterium meer is dan een gemakfunctie — het is een echte barrière voor veel mensen.

Gebruikers met motorische beperkingen, zoals mensen met tremoren, dwarslaesies of aandoeningen als ALS of multiple sclerose, kunnen afhankelijk zijn van switch‑toegang, mondstokken, oogvolgsoftware of spraakbesturing om tekst in te voeren. Voor deze gebruikers kan het typen van zelfs een kort adres meerdere minuten en aanzienlijke fysieke inspanning kosten. Verplicht worden om die invoer te herhalen is niet alleen irritant — het kan fysieke pijn veroorzaken of de taak praktisch onmogelijk maken binnen één sessie.

Gebruikers met cognitieve beperkingen, waaronder dyslexie, aandachtsstoornissen, traumatisch hersenletsel en dementiegerelateerde aandoeningen, kunnen moeite hebben om te onthouden wat ze drie stappen geleden hebben ingevoerd. Informatie meerdere keren nauwkeurig overnemen uit het geheugen of van een papieren document verhoogt de foutpercentages en uitval aanzienlijk. Volgens de Wereldgezondheidsorganisatie leven wereldwijd meer dan 1 miljard mensen met een of andere vorm van beperking, en cognitieve beperkingen vormen een van de grootste en meest onderbediende segmenten in toegankelijkheidsplanning.

Gebruikers met verschillen in de bovenste ledematen, waaronder mensen die geboren zijn met of later verschillen in ledematen hebben gekregen, typen veel langzamer en gebruiken mogelijk alternatieve invoerapparaten. Elke extra vereiste toetsaanslag vermenigvuldigt de belasting voor deze gebruikers.

Denk aan een scenario uit de echte wereld: een gebruiker met reumatoïde artritis boekt een medische afspraak via het online portaal van een ziekenhuis. Op scherm 1 voert diegene het nationale ID‑nummer, de naam, geboortedatum en contacttelefoonnummer in. Op scherm 3 vraagt het portaal opnieuw om naam en geboortedatum om het patiëntendossier te bevestigen. Deze gebruiker moet moeizaam informatie opnieuw typen die slechts twee schermen eerder is verstrekt, met het risico op typefouten die dossiers kunnen laten mismatchen, en ervaart onnodige fysieke belasting. Een eenvoudige vooraf invulling of automatische populatie van die velden zou de barrière volledig wegnemen.

Naast toegankelijkheid verbetert het elimineren van redundante invoer de conversieratio’s, vermindert het het afbreken van formulieren en verlaagt het het aantal supporttickets als gevolg van invoerfouten — het levert meetbare zakelijke waarde op naast inclusief ontwerp.

Gerelateerde Axe-core Regels

WCAG 3.3.7 is een criterium dat handmatige tests vereist. Er bestaat momenteel geen geautomatiseerde axe‑core‑regel die overtredingen van redundante invoer betrouwbaar kan detecteren, omdat geautomatiseerde tools de semantische relatie tussen gegevens die in meerdere stappen of pagina’s van een dynamisch proces zijn ingevoerd niet kunnen begrijpen. Ze hebben geen inzicht in welke informatie in een vorige stap is verzameld, welke informatie in de huidige stap wordt gevraagd, of of die twee stukjes informatie logisch identiek zijn. Alleen een menselijke tester die de volledige flow doorloopt kan observeren en beoordelen of dezelfde gegevens twee keer worden gevraagd zonder vooraf invulling.

• Handmatige test vereist (WCAG 2.2 nieuw): axe‑core en andere geautomatiseerde toegankelijkheidsscanners analyseren de DOM van één paginastatus tegelijk. Ze kunnen door de gebruiker ingevoerde waarden niet volgen over meerdere paginaladingen of formulierstappen, kunnen veldlabels niet over stappen heen vergelijken om semantische duplicatie te identificeren, en kunnen niet beoordelen of een vooraf invulmechanisme correct functioneert. Testers moeten meerstapsprocessen handmatig doorlopen, vastleggen welke gegevens ze in elke stap invoeren en bij elke volgende stap verifiëren of eerder verstrekte gegevens ofwel automatisch worden ingevuld of selecteerbaar zijn. Elke tool die beweert 3.3.7‑overtredingen automatisch te detecteren, zou een extreem hoog percentage fout-negatieven opleveren en mag niet worden gebruikt als enige testmethode.

Hoe te Testen

1. Geautomatiseerde scan als startpunt: Voer axe DevTools, Lighthouse of de Accsible‑auditor uit op elke afzonderlijke stap van je meerstapsproces. Hoewel deze tools 3.3.7‑overtredingen niet direct zullen markeren, brengen ze gerelateerde problemen aan het licht, zoals ontbrekende autocomplete‑attributen, niet‑gelabelde formuliervelden en andere 3.3.x‑criteriumfouten die vaak samen voorkomen. Documenteer elk formulierveld dat je in elke stap vindt.
2. Breng de gegevensvereisten over de stappen in kaart: Maak vóór handmatig testen een eenvoudige tabel of spreadsheet met elke stap in het proces en alle gegevensvelden die daarin worden verzameld. Identificeer vervolgens elk veldlabel of gegevenstype dat in meer dan één stap voorkomt. Deze mappingoefening brengt potentiële overtredingen aan het licht nog voordat je een browser opent.
3. Handmatige walkthrough — desktop: Voltooi met een standaardmuis en ‑toetsenbord het volledige meerstapsproces (bijv. checkout, registratie, indiening van een claim). Voer realistische waarden in elk veld in. Wanneer je bij een stap komt die in je kaart als een dubbel veld verschijnt, controleer dan of het veld vooraf is ingevuld met je eerdere invoer, of dat er een selecteerbare optie beschikbaar is die je eerdere invoer presenteert. Als geen van beide het geval is, noteer dan een fout. Herhaal deze test met een schermlezer (NVDA met Firefox, JAWS met Chrome, VoiceOver met Safari) om te bevestigen dat vooraf ingevulde waarden correct worden aangekondigd en dat selectie‑elementen voor eerder ingevoerde waarden met het toetsenbord bereikbaar zijn.
4. Handmatige walkthrough — mobiel: Voltooi dezelfde flow op iOS (VoiceOver + Safari) en Android (TalkBack + Chrome). Let erop of native autocomplete‑ of autofill‑functies door de applicatie worden onderdrukt, wat onbedoeld barrières van redundante invoer kan creëren, zelfs als de ontwikkelaar autocomplete bedoeld had als hulp.
5. Test de uitzonderingen: Identificeer velden die bewust om dubbele invoer vragen (bijv. wachtwoordbevestiging, e‑mail opnieuw invoeren). Controleer of deze kwalificeren als essentiële beveiligings‑ of validatiecontroles onder de WCAG‑uitzondering en niet simpelweg redundante velden zijn die moeten worden verwijderd of vooraf ingevuld.
6. Test met autocomplete uitgeschakeld: Sommige gebruikers schakelen autocomplete van de browser uit om privacyredenen. Test of het eigen vooraf invulmechanisme van de applicatie (server‑side of JavaScript‑gestuurd) nog steeds correct functioneert wanneer autocomplete van de browser is uitgeschakeld, zodat het criterium wordt gehaald onafhankelijk van het gedrag van de browser.

Hoe te Oplossen

Meerstapscheckout — hetzelfde adres vereist op twee schermen — Onjuist

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

Meerstapscheckout — hetzelfde adres vereist op twee schermen — Juist

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

Registratiewizard die zonder rechtvaardiging twee keer om e‑mail vraagt — Onjuist

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

Registratiewizard — e‑mail vooraf ingevuld vanuit sessiegegevens — Juist

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

Afspraak boeken — patiëntgegevens opnieuw gevraagd in summarystap — Onjuist

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

Afspraak boeken — geboortedatum getoond als alleen-lezen bevestiging — Juist

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

Veelvoorkomende Fouten

• Meerstapsformulieren bouwen als onafhankelijke pagina’s zonder gedeelde sessiestatus, waardoor er geen mechanisme is om waarden uit eerdere stappen mee te nemen — de meest fundamentele architecturale fout die tot 3.3.7‑overtredingen leidt.
• Een selectievakje "same as shipping" aanbieden maar de factuurvelden niet daadwerkelijk invullen wanneer het is aangevinkt, waardoor gebruikers adresgegevens nog steeds handmatig moeten typen, zelfs nadat ze hebben aangegeven dat deze moeten overeenkomen.
• Velden vooraf invullen bij het laden van de pagina maar ze vervolgens leegmaken bij een validatiefout, zodat een gebruiker die in een latere stap een fout maakt alle eerder verstrekte gegevens opnieuw moet invoeren wanneer diegene terugkeert om deze te corrigeren.
• Sessiegegevens onveilig opslaan en ervoor kiezen deze uit te schakelen in plaats van het beveiligingsprobleem op te lossen, wat resulteert in een gebroken vooraf invulervaring die technisch gezien een 3.3.7‑overtreding vormt.
• De uitzondering voor wachtwoordbevestiging gebruiken als rechtvaardiging om gebruikers e‑mailadressen opnieuw te laten invoeren, terwijl e‑mailbevestiging geen essentiële beveiligingscontrole is en niet onder de WCAG‑uitzondering valt.
• Overgenomen waarden niet via verborgen velden doorgeven in server‑side gerenderde formulieren, waardoor vooraf ingevulde waarden verloren gaan wanneer een gebruiker met de browsergeschiedenisknoppen heen en weer navigeert tussen stappen.
• Uitsluitend vertrouwen op autofill van de browser om aan dit criterium te voldoen, zonder een applicatieniveau‑mechanisme voor vooraf invullen te implementeren — gebruikers die autofill om privacyredenen uitschakelen hebben dan geen conforme route door het proces.
• Een veld vooraf invullen maar het als disabled in plaats van readonly instellen, waardoor de waarde in de meeste browsers wordt uitgesloten van formulierverzending, het proces breekt en mogelijk herinvoer afdwingt.
• De volledige end‑to‑end‑flow niet testen met gebruikers die spraakinvoersoftware zoals Dragon NaturallySpeaking gebruiken, waarbij redundante velden kunnen vereisen dat hetzelfde verbale dicteercommando meerdere keren wordt herhaald — een aanzienlijke belasting die in ontwikkelaarstests gemakkelijk over het hoofd wordt gezien.
• Dit criterium behandelen alsof het alleen van toepassing is op adresvelden, terwijl het evenzeer geldt voor elke herhaalde gegevens, waaronder namen, telefoonnummers, nationale ID‑nummers, polisnummers, datums en alle andere door de gebruiker verstrekte informatie die meer dan eens in hetzelfde proces wordt gevraagd.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Presidentiële Circulaire 2025/10 van Turkije, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, verplicht naleving van webtoegankelijkheid voor een breed scala aan publieke en private entiteiten die in Turkije actief zijn. WCAG 3.3.7 Redundant Entry is een criterium op Niveau A onder WCAG 2.2, en conformiteit op Niveau A is de verplichte basislijn onder deze circulaire. Dit betekent dat elke betrokken entiteit die een website, webapplicatie of digitale dienst exploiteert, gebruikers niet mag verplichten informatie opnieuw in te voeren die zij al binnen hetzelfde proces hebben verstrekt — zonder uitzondering — op straffe van niet‑naleving.

De circulaire stelt een gefaseerde implementatietijdlijn vast: publieke instellingen moeten binnen één jaar na publicatie van de circulaire conformiteit bereiken, terwijl entiteiten in de private sector in de betrokken categorieën twee jaar hebben om te voldoen.

De typen entiteiten die onder de circulaire vallen, zijn uitgebreid en omvatten e‑commerceplatforms en marktplaatsen, alle publieke instellingen en overheidsinstanties, banken en aanbieders van financiële diensten, ziekenhuizen en zorgportalen (zowel publiek als privaat), telecombedrijven met 200,000 of meer abonnees, erkende reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministry of National Education (MoNE). Voor al deze entiteiten moeten meerstaps digitale processen — checkoutflows op e‑commercesites, patiëntenregistratie op ziekenhuisportalen, het openen van rekeningen op bankplatforms, inschrijfformulieren op schoolwebsites — worden geaudit en gecorrigeerd om elke vorm van redundante invoer te elimineren.

In de praktijk brengt deze regelgeving WCAG 3.3.7‑naleving duidelijk binnen het werkterrein van inkoop‑, product‑ en juridische teams in de digitale economie van Turkije. Een Turks e‑commerceplatform dat bijvoorbeeld een meerstapscheckout exploiteert die op het ene scherm om een afleveradres vraagt en op het volgende om een factuuradres zonder een optie voor vooraf invullen of kopiëren aan te bieden, is in directe overtreding van zowel WCAG 2.2 Niveau A als de Presidentiële Circulaire. Evenzo is een afspraakboekingsportaal van een staatsziekenhuis dat patiënten vraagt hun identiteitsnummer of geboortedatum op meerdere schermen opnieuw in te voeren, niet‑conform. Organisaties die onder de circulaire vallen, moeten een end‑to‑end‑audit van alle meerstapsprocessen prioriteren als onderdeel van hun conformiteitstraject, waarbij het elimineren van redundante invoer wordt behandeld als een vereiste engineeringtaak, niet als een optionele verbetering.