WCAG 3.3.8: Tillgänglig autentisering (minimi)

Vad den här regeln innebär

WCAG 3.3.8 Accessible Authentication (Minimum) är ett kriterium på nivå AA som infördes i WCAG 2.2. Det anger att ett kognitivt funktionstest – definierat som en uppgift som kräver att en användare minns, bearbetar eller transkriberar information – inte får vara det enda sättet att slutföra ett autentiseringssteg, om inte minst ett av följande villkor är uppfyllt:

• Alternativ metod: En annan autentiseringsväg finns tillgänglig som inte bygger på ett kognitivt funktionstest (till exempel en magisk länk som skickas via e-post, biometrisk inloggning eller en passnyckel).
• Mekanism för assistans: Användaragenten eller ett tredjepartsverktyg tillåts slutföra steget för användarens räkning – till exempel att en lösenordshanterare autofyller inloggningsuppgifter, eller en kopiera-klistra in-åtgärd för en engångskod.
• Undantag för objektigenkänning: Det kognitiva funktionstestet innebär att identifiera ett objekt i en bild (till exempel att välja alla bilder som innehåller ett trafikljus) — denna typ av test är tillåten på Minimum-nivån (AA).
• Undantag för personligt innehåll: Testet bygger på innehåll som användaren själv har tillhandahållit, såsom att välja ett tidigare uppladdat foto från ett rutnät.

I praktiken uppfyller ett inloggningsformulär som endast kräver användarnamn och lösenord faktiskt detta kriterium, förutsatt att formuläret tillåter webbläsarens autofyll och lösenordshanterare att fungera (d.v.s. att fälten använder standard-<input type='password'> och inte blockeras från att klistra in). Ett CAPTCHA som kräver transkribering av förvrängd text utan någon alternativ autentiseringsväg är ett tydligt fel. Ett CAPTCHA som ber användare att välja bilder som matchar en kategori (objektigenkänning) är tillåtet på AA-nivå men hanteras striktare på AAA-nivå (3.3.9).

Kriteriet gäller alla steg i en autentiseringsprocess: initial inloggning, step-up-autentisering, multifaktorverifiering, kontorecovery och återautentisering av sessioner. Det gäller också alla processer som skyddar åtkomst till funktionalitet, inte bara den primära inloggningsskärmen.

En viktig teknisk konsekvens är att utvecklare inte får använda autocomplete='off' på autentiseringsfält, inte får inaktivera klistra in via JavaScript-händelsehanterare och inte får bryta de standardiserade inmatningssemantiker som gör att hjälpmedelsteknik och webbläsarens autofyll fungerar korrekt.

Varför det är viktigt

Autentisering är en port till nästan alla digitala tjänster som människor förlitar sig på dagligen – banktjänster, vårdportaler, myndighetstjänster, e-handel och kommunikationsplattformar. När den porten inför kognitiva hinder utestänger den systematiskt en betydande del av befolkningen.

Kognitiva funktionsnedsättningar omfattar ett brett spektrum: dyslexi, dyskalkyli, uppmärksamhetsstörningar, förvärvade hjärnskador, demens, intellektuella funktionsnedsättningar och ångestsyndrom. Världshälsoorganisationen uppskattar att ungefär 1 av 6 personer globalt upplever någon form av betydande funktionsnedsättning, och kognitiva och neurologiska tillstånd utgör en av de största kategorierna. För dessa användare kan uppgifter som att korrekt transkribera en sträng av förvrängda tecken, lösa ett visuellt pussel under tidspress eller växla mellan en autentiseringsapp och ett inloggningsformulär vara genuint omöjliga eller djupt utmattande.

Överväg ett konkret scenario: en person med dyslexi försöker logga in på sin sjukförsäkringsportal för att se provsvar. Webbplatsen visar ett text-CAPTCHA utan något ljudalternativ och utan möjlighet att kringgå det. De förvrängda bokstavsformerna är omöjliga att skilja åt för denna användare, och inmatningsfältet blockerar klistra in. Efter flera misslyckade försök låses kontot. Användaren kan inte komma åt tidskritisk medicinsk information. Detta är inte ett hypotetiskt extremfall – det är en rutinupplevelse för miljontals människor.

