WCAG 1.3.5: Identifiera inmatningssyfte

Vad denna regel innebär

WCAG 1.3.5 — Identify Input Purpose är ett kriterium på nivå AA som introducerades i WCAG 2.1 och förts vidare in i WCAG 2.2. Det kräver att varje <input>-, <select>- eller <textarea>-element som samlar in information om användaren måste ha sitt syfte kommunicerat programmatiskt, så att webbläsare och hjälpmedel kan identifiera och agera på detta syfte automatiskt.

Mekanismen för att uppfylla detta kriterium är attributet autocomplete, kombinerat med rätt token-värde från den officiella lista som definieras i HTML-specifikationen. När ett fält samlar in en användares namn, e-postadress, telefonnummer, postadress, kreditkortsnummer eller liknande personuppgifter måste attributet autocomplete ha ett värde som korrekt beskriver fältets syfte — till exempel autocomplete="given-name" för ett fält för förnamn, eller autocomplete="email" för ett e-postfält.

Kriteriet gäller specifikt för inmatningar som samlar in information om användaren själv. Det gäller inte för fält där en användare matar in data om någon annan (till exempel ett resebokningsformulär som frågar efter en passagerares namn när användaren bokar för någon annan), och det gäller inte heller för fält där autofyll skulle skapa en säkerhetsrisk — såsom engångslösenord eller CAPTCHA-liknande utmaningar, som legitimt kan använda autocomplete="off" eller autocomplete="one-time-code".

För att bli godkänd krävs att: (1) varje fält inom kriteriets omfattning har ett autocomplete-attribut; och (2) värdet på detta attribut är en giltig, igenkänd token från HTML-autofyllspecifikationen — inte en godtycklig sträng, inte ett tomt värde där ett meningsfullt krävs, och inte en felstavad token. Ett fel uppstår när ett fält inom kriteriets omfattning saknar autocomplete-attribut, har autocomplete="off" utan motivering, eller har en ogiltig token såsom autocomplete="firstname" (den korrekta token är given-name) eller autocomplete="phone" (den korrekta token är tel).

Den fullständiga listan över giltiga autocomplete-tokens underhålls av WHATWG HTML Living Standard och inkluderar värden för namn (given-name, family-name, additional-name), adresser (street-address, address-line1, postal-code, country-name), kontaktinformation (email, tel, tel-national), inloggningsuppgifter (username, current-password, new-password), betalningsuppgifter (cc-name, cc-number, cc-exp, cc-csc) och mer. Tokens kan också föregås av sektionsidentifierare (t.ex. section-billing) samt nyckelord för leverans eller fakturering för att hantera flera adressgrupper på en och samma sida.

Varför det är viktigt

Detta kriterium finns främst för att gynna användare med kognitiva funktionsnedsättningar, inklusive personer med dyslexi, minnesnedsättningar, uppmärksamhetsstörningar och inlärningssvårigheter. För dessa användare kan det vara en betydande kognitiv belastning att fylla i ett komplext kassaflöde korrekt — med separata fält för förnamn, efternamn, gatuadress, stad, postnummer, telefon och betalningsuppgifter. När autocomplete-tokens är korrekta kan webbläsare förifylla fält från användarens sparade profil med en enda interaktion, vilket dramatiskt minskar friktion och risken för fel.

Användare med motoriska funktionsnedsättningar — inklusive personer med begränsad handfunktion som använder switch-styrning, ögonstyrningsprogram eller sug- och blås-enheter — har lika stor nytta. För dessa användare är skrivande långsamt, ansträngande och ibland smärtsamt. Autofyll som fungerar tillförlitligt kan förvandla en tio minuter lång prövning till en nästan omedelbar uppgift. Enligt Världshälsoorganisationen lever cirka 1,3 miljarder människor globalt med någon form av betydande funktionsnedsättning, och motoriska nedsättningar som påverkar finmotoriken i händerna är bland de vanligaste.

Utöver autofyll gör korrekta autocomplete-tokens det möjligt för webbläsare och hjälpmedel att presentera anpassade ikoner, etiketter eller förstärkta inmatningsgränssnitt — till exempel att automatiskt visa ett telefonknappsats för ett tel-fält på en mobil enhet, eller visa en kreditkortsikon för ett cc-number-fält. Lösenordshanterare, som är kritiska hjälpmedel för användare med minnesnedsättningar, förlitar sig också på dessa tokens för att identifiera och fylla i fält för inloggningsuppgifter korrekt.

