WCAG 3.3.7: Redundant Entry

Vad den här regeln innebär

WCAG 3.3.7 Redundant Entry är ett framgångskriterium på nivå A som introducerades i WCAG 2.2. Det säger: "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." Med enklare ord: om en användare redan har skrivit in sin e-postadress, leveransadress, födelsedatum eller någon annan information under en session, får ditt gränssnitt inte tvinga dem att skriva in den igen inom samma process eller flöde.

Kriteriet gäller brett för alla flerstegiga formulär, kassaflöden, registreringsguider, bokningsflöden för tidsbokning eller liknande sekvenser där data som samlas in i ett steg kan behövas igen i ett senare steg. De berörda beteendena inkluderar textfält, rullgardinsmenyer, kryssrutor, alternativknappar och andra formulärkontroller som samlar in användarens data. När samma information krävs igen måste den antingen fyllas i automatiskt med det tidigare angivna värdet, eller erbjudas som ett valbart alternativ så att användaren kan bekräfta i stället för att skriva in den på nytt.

Ett godkänt exempel för detta kriterium ser ut så här: ett faktureringsadressformulär som är förifyllt med leveransadressen som användaren angav på föregående skärm, eller ett bekräftelsesteg som visar användarens tidigare angivna e-postadress i ett skrivskyddat fält. Ett annat godkänt mönster är en kryssruta med etiketten "Min faktureringsadress är samma som min leveransadress" som, när den är markerad, kopierar över värdena automatiskt. Ett underkänt exempel ser ut så här: ett flerstegigt registreringsflöde som frågar efter en e-postadress i steg 1 och igen i steg 3 utan att förifylla det andra fältet, eller ett försäkringsanspråksformulär som frågar efter den sökandes namn och försäkringsnummer på flera separata skärmar utan någon autofyll.

WCAG 3.3.7 definierar två officiella undantag. Det första undantaget gäller när återinmatning av informationen är väsentlig för processen — till exempel ber ett fält "Bekräfta ditt nya lösenord" medvetet användare att skriva samma lösenord två gånger som ett skydd mot felskrivningar, och detta anses vara en väsentlig säkerhetskontroll. Det andra undantaget gäller när den tidigare angivna informationen inte längre är giltig — till exempel om en session har löpt ut eller en produkt har tagit slut i lager och användaren måste starta om en process med färska data. Utanför dessa undantag är redundant inmatning ett bristande uppfyllande av kriteriet.

Varför det är viktigt

Redundant inmatning belastar oproportionerligt användare vars tillstånd gör skrivande långsamt, smärtsamt, felbenäget eller kognitivt ansträngande. Att förstå vilka som påverkas hjälper utvecklare och designers att uppskatta varför detta kriterium är mer än en bekvämlighetsfunktion — det är ett verkligt hinder för många människor.

Användare med motoriska funktionsnedsättningar, såsom personer med skakningar, ryggmärgsskador eller tillstånd som ALS eller multipel skleros, kan vara beroende av switch-styrning, munpinnar, ögonspårningsprogram eller röststyrning för att skriva text. För dessa användare kan det ta flera minuter och betydande fysisk ansträngning att skriva även en kort adress. Att tvingas upprepa den inmatningen är inte bara irriterande — det kan orsaka fysisk smärta eller göra uppgiften praktiskt taget omöjlig i en enda session.

Användare med kognitiva funktionsnedsättningar, inklusive dyslexi, uppmärksamhetsstörningar, traumatiska hjärnskador och demensrelaterade tillstånd, kan ha svårt att minnas vad de skrev in tre steg tidigare. Att skriva av information korrekt från minnet eller från ett pappersdokument flera gånger ökar felprocenten och avhoppen kraftigt. Enligt Världshälsoorganisationen lever över 1 miljard människor världen över med någon form av funktionsnedsättning, och kognitiva funktionsnedsättningar utgör en av de största och mest underbetjänade grupperna i tillgänglighetsplanering.

Användare med skillnader i övre extremiteter, inklusive de som är födda med eller har förvärvat skillnader i armar eller händer, skriver mycket långsammare och kan använda alternativa inmatningsenheter. Varje ytterligare obligatoriskt tangenttryck multiplicerar bördan för dessa användare.

Fundera på ett scenario i verkligheten: en användare med reumatoid artrit bokar en läkartid via ett sjukhus onlineportal. På skärm 1 anger hen sitt personnummer, namn, födelsedatum och kontakttelefonnummer. På skärm 3 ber portalen återigen om namn och födelsedatum för att bekräfta patientjournalen. Den här användaren måste mödosamt skriva in information som hen angav bara två skärmar tidigare, riskera felskrivningar som kan leda till felaktig matchning av journaler och uppleva onödig fysisk belastning. En enkel förifyllning eller automatisk ifyllning av dessa fält skulle helt ta bort hindret.

Utöver tillgänglighet förbättrar borttagning av redundant inmatning konverteringsgrader, minskar avhopp i formulär och minskar supportärenden orsakade av inmatningsfel — vilket ger mätbart affärsvärde tillsammans med inkluderande design.

