WCAG 3.3.3: Felrekommendation

Vad den här regeln innebär

WCAG 3.3.3 Error Suggestion är ett kriterium på nivå AA under principen Begriplig. Det bygger direkt på 3.3.1 (Error Identification), som kräver att fel identifieras i text. Error Suggestion går längre: när ett inmatningsfel upptäcks automatiskt måste gränssnittet också föreslå hur användaren kan rätta det, förutsatt att förslaget inte äventyrar säkerheten eller syftet med innehållet.

Den viktiga skillnaden här är mellan felidentifiering och felförslag. Att säga till en användare "Your date of birth is invalid" är identifiering. Att säga "Your date of birth is invalid — please enter a date in DD/MM/YYYY format" är ett förslag. Båda krävs enligt sina respektive kriterier, men Error Suggestion kräver att handlingsbar, korrigerande vägledning åtföljer felmeddelandet där det är möjligt.

Kriteriet gäller när ett inmatningsfel upptäcks automatiskt — det vill säga när valideringslogik på klient- eller serversidan avgör att ett inskickat eller inmatat värde inte uppfyller de förväntade kriterierna. Det gäller alla formulärkontroller: textfält, select-fält, kryssrutor, alternativknappar, datumväljare, fält för filuppladdning och alla interaktiva komponenter som samlar in användardata.

Vad som räknas som godkänt: Felmeddelandet presenteras i text (inte enbart genom färg eller ikon), identifierar tydligt fältet med fel och ger specifik vägledning om hur det ska rättas. Till exempel: "Password must be at least 8 characters and include one uppercase letter" i stället för bara "Invalid password." Förslaget måste visas nära fältet, vara programmatiskt associerat med det (via aria-describedby eller liknande) och vara uppfattbart för hjälpmedel.

Vad som räknas som underkänt: Alla felmeddelanden som bara anger att ett fel inträffat utan att förklara vad som är fel eller hur det ska åtgärdas. Generiska meddelanden som "Error", "Invalid input" eller "Required field" utan ytterligare sammanhang underkänns enligt detta kriterium. Fel som endast kommuniceras genom en röd kantlinje eller en varningsikon, utan beskrivande text, underkänns också.

Definierade undantag: Kriteriet innehåller två uttryckliga undantag där ett förslag inte krävs. För det första, om att ge förslaget skulle äventyra säkerheten — till exempel i ett inloggningsformulär där en exakt förklaring till varför ett lösenord underkändes (fel lösenord vs. fel användarnamn) skulle kunna underlätta brute-force-attacker. För det andra, om att ge förslaget skulle äventyra syftet med innehållet — till exempel i ett utbildande quiz där det skulle motverka bedömningssyftet att avslöja det rätta svaret. Dessa undantag är snäva och ska inte användas för att undvika kravet i vanliga formulärsammanhang.

Varför det är viktigt

Error Suggestion finns eftersom att fylla i formulär är en av de mest kognitivt krävande aktiviteterna användare utför på webben, och det är också en av de mest betydelsefulla — fel i kassaflöden, ansökningar om statliga förmåner, medicinska intagsformulär eller bankportaler kan få verkliga konsekvenser för användare som inte kan förstå vad som gick fel eller hur de ska återhämta sig.

Kognitiva funktionsnedsättningar: Användare med dyslexi, ADHD, inlärningssvårigheter eller begränsad läskunnighet kan ha svårt att tyda vaga felmeddelanden och koppla dem till det specifika fältet eller det krav på format som gäller. Utan ett tydligt korrigerande förslag kan de överge formuläret helt eller skicka in felaktig information. Enligt Världshälsoorganisationen lever ungefär 1 av 6 personer globalt — över 1,3 miljarder — med någon form av funktionsnedsättning, och kognitiva funktionsnedsättningar är bland de vanligaste men minst tillgodosedda kategorierna.

