Gdy komponent interfejsu użytkownika otrzymuje fokus klawiatury, wskaźnik fokusu musi spełniać minimalny współczynnik kontrastu wynoszący 3:1 względem sąsiadujących kolorów i pokrywać co najmniej obwód 2-pikselowego (CSS) solidnego zarysu wokół sfokusowanego elementu lub równoważnego obszaru wskaźnika. Kryterium jest jednym z nielicznych uzupełnień WCAG określających mierzalną geometrię, a nie zachowanie.

Domyślne obramowania fokusu przeglądarek, które projektanci przez piętnaście lat zastępowali ze względów estetycznych, nie spełniają tego pomiaru w przypadku większości audytowanych produkcyjnych serwisów. Niestandardowe style fokusu używają zazwyczaj 1-pikselowych zarysów lub kolorów akcentu o niskim kontraście, które wyglądają poprawnie w narzędziach projektowania, lecz uzyskują wyniki poniżej 3:1 względem tła sfokusowanego elementu.

Liczba ma znaczenie mimo że kryterium jest AAA: wskazuje, co by się stało, gdyby przyszły regulator przypiął do WCAG 2.2 poziom AAA lub gdyby umowa zamówieniowa wyodrębniła to jedno kryterium.

Należy ustawić 2-pikselowy (CSS) zarys w kolorze uzyskującym co najmniej 3:1 względem tła elementu; weryfikować to narzędziem do sprawdzania kontrastu, a nie gołym okiem. W miejscach, gdzie system projektowania zastępuje fokus przeglądarki, należy udostępnić token stylu fokusu, którego projektanci nie mogą przypadkowo obniżyć poniżej progu kontrastu.

Cel dotyku każdego wejścia wskaźnikowego musi wynosić co najmniej 24 na 24 piksele CSS, z wyjątkiem sytuacji, gdy cel jest wbudowany w zdanie, gdy jest skalowany przez agenta użytkownika, gdy dostępny jest równoważny cel lub gdy funkcja celu jest niezbędna. Kryterium mierzy cel dotyku, a nie widoczną ikonę.

Kryterium wychwytuje konkretny wzorzec UI: gęste paski narzędzi z ikonami, szczególnie w edytorach, panelach i nagłówkach tabel danych. Większość bibliotek przycisków-ikon domyślnie ustawia rozmiar ikon 16×16 lub 20×20 pikseli w nieznacznie większym celu dotyku. Gdy cel dotyku jest również poniżej 24×24, kryterium nie jest spełnione — a projektanci pasków narzędzi rutynowo zmniejszają odstępy, by zmieścić więcej ikon w ograniczonej szerokości.

Należy ustawić minimalny token celu dotyku wynoszący 24 na 24 piksele CSS w systemie projektowania, stosowany poprzez dopełnienie, a nie własne wymiary ikony. W przypadku pasków narzędzi, które nie mogą pomieścić progu, należy dodać odpowiedni odstęp, aby sąsiadujące cele nie znajdowały się w zasięgu wykluczenia nakładania z kryterium. Należy zapewnić równoważnik na poziomie ustawień (większe menu) dla rzeczywiście zatłoczonych powierzchni.

Krok uwierzytelnienia w serwisie lub aplikacji nie może opierać się na teście funkcji poznawczej — rozwiązywaniu zagadki, przepisywaniu zniekształconego obrazu, rozpoznawaniu obiektów w siatce — chyba że zapewniono alternatywną metodę uwierzytelnienia, dostępny jest mechanizm wspomagający lub ma zastosowanie wyjątek dotyczący rozpoznawania obiektów. Zapamiętywanie hasła liczy się jako test funkcji poznawczej, dlatego menedżery haseł są wyraźnie uwzględnione.

Większość CAPTCHA opartych na obrazach zawodzi tutaj z definicji. Podobnie zadania „kliknij kwadraty ze światłami drogowymi“, testy przepisywania zniekształconego tekstu i każdy przepływ wklejający jednorazowy kod do pola, lecz wyłączający interakcję wklejania. Wzorzec koncentruje się w przepływach logowania, resetowania hasła i zakładania konta — dokładnie w punktach o wysokich stawkach, gdzie blokada ma największy koszt.