Relaterade Axe-core-regler

WCAG 3.3.7 är ett kriterium som kräver manuell testning. Ingen automatiserad axe-core-regel finns för närvarande som på ett tillförlitligt sätt kan upptäcka överträdelser av redundant inmatning, eftersom automatiserade verktyg inte kan förstå den semantiska relationen mellan data som skrivs in över flera steg eller sidor i en dynamisk process. De har ingen kännedom om vilken information som samlades in i ett tidigare steg, vilken information som efterfrågas i det aktuella steget eller om dessa två informationsmängder är logiskt identiska. Endast en mänsklig testare som går igenom hela flödet kan observera och utvärdera om samma data efterfrågas två gånger utan förifyllning.

• Manuell testning krävs (ny i WCAG 2.2): axe-core och andra automatiska tillgänglighetsskannrar analyserar DOM:en för ett enskilt sidtillstånd åt gången. De kan inte spåra användarens inmatade värden över flera sidladdningar eller formulärsteg, kan inte jämföra fältetiketter över steg för att identifiera semantisk duplicering och kan inte utvärdera om en förifyllningsmekanism fungerar korrekt. Testare måste manuellt gå igenom flerstegiga processer, dokumentera vilken data de skriver in i varje steg och verifiera i varje efterföljande steg om tidigare angiven data antingen fylls i automatiskt eller är valbar. Alla verktyg som påstår sig automatiskt upptäcka överträdelser av 3.3.7 skulle ge en extremt hög andel falska negativa och bör inte användas som enda testmetod.

Hur man testar

1. Automatisk skanning som startpunkt: Kör axe DevTools, Lighthouse eller Accsible-auditorn på varje enskilt steg i din flerstegsprocess. Även om dessa verktyg inte direkt flaggar överträdelser av 3.3.7, kommer de att lyfta fram relaterade problem som saknade autocomplete-attribut, oetiketterade formulärfält och andra 3.3.x-kriteriebrister som ofta förekommer samtidigt. Dokumentera alla formulärfält du hittar i varje steg.
2. Kartlägg datakraven över stegen: Innan manuell testning, skapa en enkel tabell eller kalkylblad som listar varje steg i processen och alla datafält som samlas in. Identifiera sedan alla fältetiketter eller datatyper som förekommer i mer än ett steg. Denna kartläggningsövning lyfter fram potentiella överträdelser redan innan du öppnar en webbläsare.
3. Manuell genomgång — skrivbord: Använd en vanlig mus och ett vanligt tangentbord och genomför hela flerstegsprocessen (t.ex. kassa, registrering, anspråksinlämning). Ange realistiska värden i varje fält. När du kommer till ett steg som i din karta framstår som ett duplicerat fält, kontrollera om fältet är förifyllt med din tidigare inmatning eller om ett valbart alternativ som presenterar din tidigare inmatning finns tillgängligt. Om inget av detta stämmer, registrera ett fel. Upprepa detta test med en skärmläsare (NVDA med Firefox, JAWS med Chrome, VoiceOver med Safari) för att bekräfta att förifyllda värden annonseras korrekt och att valkontroller för tidigare angivna värden är nåbara med tangentbord.
4. Manuell genomgång — mobil: Genomför samma flöde på iOS (VoiceOver + Safari) och Android (TalkBack + Chrome). Var uppmärksam på om inbyggda autocomplete- eller autofyllfunktioner undertrycks av applikationen, vilket oavsiktligt kan skapa hinder med redundant inmatning även om utvecklaren avsåg att autocomplete skulle hjälpa.
5. Testa undantagen: Identifiera alla fält som medvetet ber om dubbel inmatning (t.ex. lösenordsbekräftelse, skriv in e-post igen). Verifiera att dessa kvalificerar sig som väsentliga säkerhets- eller valideringskontroller enligt WCAG-undantaget och inte bara är redundanta fält som bör tas bort eller förifyllas.
6. Testa med autocomplete inaktiverat: Vissa användare inaktiverar webbläsarens autocomplete av integritetsskäl. Testa om applikationens egen förifyllningsmekanism (server-side eller JavaScript-driven) fortfarande fungerar korrekt när webbläsarens autocomplete är avstängd, så att kriteriet uppfylls oberoende av webbläsarens beteende.

Hur man åtgärdar

Flerstegskassa — samma adress krävs på två skärmar — Felaktigt

<!-- 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>

Flerstegskassa — samma adress krävs på två skärmar — Korrekt

<!-- 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>

Registreringsguide som frågar efter e-post två gånger utan motivering — Felaktigt

<!-- 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>

Registreringsguide — e-post förifylld från sessionsdata — Korrekt

<!-- 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>

Tidsbokning — patientuppgifter efterfrågas igen i sammanfattningssteget — Felaktigt

<!-- 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 -->

Tidsbokning — födelsedatum visas som skrivskyddad bekräftelse — Korrekt

<!-- 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>

Vanliga misstag

