WCAG 3.3.6: Felhantering (alla)

Vad denna regel innebär

WCAG 3.3.6 — Felprevention (Alla) är ett framgångskriterium på nivå AAA under principen Begriplig. Det utökar kraven i 3.3.4 (Felprevention: juridiskt, finansiellt, data) till att omfatta alla sidor som kräver att en användare skickar in information, oavsett om denna insändning innebär juridiska åtaganden, finansiella transaktioner eller personligt identifierbar data.

I grunden kräver kriteriet att för varje webbsida där en användare skickar in information måste minst ett av följande tre villkor vara uppfyllt:

• Reversibel: Insändningar är reversibla i efterhand. Användaren kan ångra, avbryta eller dra tillbaka en åtgärd inom en rimlig tidsram. Till exempel kan ett skickat meddelande återkallas, eller ett inskickat formulär kan avbrytas från en bekräftelsekö.
• Kontrollerad: Data som matas in av användaren kontrolleras för inmatningsfel före slutlig insändning, och användaren får möjlighet att rätta dessa fel. Detta innebär inline-validering, sammanfattningar före insändning eller stegvisa granskningsflöden.
• Bekräftad: En mekanism tillhandahålls för att granska, bekräfta och korrigera information innan insändningen slutförs. Detta kan vara en granskningssida, en bekräftelsedialog eller en flerstegsguide med ett sista granskningssteg.

Den viktigaste skillnaden mellan 3.3.4 och 3.3.6 är omfattningen. Kriterium 3.3.4 gäller endast juridiska avtal, finansiella transaktioner, provsvar och radering av användarkontrollerad data. Kriterium 3.3.6 utvidgar detta till varje sida som kräver någon form av insändning av användarinmatning—inklusive kontaktformulär, nyhetsbrevsanmälningar, kommentarsfält, enkätsvar, profiluppdateringar, sökinställningar och all annan användarkontrollerad datainmatning.

Vad som räknas som godkänt: Ett formulär blir godkänt om det konsekvent implementerar minst en av de tre mekanismerna ovan. En bekräftelsesida före slutlig insändning, en sammanfattningssida med ett "Redigera"-alternativ, klient- eller serverbaserad validering med möjlighet att rätta fel, eller ett tydligt kommunicerat ångra-fönster uppfyller alla kriteriet.

Vad som räknas som underkänt: Ett enstegsformulär som skickar in data omedelbart vid knapptryckning utan validering, utan granskningssida och utan ångra-mekanism underkänns enligt detta kriterium. På samma sätt underkänns ett formulär som validerar men inte ger möjlighet att rätta fel innan ny insändning.

WCAG-specifikationen kräver inte alla tre mekanismer samtidigt—det räcker att uppfylla en. Men att kombinera två eller tre mekanismer ger ett djupare skydd och tjänar ett bredare spektrum av användare och sammanhang.

Varför det är viktigt

Felprevention är inte bara en användbarhetsfiness—det är ett grundläggande tillgänglighetskrav för användare som löper förhöjd risk för inmatningsfel på grund av funktionsnedsättning eller situationsbetingade begränsningar.

Kognitiva och inlärningsrelaterade funktionsnedsättningar: Användare med dyslexi, ADHD eller minnesnedsättningar gör ofta skrivfel, byter plats på siffror eller tappar bort sig i komplexa formulär med många fält. Utan en granskningsmekanism kan en felstavad e-postadress i ett kontaktformulär innebära ett missat svar, eller en felaktigt angiven adress i ett leveransformulär kan orsaka förlorade paket. Detta är inte extrema undantag—enligt Världshälsoorganisationen lever cirka 1 miljard människor världen över med någon form av kognitiv eller neurologisk funktionsnedsättning som påverkar vardagsfunktionen.

Motoriska funktionsnedsättningar: Användare med skakningar, begränsad finmotorik eller som är beroende av switch-styrning eller röststyrd programvara aktiverar ofta formulärinsändningar av misstag eller matar in oavsiktliga tecken. En användare med Parkinsons sjukdom som navigerar i ett komplext formulär med ett switch-gränssnitt kan oavsiktligt skicka in ett ofullständigt eller felaktigt formulär. Utan reversibilitet eller bekräftelsesteg blir dessa fel permanenta.

Skärmläsaranvändare: Blinda användare som navigerar med JAWS, NVDA eller VoiceOver har inte samma visuella överblick över ett ifyllt formulär som seende användare har före insändning. En bekräftelsesida eller sammanfattning som läses upp av en skärmläsare ger dessa användare en sista chans att verifiera sina uppgifter innan de oåterkalleligt skickas in.

