När ett gränssnittskomponent tar emot tangentbordsfokus måste fokusen indikatorn ha ett kontrastförhållande på minst 3:1 mot angränsande färg och täcka åtminstone omkretsen av en 2 CSS-pixel solid kontur runt det fokuserade elementet, eller ett ekvivalent indikatorområde. Kriteriet är ett av de få WCAG-tillägg som specificerar mätbar geometri snarare än beteende.

De standardfokusringar i webbläsare som designers spenderade femton år på att åsidosätta av estetiska skäl misslyckas med den här mätningen på majoriteten av granskade produktionssajter. Anpassade fokusstjärnor tenderar att använda 1 px-konturer eller lågkontrastiga accentfärger som ser korrekta ut i designverktyg men hamnar under 3:1 mot bakgrunden av det faktiska fokuserade elementet.

Siffran spelar roll trots att kriteriet är AAA: den indikerar vad som skulle hända om en framtida regulator låser vid WCAG 2.2 nivå AAA, eller om ett upphandlingsavtal lyfter just det här kriteriet.

Sätt en 2 CSS-pixel kontur i en färg som ger minst 3:1 mot elementets bakgrund; verifiera med ett kontrastkontrollverktyg snarare än med blotta ögat. Där designsystemet åsidosätter webbläsarens fokus, exponera en fokusstilstoken som designers inte av misstag kan sänka under kontrasttröskeln.

Pekmålet för varje pekarinmatning måste vara minst 24 × 24 CSS-pixlar, utom när målet är inbäddat i en mening, när det storleksätts av användaragenten, när ett likvärdigt mål är tillgängligt, eller när målets funktion är väsentlig. Kriteriet mäter pekmålet, inte den synliga ikonen.

Kriteriet fångar ett specifikt UI-mönster: täta ikonverktygsfält, särskilt i redigerare, instrumentpaneler och datatabellshuvuden. De flesta ikonknappsbibliotek har standardikonsstorlekar på 16×16 eller 20×20 visuella pixlar inuti ett något större pekmål. Där pekmålet också är under 24×24 misslyckas kriteriet — och verktygsfältsdesigners minskar rutinmässigt mellanrummen för att få plats med fler ikoner i begränsat horisontellt utrymme.

Sätt en minsta pekmålstoken på 24 × 24 CSS-pixlar i designsystemet, tillämpad via utfyllnad snarare än ikonens egna dimensioner. Där verktygsfält inte kan rymma golvet, lägg till tillräckligt mellanrum så att angränsande mål inte hamnar inom kriteriets överlappningsundantag. Tillhandahåll en inställningsnivåekvivalent (en större meny) för de verkligt trångbodda ytorna.

Autentiseringssteget för en webbplats eller app kan inte förlita sig på ett kognitivt funktionstest — lösa ett pussel, transkribera en förvrängd bild, känna igen objekt i ett rutnät — om inte en alternativ autentiseringsmetod tillhandahålls, ett hjälpmedel finns tillgängligt, eller ett undantag för objektigenkänning gäller. Att memorera ett lösenord räknas som ett kognitivt funktionstest, varför lösenordshanterare uttryckligen tillgodoses.

De flesta bildbaserade CAPTCHA misslyckas med detta på stående fot. Detsamma gäller “klicka på rutorna med trafikljus”-utmaningar, förvrängda texttranskriptionstest och alla flöden som klistrar in en engångskod i ett fält men inaktiverar inklistringsinteraktionen. Mönstret är koncentrerat till inloggnings-, lösenordsåterställnings- och kontoregistreringsflöden — precis de högriskpunkter där det kostar mest att stängas ute.

Autentiseringsflöden är också det område där kriteriets skärpa är störst, eftersom felet inte försämrar upplevelsen — det avslutar den.

Ersätt kognitiva CAPTCHA med ett icke-kognitivt alternativ — enhetsbaserad attestering, magiska länkar, lösenordsnycklar (passkeys), eller osynlig riskbedömning. Tillåt autofyll från lösenordshanterare. Se till att kopiera och klistra in fungerar i fält för engångskoder. Där ett CAPTCHA måste finnas kvar, tillhandahåll ett ljudalternativ som i sig inte kräver transkription av förvrängd tal.

När ett gränssnittskomponent tar emot tangentbordsfokus får det fokuserade elementet inte vara helt dolt av skaparskapat innehåll. Partiell ockludion är tillåten på den här nivån (ett klisterhuvud som täcker övre halvan av ett fokuserat fält är tillåtet); total ockludion är det inte.

Den vanligaste kollisionen är ett klisterhuvud — ibland en cookiebanner eller flytande chattwidget — som täcker det fokuserade formulärfältet när en tangentbordsanvändare tabbar in i det. Produktionssajter som lade till ett klisterhuvud på ett befintligt formulär under omdesignperioden 2020–22 missade rutinmässigt fokus-och-rullningsbeteendet eftersom det ursprungliga formuläret skapades innan klisterelement existerade.

Sätt scroll-margin-top (eller scroll-padding-top på rullningsbehållaren) lika med höjden på eventuella klistrande överlagringar. Testa att tabbning igenom ett långt formulär rullar det fokuserade elementet helt in i synfältet under eventuella huvuden. Para ihop detta med fokus-synliga stilar så att användaren kan se var fokus faktiskt hamnade.

