WCAG 3.3.2: Etiketter eller instruktioner

Vad den här regeln innebär

WCAG framgångskriterium 3.3.2 — Etiketter eller instruktioner (Nivå A) säger: "Etiketter eller instruktioner tillhandahålls när innehåll kräver inmatning från användaren." I praktiken innebär detta att varje formulärfält, inmatningskontroll, textområde och select-element som ber användaren att ange eller välja information måste ha en synlig, meningsfull etikett eller en uppsättning instruktioner som gör fältets syfte tydligt innan användaren interagerar med det.

Kriteriet är avsiktligt brett till sin omfattning. Det täcker alla mekanismer genom vilka en användare tillhandahåller data: <input>-element av alla typer (text, email, password, number, date, checkbox, radio, file upload), <textarea>-element för flerradig text och <select>-rullgardinsmenyer. Det gäller också anpassade interaktiva kontroller byggda med ARIA-roller såsom role='combobox' eller role='listbox'.

En etikett kan tillhandahållas på flera sätt som uppfyller detta kriterium. Det mest robusta är ett programmatiskt associerat <label>-element som är visuellt närvarande och länkat till kontrollen via ett matchande for/id-par. Alternativt kan en synlig etiketttext associeras med hjälp av aria-labelledby som pekar på ett befintligt element, eller kompletterande instruktioner kan kopplas med aria-describedby. Nyckelkravet är att etiketten eller instruktionen är tillhandahållen — den måste finnas i någon form som användaren kan uppfatta. Enbart platshållartext uppfyller inte detta kriterium eftersom den försvinner så snart användaren börjar skriva, och den förmedlas inte pålitligt av alla hjälpmedel som en beständig etikett.

Ett godkänt resultat kräver att varje inmatningsfält har en etikett som är synlig (eller åtminstone programmatiskt fastställbar), finns där innan användaren åtar sig att fylla i fältet och är tillräckligt beskrivande för att förmedla vilken data som förväntas. Ett underkänt resultat uppstår när ett fält saknar etikett helt, när den enda etiketten är ett placeholder-attribut, när etiketten är visuellt närvarande men inte programmatiskt associerad, eller när instruktioner om krävt format (t.ex. "Ange datum som DD/MM/ÅÅÅÅ") helt saknas.

WCAG noterar ett snävt undantag: när ett formulär innehåller ett enda, uppenbart fält — såsom en webbplatsövergripande sökruta med en tydligt märkt skicka-knapp direkt intill — kan sammanhanget i sig ge tillräcklig instruktion. Detta undantag är dock snävt och bör inte användas som en generell motivering för att utelämna etiketter i formulär med flera fält.

Varför det är viktigt

Formuläretiketter är den enskilt mest betydelsefulla tillgänglighetsfunktionen för en bred grupp användare. Deras frånvaro skapar hinder som kan göra det omöjligt för många människor att slutföra transaktioner, registrera sig för tjänster eller kontakta en organisation.

För blinda och synsvaga användare som förlitar sig på skärmläsare annonseras ett oetiketterat fält helt enkelt som "edit text" eller "blank" utan sammanhang. Användaren har inget sätt att veta om hen ska ange sitt namn, sin e-postadress eller sitt kreditkortsnummer. Enligt Världshälsoorganisationen har cirka 2,2 miljarder människor globalt någon form av synnedsättning, och miljoner av dem använder skärmläsare som sitt primära sätt att interagera med webben.

För användare med kognitiva och inlärningssvårigheter — inklusive dyslexi, ADHD och minnesrelaterade tillstånd — är platshållartext särskilt skadlig. Eftersom platshållare försvinner vid fokus eller inmatning har en användare som pausar mitt i ett formulär ingen referens för vad som förväntades i ett fält som hen redan har börjat fylla i. Detta tvingar dem att rensa fältet för att läsa instruktionen igen, vilket skapar förvirring och frustration. Beständiga, synliga etiketter tar bort denna kognitiva börda helt.

För motoriskt nedsatta användare som navigerar med tangentbord, switch-enhet eller röststyrning har etiketter en ytterligare funktion: de tillhandahåller de talade orden som används för att aktivera ett fält via röststyrningsprogramvara såsom Dragon NaturallySpeaking. Om den synliga etiketttexten inte matchar det programmatiska tillgängliga namnet misslyckas röstkommandot tyst.