Låg digital kompetens och äldre befolkning: Äldre vuxna och användare som är nya inför digitala gränssnitt är särskilt sårbara för oavsiktliga insändningar. Ett bekräftelsesteg med sammanfattningar på klarspråk ger ett skyddsnät som dramatiskt minskar supportkostnader och användarfrustration.

Scenario från verkligheten: Tänk på en turkisk e-förvaltningsportal där en medborgare fyller i ett långt byråkratiskt formulär för att registrera ett företag. Om medborgaren av misstag utelämnar ett obligatoriskt fält eller anger sitt skatteidentifikationsnummer felaktigt och formuläret skickas in direkt utan granskningssteg, kanske hen inte inser felet förrän hen får ett formellt avslag flera dagar senare. En enkel bekräftelsesida som visar all inmatad data före slutlig insändning skulle helt ha förhindrat detta.

SEO- och användbarhetsfördelar: Sidor som implementerar robust felprevention tenderar att ha lägre avhoppsfrekvens i formulär, högre konverteringsgrad och bättre användarnöjdhet. Sökmotorer väger i allt högre grad in användarupplevelsesignaler i rankningen, och sidor med hög avvisningsfrekvens på grund av formulärfel drabbas indirekt i organisk synlighet.

Relaterade Axe-core-regler

WCAG 3.3.6 kräver manuell testning eftersom inget automatiserat verktyg kan avgöra om ett givet formulärflöde för insändning uppfyller kraven på reversibilitet, felkontroll eller bekräftelse i detta kriterium. Automatiska tillgänglighetsskannrar som axe-core kan verifiera förekomsten av enskilda ARIA-attribut, etiketter och felmeddelanden, men de kan inte utvärdera den övergripande logiken i insändningsflödet, förekomsten av ett bekräftelsesteg eller om en ångra-mekanism faktiskt fungerar. Kriteriet handlar i grunden om interaktionsdesign och användarupplevelseflöde—inte statisk markup.

• Ingen dedikerad axe-core-regel finns för 3.3.6. Axe-core och liknande motorer testar enskilda DOM-element mot specifika attribut- eller rollkrav. Att avgöra om ett flersidigt formulär innehåller ett granskningssteg före slutlig insändning kräver förståelse för applikationens navigationsflöde och serverbeteende—information som statiska analysverktyg inte kan komma åt. En mänsklig testare måste gå igenom hela insändningsresan för att utvärdera efterlevnad.
• Relaterade regler som stödjer den övergripande formulärkvaliteten (även om de inte specifikt gäller 3.3.6): Regler som label (varje inmatningsfält har en associerad etikett), aria-required-attr (obligatoriska ARIA-attribut finns) och form-field-multiple-labels (inmatningsfält har inte motstridiga etiketter) bidrar till grunden för tillgängliga formulär. Att säkerställa att dessa godkänns är en förutsättning för meningsfull felprevention, men att klara dem garanterar inte efterlevnad av 3.3.6.
• Varför automatisering inte räcker: En automatisk skanning av en kassasida kan bekräfta att alla inmatningsfält har etiketter och att felmeddelanden är programmatiskt associerade med fälten. Men den kan inte avgöra om ett klick på "Skicka" tar användaren till en granskningssida, om det finns ett "Avbryt"-alternativ eller om systemet skickar ett bekräftelsemejl med en avbokningslänk. Detta är beteende- och processfrågor som bara mänsklig utvärdering kan besvara.

Hur man testar

