WCAG 3.3.1: Felidentifiering

Vad den här regeln innebär

WCAG 3.3.1 Error Identification är ett framgångskriterium på nivå A under principen Förståelig. Det säger: ”Om ett inmatningsfel upptäcks automatiskt ska det objekt som innehåller felet identifieras och felet beskrivas för användaren i text.” I praktiken innebär detta att när din webbplats eller applikation automatiskt validerar användarinmatning – vid formulärskick, när ett fält tappar fokus eller i realtid – måste två saker ske om ett fel upptäcks: det specifika fältet eller kontrollen som innehåller felet måste tydligt identifieras, och felets natur måste kommuniceras med faktisk text (inte enbart färg, ikon eller ljud).

Kriteriet gäller alla situationer där inmatning samlas in från användare och validering sker automatiskt. Detta inkluderar HTML-formulärelement som <input>, <select>, <textarea>, samt anpassade interaktiva widgets byggda med ARIA. Det omfattar klient-sidevalidering som triggas av JavaScript, inbyggd webbläsarvalidering med attribut som required, pattern, minlength och type, samt server-sidevalidering vars resultat visas efter att sidan laddats om eller injiceras dynamiskt i DOM:en.

Ett godkänt resultat kräver att: (1) varje fält med fel är programmatiskt associerat med ett felmeddelande – vanligtvis via aria-describedby eller aria-errormessage – så att hjälpmedel kan läsa upp det; (2) felmeddelandet är i klartext synlig i gränssnittet (inte dold för seende användare); och (3) texten tydligt beskriver vad som gick fel, inte bara att något gick fel. Till exempel är ”E-postadress är obligatorisk” en giltig felbeskrivning, medan att enbart visa en röd kantlinje eller en utropsteckenikon utan textalternativ är ett underkännande.

Ett underkännande inträffar när: fel endast indikeras genom färgförändringar (röd kantlinje utan text), fel endast annonseras via role="alert" utan att ange vilket fält som påverkas, felmeddelandetexten är tom eller alltför generell (t.ex. ”Ogiltig inmatning”), eller felmeddelanden finns i DOM:en men inte är programmatiskt länkade till motsvarande fält så att skärmläsare inte kan koppla dem.

WCAG 3.3.1 gäller inte när ingen automatisk upptäckt sker – till exempel om ett formulär skickas in och servern helt enkelt laddar om sidan utan någon indikation på vad som gick fel; det är ett separat användbarhetsproblem men faller utanför detta kriteriums strikta tillämpningsområde. Men om ditt system utför automatisk upptäckt (vilket i princip alla moderna formulär gör) är kriteriet fullt tillämpligt. Det finns inga undantag definierade i själva kriteriet för specifika inmatningstyper eller användningsfall.

Varför det är viktigt

Felidentifiering påverkar direkt flera grupper av personer med funktionsnedsättning på betydande sätt. För blinda och synsvaga användare som förlitar sig på skärmläsare som NVDA, JAWS eller VoiceOver kommunicerar en röd kantlinje eller en varningsikon ingenting. Om ett felmeddelande inte finns som faktisk text och inte är programmatiskt associerat med fältet med fel, kommer skärmläsaren inte att läsa upp det, och användaren kan skicka in ett formulär upprepade gånger utan att förstå varför det misslyckas. Enligt Världshälsoorganisationen har cirka 2,2 miljarder människor globalt någon form av synnedsättning, och miljoner förlitar sig dagligen på hjälpmedel för att interagera med webbinnehåll.

För användare med kognitiva funktionsnedsättningar – inklusive dyslexi, uppmärksamhetsstörning och minnesnedsättningar – skapar vaga felmeddelanden som ”Något gick fel” betydande hinder. Dessa användare har stor nytta av precisa, beskrivande feltexter som talar om exakt vilket fält som behöver korrigeras och vilket korrekt format eller värde ska vara. Till exempel är ett meddelande som ”Födelsedatum måste vara i formatet DD/MM/ÅÅÅÅ” mycket mer användbart än ”Ogiltigt datum”.

