Tillgänglig autentisering (minimum)

Vad det kräver

För att autentisera sig får användaren inte tvingas genomföra ett kognitivt funktionstest – att minnas ett lösenord, transkribera en kod, identifiera objekt i bilder eller lösa ett pussel – om inte ett av följande gäller:

• Alternativ: en annan autentiseringsmetod som inte kräver ett kognitivt funktionstest finns tillgänglig.
• Mekanism: hjälp finns tillgänglig för att slutföra testet (automatisk ifyllning via lösenordshanterare, kopiera-klistra från ett verifieringsmail).
• Igenkänning av objekt: testet kräver bara igenkänning av objekt, inte lösning av ett pussel (detta undantag är snävt).
• Personligt innehåll: testet kräver bara identifiering av icke-textinnehåll som användaren själv tillhandahållit (t.ex. sin profilbild).

Syftet är att göra autentisering möjlig för användare med kognitiva funktionsnedsättningar, minnesproblem, dyslexi och afasi, som systematiskt utestängs av lösenords- och CAPTCHA-baserade flöden.

Hur man uppfyller det

• Tillåt lösenordshanterare: blockera inte inklistring i lösenordsfält, inaktivera inte automatisk ifyllning, ta inte bort autocomplete="current-password" / autocomplete="new-password". Denna enda åtgärd räcker ofta för att uppfylla framgångskriteriet.
• Stöd lösenordsnycklar (passkeys) / WebAuthn: en biometrisk eller enhetsbunden autentiseringsuppgift kringgår det kognitiva testet helt.
• Stöd OAuth / inloggning med socialt konto som alternativ väg.
• Magiska länkar: skicka en länk för direktinloggning via e-post istället för att kräva lösenordsåterkallelse.
• E-post- / SMS-koder: se till att kopiera-klistra fungerar från meddelandet till fältet, och låt systemet fylla i automatiskt där plattformen stöder det (t.ex. iOS automatisk ifyllning av SMS-koder).
• Undvik bild-CAPTCHA (reCAPTCHAs “klicka alla trafikljus”) om inte ett icke-kognitivt alternativ erbjuds.
• Tillåt knapp för att visa lösenord: hjälper användare med dyslexi eller motoriska svårigheter att verifiera sin inmatning.

Vanliga fel

• Inloggningsformulär som blockerar inklistring i lösenordsfältet – detta enda antimönster bryter mot 3.3.8 direkt för användare som är beroende av lösenordshanterare.
• autocomplete="off" på lösenordsinmatningar, vilket förhindrar automatisk ifyllning från webbläsare och lösenordshanterare.
• Bild-CAPTCHA som enda verifieringssteg, utan ljud eller alternativ.
• Multifaktorflöden som visar en 6-siffrig kod på en enhet och kräver att användaren memorerar och skriver in den i en annan, utan möjlighet att kopiera-klistra.
• Inloggningssidor som kräver att användaren identifierar vilken av nio bilder som innehåller ett specifikt objekt.
• “Säkerhetsfråge”-flöden som kräver återkallelse av oklar personlig information (“förnamn på första husdjuret”) utan reservalternativ.
• Lösenordsregler som förbjuder vanliga mönster OCH förbjuder inklistring, vilket tvingar fram manuell inmatning av en osäker sträng.
• Autentiseringsappkoder utan automatisk ifyllning och utan kopieringsstöd, vilket kräver transkribering inom ett 30-sekunders fönster.

Varför det är viktigt

Det här är det mest uppmärksammade nya framgångskriteriet i WCAG 2.2 och det som sannolikt tvingar fram produktändringar hos stora företag. Kognitiva funktionsnedsättningar drabbar fler än var tionde vuxen, och modellen “kom ihåg det här lösenordet” har alltid misslyckats för dem – framgångskriteriet formaliserar det misslyckandet som ett efterlevnadsproblem.

Den vanligaste vägen till efterlevnad är också den billigaste: tillåt inklistring, tillåt automatisk ifyllning, stöd lösenordsnycklar och magiska länkar. Många befintliga inloggningssidor kan bli 3.3.8-kompatibla genom att tre rader antiinklipskod tas bort. CAPTCHA-ersättningar är det svårare problemet – moderna alternativ inkluderar enhetsbaserad riskbedömning (Cloudflare Turnstile, hCaptcha osynligt läge) och beteendeanalys, som båda kringgår det kognitiva testet för de flesta användare.

Förvänta att 3.3.8 dominerar 2.2-granskningsfynd under de kommande åren.