Blinda och synsvaga användare: Skärmläsaranvändare är helt beroende av textbeskrivningar för att förstå valideringsfel. När ett felmeddelande bara säger "Invalid" och inte ger något förslag har användaren ingen möjlighet att avgöra vad "invalid" betyder för det fältet. De kan inte kasta en blick på intilliggande etiketter, platshållartext eller visuella formateringsledtrådar för att sluta sig till det förväntade formatet. Ett tydligt förslag, programmatiskt associerat med inmatningen via aria-describedby, är den enda tillförlitliga informationskanalen.

Motoriskt nedsatta användare: Användare som förlitar sig på switch-styrning, röststyrning eller alternativa inmatningsenheter utsätts för betydande fysisk ansträngning när de fyller i formulär. Att behöva navigera tillbaka till ett formulär efter en misslyckad inskickning — utan att förstå vad som måste ändras — innebär en oproportionerlig belastning. Tydliga förslag minskar bördan av återinmatning och antalet misslyckade inskickningscykler.

Icke modersmålstalare och äldre användare: Användare som inte är flytande i formulärets språk, eller som har mindre erfarenhet av webbkonventioner, har också stor nytta av explicita korrigerande förslag. Ett meddelande som "Enter your phone number without spaces or dashes, e.g. 05321234567" tar bort tvetydighet för användare som annars kanske aldrig lyckas slutföra formuläret.

Scenario i verkligheten: Tänk på en turkisk medborgare som ansöker om ett socialt bistånd via en e-förvaltningsportal. Ansökan kräver ett TR Identity Number (TC Kimlik Numarası), ett specifikt 11-siffrigt format. Om användaren anger 10 siffror och bara får meddelandet "TC Kimlik Numarası hatalı" (TC Identity Number is incorrect), kanske en användare med kognitiv funktionsnedsättning, en äldre användare eller en skärmläsaranvändare inte vet om numret är för kort, innehåller ett ogiltigt tecken eller har ett formateringsproblem. Att lägga till "TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901" (TC Identity Number must be 11 digits, e.g., 12345678901) undanröjer omedelbart tvetydigheten och gör det möjligt för användaren att rätta sig själv.

Fördelar för användbarhet och konvertering: Utöver tillgänglighet är avhopp från formulär en kritisk affärsmetrik. Forskning visar konsekvent att otydliga felmeddelanden är bland de främsta orsakerna till att användare avbryter e-handelskassor och registreringsflöden. Specifika, handlingsbara felförslag minskar avhoppsfrekvensen i formulär och förbättrar slutförandefrekvensen för alla användare — vilket gör detta kriterium till ett starkt affärsargument såväl som ett tillgänglighetskrav.

Relaterade Axe-core-regler

WCAG 3.3.3 kräver manuell testning eftersom automatiserade verktyg inte kan utvärdera kvaliteten eller fullständigheten i texten i felmeddelanden. En automatiserad skanner kan upptäcka att ett felmeddelande finns och att det är programmatiskt associerat med ett formulärfält, men den kan inte avgöra om meddelandet faktiskt ger ett användbart korrigerande förslag. Detta kräver mänsklig bedömning för att avgöra om texten är specifik, handlingsbar och tillräcklig för att vägleda användaren mot en giltig inmatning.