Användare med motoriska funktionsnedsättningar som navigerar med tangentbord eller brytarkontakter lägger ner betydande ansträngning på att ta sig genom ett formulär. När ett fel är otydligt eller oidentifierat måste de gå igenom hela formuläret igen för att hitta problemet, vilket kraftigt ökar den kognitiva och fysiska belastningen vid formulärifyllnad. Tydlig felidentifiering gör det möjligt för dessa användare att hoppa direkt till det problematiska fältet.

Överväg följande verkliga scenario: en turkisk medborgare försöker registrera sig på en offentlig e-tjänsteportal för att ansöka om ett funktionshinderbidrag. Formuläret kräver ett nationellt ID-nummer i ett specifikt format. Användaren, som är blind, matar in sitt ID-nummer. Vid inskickning laddas formuläret om med rödmarkerade fält men utan något associerat textfel. Skärmläsaren läser bara upp fältetiketterna igen – användaren har ingen aning om vad som gick fel eller vilket fält som är problemet. De avbryter processen helt och hållet och förlorar tillgången till en kritisk offentlig tjänst. Det är precis denna situation som WCAG 3.3.1 är utformad för att förhindra.

Utöver tillgänglighet förbättrar tydlig felidentifiering konverteringsgrad och användbarhet för alla användare. Studier inom UX-forskning visar konsekvent att beskrivande inline-felmeddelanden minskar avhopp från formulär. Ur ett SEO-perspektiv påverkar förbättrade signaler om användarengagemang – inklusive längre tid på webbplatsen och lyckade formulärinskick – sökrankningen positivt över tid.

Relaterade Axe-core-regler

WCAG 3.3.1 kräver manuell testning för fullständig verifiering. Detta beror på att automatiska verktyg kan upptäcka förekomst eller avsaknad av strukturella mönster (som aria-describedby eller aria-errormessage), men de kan inte bedöma om textinnehållet i ett felmeddelande är meningsfullt, korrekt eller tillräckligt för att hjälpa användaren att förstå och rätta felet. Ett automatiskt verktyg ser att ett role="alert"-element finns; det kan inte avgöra om meddelandet ”Fel på rad 4” på ett adekvat sätt beskriver en valideringsmiss för en skärmläsaranvändare.

• aria-required-attr: Denna axe-core-regel kontrollerar att element med vissa ARIA-roller har alla obligatoriska ARIA-attribut. Även om det inte uteslutande är en regel för felidentifiering är den relevant eftersom ett formulärfält i ett felläge som använder role="textbox" eller liknande utan de obligatoriska attributen kan misslyckas med att förmedla tillståndsinformation till hjälpmedel, vilket undergräver felkommunikationen.
• aria-valid-attr-value: Denna regel flaggar fall där ARIA-attribut refererar till ID:n som inte finns i DOM:en. Om ett fält till exempel använder aria-describedby="email-error" men inget element med id="email-error" finns, bryts kopplingen och felmeddelandet kommer inte att läsas upp av skärmläsare. Detta är ett vanligt mönsterfel för 3.3.1.
• Krav på manuell utvärdering: Testare måste manuellt utlösa valideringsfel och sedan använda en skärmläsare för att bekräfta att: fältet med fel identifieras med namn eller etikett, felbeskrivningen läses upp, meddelandet är meningsfullt och handlingsbart, och att felet inte kommuniceras enbart genom icke-textuella medel. Automatiska skanningar kan inte simulera sekvenser av användarinteraktion eller bedöma den semantiska kvaliteten på meddelandetext, vilket gör mänsklig bedömning oumbärlig för detta kriterium.

Hur man testar