Användare med motoriska funktionsnedsättningar som är beroende av switch-styrning eller ögonspårningsenheter påverkas också. Att skriva om en komplex engångskod från en separat enhet, eller att dra bildrutor i en viss ordning, kan vara fysiskt omöjligt med dessa inmatningsmetoder. Att tillåta kopiera-klistra in eller autentisering med passnyckel löser hindret helt.

Äldre vuxna utgör en annan betydande grupp. Åldersrelaterad kognitiv nedsättning påverkar minne och bearbetningshastighet, vilket gör komplexa CAPTCHA och flerstegsuppgifter som kräver memorering oproportionerligt svåra. I takt med att befolkningen i Turkiet och globalt åldras blir det affärsmässiga och regulatoriska argumentet för tillgänglig autentisering starkare för varje år.

Ur ett användbarhets- och konverteringsperspektiv ökar friktion i autentiseringsflöden direkt avhoppsfrekvensen. E-handelsplattformar som ersätter text-CAPTCHA med riskbaserad autentisering eller passnycklar rapporterar konsekvent högre andel slutförda inloggningar och lägre supportkostnader relaterade till låsta konton.

Relaterade Axe-core-regler

WCAG 3.3.8 klassificeras som kräver manuell testning eftersom automatiserade verktyg inte fullt ut kan bedöma om en autentiseringsprocess inför ett otillgängligt kognitivt funktionstest. Att avgöra om ett inloggningsflöde saknar alternativ väg, eller om klistra in blockeras på ett kontextberoende sätt, kräver mänsklig bedömning och interaktion med ett live-autentiseringsflöde. Med det sagt finns vissa automatiserade kontroller som stödjer detta kriterium:

• Manuell granskning — revision av autentiseringsflöde: Testare måste gå igenom varje autentiseringssteg och avgöra om ett kognitivt funktionstest förekommer, och i så fall om det finns ett alternativ i enlighet med kraven eller en assisterande mekanism. Ingen axe-core-regel triggas för närvarande automatiskt för detta kriterium eftersom logiken beror på att förstå syftet och kontexten för formulärfält och omgivande UI, inte bara deras markup.
• Kontroller av autocomplete-attribut (relaterat): Axe-cores regel autocomplete-valid flaggar inmatningsfält vars autocomplete-attributvärden inte hämtas från WCAG 1.3.5:s tokenlista. Även om denna regel riktar sig direkt mot 1.3.5 är den en stödjande kontroll för 3.3.8: om autocomplete='username' och autocomplete='current-password' saknas eller är felaktigt satta kan lösenordshanterare inte autofylla, vilket tar bort den assisterande mekanism som gör standardlösenordsinloggning förenlig med 3.3.8.
• Upptäckt av blockering av klistra in — manuellt: Automatiska skannrar kan inte pålitligt upptäcka JavaScript som fångar upp paste-händelser och undertrycker dem på autentiseringsfält. En manuell testare måste försöka klistra in en inloggningsuppgift eller OTP i varje relevant fält och bekräfta att åtgärden lyckas.
• Upptäckt av CAPTCHA-alternativ — manuellt: Axe-core kan upptäcka förekomsten av vanliga CAPTCHA-widgets (t.ex. reCAPTCHA-iframes) men kan inte avgöra om en alternativ autentiseringsväg erbjuds någon annanstans på sidan eller via en annan väg. Denna bedömning kräver manuell granskning av hela autentiseringsupplevelsen.

Hur man testar