• Manuell granskning — innehållskvalitet i felmeddelanden: Testare måste manuellt utlösa varje valideringsvillkor (skicka in ett tomt obligatoriskt fält, ange data i fel format, överskrida teckenbegränsningar osv.) och utvärdera varje resulterande felmeddelande. Testaren frågar: talar detta meddelande om för användaren inte bara att ett fel inträffade, utan specifikt vad de ska göra för att rätta det? Om meddelandet är generiskt ("Invalid", "Error", "Please check this field") underkänns det enligt 3.3.3 oavsett om det är programmatiskt exponerat.
• Manuell granskning — programmatiska kopplingar: Testare måste verifiera att texten med felförslag är programmatiskt kopplad till det relevanta inmatningsfältet med aria-describedby, aria-live-regioner eller inline-koppling, så att skärmläsare läser upp det utan att kräva ytterligare navigering. Detta överlappar delvis med axe-regler som label och aria-input-field-name, men själva förslagstexten kontrolleras inte av dessa regler.
• Manuell granskning — giltighet för säkerhetsundantag: Testare bör verifiera att alla formulär som utelämnar korrigerande förslag av säkerhetsskäl (t.ex. inloggningsformulär) verkligen kvalificerar sig enligt säkerhetsundantaget, och att detta undantag inte används för att undvika kravet för icke-känsliga fält.
• Delvis automatiserat — label-regel: Även om axe-core-regeln label kontrollerar att formulärinmatningar har tillgängliga namn, kontrollerar den inte om felmeddelanden ger korrigerande förslag. Den kan lyfta fram saknade etiketter som skulle förvärra problemet med felförslag, och att åtgärda etikettproblem är en förutsättning för en effektiv implementering av felförslag.

Hur man testar

1. Automatiserad skanningsbaslinje: Kör axe DevTools eller Lighthouse mot sidan som innehåller formuläret. Notera eventuella befintliga överträdelser relaterade till formuläretiketter, ARIA-roller eller felidentifiering (3.3.1). Dessa måste åtgärdas först, eftersom de är förutsättningar för effektiva felförslag. Automatiska skanningar kommer inte att flagga saknade förslag — de etablerar bara den strukturella baslinjen.
2. Utlös alla valideringsvillkor: För varje formulärfält, utlös medvetet varje möjligt felläge: skicka in ett tomt obligatoriskt fält, ange data i fel format (fel datumformat, ogiltig e-post, för kort lösenord, icke-numeriskt värde i ett numeriskt fält) och överskrid eventuella teckenbegränsningar. Dokumentera varje felmeddelande som visas.
3. Utvärdera förslagets kvalitet: För varje felmeddelande, fråga: (a) Identifierar det det specifika fältet? (b) Förklarar det vad som är fel? (c) Ger det handlingsbar vägledning om hur inmatningen ska rättas? Ett meddelande som besvarar alla tre uppfyller 3.3.3. Ett meddelande som bara besvarar (a) uppfyller 3.3.1 men underkänns enligt 3.3.3.
4. Skärmläsartestning med NVDA + Firefox: Navigera till formuläret med Tab. Fyll i ett ogiltigt värde. Skicka in eller flytta fokus. Lyssna på vad NVDA meddelar. Verifiera att texten med felförslag läses upp automatiskt (via en aria-live-region eller fokusstyrning till felet) utan att användaren behöver leta upp den manuellt.
5. Skärmläsartestning med VoiceOver + Safari (macOS/iOS): Utför samma steg. Använd VO+Högerpil för att läsa fältet och dess associerade beskrivning. Bekräfta att förslagstexten läses upp som en del av fältets tillgängliga beskrivning, inte bara som närliggande text som kan hoppas över.
6. Skärmläsartestning med JAWS + Chrome: Efter att ha skickat in ett formulär med fel, bekräfta att JAWS läser upp felförslaget antingen via fokusstyrning (fokus flyttas till felöversikten) eller via uppdateringar i en aria-live-region. Använd JAWS virtuella markör för att navigera till fältet och bekräfta att förslaget är en del av fältets beskrivning.
7. Endast tangentbordsnavigering: Utan skärmläsare, navigera i formuläret med enbart Tab, Shift+Tab och Enter. Verifiera att felförslag är synliga i vyn, inte dolda utanför skärmen eller skymda av andra element, när fältet får fokus efter en misslyckad inskickning.
8. Verifiera säkerhetsundantag: För inloggnings- och autentiseringsformulär, bekräfta att utelämnandet av specifika förslag är avsiktligt och dokumenterat, och att säkerhetsundantaget är begränsat till de fält som är absolut nödvändiga.

Hur man åtgärdar

Generiskt felmeddelande — Felaktigt