Överväg ett konkret scenario i verkligheten: en användare med nedsatt syn ansöker om en statlig förmån på en turkisk offentlig institutions portal. Formuläret använder platshållartext istället för etiketter. När användaren zoomar till 200 % för att läsa skärmen försvinner platshållarna innan de kan läsas. Användaren fyller i fälten genom att gissa och skickar in ett formulär med fel, för att sedan få ett generiskt felmeddelande utan någon indikation på vilka fält som är felaktiga. Detta scenario resulterar i utestängning från en kritisk offentlig tjänst — och det är helt förebyggbart.

Utöver tillgänglighet förbättrar etiketterade formulär SEO eftersom sökmotorers crawlers bättre kan förstå formulärets syfte, och de förbättrar användbarheten för alla användare, inklusive de på mobila enheter där små tryckytor gynnas av klickbara etikettområden som utökar aktiveringszonen för det associerade inmatningsfältet.

Relaterade Axe-core-regler

• label — Denna regel kontrollerar att varje <input>-element (förutom de med type='hidden', type='image', type='button', type='submit' och type='reset'), varje <textarea> och varje <select> har ett tillgängligt namn. Regeln flaggar element som saknar ett associerat <label>, ett aria-label-attribut, en aria-labelledby-referens eller ett title-attribut. Detta är den primära automatiserade signalen för 3.3.2-överträdelser på standardformulärkontroller.
• select-name — Denna regel riktar sig specifikt mot <select>-rullgardinselement och verifierar att de har ett icke-tomt tillgängligt namn. Utvecklare antar ibland att en rullgardinsmenys alternativ gör dess syfte självklart, men utan en etikett hör skärmläsaranvändare endast det för närvarande valda alternativets värde — vilket kan vara ett generiskt standardvärde som "Select one" — utan någon indikation på vilken kategori de väljer från. Axe flaggar <select>-element som saknar någon av de standardiserade märkningsmekanismerna.
• textarea-label — Denna regel kontrollerar <textarea>-element för ett tillgängligt namn. Flerradiga textområden används ofta för kommentarer, meddelanden eller detaljerad inmatning, men lämnas ofta oetiketterade under den felaktiga föreställningen att omgivande sammanhang är tillräckligt. Axe flaggar alla <textarea> som inte kan associeras programmatiskt med en etikett via <label for>, aria-label, aria-labelledby eller title.

Det är viktigt att förstå begränsningarna med automatiserad testning för detta kriterium. Axe-core kan upptäcka avsaknaden av en programmatisk etikett, men kan inte avgöra om en etikett som finns faktiskt är meningsfull eller korrekt. Ett fält märkt "Field 1" eller en etikett som bara lyder "*" kommer att klara automatiska kontroller samtidigt som de helt misslyckas för användare. Manuell granskning krävs alltid för att bekräfta att etiketter tydligt beskriver den förväntade inmatningen, att formatinstruktioner finns där de behövs (t.ex. datumformat, lösenordskrav) och att obligatoriska fält identifieras — helst både visuellt och programmatiskt.

Hur man testar

1. Automatisk skanning med axe DevTools eller Lighthouse: Öppna sidan som innehåller formuläret i Chrome eller Firefox. Kör webbläsartillägget axe DevTools och filtrera resultaten efter reglerna label, select-name och textarea-label. Notera varje flaggat element. Kör Google Lighthouse (Accessibility audit) som en sekundär kontroll. Exportera eller ta skärmdumpar av alla överträdelser. Kom ihåg att en ren automatisk rapport inte garanterar efterlevnad — fortsätt med manuella steg.
2. Visuell inspektion: Utan att använda någon hjälpmedelsteknik, granska varje formulärfält på sidan. Bekräfta att varje fält har en synlig, statisk etikett — inte bara en platshållare — placerad tydligt nära fältet (vanligtvis ovanför eller till vänster). Bekräfta att formatkrav (t.ex. "Lösenord måste vara minst 8 tecken") visas före eller vid inmatningstillfället, inte bara efter ett misslyckat försök att skicka formuläret. Bekräfta att obligatoriska fält identifieras med mer än enbart färg.
3. Tangentbordsnavigeringstest: Tabba genom varje formulärfält. Säkerställ att när varje fält får fokus är dess syfte omedelbart tydligt från den synliga etiketten. Inget fält ska kunna nås med tangentbord utan att en intilliggande, beständig etikett är synlig vid det tillfället.
4. Skärmläsartest med NVDA och Firefox: Öppna formuläret med NVDA igång. Tryck på Tab för att flytta genom varje interaktiv kontroll. NVDA ska annonsera etiketten, rollen (t.ex. "edit", "combo box") och eventuell status (t.ex. "required"). Om NVDA endast annonserar rollen och status utan etikett underkänns fältet. Använd NVDAs formulärläge (utlöses automatiskt på interaktiva element) för att simulera realistisk användarnavigering.
5. Skärmläsartest med VoiceOver och Safari (macOS/iOS): Aktivera VoiceOver (Command + F5 på Mac). Använd Tab eller svep för att navigera till varje formulärfält. VoiceOver ska annonsera etiketten före rollen. På iOS, tryck på varje fält och bekräfta att etiketten läses upp innan tangentbordet visas. Fält med enbart platshållare läses vanligtvis upp som platshållaren vid första fokus men blir tysta när text har matats in.
6. Skärmläsartest med JAWS och Chrome: Öppna JAWS och navigera i formuläret med Tab. Använd JAWS formulärläge. Bekräfta att varje fälts annonserade namn motsvarar dess synliga etikett exakt. Använd JAWS Insert + F1 (fält-hjälp) för att kontrollera eventuella ytterligare beskrivningar via aria-describedby.
7. Röststyrningstest med Dragon NaturallySpeaking: Aktivera Dragon och försök interagera med varje fält genom att uttala dess synliga etikett. Om den uttalade etiketten inte matchar det programmatiska tillgängliga namnet kommer fältet inte att svara på röstkommandot, vilket indikerar en mismatch som bryter mot både 3.3.2 och relaterade kriterier.