1. Kör en automatisk skanning som baslinje: Använd axe DevTools, Lighthouse eller Accsible-widgetens inbyggda granskningsläge för att skanna alla sidor som innehåller formulär. Även om dessa verktyg inte direkt flaggar överträdelser av 3.3.6, lägger de en grund genom att identifiera saknade etiketter, frånvarande felmeddelanden eller felaktigt associerad valideringsfeedback. Åtgärda alla automatiskt identifierade problem innan du går vidare till manuell testning.
2. Identifiera alla insändningsformulär på webbplatsen: Skapa en komplett inventering av varje sida som tar emot och skickar in användarinmatning—kontaktformulär, registreringsformulär, inloggningsformulär, formulär för sökinställningar, sidor för profiluppdatering, kommentarsfält, nyhetsbrevsanmälningar och alla flerstegsguider. Var och en måste testas separat.
3. Testa det lyckade flödet med avsiktliga fel: Ange avsiktligt felaktig, ofullständig eller felaktigt formaterad data i varje formulär (t.ex. en ogiltig e-postadress, ett telefonnummer med bokstäver, lämna obligatoriska fält tomma). Skicka in formuläret och observera: Förhindrar sidan insändning och visar felmeddelanden? Är felmeddelandena associerade med rätt fält? Har användaren en tydlig möjlighet att rätta och skicka in på nytt?
4. Testa bekräftelse- eller granskningsmekanismer: För formulär som klarar valideringen, fyll i formuläret med giltig data och skicka in. Observera om en bekräftelsesida, sammanfattningsdialog eller granskningssteg visas innan datan oåterkalleligt skickas in. Verifiera att granskningssteget låter användaren gå tillbaka och redigera uppgifter.
5. Testa reversibilitet efter insändning: Efter en lyckad insändning, kontrollera om det finns en mekanism för avbokning, ångra eller tillbakadragande. Detta kan vara en "Avbryt insändning"-länk i ett bekräftelsemejl, en köhanteringssida i ett adminområde eller en avisering i appen med en ångra-åtgärd. Verifiera att mekanismen fungerar och är tydligt kommunicerad till användarna.
6. Skärmläsartestning med NVDA + Firefox: Navigera till varje formulär med NVDA och Firefox. Tabba genom alla fält, mata in data och skicka in formuläret. Verifiera att felmeddelanden annonseras när de visas, att granskningssidan (om den finns) är fullt läsbar i dokumentordning och att alla interaktiva kontroller (redigeringsknappar, bekräftelseknappar, avbrytknappar) på bekräftelsesidan är tangentbordsåtkomliga och korrekt etiketterade.
7. Skärmläsartestning med VoiceOver + Safari (macOS/iOS): Upprepa processen ovan med VoiceOver i Safari. Var särskilt uppmärksam på dynamiska innehållsuppdateringar—om valideringsfel visas dynamiskt via JavaScript utan sidomladdning, bekräfta att de exponeras via live-regioner (aria-live) så att VoiceOver annonserar dem utan att användaren behöver utforska sidan manuellt.
8. Testning med enbart tangentbord: Utan mus, navigera genom hela formulärflödet med endast Tab, Skift+Tab, Enter och mellanslag. Bekräfta att varje interaktivt element—inklusive redigera-, tillbaka-, bekräfta- och avbrytknappar på granskningssidor—är nåbart och användbart utan pekdon.

Hur man åtgärdar

Kontaktformulär utan validering eller granskning — felaktigt

<!-- Fails 3.3.6: submits immediately with no validation, no review, no undo -->
<form action='/submit-contact' method='post'>
  <label for='name'>Name</label>
  <input type='text' id='name' name='name'>

  <label for='email'>Email</label>
  <input type='text' id='email' name='email'>

  <label for='message'>Message</label>
  <textarea id='message' name='message'></textarea>

  <button type='submit'>Send</button>
</form>

Kontaktformulär med validering och bekräftelsesteg — korrekt

<!-- Step 1: Form with client-side validation before submission -->
<form id='contact-form' novalidate>
  <div role='group' aria-labelledby='form-heading'>
    <h2 id='form-heading'>Contact Us</h2>

    <div class='field-group'>
      <label for='name'>Full Name <span aria-hidden='true'>*</span></label>
      <input
        type='text'
        id='name'
        name='name'
        required
        aria-required='true'
        aria-describedby='name-error'
        autocomplete='name'
      >
      <span id='name-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='email'>Email Address <span aria-hidden='true'>*</span></label>
      <input
        type='email'
        id='email'
        name='email'
        required
        aria-required='true'
        aria-describedby='email-error'
        autocomplete='email'
      >
      <span id='email-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='message'>Message <span aria-hidden='true'>*</span></label>
      <textarea
        id='message'
        name='message'
        required
        aria-required='true'
        aria-describedby='message-error'
      ></textarea>
      <span id='message-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <!-- Review button triggers a confirmation summary before final submission -->
    <button type='button' onclick='showReviewScreen()'>Review &amp; Send</button>
  </div>
</form>

<!-- Step 2: Confirmation/review screen (shown after validation passes) -->
<section id='review-screen' hidden aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Message</h2>
  <p>Please review your details before sending. You can go back to make changes.</p>

  <dl>
    <dt>Full Name</dt>
    <dd id='review-name'></dd>
    <dt>Email</dt>
    <dd id='review-email'></dd>
    <dt>Message</dt>
    <dd id='review-message'></dd>
  </dl>

  <!-- Edit option satisfies the 'reversible/correctable before final commit' requirement -->
  <button type='button' onclick='goBackToForm()'>Edit My Details</button>
  <button type='button' onclick='submitFinalForm()'>Confirm and Send</button>