Przepływy uwierzytelniania to jednocześnie obszar, w którym oddziaływanie kryterium jest najostrzejsze, ponieważ błąd nie degraduje doświadczenia — kończy je.

Należy zastąpić CAPTCHA oparte na funkcjach poznawczych niepoznawczą alternatywą — atestacją opartą na urządzeniu, magic links, passkeys lub niewidocznym scoringiem ryzyka. Zezwolić na autouzupełnianie przez menedżery haseł. Zapewnić działanie kopiuj-wklej w polach jednorazowych kodów. W miejscach, gdzie CAPTCHA musi pozostać, zapewnić alternatywę audio, która sama w sobie nie wymaga przepisywania zniekształconej mowy.

Gdy komponent interfejsu użytkownika otrzymuje fokus klawiatury, sfokusowany element nie może być całkowicie ukryty przez treść stworzoną przez autora. Częściowe zasłonięcie jest dozwolone na tym poziomie (lepki nagłówek nakładający się na górną połowę sfokusowanego pola jest dopuszczalny); całkowite zasłonięcie jest niedozwolone.

Najczęstszą kolizją jest lepki nagłówek — niekiedy baner o plikach cookie lub pływający widget czatu — nakładający się na sfokusowane pole formularza, gdy użytkownik klawiatury wchodzi w nie tabulatorem. Produkcyjne serwisy, które nałożyły lepki nagłówek na istniejący formularz w erze redesignu 2020–22, rutynowo pomijały zachowanie fokusu i przewijania, ponieważ oryginalny formularz powstał przed erą elementów lepkich.

Należy ustawić scroll-margin-top (lub scroll-padding-top na kontenerze przewijania) równy wysokości każdej nakładki lepkiej. Przetestować, czy nawigacja tabulatorem przez długi formularz przewija sfokusowany element w całości poniżej nagłówka. Połączyć to z widocznymi stylami focused-visible, żeby użytkownik widział, gdzie faktycznie wylądował fokus.

Funkcja wykorzystująca ruch przeciągania musi być również dostępna za pomocą akcji jednowskaźnikowej — dotknięcia, kliknięcia lub odpowiednika niewymagającego stałego ruchu wskaźnika. Interakcje drag-and-drop nie są zakazane; po prostu nie mogą być jedyną dostępną ścieżką do funkcji.

Interfejsy zmiany kolejności list i kanban często dostarczane są wyłącznie z zmienianiem kolejności przez przeciąganie. To samo dotyczy elementów sterujących suwakiem zaimplementowanych jako przeciągalne suwaki bez odpowiadającego im pola spinbutton lub tekstowego oraz interfejsów przycinarki obrazów wymagających przeciągania do ustawienia granic. Kryterium wychwytuje te przypadki za każdym razem.

Dla każdej interakcji przeciągania należy dostarczyć równoważnik dotykowy/kliknięciem — przyciski „przesuń w górę“ i „przesuń w dół“ obok przeciągalnych elementów listy, wejście numeryczne obok suwaka, tryb kliknij-aby-ustawić-granice w przycinarce. W miejscach, gdzie alternatywa jest ukryta w menu kontekstowym, należy zapewnić jej dostępność z klawiatury.

W ramach tego samego uwierzytelnionego procesu nie należy wymagać od użytkownika dwukrotnego wprowadzenia tych samych informacji — chyba że ponowne wpisanie jest niezbędne, poprzedni wpis nie jest już ważny lub informacja dotyczy bezpieczeństwa (ponowne wpisanie hasła podczas zakładania konta to kanoniczny wyjątek). Automatyczne wypełnianie lub wybieranie z wcześniej wprowadzonych wartości spełniają kryterium.

Wieloetapowe przepływy zakupu, wielostronicowe formularze wniosków oraz wnioski wizowe/o pozwolenia rutynowo proszą o te same dane adresowe, imię i nazwisko lub dane kontaktowe w dwóch oddzielnych krokach, ponieważ kroki te były budowane przez różne zespoły i nigdy nie zostały ujednolicone. Wcześniej wprowadzone wartości użytkownika nie są przechowywane w sesji współdzielonej między krokami.