Hur man åtgärdar

Saknad etikett på ett textfält — Felaktigt

<!-- No label provided; placeholder is the only hint -->
<input type='text' name='email' placeholder='Email address' />

Saknad etikett på ett textfält — Korrekt

<!-- Visible <label> associated via matching for/id attributes.
     Placeholder may still be used as supplementary hint,
     but the label is the primary, persistent identifier. -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

Oetiketterad select-rullgardinsmeny — Felaktigt

<!-- No label; screen readers will only announce the selected option value -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Oetiketterad select-rullgardinsmeny — Korrekt

<!-- Programmatically associated label makes the field's purpose clear
     before the user opens the dropdown. -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Textarea utan etikett — Felaktigt

<!-- The textarea has no label; surrounding paragraph text is not
     programmatically associated and will not be read by screen readers
     as the field's label. -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

Textarea utan etikett — Korrekt

<!-- Using aria-labelledby to associate the existing visible heading
     with the textarea, or alternatively wrapping with a <label> element. -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

Formatinstruktioner saknas för ett datumfält — Felaktigt

<!-- Label present but no instruction about expected date format;
     users must guess whether to enter 01/06/2025 or 2025-06-01. -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

Formatinstruktioner finns för ett datumfält — Korrekt

<!-- Format instruction is visible and linked via aria-describedby
     so screen readers announce it when the field receives focus. -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

Vanliga misstag

• Att använda placeholder som den enda etiketten: Platshållartext försvinner vid inmatning, annonseras inte pålitligt som etikett av alla skärmläsare och misslyckas för användare med kognitiva funktionsnedsättningar som behöver beständig referenstext. Tillhandahåll alltid ett synligt <label> utöver eventuell platshållare.
• Att visuellt placera en etikett nära ett fält utan programmatisk association: Ett <p> eller <span> placerat visuellt ovanför ett inmatningsfält ser ut som en etikett för seende användare men ignoreras av skärmläsare. Använd <label for='id'>, aria-labelledby eller kapsla in inmatningsfältet i ett <label>-element.
• Att använda aria-label med text som inte matchar den synliga etiketten: När det programmatiska tillgängliga namnet skiljer sig från den synliga texten kan röststyrningsanvändare inte aktivera fältet genom att säga det de läser på skärmen, vilket bryter mot SC 2.5.3 (Label in Name) och skapar förvirring för skärmläsaranvändare.
• Att märka en grupp radioknappar men utelämna gruppens legend: Enskilda radioknappar kan var och en vara etiketterade med sin alternativtext, men om den övergripande frågan (t.ex. "Payment method") inte tillhandahålls via ett <fieldset> och <legend> hör användare som navigerar med tangentbord varje alternativ isolerat utan att förstå vad de väljer mellan.
• Att identifiera obligatoriska fält enbart med färg eller asterisk utan förklaring: En asterisk (*) bredvid en etikett förmedlar ingenting till skärmläsaranvändare om inte dess betydelse förklaras (t.ex. en notering högst upp i formuläret som säger "Fields marked with * are required") och obligatoriska fält också har attributet required eller aria-required='true'.
• Att utelämna formatinstruktioner tills efter ett misslyckat försök att skicka formuläret: Att visa lösenordsregler eller datumformatkrav endast i felmeddelanden efter inskickning tvingar användare att göra ett misstag innan de kan lära sig vad som förväntas. Instruktioner måste finnas före eller vid den tidpunkt då användaren interagerar med fältet.
• Att dölja etiketter med display:none eller visibility:hidden: Dessa CSS-egenskaper tar bort etiketter helt från tillgänglighetsträdet. Om en etikett måste döljas visuellt (t.ex. för en minimalistisk design), använd en visuellt dold CSS-klass som behåller elementet i tillgänglighetsträdet samtidigt som det flyttas utanför skärmen.
• Att använda title-attributet som den enda etiketten och anta att det är tillräckligt: Även om axe-core kanske inte flaggar en etikett som enbart bygger på title, visas title-attributet endast som en tooltip vid hovring och är otillgängligt för tangentbordsanvändare och mobilanvändare. Det bör användas som kompletterande beskrivning, inte som primär etikett.
• Att applicera ett enda aria-label på ett container-<div> och förvänta sig att det ska märka underordnade inmatningsfält: ARIA-etiketter på containerelement ärvs inte av deras underordnade formulärkontroller. Varje interaktiv kontroll måste märkas individuellt.
• Att misslyckas med att återassociera etiketter efter dynamiska innehållsuppdateringar: När formulärfält injiceras dynamiskt via JavaScript (t.ex. lägga till en adressrad) saknar nyligen insatta inmatningsfält ofta associerade etiketter eftersom utvecklaren bara lade till den synliga etiketttexten som ett syskonelement utan korrekt for/id-bindning.