Föreställ dig ett scenario i verkligheten: en användare med cerebral pares fyller i en ansökan om statliga förmåner. Formuläret har tolv fält som täcker namn, adress, nationellt ID och kontaktuppgifter. Utan korrekta autocomplete-värden måste varje fält skrivas in manuellt. En enda felstavad token — till exempel autocomplete="surname" istället för autocomplete="family-name" — räcker för att hindra webbläsaren från att känna igen fältet, vilket gör att användaren måste skriva sitt efternamn tecken för tecken. Med korrekta tokens kan hela formuläret autofyllas på några sekunder, vilket minskar både ansträngning och felgrad.

Det finns också användbarhets- och konverteringsfördelar för organisationer: forskning visar konsekvent att formulär som är kompatibla med autofyll har lägre avhoppsfrekvens och högre slutförandefrekvens, vilket innebär att åtgärdande av autocomplete-tokens inte bara är en tillgänglighetsförbättring utan också en direkt affärsförbättring.

Relaterade Axe-core-regler

• autocomplete-valid — Detta är den primära axe-core-regeln för WCAG 1.3.5. Den inspekterar varje <input>-, <select>- och <textarea>-element som har ett autocomplete-attribut och kontrollerar om attributets värde är en igenkänd, giltig token från HTML-autofyllspecifikationen. Regeln flaggar element där token är felstavad (t.ex. given name med ett mellanslag istället för ett bindestreck), där ett icke-standardiserat proprietärt värde har använts (t.ex. autocomplete="first-name"), eller där token-ordningen i ett värde med flera tokens är felaktig (t.ex. när ett fältnamn placeras före ett obligatoriskt sektionsprefix). Regeln flaggar inte fält som helt saknar ett autocomplete-attribut — den situationen kräver manuell granskning — eftersom axe-core inte programmatiskt kan avgöra om ett visst fält omfattas av kriteriet (dvs. om det samlar in information om användaren).
• Varför manuell testning också krävs — Automatiserade verktyg som axe-core kan bara validera att ett befintligt autocomplete-värde är syntaktiskt korrekt; de kan inte avgöra om den valda token korrekt beskriver fältets syfte. Till exempel skulle ett fakturerings-telefonfält med autocomplete="email" klara den automatiserade regeln (eftersom email är en giltig token) men skulle inte uppfylla kriteriet eftersom token inte matchar fältets faktiska syfte. På samma sätt kan automatiserade verktyg inte identifiera fält som saknar ett autocomplete-attribut men borde ha ett, eftersom det kräver mänsklig bedömning baserad på kontext att avgöra om ett fält samlar in personuppgifter om användaren. Manuell granskning av varje formulärfält som samlar in användarspecifik data är därför avgörande för full efterlevnad av 1.3.5.

Hur man testar