1. Automatisk skanning med axe DevTools eller Lighthouse: Kör en axe DevTools-skanning på sidan som innehåller formuläret före och efter att valideringsfel har utlösts. Titta specifikt efter överträdelser relaterade till trasiga aria-describedby- eller aria-errormessage-referenser, saknade role="alert"- eller aria-live-regioner som används för dynamisk felinjektion, och formulärfält utan etiketter (vilket också förhindrar korrekt felkoppling). I Lighthouse, kontrollera Accessibility-granskningen för formulärrelaterade överträdelser. Observera att en ren automatisk rapport inte bekräftar efterlevnad av 3.3.1 – den utesluter bara vissa strukturella fel.
2. Manuellt test med tangentbordsnavigering: Använd endast tangentbord (Tabb, Skift+Tabb, Enter, Mellanslag) för att försöka skicka in formuläret med avsiktligt felaktiga eller saknade värden. Verifiera att: fokus flyttas till eller nära det första fältet med fel, varje felmeddelande är synligt i vyn, och att felmeddelandena identifierar det specifika fältet vid namn och beskriver problemet i klartext.
3. Skärmläsartest med NVDA + Firefox: Öppna formuläret i Firefox med NVDA aktivt. Skicka in formuläret med fel. Lyssna noga: meddelar NVDA vilket fält som har ett fel? Läser den upp felbeskrivningen? Tabb in i det felaktiga fältet – läser NVDA upp det associerade felmeddelandet som en del av fältets tillgängliga beskrivning? Om aria-live-regioner används, verifiera att uppspelningen inte är fördröjd eller undertryckt.
4. Skärmläsartest med VoiceOver + Safari (macOS/iOS): Upprepa samma process med VoiceOver i Safari. Använd VO+Högerpil för att läsa genom formuläret efter inskickning. Bekräfta att varje fält med fel inkluderar feltexten i sitt tillgängliga namn eller sin beskrivning. På iOS, testa med peknavigering och svepgester.
5. Skärmläsartest med JAWS + Chrome: Med JAWS igång i Chrome, skicka in formuläret med fel. Använd JAWS virtuella markör för att navigera till varje formulärfält med fel. Bekräfta att felmeddelandetexten ingår i JAWS uppläsning av fältet. Kontrollera också JAWS formulärläge, eftersom formulärläget undertrycker vissa live region-uppdateringar.
6. Granskning av färg- och icke-textuella signaler: Inspektera varje felläge visuellt. Ta bort eller inaktivera CSS tillfälligt (med webbläsarens utvecklarverktyg eller ett bokmärke) och bekräfta att felidentifiering fortfarande finns som text i DOM:en. Detta verifierar att felkommunikationen inte enbart förlitar sig på färg eller ikoner.
7. Kontroll av dynamisk injektion: För enkel-sidiga applikationer eller formulär med realtidsvalidering, använd webbläsarens utvecklarverktyg för att inspektera DOM:en efter att ett fel har utlösts. Bekräfta att felmeddelandeelementet finns i DOM:en, innehåller icke-tom text och refereras av motsvarande inmatning via aria-describedby eller aria-errormessage.

Hur man åtgärdar

Scenario 1: Fel indikeras endast med färg – Felaktigt

<!-- Fail: red border added via class, no error text associated -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' class='input-error'>
<!-- CSS sets border: 2px solid red on .input-error -->
<!-- No error message text is rendered in the DOM -->

Scenario 1: Fel indikeras endast med färg – Korrekt

<!-- Pass: error text is present, visible, and linked to the input -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-describedby='email-error'
  aria-invalid='true'
>
<!-- aria-invalid signals the error state to assistive technologies -->
<!-- aria-describedby links the input to its error message by ID -->
<p id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</p>

Scenario 2: Generell felsammanfattning utan fältidentifiering – Felaktigt

<!-- Fail: a summary alert exists but does not identify which fields failed -->
<div role='alert'>
  <p>There are errors in the form. Please correct them and try again.</p>