1. Automatisk skanning (axe DevTools / Lighthouse): Kör axe DevTools på varje autentiseringssida (inloggning, registrering, kontorecovery, MFA). Leta efter autocomplete-valid-överträdelser på användarnamns- och lösenordsfält. Granska i Lighthouse Accessibility-granskningen efter formulärrelaterade problem. Observera att ingen automatisk regel definitivt kommer att flagga ett 3.3.8-fel — automatiska resultat är endast en startpunkt.
2. Identifiera alla kognitiva funktionstester: Kartlägg manuellt varje steg i autentiseringsflödet. Notera varje steg som kräver att användaren minns information som inte tillhandahålls på den aktuella skärmen, transkriberar tecken, löser ett pussel eller utför en beräkning. Kontrollera om varje sådant steg har ett alternativ i enlighet med kraven (objektigenkänning, personligt innehåll, alternativ inloggningsmetod eller assisterande mekanism).
3. Testa funktionalitet för klistra in: För varje autentiseringsfält (användarnamn, lösenord, OTP, återställningskod), försök att klistra in text med tangentbordsgenvägen (Ctrl+V på Windows/Linux, Cmd+V på macOS). Bekräfta att den inklistrade texten visas i fältet. Upprepa med högerklicksmenyn. Om klistra in blockeras är detta ett fel om det inte finns ett alternativ utan kognitivt funktionstest.
4. Testa autofyll med en lösenordshanterare: Använd en webbläsare med en lösenordshanterare (inbyggd eller som tillägg), spara inloggningsuppgifter under registreringen och gå sedan tillbaka till inloggningssidan. Bekräfta att lösenordshanteraren kan upptäcka fälten och autofylla dem. Testa i Firefox med NVDA, Safari med VoiceOver (macOS/iOS) och Chrome med JAWS för att täcka de viktigaste kombinationerna av hjälpmedelsteknik och webbläsare. Om fälten använder icke-standardiserad markup eller JavaScript som rensar autofyllda värden är detta ett fel.
5. NVDA + Firefox — genomgång med skärmläsare: Navigera i inloggningsformuläret enbart med tangentbordet och NVDA. Bekräfta att varje fält går att nå, att fältetiketter läses upp korrekt och att eventuella CAPTCHA-widgets har ett tillgängligt alternativ. Om CAPTCHA:t är enbart visuellt utan ljudalternativ och utan alternativ inloggningsväg, notera ett fel.
6. VoiceOver + Safari (iOS): Försök på en mobil enhet att logga in med Face ID eller Touch ID om webbplatsen erbjuder biometrisk inloggning. Bekräfta att det biometriska alternativet går att nå via svepnavigering och att VoiceOver annonserar det korrekt. Detta bekräftar att ett alternativ utan kognitivt funktionstest är praktiskt tillgängligt, inte bara nominellt närvarande.
7. Kontrollera tidsgränser för kognitiva steg: Om ett CAPTCHA eller en OTP-inmatning har en tidsgräns, kontrollera om användaren kan förlänga eller inaktivera den (relevant för 2.2.1), och notera separat om det tidsbegränsade steget utgör ett kognitivt funktionstest utan alternativ.

Hur man åtgärdar

Text-CAPTCHA utan alternativ — Felaktigt

<!-- Fails 3.3.8: only authentication method is transcribing distorted text;
     no alternative login path is offered, and paste is disabled -->
<form action='/login' method='post'>
  <label for='user'>Username</label>
  <input type='text' id='user' name='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='off'
         onpaste='return false;'>

  <img src='/captcha-image.png' alt=''>
  <label for='captcha'>Type the characters above</label>
  <input type='text' id='captcha' name='captcha'
         autocomplete='off'
         onpaste='return false;'>

  <button type='submit'>Log in</button>
</form>

Text-CAPTCHA utan alternativ — Korrekt

<!-- Passes 3.3.8: text CAPTCHA is replaced with a passkey / magic-link option;
     password field supports autofill and paste so password managers can assist -->
<form action='/login' method='post'>
  <label for='user'>Username or email</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'>

  <!-- No CAPTCHA; bot protection handled server-side via risk-based signals -->
  <button type='submit'>Log in</button>
</form>