<!-- Error message provides no suggestion on how to fix the problem -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

Generiskt felmeddelande — Korrekt

<!-- aria-describedby links the suggestion text to the input;
     the suggestion explains exactly what format is expected -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

Lösenordsvalidering utan formatvägledning — Felaktigt

<!-- User is told the password is wrong but not why or how to fix it -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

Lösenordsvalidering utan formatvägledning — Korrekt

<!-- The suggestion lists exactly what the password must contain,
     enabling the user to self-correct without guessing -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

Datumfält med otydligt formatfel — Felaktigt

<!-- No indication of which date format is expected -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

Datumfält med otydligt formatfel — Korrekt

<!-- The suggestion states the required format and provides
     a concrete example, removing all ambiguity -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

Formulär med flera fält och serverside-felöversikt — Felaktigt

<!-- Error summary exists but links do not associate suggestions
     with individual fields, and messages are vague -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

Formulär med flera fält och serverside-felöversikt — Korrekt

<!-- Error summary includes linked, specific suggestions;
     each list item links to the relevant field;
     inline errors also appear adjacent to each field -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

Vanliga misstag

• Att använda placeholder som ersättning för felförslag: Platshållartext försvinner så snart användaren börjar skriva och läses inte tillförlitligt upp av skärmläsare som ett fel. Förlita dig aldrig enbart på platshållartext för att kommunicera vilket format som krävs efter att ett fel har inträffat.
• Att visa felmeddelanden endast i en toast-notis som försvinner efter några sekunder: Flyktiga notiser är inte uppfattbara för alla användare — skärmläsaranvändare kan missa uppspelningen, och meddelandet är borta innan en långsam läsare hinner bearbeta det. Felförslag måste finnas kvar tills felet är åtgärdat.
• Att använda aria-invalid='true' utan att aria-describedby pekar på förslagstexten: Att sätta aria-invalid signalerar att ett fält har ett fel, men utan att aria-describedby länkar till förslagselementet kommer skärmläsare inte att läsa upp förslagstexten när fältet får fokus.
• Att bara ge förslaget i den visuella designen (t.ex. en tooltip vid hovring) och inte i DOM:en: Endast hovringsbaserade tooltips är otillgängliga för tangentbordsanvändare och skärmläsaranvändare. Förslagstexten måste finnas i DOM:en och vara programmatiskt associerad med fältet.
• Att använda enbart färg eller ikoner för att indikera vilket fält som har ett fel: En röd kantlinje eller varningsikon utgör inte ett felförslag. Förslaget måste vara en textbeskrivning som förklarar den korrigerande åtgärden, inte en visuell indikator.
• Att skriva förslag som identifierar problemet men inte lösningen: "Your password is too short" identifierar felet men föreslår ingen lösning. "Your password must be at least 8 characters" ger den nödvändiga korrigerande vägledningen. Båda delarna krävs för att uppfylla 3.3.3.
• Att tillämpa säkerhetsundantaget för brett: Säkerhetsundantaget gäller snävt i situationer där ett förslag verkligen skulle äventyra säkerheten — vanligtvis begränsat till autentiseringsfält. Det gäller inte vanliga formulärfält som namn, adresser eller telefonnummer, där generiska fel är oberättigade.
• Att placera felförslaget efter skicka-knappen eller långt från fältet: Felförslag måste vara visuellt och programmatiskt nära det fält de beskriver. Att placera alla fel längst ned i ett långt formulär, utan att också inkludera inline-förslag vid varje fält, tvingar användare att kontextskifta och komma ihåg vilket förslag som hör till vilket fält.
• Att inte flytta fokus till felöversikten efter en misslyckad serverside-inskickning: När en sida laddas om efter en misslyckad inskickning återgår fokus vanligtvis till sidans topp. Utan programmatiskt fokus på felöversikten eller det första fältet med fel måste skärmläsaranvändare navigera genom hela sidan för att upptäcka vad som gick fel.
• Att använda vag formulering som "Please check your input" eller "Something went wrong": Dessa meddelanden ger ingen information om vad som är fel eller hur det ska rättas. Varje felförslag måste vara specifikt för fältet och den specifika valideringsregeln som överträtts.