</div>
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' name='phone' class='is-invalid'>
<!-- No per-field error message; user cannot determine which field failed -->

Scenario 2: Generell felsammanfattning utan fältidentifiering – Korrekt

<!-- Pass: summary lists specific fields in error, and each field has inline error text -->
<div role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>2 errors found. Please fix the following:</h2>
  <ul>
    <li><a href='#phone'>Phone Number: must contain only digits and be 10 characters long</a></li>
    <li><a href='#dob'>Date of Birth: required field — please enter your date of birth</a></li>
  </ul>
</div>
<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-error'
  aria-invalid='true'
>
<!-- Inline error linked via aria-describedby -->
<p id='phone-error'>Phone Number must contain only digits and be 10 characters long.</p>

Scenario 3: Trasig aria-describedby-referens – Felaktigt

<!-- Fail: aria-describedby references an ID that does not exist in the DOM -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- The element with id='username-msg' was never rendered or was removed -->
<!-- Screen readers find no target and announce nothing for the description -->

Scenario 3: Trasig aria-describedby-referens – Korrekt

<!-- Pass: the referenced element exists in the DOM with matching ID -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- Element with matching id is present and contains descriptive text -->
<span id='username-msg'>
  Username must be between 4 and 20 characters and contain only letters and numbers.
</span>

Scenario 4: Realtidsvalideringsfel injicerat dynamiskt – Felaktigt

<!-- Fail: error injected into DOM but not associated with input; no live region -->
<label for='password'>Password</label>
<input type='password' id='password' name='password'>
<!-- After blur, JavaScript appends this element, but no aria-describedby on input -->
<div class='error-text'>Password is too short.</div>

Scenario 4: Realtidsvalideringsfel injicerat dynamiskt – Korrekt

<!-- Pass: error container pre-exists in DOM (empty), input references it; aria-live announces changes -->
<label for='password'>Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-describedby='password-error'
  aria-invalid='false'
>
<!-- Empty span present at page load; JavaScript populates text and sets aria-invalid='true' on error -->
<span id='password-error' aria-live='polite'></span>
<!-- JavaScript on blur: -->
<!-- document.getElementById('password-error').textContent = 'Password must be at least 8 characters.'; -->
<!-- document.getElementById('password').setAttribute('aria-invalid', 'true'); -->

Vanliga misstag