1. Kör en automatiserad skanning med axe DevTools eller Lighthouse. Öppna sidan som innehåller formuläret i Chrome eller Firefox. I axe DevTools, klicka på "Analyze" och filtrera resultaten efter regel-ID:t autocomplete-valid. I Lighthouse, kör en tillgänglighetsgranskning och leta efter överträdelser som refererar till autocomplete. Notera varje flaggat element och dokumentera de ogiltiga token-värden som rapporteras. Åtgärda varje flaggat element och skanna om för att bekräfta att felet är löst.
2. Identifiera manuellt alla fält inom kriteriets omfattning. Gå igenom formuläret och lista varje fält som samlar in information om den aktuella användaren — namnfält, adressfält, e-post, telefon, betalningsuppgifter, inloggningsuppgifter. För varje fält, verifiera att ett autocomplete-attribut finns och att dess token matchar fältets faktiska syfte enligt listan över HTML-autofylltokens. Fält som samlar in information om andra personer ligger utanför kriteriets omfattning och kan uteslutas.
3. Testa webbläsarens autofyllbeteende. I Chrome eller Firefox, säkerställ att webbläsaren har en sparad profil (Inställningar > Autofill). Navigera till formulärsidan och klicka i det första fältet för personuppgifter. Bekräfta att webbläsaren presenterar ett autofyllförslag och att val av detta fyller i rätt fält med rätt värden. Upprepa för adressfält, betalningsfält och fält för inloggningsuppgifter. Om autofyll inte föreslår värden eller fyller i fel fält är autocomplete-tokens sannolikt felaktiga.
4. Testa med en kombination av skärmläsare och webbläsare. Med NVDA och Firefox, navigera till varje formulärfält med Tab-tangenten. NVDA ska läsa upp fältets etikett och syfte; vissa kombinationer av skärmläsare och webbläsare kommer också att läsa upp autocomplete-syftet. Med VoiceOver på macOS (Safari), navigera mellan fält med Tab och lyssna efter att VoiceOver meddelar att autofyll är tillgängligt. Med JAWS och Chrome, tabba på liknande sätt genom fälten och bekräfta att JAWS meddelar förväntad fältkontext. Även om skärmläsare inte alltid uttryckligen meddelar autocomplete-tokens, bekräftar du genom att säkerställa att autofyll fungerar korrekt i kombination med tangentbordsnavigering att det programmatiska syftet exponeras.
5. Inspektera autocomplete-attribut i webbläsarens DevTools. Högerklicka på varje formulärfält och välj "Inspect." I panelen Elements, bekräfta att autocomplete-attributet finns och att dess värde exakt matchar en giltig token. Var särskilt uppmärksam på värden med flera tokens — till exempel autocomplete="shipping street-address" — och bekräfta att token-ordningen följer specifikationen (sektionsnamn, sedan "shipping" eller "billing", sedan fältnamn).

Hur man åtgärdar

Namnfält — Felaktigt

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

Namnfält — Korrekt

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

Adressformulär med fakturerings- och leveranssektioner — Felaktigt

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

Adressformulär med fakturerings- och leveranssektioner — Korrekt

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

Telefonfält — Felaktigt

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

Telefonfält — Korrekt

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

Inloggningsuppgifter — Felaktigt

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

Inloggningsuppgifter — Korrekt

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

Vanliga misstag

• Att använda autocomplete="firstname" eller autocomplete="first-name" istället för den korrekta token given-name". Dessa icke-standardiserade värden känns inte igen av webbläsare eller hjälpmedel även om de verkar logiska. Använd alltid de exakta tokens från HTML-autofyllspecifikationen.
• Att använda autocomplete="phone" istället för autocomplete="tel". Ordet "phone" är inte en giltig token. Specifikationen använder tel för ett fullständigt telefonnummer, och tel-national, tel-area-code, tel-local för delarna av ett telefonnummer.
• Att sätta autocomplete="off" på fält för inloggningsuppgifter som en missriktad säkerhetsåtgärd. Moderna webbläsare och WCAG-specifikationen erkänner båda att det skapar verkliga hinder för användare med funktionsnedsättningar att förhindra autofyll på inloggningsformulär, och att det inte på något meningsfullt sätt förbättrar säkerheten. Använd autocomplete="username" och autocomplete="current-password" istället.
• Att helt utelämna autocomplete-attributet på fält för personuppgifter, i tron att webbläsaren kommer att härleda syftet från fältnamnet eller etiketten. Webbläsare använder heuristik för att gissa fältsyfte, men dessa är opålitliga och inkonsekventa mellan olika webbläsare. Tydliga tokens krävs för en garanterat tillgänglig upplevelse.
• Att använda autocomplete="address" istället för de specifika adress-subtokens. Det finns ingen address-token i specifikationen. Du måste använda street-address, address-line1, address-line2, address-level1 (delstat/län), address-level2 (stad) och postal-code var för sig.
• Att placera nyckelorden för leverans eller fakturering i fel ordning i värden med flera tokens. Den korrekta ordningen är: valfritt sektionsprefix (t.ex. section-billing), sedan valfritt nyckelord för leverans/fakturering, sedan fältnamns-token. Att skriva autocomplete="street-address billing" är ogiltigt; den korrekta formen är autocomplete="billing street-address".
• Att bara tillämpa autocomplete på synliga fält och ignorera dolda eller dynamiskt visade fält. Fält som initialt är dolda men visas genom användarinteraktion (såsom ytterligare adressrader eller valfria fält) måste också ha korrekta autocomplete-tokens när de blir aktiva.
• Att använda JavaScript för att dynamiskt ta bort eller skriva över autocomplete-attributet efter sidladdning. Vissa formulärbibliotek eller UI-ramverk återställer inmatningsattribut när komponenter monteras eller renderas om, vilket oavsiktligt tar bort autocomplete-tokens. Verifiera alltid att attributet finns kvar i den levande DOM:en efter att all JavaScript har körts.
• Att anta att type="email" eller type="tel" på ett input-fält är tillräckligt för att kommunicera syfte utan autocomplete. Även om type ger viss information är autocomplete-attributet en separat, explicit signal som krävs av WCAG 1.3.5 och används på ett annat sätt av webbläsare och hjälpmedel.
• Att använda samma autocomplete-token på två olika fält som samlar in olika data. Till exempel förvirrar det webbläsare att märka både ett fält för jobb-e-post och ett fält för privat e-post med autocomplete="email", och kan leda till felaktig autofyll. Använd sektionsprefix (t.ex. section-work email respektive section-personal email) för att särskilja dem.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i Official Gazette nr 32933 den 21 juni 2025, fastställer bindande tillgänglighetskrav för ett brett spektrum av organisationer som är verksamma i Turkiet. Cirkuläret kräver överensstämmelse med WCAG 2.2 på nivå AA som grundstandard för digitala tjänster, vilket direkt inkluderar WCAG 1.3.5 — Identify Input Purpose.