</section>

Flerstegsguide utan sammanfattningssteg — felaktigt

<!-- Fails 3.3.6: final step submits directly without allowing user to review previous steps -->
<form action='/register' method='post'>
  <!-- Step 3 of 3 — no ability to review steps 1 and 2 -->
  <h2>Step 3: Payment</h2>
  <label for='card'>Card Number</label>
  <input type='text' id='card' name='card'>
  <button type='submit'>Complete Registration</button>
</form>

Flerstegsguide med slutligt granskningssteg — korrekt

<!-- Step 4 of 4: Summary review before final submission -->
<section aria-labelledby='summary-heading'>
  <h2 id='summary-heading'>Step 4 of 4: Review Your Registration</h2>
  <p>Please confirm the information below before completing your registration. Use the edit links to correct any errors.</p>

  <h3>Personal Details
    <a href='/register/step-1' aria-label='Edit personal details'>Edit</a>
  </h3>
  <dl>
    <dt>Full Name</dt><dd>Ayşe Kaya</dd>
    <dt>Date of Birth</dt><dd>15/04/1988</dd>
  </dl>

  <h3>Contact Information
    <a href='/register/step-2' aria-label='Edit contact information'>Edit</a>
  </h3>
  <dl>
    <dt>Email</dt><dd>[email protected]</dd>
    <dt>Phone</dt><dd>+90 532 000 0000</dd>
  </dl>

  <h3>Payment
    <a href='/register/step-3' aria-label='Edit payment details'>Edit</a>
  </h3>
  <dl>
    <dt>Card ending</dt><dd>**** 4242</dd>
  </dl>

  <!-- Final submit only after user has reviewed all data -->
  <form action='/register/complete' method='post'>
    <button type='submit'>Confirm and Complete Registration</button>
  </form>
</section>

Formulär med omedelbar insändning och ingen ångra — felaktigt

<!-- Fails 3.3.6: deletes comment immediately with no undo or confirmation -->
<form action='/comments/42/delete' method='post'>
  <button type='submit'>Delete Comment</button>
</form>

Destruktiv åtgärd med bekräftelsedialog — korrekt

<!-- Passes 3.3.6: user must confirm before destructive action is executed -->
<button
  type='button'
  aria-haspopup='dialog'
  onclick='openConfirmDialog(42)'
>
  Delete Comment
</button>

<dialog
  id='confirm-delete-dialog'
  aria-labelledby='dialog-title'
  aria-describedby='dialog-desc'
>
  <h2 id='dialog-title'>Delete this comment?</h2>
  <p id='dialog-desc'>
    This action cannot be undone. The comment will be permanently removed.
  </p>
  <form action='/comments/42/delete' method='post'>
    <button type='submit'>Yes, Delete</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Vanliga misstag