• Att endast använda CSS-klassändringar (t.ex. lägga till border-color: red) för att indikera fel utan motsvarande text i DOM:en. Färg ensam är inte uppfattbar för blinda användare eller användare med färgblindhet och bryter mot både 3.3.1 och 1.4.1.
• Att skriva aria-describedby på inmatningen men peka på ett ID som renderas villkorligt eller tas bort från DOM:en vid återställning av validering. Den trasiga referensen innebär att skärmläsaren inte hittar något associerat innehåll och att felet i praktiken är osynligt för användare av hjälpmedel.
• Att använda placeholder-text som det enda felmeddelandet. Placeholder-text försvinner när användaren börjar skriva, är ofta lågkontrast och läses inte pålitligt upp av alla skärmläsare som en del av fältets beskrivning vid fellägen.
• Att injicera felmeddelanden dynamiskt i DOM:en utan att säkerställa att de är associerade med sitt överordnade fält via aria-describedby. Ett visuellt intilliggande felmeddelande är inte automatiskt associerat med en inmatning – den programmatiska kopplingen måste vara explicit.
• Att visa en felöversikt på sidnivå utan att länka varje sammanfattningspost till det specifika fältet med fel. Användare av skärmläsare eller tangentbordsnavigering måste kunna gå direkt från felbeskrivningen till fältet som behöver korrigeras.
• Att sätta aria-invalid='true' på ett fält men inte tillhandahålla någon felmeddelandetext. Attributet aria-invalid signalerar att ett fält är i ett felläge men beskriver inte felet – det måste kombineras med ett beskrivande meddelande.
• Att tillhandahålla felmeddelanden som är alltför generella, såsom ”Ogiltig inmatning” eller ”Fel i fält”. Dessa beskrivningar förklarar inte vad som är fel eller hur det ska åtgärdas, vilket inte uppfyller kravet på beskrivning i 3.3.1 och gör felkorrigering onödigt svår för alla användare.
• Att ta bort aria-live-regioner eller role='alert' från felbehållare när ett formulär återställs, vilket gör att behållarna försvinner innan skärmläsare har läst klart deras innehåll. Feluppläsningar kan avbrytas, vilket lämnar användaren ovetande om valideringsresultatet.
• Att förlita sig på inbyggda webbläsarvalideringsbubblor (webbläsarens standardverktygstips) utan anpassning. Inbyggda webbläsarvalideringsgränssnitt är inkonsekventa mellan webbläsare och hjälpmedelskombinationer och uppfyller ofta inte WCAG-kraven på identifiering och beskrivning i komplexa formulärscenarier.
• Att placera felmeddelanden visuellt långt från sina associerade fält – till exempel endast i en varningsruta i sidhuvudet – utan att också tillhandahålla inline-meddelanden nära varje fält. Användare med nedsatt syn som förstorar skärmen kanske inte ser varningen i sidhuvudet medan de är fokuserade på inmatningsområdet, och tangentbordsanvändare måste förflytta sig långt för att läsa felet.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i Official Gazette nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webbtillgänglighet för ett brett spektrum av aktörer verksamma i Turkiet. Cirkuläret antar WCAG 2.2 som teknisk standard, vilket gör alla framgångskriterier på nivå A – inklusive WCAG 3.3.1 Error Identification – juridiskt obligatoriska för berörda organisationer.

Tidsplanen för efterlevnad som fastställs i cirkuläret är ett år för offentliga institutioner och två år för privata aktörer från publiceringsdatumet. Detta innebär att offentliga institutioner måste uppnå WCAG 2.2 nivå A-konformitet senast i juni 2026, och privata berörda aktörer senast i juni 2027.

De aktörer som omfattas av cirkuläret inkluderar ett brett spektrum av turkiska digitala tjänster. Offentliga institutioner – inklusive alla centrala regeringsdepartement, kommuner, statliga universitet och offentliga myndigheter – måste säkerställa att deras digitala tjänster är tillgängliga. Inom privat sektor omfattar cirkuläret e-handelsplattformar, banker och finansiella institutioner, sjukhus och privata vårdgivare, telekomfö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 WCAG 3.3.1 direkt relevant där onlineformulär används – vilket i praktiken innebär nästan varje digital kontaktpunkt. Kassaflöden i e-handel, processer för öppnande av bankkonton, patientregistreringsportaler på sjukhus, ansökningsformulär för offentliga förmåner, bokningssystem för flyg och buss samt sidor för skolinskrivning är alla beroende av formulärvalidering. Om något av dessa system automatiskt upptäcker ett inmatningsfel och misslyckas med att identifiera fältet eller beskriva felet i text, bryter de direkt mot cirkulärets krav.

Bristande efterlevnad av cirkuläret kan utsätta berörda aktörer för tillsyn, skadat anseende och potentiella sanktioner i takt med att Turkiets ramverk för tillsyn av digital tillgänglighet utvecklas. Utöver juridisk efterlevnad visar efterlevnad av 3.3.1 ett åtagande för inkluderande tjänsteleverans – vilket säkerställer att alla medborgare, inklusive de cirka 8,5 miljoner personer med funktionsnedsättning i Turkiet (enligt TÜİK-data), kan få tillgång till viktiga tjänster online utan hinder. Organisationer som verkar inom Accsibles SDK-ramverk bör prioritera både automatiserad strukturell efterlevnad och grundlig manuell testning för att säkerställa att deras felhantering fullt ut uppfyller detta grundläggande kriterium.