• Att bygga flerstegiga formulär som fristående sidor utan delat sessionsläge, så att det inte finns någon mekanism för att föra vidare värden som skrivits in i tidigare steg — det mest grundläggande arkitektoniska misstaget som leder till 3.3.7-fel.
• Att tillhandahålla en kryssruta "samma som leveransadress" men inte faktiskt fylla i faktureringsfälten när den är markerad, vilket tvingar användare att ändå skriva in adressuppgifter manuellt även efter att de har angett att de ska vara samma.
• Att förifylla fält vid sidladdning men sedan rensa dem vid valideringsfel, så att en användare som gör ett misstag i ett senare steg måste skriva in all tidigare angiven data igen när hen återvänder för att rätta det.
• Att lagra sessionsdata på ett osäkert sätt och välja att inaktivera den i stället för att åtgärda säkerhetsproblemet, vilket resulterar i en trasig förifyllningsupplevelse som tekniskt sett utgör ett 3.3.7-fel.
• Att använda undantaget för lösenordsbekräftelse som motivering för att tvinga användare att skriva in e-postadresser igen, när e-postbekräftelse inte är en väsentlig säkerhetskontroll och inte kvalificerar sig enligt WCAG-undantaget.
• Att inte föra vidare överförda värden via dolda fält i serverrenderade formulär, vilket gör att förifyllda värden går förlorade när en användare navigerar fram och tillbaka genom steg med webbläsarens historikknappar.
• Att enbart förlita sig på webbläsarens autofyll för att uppfylla detta kriterium, utan att implementera förifyllning på applikationsnivå — användare som inaktiverar autofyll av integritetsskäl har då ingen överensstämmande väg genom processen.
• Att förifylla ett fält men sätta det som disabled i stället för readonly, vilket gör att värdet utesluts från formulärinlämningen i de flesta webbläsare, vilket bryter processen och potentiellt tvingar till återinmatning.
• Att inte testa hela end-to-end-flödet med användare som använder röstinmatningsprogram som Dragon NaturallySpeaking, där redundanta fält kan kräva att samma dikteringskommando upprepas flera gånger, en betydande börda som är lätt att förbise i utvecklartestning.
• Att behandla detta kriterium som om det bara gäller adressfält, när det i lika hög grad gäller all upprepad data, inklusive namn, telefonnummer, personnummer, försäkringsnummer, datum och all annan användaruppgiven information som efterfrågas mer än en gång i samma process.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentdekret 2025/10, publicerat i den officiella tidningen nr 32933 den 21 juni 2025, kräver överensstämmelse med webbtillgänglighet för ett brett spektrum av offentliga och privata aktörer som är verksamma i Turkiet. WCAG 3.3.7 Redundant Entry är ett kriterium på nivå A enligt WCAG 2.2, och överensstämmelse på nivå A är den obligatoriska basnivån enligt detta dekret. Detta innebär att alla berörda aktörer som driver en webbplats, webbapplikation eller digital tjänst inte får kräva att användare skriver in information på nytt som de redan har lämnat inom samma process — utan undantag — annars riskerar de bristande efterlevnad.

Dekretet fastställer en stegvis genomförandetidsplan: offentliga institutioner måste uppnå överensstämmelse inom ett år från dekretets publicering, medan privata aktörer i de berörda kategorierna har två år på sig att uppfylla kraven.

De aktörstyper som omfattas av dekretet är omfattande och inkluderar e-handelsplattformar och marknadsplatser, alla offentliga institutioner och statliga myndigheter, banker och finansiella tjänsteleverantörer, sjukhus och vårdportaler (både offentliga och privata), telekommunikationsföretag med 200,000 eller fler abonnenter, licensierade resebyråer, privata transportföretag och privatskolor som godkänts av Ministry of National Education (MoNE). För alla dessa aktörer måste flerstegiga digitala processer — kassaflöden på e-handelssajter, patientregistrering på sjukhusportaler, kontoöppning på bankplattformar, anmälningsformulär på skolwebbplatser — granskas och korrigeras för att eliminera alla fall av redundant inmatning.

I praktiken placerar denna reglering efterlevnad av WCAG 3.3.7 tydligt inom räckvidden för upphandlings-, produkt- och juridikteam i Turkiets digitala ekonomi. Till exempel är en turkisk e-handelsplattform som driver en flerstegskassa där en leveransadress efterfrågas på en skärm och en faktureringsadress på nästa utan att erbjuda en förifyllnings- eller kopieringsmöjlighet i direkt strid med både WCAG 2.2 nivå A och presidentdekretet. På samma sätt är en statlig sjukhusportals tidsbokningssystem som ber patienter att skriva in sitt identitetsnummer eller födelsedatum på nytt på flera skärmar icke-överensstämmande. Organisationer som omfattas av dekretet bör prioritera en end-to-end-granskning av alla flerstegsprocesser som en del av sin plan för överensstämmelse och behandla eliminering av redundant inmatning som en obligatorisk ingenjörsuppgift, inte en valfri förbättring.