• Implementera validering men inte exponera den för skärmläsare: Att visa felmeddelanden visuellt via CSS-färgändringar eller ikoner utan att associera dem med inmatningsfältet med aria-describedby eller injicera dem i en aria-live-region innebär att blinda användare aldrig hör felet—formuläret verkar ha skickats in korrekt samtidigt som det i själva verket är ofullständigt.
• Behandla efterlevnad av 3.3.4 som tillräcklig för AAA: Team implementerar ofta felprevention endast för finansiella eller juridiska formulär (uppfyller 3.3.4) och antar att alla formulär därmed är täckta. Kriterium 3.3.6 kräver samma skydd för varje formulär på webbplatsen, inklusive nyhetsbrevsanmälningar, kommentarer och profiluppdateringar.
• Tillhandahålla en bekräftelsesida som är skrivskyddad utan möjlighet att redigera: En granskningssida som visar inskickad data men bara erbjuder en "Bekräfta"-knapp—utan möjlighet att gå tillbaka och rätta fel—uppfyller inte fullt ut kriteriets anda och lämnar användare utan möjlighet att agera om de upptäcker ett misstag under granskningen.
• Använda window.confirm() som enda bekräftelsemekanism: Webbläsarens inbyggda bekräftelsedialoger är inte tillgängliga för alla användare och kan inte stylas eller struktureras för tydlighet. De beter sig också inkonsekvent mellan olika hjälpmedelstekniker. Använd istället ett korrekt <dialog>-element med lämpliga ARIA-attribut.
• Återställa hela formuläret vid valideringsfel istället för att bevara giltiga uppgifter: När en användare skickar in ett formulär med 10 fält och ett fel, och formuläret rensar alla fält, måste användaren mata in all data på nytt. Detta är särskilt betungande för användare med motoriska funktionsnedsättningar eller kognitiv utmattning. Bevara alltid giltig data och fokusera uppmärksamheten endast på de felaktiga fälten.
• Placera sammanfattande felmeddelanden utanför vyn eller tangentbordsfokusordningen: En felöversiktsbanner som injiceras högst upp på sidan efter en misslyckad insändning gör ingen nytta för användare som har fokus mitt i formuläret. Använd aria-live='assertive' på sammanfattningsbehållaren och flytta fokus programmatiskt till den vid misslyckad insändning.
• Märka bekräftelseknappar med vaga etiketter som "OK" eller "Yes": På en granskningssida måste knappar tydligt kommunicera vad som kommer att hända. "Confirm and Send Message" är entydigt; "OK" är det inte—särskilt för skärmläsaranvändare som kanske inte har den omgivande visuella kontexten tillgänglig.
• Anta att enbart serverbaserad validering uppfyller kriteriet: Om klientbaserad validering saknas kräver varje insändning en fullständig tur-och-retur till servern innan användaren får veta att ett fel uppstått. Användare med långsamma uppkopplingar eller som tappar nätverket mitt i insändningen kan lämnas i ett osäkert läge utan tydlig felfeedback.
• Underlåta att testa reversibilitetsmekanismen under realistiska förhållanden: Team implementerar ibland ett "avbryt"-alternativ i ett bekräftelsemejl men testar aldrig om avbokningslänken är tillgänglig, om den fungerar efter att tidsfönstret löpt ut eller om länken är användbar med skärmläsare. En otillgänglig ångra-mekanism uppfyller inte kriteriet.
• Misslyckas med att hantera kantfall med autofyll på granskningssidor: När webbläsare eller lösenordshanterare autofyller formulärfält kan värdena som visas på en granskningssida skilja sig från vad som faktiskt skickades in om JavaScriptet som fyller granskningssidan hämtar från DOM:en innan autofyll slutförts. Hämta alltid värden omedelbart innan granskningssidan renderas, inte vid initial sidladdning.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentdekret 2025/10, publicerat i den officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på digital tillgänglighet för ett brett spektrum av aktörer som är verksamma i Turkiet. Cirkuläret kräver att berörda organisationer följer WCAG 2.2 på nivå AA som baslinje. De aktörer som uttryckligen omfattas inkluderar offentliga institutioner och myndigheter, e-handelsplattformar, banker och finansiella institutioner, sjukhus och vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, licensierade resebyråer, privata transportföretag och privatskolor som godkänts av Ministeriet för nationell utbildning (MoNE).

WCAG 3.3.6 är ett kriterium på nivå AAA och är därför inte ett direkt juridiskt krav enligt cirkulär 2025/10. Dess betydelse i den turkiska regulatoriska kontexten bör dock inte avfärdas. Flera av de berörda aktörstyperna—särskilt banker, e-handelsplattformar och vårdgivare—hanterar transaktionsformulär med höga insatser där felprevention inte bara är en bästa praxis utan en juridisk och etisk nödvändighet. Ett turkiskt banks onlineformulär för penningöverföring, ett vårdportals system för tidsbokning eller ett e-handelsflöde för kassa som saknar bekräftelsesteg eller mekanismer för felkorrigering kanske inte bryter mot 3.3.6 i en juridiskt verkställbar mening, men det skapar betydande risk för skada för användare med funktionsnedsättning och utsätter organisationen för rykte- och driftsrisk.

Vidare signalerar cirkuläret en tydlig utveckling mot ökade tillgänglighetskrav över tid, i linje med ramen för European Accessibility Act (EAA) som Turkiet har anpassat sig till. Organisationer som implementerar AAA-kriterier som 3.3.6 idag är proaktivt positionerade inför framtida skärpningar av regelverket och visar ett engagemang för inkluderande design som går bortom miniminivåer för efterlevnad. För aktörer som privatsjukhus och finansiella institutioner som betjänar äldre befolkning eller användare med kognitiva och motoriska funktionsnedsättningar i oproportionerligt hög grad är implementering av 3.3.6 i alla formulär ett klokt riskhanteringsbeslut oberoende av dess juridiska status. Accsibles overlay-SDK kan hjälpa till att exponera felmeddelanden, förstärka valideringstillstånd och tillhandahålla kompletterande bekräftelseuppmaningar som ett lager av förstärkt skydd för turkiska organisationer som strävar efter att ligga i framkant när det gäller tillgänglighet.