Należy utrwalać wartości wprowadzone przez użytkownika między etapami jednego procesu; wstępnie wypełniać pasujące pola w kolejnych krokach; lub udostępnić kontrolkę jednokliknij „użyj tego samego adresu“. Wzorzec zazwyczaj ujawnia się podczas mapowania procesu, a nie podczas audytu front-endu, więc praktycznym krokiem naprawczym jest przegląd przepływu między zespołami.

Jeśli zapewniony jest mechanizm pomocy — link kontaktowy, link do pomocy, widget czatu, numer telefonu wsparcia, link do samodzielnej pomocy — musi on pojawiać się w tej samej względnej lokalizacji na stronach, na których jest dostępny. Kryterium nie wymaga obecności pomocy; jedynie tego, żeby tam, gdzie jest obecna, jej umiejscowienie było spójne.

Kryterium jest proste w zasadzie i wychwytuje wąski zestaw serwisów, które mają link „Skontaktuj się z nami“ w nagłówku na niektórych stronach, w stopce na innych i wewnątrz pływającego widgetu czatu na trzecim zestawie stron — często w wyniku różnych sekcji serwisu należących do różnych zespołów z osobnymi szablonami.

Należy przeprowadzić audyt umieszczenia mechanizmów pomocy w różnych szablonach; ustalić jedną kanoniczną lokalizację (nagłówek, stała stopka lub pływający widget) i ujednolicić wszelkie wyjątki. Naprawa rzadko jest techniczna; to krok zarządzania treścią i szablonami.

Odpowiednik AAA kryterium 2.4.11: gdy komponent interfejsu użytkownika otrzymuje fokus klawiatury, sfokusowany element nie może być w żaden sposób zasłonięty przez treść stworzoną przez autora. Częściowe zasłonięcie jest na tym poziomie zabronione — lepki nagłówek zakrywający jakąkolwiek część sfokusowanego pola nie spełnia kryterium.

Te same kolizje z lepkimi nakładkami, które napędzają błędy 2.4.11, utrzymują się przy 2.4.12. Serwisy, które zastosowały scroll-margin-top dla spełnienia kryterium minimum, mają nadal tendencję do pozostawiania kilku pikseli CSS nakładki przy granicznych wysokościach okna. Na poziomie AAA ta nakładka to błąd.

Należy dostroić scroll-margin-top tak, by wygodnie przekraczał wysokość każdej nakładki stworzonej przez autora, w tym dynamicznych (banery o plikach cookie pojawiające się przy pierwszej wizycie, widgety czatu rozwijające się po najechaniu). Dodać explicitne testy regresji dla zachowania tab-into-form przy typowych rozmiarach okna.

Odpowiednik AAA kryterium 3.3.8: uwierzytelnianie nie może opierać się na teście funkcji poznawczej, kropka. Wyjątki dotyczące rozpoznawania obiektów i treści osobistych stosowane na poziomie AA nie mają tutaj zastosowania. Testy pamięciowe, testy przepisywania i zadania rozpoznawania obrazów zawodzą na tym poziomie.

Nawet serwisy, które zastąpiły tradycyjne CAPTCHA zadaniami rozpoznawania obiektów (wyjątek AA), nie spełniają kryterium 3.3.9. Kryterium to sygnał grupy roboczej wskazujący kierunek, w jakim powinno zmierzać uwierzytelnianie: z dala od wyzwań poznawczych w całości, w kierunku atestacji urządzenia lub weryfikacji biometrycznej.

Należy przyjąć passkeys (WebAuthn) jako podstawowy mechanizm uwierzytelniania; traktować hasło-plus-passkey jako stan przejściowy, a nie docelowy. W miejscach, gdzie rozpoznawanie obrazów zostało zachowane dla scoringu ryzyka, uruchamiać je po stronie serwera na podstawie sygnałów behawioralnych, a nie jako wyzwanie widoczne dla użytkownika.