De enhetstyper som omfattas av cirkuläret är mycket omfattande. Offentliga institutioner och statliga myndigheter måste uppfylla dessa standarder för alla medborgarorienterade digitala tjänster. Privata aktörer som omfattas inkluderar e-handelsplattformar, banker och finansiella tjänsteleverantörer, sjukhus och vårdgivare, teleoperatörer med 200,000 eller fler abonnenter, licensierade resebyråer, privata persontransportföretag och privata utbildningsinstitutioner som auktoriserats av Ministry of National Education (MoNE). Den praktiska innebörden är att i princip varje större konsumentinriktad digital produkt i Turkiet — från bankappar till kassor i nätbutiker till vårdbokningsportaler — måste ha korrekt implementerade autocomplete-tokens på alla inmatningsfält för personuppgifter.

För WCAG 1.3.5 specifikt innebär detta att alla turkiska kassaflöden för e-handel, formulär för öppnande av bankkonton, formulär för patientregistrering på sjukhus eller formulär för telekomabonnemang som samlar in användarinformation såsom namn, adress, telefonnummer eller betalningsuppgifter måste inkludera giltiga autocomplete-attributvärden på varje relevant inmatningsfält. Underlåtenhet att göra detta utgör en bristande överensstämmelse på nivå AA och kan hindra en organisation från att få eller behålla Accessibility Logo (Erişilebilirlik Logosu), det officiella märke som utfärdas av Ministry of Family and Social Services och som intygar att en organisations digitala tjänster uppfyller tillgänglighetsstandarder.

Accessibility Logo har både anseendemässig och regulatorisk tyngd, och organisationer på konkurrensutsatta konsumentmarknader — såsom e-handel och banksektorn — har starka incitament att uppnå och behålla den. Eftersom WCAG 1.3.5 är enkel att implementera (att lägga till eller korrigera autocomplete-attributvärden kräver inga arkitektoniska förändringar) men ger betydande nytta för användare med kognitiva och motoriska funktionsnedsättningar, utgör den en av de mest värdefulla och minst arbetskrävande tillgänglighetsförbättringarna en organisation kan göra i jakten på full överensstämmelse på nivå AA enligt cirkulär 2025/10.

Organisationer bör granska alla formulär på sina digitala egendomar — inklusive mobila webbgränssnitt och responsiva layouter — och etablera en utvecklingspolicy som kräver korrekta autocomplete-tokens som en standarddel av varje formulärimplementation. Detta bör upprätthållas genom automatiserad testning i CI/CD-pipelines med hjälp av verktyg som axe-core, så att regressioner fångas innan de når produktion.