Funktioner som använder en drag-rörelse måste också kunna användas via en enpunktsåtgärd — ett tryck, ett klick eller ett likvärdigt alternativ som inte kräver uthållen pekarörelse. Dra-och-släpp-interaktioner är inte förbjudna; de kan helt enkelt inte vara den enda tillgängliga vägen till funktionen.

Listordnings- och kanban-liknande UI:er levereras ofta med drag-enbart-sortering. Detsamma gäller skjutreglage implementerade som draftbara tummar utan ett motsvarande spinbutton- eller textinmatningsfält, och bildklippnings-UI:er som kräver ett drag för att ange gränser. Kriteriet fångar dessa varje gång.

För varje drag-interaktion, leverera ett likvärdigt tryck/klick-alternativ — “flytta upp” och “flytta ned”-knappar bredvid dragbara listobjekt, ett numeriskt inmatningsfält bredvid ett skjutreglage, ett klicka-för-att-ange-gränser-läge i klippverktyget. Där alternativet är dolt i en kontextmeny, se till att det är nåbart via tangentbordet.

Inom samma autentiserade process, kräv inte att användaren anger samma information två gånger — om inte återinmatning är väsentlig, den tidigare inmatningen inte längre är giltig, eller informationen rör säkerhet (ett lösenordsupprepning vid kontoregistrering är det kanoniska undantaget). Att fylla i eller välja från tidigare angivna värden tillgodoser båda kriteriet.

Flerstegskassaflöden, flersidiga ansökningsformulär och visum-/tillståndsansökningar ber rutinmässigt om samma adress, namn eller kontaktinformation i två separata steg eftersom stegen byggdes av olika team och aldrig samordnades. Användarens tidigare angivna värden hålls inte kvar i en session som delas mellan stegen.

Behåll användares angivna värden mellan stegen i en enskild process; fyll i matchande fält i efterföljande steg i förväg; eller exponera ett enpunkts “använd samma adress”-reglage. Mönstret dyker vanligtvis upp vid processmappning snarare än vid klientdelsgranskning, så en tvärteamsbedömning av flödet är det praktiska åtgärdssteget.

Om en hjälpmekanism tillhandahålls — en kontaktlänk, en hjälplänk, en chattwidget, ett supporttelefonnummer, en självhjälpslänk — måste den visas på samma relativa plats på de sidor där den tillhandahålls. Kriteriet kräver inte att hjälp ska finnas; bara att, där den finns, placeringen är konsekvent.

Kriteriet är enkelt i princip och fångar en smal uppsättning sajter som har en “Kontakta oss”-länk i sidhuvudet på vissa sidor, i en sidfot på andra, och inuti en flytande chattwidget på en tredje uppsättning sidor — ofta resultatet av flera webbplatsavsnitt ägda av olika team med separata mallar.

Granska placeringen av hjälpmekanismer i alla mallar; enas om en enda kanonisk plats (sidhuvud, permanent sidfot eller flytande widget) och åtgärda eventuella avvikare. Åtgärden är sällan teknisk; det är ett styrningssteg för innehåll och mallar.

AAA-kusinen till 2.4.11: när ett gränssnittskomponent tar emot tangentbordsfokus får det fokuserade elementet inte vara alls dolt av skaparskapat innehåll. Partiell ockludion är förbjuden på den här nivån — ett klisterhuvud som täcker någon del av det fokuserade fältet misslyckas.

Samma klistrande-overlappningskollisioner som driver 2.4.11-fel kvarstår vid 2.4.12. Sajter som antog scroll-margin-top för att tillgodose minimumkriteriet tenderar fortfarande att lämna några CSS-pixlars överlappning på kantfalls-viewporthöjder. På AAA är den överlappningen felet.

Justera scroll-margin-top så att det bekvämt överstiger höjden på varje skaparskapat lager, inklusive dynamiska sådana (cookiebanners som visas vid första besöket, chattwidgets som expanderar vid hover). Lägg till explicita regressionstester för tabb-in-i-formulär-beteende vid vanliga viewportstorlekar.

AAA-kusinen till 3.3.8: autentisering kan inte förlita sig på ett kognitivt funktionstest, punkt. Undantagen för objektigenkänning och personligt innehåll som gäller på AA gäller inte här. Minnestester, transkriptionstester och bildigenknänningsutmaningar misslyckas alla på den här nivån.

Även sajter som ersatte traditionella CAPTCHA med objektigenknänningsutmaningar (AA-undantaget) misslyckas med 3.3.9. Kriteriet är arbetsgruppens signal om vart autentisering bör gå: bort från kognitiva utmaningar helt och hållet, och mot enhetsattest eller biometrisk verifiering.

Anta lösenordsnycklar (WebAuthn) som primär autentiseringsmekanism; behandla lösenord-plus-lösenordsnyckel som ett övergångstillstånd snarare än en destination. Där bildigenknänning har behållits för riskbedömning, kör det serversidan baserat på beteendesignaler snarare än som en användarriktad utmaning.