Relation till Turkiets tillgänglighetsreglering

Turkiets tillgänglighetslandskap har utvecklats avsevärt med presidentcirkulär 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025. Detta cirkulär fastställer obligatoriska krav på webb- och mobiltillgänglighet i linje med WCAG 2.2, med krav på nivå AA-konformitet för aktörer som vill erhålla Erişilebilirlik Logosu (tillgänglighetslogotypen) utfärdad av Aile ve Sosyal Hizmetler Bakanlığı (Ministeriet för familje- och socialtjänster).

WCAG 3.3.3 Error Suggestion, som ett kriterium på nivå AA, omfattas av detta obligatoriska krav. Alla berörda aktörer som använder formulär — för registrering, betalning, tjänsteansökningar eller kontohantering — måste säkerställa att deras felmeddelanden inte bara identifierar fel utan ger handlingsbara korrigerande förslag, enligt beskrivningen i detta kriterium.

De aktörer som omfattas av presidentcirkulär 2025/10 spänner över ett brett spektrum av sektorer. Offentliga institutioner och myndigheter måste följa reglerna, vilket innebär att alla e-förvaltningsportaler (t.ex. e-Devlet-tjänster, kommunala portaler, system för ansökan om förmåner) måste tillhandahålla implementeringar av felförslag som uppfyller kraven. Eftersom många myndighetstjänster kräver att medborgare lämnar komplexa personuppgifter — identitetsnummer, adresskoder, skattenummer — är tydliga felförslag särskilt kritiska i detta sammanhang.

Banker och finansiella institutioner omfattas, inklusive plattformar för internetbank, registreringsformulär för investeringskonton och portaler för låneansökningar. Dessa formulär samlar rutinmässigt in känsliga och exakt formaterade data, och avsaknaden av korrigerande förslag skapar verkliga hinder för kunder med funktionsnedsättning och potentiell juridisk risk.

Sjukhus och vårdgivare måste också följa reglerna, vilket omfattar patientregistreringssystem, formulär för tidsbokning och portaler för försäkringsanspråk. Medicinska formulär innehåller ofta komplexa fältkrav (diagnoskoder, försäkringspolicynummer, exakta datumformat), vilket gör tydliga felförslag särskilt viktiga för äldre och kognitivt funktionsnedsatta patienter.

Telekomföretag med 200,000 eller fler abonnenter omfattas, vilket inkluderar stora operatörers kundportaler, formulär för SIM-registrering och gränssnitt för kontohantering. E-handelsplattformar — inklusive kassaflöden och kontoregistrering — måste följa reglerna, vilket gör Error Suggestion direkt relevant för formulär för produkt- och varukorgshantering som är centrala för deras affärsverksamhet.

Resebyråer, privata transportföretag och privatskolor auktoriserade av Ministry of National Education (MoNE) omfattas också. Bokningsformulär, ansökningar om inskrivning och betalningsgränssnitt som drivs av dessa aktörer måste uppfylla standarder på nivå AA, inklusive 3.3.3.

Ur ett praktiskt efterlevnadsperspektiv bör organisationer som strävar efter Erişilebilirlik Logosu behandla WCAG 3.3.3 som en central revisionspunkt under alla tillgänglighetsbedömningar. Manuell testning av alla valideringsflöden i formulär — inklusive både klient- och serverside-fel — krävs, och dokumentation av motiveringen för säkerhetsundantag bör upprätthållas för alla fält där korrigerande förslag medvetet utelämnas. Underlåtenhet att uppfylla kraven på nivå AA, inklusive Error Suggestion, kommer att hindra tilldelningen av logotypen och kan utsätta berörda aktörer för administrativa konsekvenser enligt cirkuläret.