<!-- Cognitive-function-free alternative always visible -->
<p><a href='/magic-link'>Send me a sign-in link by email instead</a></p>
<p><a href='/passkey-login'>Sign in with a passkey or biometrics</a></p>

OTP-fält som blockerar klistra in — Felaktigt

<!-- Fails 3.3.8: user must manually type a 6-digit OTP;
     paste is suppressed, forcing a transcription task -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='off'
       onpaste='event.preventDefault();'
       ondrop='event.preventDefault();'>

OTP-fält som blockerar klistra in — Korrekt

<!-- Passes 3.3.8: paste and autofill are permitted;
     autocomplete='one-time-code' enables OS-level SMS/OTP autofill on mobile -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='one-time-code'>
<!-- Remove all paste/drop prevention handlers.
     Risk of credential stuffing is managed server-side, not by blocking paste. -->

Bildvals-CAPTCHA utan reservlösning (AAA-fråga, AA-godkänd) — Korrekt på AA

<!-- Passes 3.3.8 (AA): object recognition CAPTCHAs are explicitly
     exempted at the Minimum level. Selecting images of bicycles
     qualifies as object recognition, not character transcription.
     Note: this would fail 3.3.9 (AAA) — provide an alternative for full conformance. -->
<fieldset>
  <legend>Select all images that contain a bicycle</legend>
  <ul role='list'>
    <li>
      <input type='checkbox' id='img1' name='captcha' value='1'>
      <label for='img1'>
        <img src='/grid/img1.jpg' alt='A city street with parked vehicles'>
      </label>
    </li>
    <!-- additional grid items -->
  </ul>
</fieldset>

Vanliga misstag

• Att sätta autocomplete='off' på lösenordsfält: Detta inaktiverar lösenordshanterarens autofyll och tar bort den assisterande mekanism som gör standardlösenordsautentisering förenlig med kraven. Använd istället autocomplete='current-password' och låt webbläsaren hantera lagring av inloggningsuppgifter.
• Att blockera klistra in med onpaste='return false;' eller addEventListener('paste', e => e.preventDefault()): Detta tvingar användare att manuellt skriva in inloggningsuppgifter, vilket skapar en otillgänglig transkriberingsuppgift. Ta bort alla hanterare som förhindrar klistra in från autentiseringsfält.
• Att erbjuda ett passnyckelalternativ som inte är tangentbordsåtkomligt: Ett biometriskt alternativ uppfyller endast 3.3.8 om det går att nå och använda via tangentbord och hjälpmedelsteknik. En passnyckelknapp som är dold bakom en hovringsmeny eller renderas som ett icke-fokuserbart <div> räknas inte som ett alternativ i enlighet med kraven.
• Att använda ett text-CAPTCHA som den enda bot-skyddslösningen: Att gå över till riskbaserad, server-side-botdetektering (analys av device fingerprint, skrivkadens, IP-rykte) eliminerar det kognitiva funktionstestet helt utan att offra säkerhet. Att enbart förlita sig på klient-side-CAPTCHA är både ett tillgänglighetsfel och en dålig säkerhetspraxis.
• Att dela upp en OTP i flera enstaka teckenfält och blockera klistra in över fält: Vissa implementationer använder sex separata <input maxlength='1'>-fält för OTP-inmatning och auto-flyttar fokus via JavaScript. Detta mönster bryter rutinmässigt klistra in från lösenordshanterare och bryter mot 3.3.8 om inte implementationen uttryckligen hanterar att klistra in en hel kod i det första fältet och fördelar tecknen korrekt.
• Att kräva bildbaserat CAPTCHA endast i kontorecovery-flöden: Team lägger ofta till tillgängliga inloggningsalternativ på huvudinloggningssidan men glömmer step-up-autentisering, återställning av lösenord och upplåsning av konton. Var och en av dessa är ett separat autentiseringssteg och måste var för sig uppfylla 3.3.8.
• Att betrakta ljud-CAPTCHA som ett fullständigt alternativ till text-CAPTCHA: Ett ljudalternativ hjälper blinda användare men hjälper inte användare med kognitiva funktionsnedsättningar eller de i bullriga miljöer. Ljud-CAPTCHA innebär också ett eget transkriberingskrav. Den korrekta åtgärden är att eliminera CAPTCHA:t eller tillhandahålla en väg som helt saknar kognitivt funktionstest.
• Att dynamiskt generera id-attribut för inmatningsfält som bryter lösenordshanterarens detektering: När id-attribut på användarnamns- och lösenordsfält slumpas vid varje sidladdning (en missriktad anti-bot-teknik) kan lösenordshanterare inte pålitligt identifiera fälten. Detta inaktiverar i praktiken autofyll och tar bort den assisterande mekanism som uppfyller kraven.
• Att anta att tredjeparts-CAPTCHA-widgets automatiskt uppfyller kraven: Populära CAPTCHA-tjänster kan erbjuda tillgängliga varianter, men de är inte aktiverade som standard. Utvecklare måste uttryckligen konfigurera den tillgängliga versionen och måste fortfarande verifiera att den uppfyller standardens krav istället för att bara lägga till en ny typ av otillgängligt test.
• Att rensa autofyllda värden via JavaScript vid fokus: Vissa formulär rensar inmatningsinnehåll när ett fält får fokus för att visa platshållartext eller uppmana till ny inmatning. Om detta beteende rensar ett lösenordshanterar-autofyllt värde tvingar det fram manuell inmatning och bryter mot 3.3.8.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i Official Gazette nr 32933 den 21 juni 2025, fastställer krav på webb- och mobiltillgänglighet i linje med WCAG 2.2. Cirkuläret kräver att berörda aktörer uppnår nivå AA över sina digitala produkter och tjänster. WCAG 3.3.8, som ett kriterium på nivå AA i WCAG 2.2, omfattas därför direkt av de obligatoriska efterlevnadskraven som införs genom detta cirkulär.