Relation till Turkiets tillgänglighetsföreskrifter

Turkiets presidentcirkulär 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webbtillgänglighet i linje med WCAG 2.2. WCAG framgångskriterium 3.3.2 — Etiketter eller instruktioner är ett krav på Nivå A, vilket innebär att det ligger på basnivån för överensstämmelse och är bland de mest strikt genomdrivna bestämmelserna enligt cirkuläret.

Cirkuläret omfattar ett brett spektrum av enhetstyper, och tidslinjerna för efterlevnad skiljer sig åt mellan sektorer. Offentliga institutioner — inklusive ministerier, kommuner, statliga myndigheter och offentligt finansierade organisationer — måste uppnå full överensstämmelse med Nivå A inom ett år från cirkulärets publicering. Privata sektorsaktörer inom tillämpningsområdet måste uppfylla kraven inom två år. De privata sektorsaktörer som uttryckligen omfattas inkluderar e-handelsplattformar, banker och finansiella institutioner, sjukhus och privata vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor auktoriserade av Ministry of National Education (MoNE).

För alla dessa aktörer är underlåtenhet att märka formulärfält inte bara en brist i användbarhet — det utgör en direkt regulatorisk bristande efterlevnad. Formulär är allestädes närvarande i alla omfattade digitala tjänster: medborgare lämnar in ansökningar på myndighetsportaler, patienter bokar tider på sjukhusens webbplatser, kunder slutför köp på e-handelsplattformar och studenter registrerar sig via skolportaler. Var och en av dessa resor är beroende av formulär, och varje oetiketterat fält i dessa formulär är en tydlig WCAG 3.3.2-överträdelse som revisorer kan dokumentera och rapportera.

Organisationer som omfattas av cirkuläret bör behandla efterlevnad av SC 3.3.2 som ett förhandskrav för alla tillgänglighetsrevisioner eller certifieringsprocesser. Eftersom detta är ett kriterium på Nivå A kan det inte undantas eller skjutas upp — påståenden om partiell överensstämmelse som utesluter punkter på Nivå A erkänns inte. Aktörer som inte kan visa etiketterade inmatningsfält i alla sina publika formulär riskerar regulatoriska anmärkningar, offentlig rapportering av bristande efterlevnad och skadat rykte på en marknad där digitalt förtroende alltmer är kopplat till inkluderande design.

Ur ett praktiskt perspektiv är uppnåendet av 3.3.2-efterlevnad ett av de mest lättuppnåeliga och mest effektfulla stegen en organisation kan ta. Att associera etiketter med befintliga formulärkontroller kräver vanligtvis endast mindre HTML-ändringar och har ingen effekt på den visuella designen när det implementeras korrekt. För organisationer som använder Accsible's overlay SDK kan automatisk upptäckt av saknade etiketter lyfta fram dessa överträdelser under rutinmässiga skanningar och ge utvecklingsteam handlingsbar vägledning för åtgärder innan regulatoriska tidsfrister infaller.