Cirkuläret omfattar ett brett spektrum av privata och offentliga aktörer. Offentliga institutioner och myndigheter måste uppnå full AA-efterlevnad. Inom den privata sektorn gäller cirkuläret för e-handelsplattformar, banker och finansiella institutioner, sjukhus och privata vårdgivare, telekomoperatörer med 200,000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor som auktoriserats av Ministry of National Education (MoNE). För dessa organisationer skapar otillgängliga autentiseringsflöden – såsom inloggningssidor med CAPTCHA som saknar stöd eller OTP-fält som blockerar klistra in – direkt regulatorisk risk.

Accessibility Logo (Erişilebilirlik Logosu), utfärdad av Ministry of Family and Social Services, är den officiella certifieringssymbolen för efterlevnad av digital tillgänglighet i Turkiet. För att erhålla denna logotyp krävs påvisad efterlevnad på nivå AA, vilket omfattar 3.3.8. För e-handelsaktörer, banker och andra högtrafikerade digitala tjänsteleverantörer fungerar logotypen som en offentlig förtroendesignal och kan refereras i upphandlings- och anbudskrav. Autentiseringsflöden som bygger på otillgängliga kognitiva test skulle blockera certifiering och utsätta organisationen för klagomål och tillsynsåtgärder.

Ur ett praktiskt efterlevnadsperspektiv bör turkiska organisationer granska varje autentiseringskontaktpunkt – inklusive inloggning, registrering, MFA, återställning av lösenord och upplåsning av konto – mot 3.3.8 innan de lämnar in för bedömning av Accessibility Logo. Att ersätta text-CAPTCHA med riskbaserade server-side-kontroller, aktivera autocomplete på alla fält för inloggningsuppgifter och erbjuda passnyckel- eller magisk-länk-alternativ är de mest effektiva åtgärderna. Dessa förändringar uppfyller samtidigt de regulatoriska kraven och förbättrar autentiseringsupplevelsen för de uppskattningsvis 8,5 miljoner personer med funktionsnedsättning i Turkiet som använder digitala tjänster.