WCAG 3.3.8: Dostępne uwierzytelnianie (minimum)

Co Oznacza Ta Zasada

WCAG 3.3.8 Accessible Authentication (Minimum) to kryterium na poziomie AA wprowadzone w WCAG 2.2. Stanowi ono, że test funkcji poznawczych — zdefiniowany jako zadanie wymagające od użytkownika zapamiętania, przetworzenia lub przepisania informacji — nie może być jedynym sposobem ukończenia kroku uwierzytelniania, chyba że spełniony jest co najmniej jeden z poniższych warunków:

• Alternatywna metoda: Dostępna jest inna ścieżka uwierzytelniania, która nie opiera się na teście funkcji poznawczych (na przykład magiczny link wysłany e-mailem, logowanie biometryczne lub klucz dostępu).
• Mechanizm wspomagający: Agent użytkownika lub narzędzie zewnętrzne może ukończyć krok w imieniu użytkownika — na przykład menedżer haseł automatycznie uzupełniający dane logowania lub akcja kopiuj-wklej dla jednorazowego kodu.
• Wyjątek dotyczący rozpoznawania obiektów: Test funkcji poznawczych polega na identyfikowaniu obiektu na obrazie (na przykład wybieranie wszystkich obrazów zawierających sygnalizację świetlną) — tego typu test jest dozwolony na poziomie Minimum (AA).
• Wyjątek dotyczący treści osobistych: Test opiera się na treści dostarczonej przez samego użytkownika, takiej jak wybór wcześniej przesłanego zdjęcia z siatki.

W praktyce formularz logowania, który wymaga jedynie nazwy użytkownika i hasła, spełnia to kryterium, pod warunkiem że formularz umożliwia działanie autouzupełniania przeglądarki i menedżerów haseł (tzn. pola używają standardowego <input type='password'> i nie blokują wklejania). CAPTCHA wymagająca przepisania zniekształconego tekstu bez jakiejkolwiek alternatywnej ścieżki uwierzytelniania jest wyraźnym naruszeniem. CAPTCHA prosząca użytkowników o wybór obrazów pasujących do kategorii (rozpoznawanie obiektów) jest dozwolona na poziomie AA, ale jest traktowana bardziej rygorystycznie na poziomie AAA (3.3.9).

Kryterium ma zastosowanie do wszystkich kroków procesu uwierzytelniania: początkowego logowania, uwierzytelniania podwyższonego poziomu, weryfikacji wieloskładnikowej, odzyskiwania konta i ponownego uwierzytelniania sesji. Dotyczy ono również każdego procesu, który chroni dostęp do funkcjonalności, a nie tylko głównego ekranu logowania.

Kluczową implikacją techniczną jest to, że deweloperzy nie mogą używać autocomplete='off' w polach uwierzytelniania, nie mogą wyłączać wklejania za pomocą obsługi zdarzeń JavaScript i nie mogą naruszać standardowej semantyki pól wejściowych, która umożliwia prawidłowe działanie technologii asystujących i autouzupełniania przeglądarki.

Dlaczego To Ma Znaczenie

Uwierzytelnianie jest bramą do niemal każdej cyfrowej usługi, z której ludzie korzystają na co dzień — bankowości, portali zdrowotnych, usług rządowych, e-commerce i platform komunikacyjnych. Gdy ta brama nakłada bariery poznawcze, systematycznie wyklucza znaczną część populacji.

Niepełnosprawności poznawcze obejmują szerokie spektrum: dysleksję, dyskalkulię, zaburzenia uwagi, nabyte urazy mózgu, demencję, niepełnosprawność intelektualną i zaburzenia lękowe. Światowa Organizacja Zdrowia szacuje, że około 1 na 6 osób na świecie doświadcza jakiejś formy istotnej niepełnosprawności, a schorzenia poznawcze i neurologiczne stanowią jedną z największych kategorii. Dla tych użytkowników zadania takie jak dokładne przepisanie ciągu zniekształconych znaków, rozwiązanie wizualnej łamigłówki pod presją czasu czy przełączanie się między aplikacją uwierzytelniającą a formularzem logowania mogą być realnie niemożliwe lub skrajnie wyczerpujące.

Rozważmy konkretny scenariusz: osoba z dysleksją próbuje zalogować się do portalu ubezpieczenia zdrowotnego, aby zobaczyć wyniki badań. Strona prezentuje tekstową CAPTCHA bez alternatywy dźwiękowej i bez możliwości jej ominięcia. Zniekształcone kształty liter są dla tej osoby nie do odróżnienia, a pole wprowadzania blokuje wklejanie. Po kilku nieudanych próbach konto zostaje zablokowane. Użytkownik nie może uzyskać dostępu do pilnych informacji medycznych. Nie jest to hipotetyczny przypadek brzegowy — to rutynowe doświadczenie milionów ludzi.

Dotyczy to także użytkowników z niepełnosprawnością ruchową, którzy polegają na przełącznikach lub urządzeniach śledzących ruch gałek ocznych. Ponowne wpisywanie złożonego jednorazowego kodu z osobnego urządzenia lub przeciąganie kafelków z obrazami w określonej kolejności może być fizycznie niemożliwe przy użyciu tych metod wprowadzania. Umożliwienie kopiuj-wklej lub uwierzytelniania opartego na kluczach dostępu całkowicie usuwa tę barierę.

Osoby starsze stanowią kolejną istotną grupę. Związany z wiekiem spadek funkcji poznawczych wpływa na pamięć i szybkość przetwarzania informacji, co sprawia, że złożone CAPTCHA i wieloetapowe zadania zapamiętywania są nieproporcjonalnie trudne. W miarę starzenia się populacji w Turcji i na całym świecie biznesowy i regulacyjny argument za dostępnym uwierzytelnianiem staje się z roku na rok silniejszy.

Z perspektywy użyteczności i konwersji tarcie w przepływach uwierzytelniania bezpośrednio zwiększa wskaźniki porzucenia. Platformy e-commerce, które zastępują tekstowe CAPTCHA uwierzytelnianiem opartym na ryzyku lub kluczach dostępu, konsekwentnie odnotowują wyższe wskaźniki ukończonych logowań i niższe koszty wsparcia związane z zablokowanymi kontami.

Powiązane Reguły Axe-core

WCAG 3.3.8 jest sklasyfikowane jako wymagające testów manualnych, ponieważ narzędzia automatyczne nie są w stanie w pełni ocenić, czy proces uwierzytelniania nakłada niedostępny test funkcji poznawczych. Ustalenie, czy przepływ logowania nie ma alternatywnej ścieżki lub czy wklejanie jest blokowane w sposób zależny od kontekstu, wymaga osądu człowieka i interakcji z działającym przepływem uwierzytelniania. Niemniej jednak pewne automatyczne kontrole wspierają to kryterium:

• Przegląd manualny — audyt przepływu uwierzytelniania: Testerzy muszą przejść przez każdy krok uwierzytelniania i ustalić, czy występuje test funkcji poznawczych, a jeśli tak, czy istnieje zgodna alternatywa lub mechanizm wspomagający. Obecnie żadna reguła axe-core nie jest uruchamiana automatycznie dla tego kryterium, ponieważ logika zależy od zrozumienia celu i kontekstu pól formularza oraz otaczającego interfejsu, a nie tylko ich znaczników.
• Kontrole atrybutu autocomplete (powiązane): Reguła axe-core autocomplete-valid oznacza pola wejściowe, których wartości atrybutu autocomplete nie pochodzą z listy tokenów WCAG 1.3.5. Chociaż reguła ta bezpośrednio dotyczy 1.3.5, jest kontrolą wspierającą 3.3.8: jeśli autocomplete='username' i autocomplete='current-password' są nieobecne lub ustawione nieprawidłowo, menedżery haseł nie mogą autouzupełniać, usuwając mechanizm wspomagający, który sprawia, że standardowe logowanie hasłem jest zgodne z 3.3.8.
• Wykrywanie blokowania wklejania — manualne: Skanery automatyczne nie są w stanie wiarygodnie wykryć JavaScriptu, który przechwytuje zdarzenia paste i tłumi je w polach uwierzytelniania. Tester manualny musi spróbować wkleić dane logowania lub OTP do każdego odpowiedniego pola i potwierdzić, że akcja się powiodła.
• Wykrywanie alternatywy dla CAPTCHA — manualne: Axe-core może wykryć obecność popularnych widżetów CAPTCHA (np. iframe reCAPTCHA), ale nie może ustalić, czy alternatywna ścieżka uwierzytelniania jest oferowana gdzie indziej na stronie lub inną drogą. To ustalenie wymaga manualnej inspekcji całego doświadczenia uwierzytelniania.

Jak Testować

1. Skan automatyczny (axe DevTools / Lighthouse): Uruchom axe DevTools na każdej stronie uwierzytelniania (logowanie, rejestracja, odzyskiwanie konta, MFA). Wyszukaj naruszenia autocomplete-valid w polach nazwy użytkownika i hasła. W Lighthouse przejrzyj audyt Accessibility pod kątem problemów związanych z formularzami. Zauważ, że żadna reguła automatyczna nie wskaże jednoznacznie naruszenia 3.3.8 — wyniki automatyczne są jedynie punktem wyjścia.
2. Identyfikacja wszystkich testów funkcji poznawczych: Ręcznie skataloguj każdy krok w przepływie uwierzytelniania. Zanotuj każdy krok, który wymaga od użytkownika przypomnienia sobie informacji niepodanych na bieżącym ekranie, przepisania znaków, rozwiązania łamigłówki lub wykonania obliczenia. Sprawdź, czy każdy taki krok ma zgodną alternatywę (rozpoznawanie obiektów, treści osobiste, alternatywną metodę logowania lub mechanizm wspomagający).
3. Testowanie funkcji wklejania: W każdym polu uwierzytelniania (nazwa użytkownika, hasło, OTP, kod odzyskiwania) spróbuj wkleić tekst za pomocą skrótu klawiaturowego (Ctrl+V w Windows/Linux, Cmd+V w macOS). Potwierdź, że wklejona treść pojawia się w polu. Powtórz, używając menu kontekstowego pod prawym przyciskiem myszy. Jeśli wklejanie jest blokowane, jest to naruszenie, chyba że istnieje alternatywa wolna od testu funkcji poznawczych.
4. Testowanie autouzupełniania z menedżerem haseł: Korzystając z przeglądarki z menedżerem haseł (wbudowanym lub w formie rozszerzenia), zapisz dane logowania podczas rejestracji, a następnie wróć na stronę logowania. Potwierdź, że menedżer haseł może wykryć pola i autouzupełnić je. Przetestuj w Firefox z NVDA, Safari z VoiceOver (macOS/iOS) i Chrome z JAWS, aby objąć główne kombinacje AT+przeglądarka. Jeśli pola używają niestandardowego kodu HTML lub JavaScript, który czyści autouzupełnione wartości, jest to naruszenie.
5. NVDA + Firefox — przejście z czytnikiem ekranu: Nawiguj po formularzu logowania, używając wyłącznie klawiatury i NVDA. Potwierdź, że każde pole jest osiągalne, etykiety pól są poprawnie odczytywane i że każdy widżet CAPTCHA ma dostępną alternatywę. Jeśli CAPTCHA jest wyłącznie wizualna, bez opcji audio i bez alternatywnej ścieżki logowania, odnotuj naruszenie.
6. VoiceOver + Safari (iOS): Na urządzeniu mobilnym spróbuj zalogować się za pomocą Face ID lub Touch ID, jeśli strona oferuje logowanie biometryczne. Potwierdź, że opcja biometryczna jest osiągalna za pomocą nawigacji gestami (swipe) i że VoiceOver poprawnie ją odczytuje. To potwierdza, że alternatywa wolna od testu funkcji poznawczych jest faktycznie dostępna operacyjnie, a nie tylko nominalnie obecna.
7. Sprawdzenie limitów czasowych w krokach poznawczych: Jeśli CAPTCHA lub wprowadzanie OTP nakłada limit czasowy, sprawdź, czy użytkownik może go wydłużyć lub wyłączyć (istotne dla 2.2.1) i osobno zanotuj, czy krok z limitem czasowym stanowi test funkcji poznawczych bez alternatywy.

Jak Naprawić

Tekstowa CAPTCHA bez alternatywy — Nieprawidłowe

<!-- 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>

Tekstowa CAPTCHA bez alternatywy — Prawidłowe

<!-- 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>

Pole OTP blokujące wklejanie — Nieprawidłowe

<!-- 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();'>

Pole OTP blokujące wklejanie — Prawidłowe

<!-- 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. -->

CAPTCHA z wyborem obrazów bez rozwiązania alternatywnego (kwestia AAA, zgodne z AA) — Prawidłowe na poziomie 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>

Typowe Błędy

• Ustawianie autocomplete='off' w polach hasła: To wyłącza autouzupełnianie menedżera haseł, usuwając mechanizm wspomagający, który sprawia, że standardowe uwierzytelnianie hasłem jest zgodne z wymaganiami. Zamiast tego użyj autocomplete='current-password' i pozwól przeglądarce zarządzać przechowywaniem danych logowania.
• Blokowanie wklejania za pomocą onpaste='return false;' lub addEventListener('paste', e => e.preventDefault()): To zmusza użytkowników do ręcznego wpisywania danych logowania, tworząc niedostępne zadanie przepisywania. Usuń wszystkie procedury blokujące wklejanie z pól uwierzytelniania.
• Oferowanie opcji klucza dostępu, która nie jest dostępna z klawiatury: Alternatywa biometryczna spełnia 3.3.8 tylko wtedy, gdy jest osiągalna i obsługiwana za pomocą klawiatury i technologii asystujących. Przycisk klucza dostępu ukryty za menu pojawiającym się po najechaniu kursorem lub wyrenderowany jako niefokusowalny <div> nie jest uznawany za zgodną alternatywę.
• Używanie tekstowej CAPTCHA jako jedynej strategii ochrony przed botami: Przejście na serwerowe wykrywanie botów oparte na ryzyku (analiza odcisku urządzenia, tempa pisania, reputacji IP) eliminuje test funkcji poznawczych całkowicie, bez poświęcania bezpieczeństwa. Poleganie wyłącznie na CAPTCHA po stronie klienta jest zarówno porażką w zakresie dostępności, jak i złą praktyką bezpieczeństwa.
• Dzielenie OTP na wiele pól jednocyfrowych i blokowanie wklejania między polami: Niektóre implementacje używają sześciu oddzielnych pól <input maxlength='1'> do wprowadzania OTP i automatycznie przenoszą fokus za pomocą JavaScript. Ten wzorzec rutynowo psuje wklejanie z menedżerów haseł i narusza 3.3.8, chyba że implementacja wprost obsługuje wklejenie całego kodu do pierwszego pola i poprawne rozdzielenie znaków.
• Wymaganie CAPTCHA opartej na obrazach wyłącznie w przepływach odzyskiwania konta: Zespoły często dodają dostępne alternatywy logowania do głównej strony logowania, ale zapominają o uwierzytelnianiu podwyższonego poziomu, resetowaniu hasła i odblokowywaniu konta. Każdy z tych kroków jest osobnym etapem uwierzytelniania i musi niezależnie spełniać 3.3.8.
• Traktowanie audio CAPTCHA jako pełnej alternatywy dla tekstowej CAPTCHA: Alternatywa dźwiękowa pomaga osobom niewidomym, ale nie pomaga użytkownikom z niepełnosprawnościami poznawczymi ani osobom w hałaśliwym otoczeniu. Audio CAPTCHA również nakłada własny wymóg przepisywania. Właściwym rozwiązaniem jest wyeliminowanie CAPTCHA lub zapewnienie ścieżki, która w ogóle nie zawiera testu funkcji poznawczych.
• Dynamiczne generowanie identyfikatorów pól wejściowych, które psują wykrywanie przez menedżery haseł: Gdy atrybuty id pól nazwy użytkownika i hasła są losowane przy każdym załadowaniu strony (błędna technika antybotowa), menedżery haseł nie mogą wiarygodnie zidentyfikować pól. To w praktyce wyłącza autouzupełnianie i usuwa zgodny mechanizm wspomagający.
• Zakładanie, że widżety CAPTCHA firm trzecich są automatycznie zgodne: Popularne usługi CAPTCHA mogą oferować warianty dostępne, ale nie są one domyślnie włączone. Deweloperzy muszą jawnie skonfigurować dostępną wersję i nadal muszą zweryfikować, że spełnia ona wymagania standardu, zamiast po prostu dodawać nowy typ niedostępnego testu.
• Czyszczenie autouzupełnionych wartości za pomocą JavaScript przy fokusie: Niektóre formularze czyszczą zawartość pola, gdy otrzymuje ono fokus, aby pokazać tekst zastępczy lub wymusić ponowne wpisanie. Jeśli to zachowanie czyści autouzupełnioną wartość menedżera haseł, wymusza ręczne ponowne wpisanie i narusza 3.3.8.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Turecka Prezydencka Okrężnica 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązki w zakresie dostępności stron internetowych i aplikacji mobilnych zgodne z WCAG 2.2. Okrężnica wymaga od podmiotów objętych zakresem osiągnięcia zgodności na poziomie AA we wszystkich ich produktach i usługach cyfrowych. WCAG 3.3.8, jako kryterium na poziomie AA w WCAG 2.2, znajduje się zatem bezpośrednio w zakresie obowiązkowych wymogów zgodności wprowadzonych przez tę okrężnicę.

Okrężnica obejmuje szeroki zakres podmiotów publicznych i prywatnych. Instytucje publiczne i agencje rządowe muszą osiągnąć pełną zgodność na poziomie AA. W sektorze prywatnym okrężnica ma zastosowanie do platform e-commerce, banków i instytucji finansowych, szpitali i prywatnych świadczeniodawców opieki zdrowotnej, operatorów telekomunikacyjnych z 200,000 lub większą liczbą abonentów, biur podróży, prywatnych firm transportowych oraz szkół prywatnych upoważnionych przez Ministerstwo Edukacji Narodowej (MoNE). Dla tych organizacji niedostępne przepływy uwierzytelniania — takie jak strony logowania z nieobsługiwanymi CAPTCHA lub pola OTP blokujące wklejanie — tworzą bezpośrednie ryzyko regulacyjne.

Logo Dostępności (Erişilebilirlik Logosu), wydawane przez Ministerstwo Rodziny i Usług Społecznych, jest oficjalnym znakiem certyfikacji zgodności z wymogami dostępności cyfrowej w Turcji. Uzyskanie tego logo wymaga wykazania zgodności na poziomie AA, która obejmuje 3.3.8. Dla operatorów e-commerce, banków i innych dostawców usług cyfrowych o dużym ruchu logo pełni rolę publicznego sygnału zaufania i może być przywoływane w wymaganiach przetargowych i zakupowych. Przepływy uwierzytelniania oparte na niedostępnych testach funkcji poznawczych uniemożliwiłyby certyfikację i naraziły organizację na skargi oraz działania egzekucyjne.

Z praktycznego punktu widzenia zgodności organizacje w Turcji powinny przeprowadzić audyt każdego punktu styku uwierzytelniania — w tym logowania, rejestracji, MFA, resetowania hasła i odblokowywania konta — pod kątem 3.3.8 przed złożeniem wniosku o ocenę do Logo Dostępności. Zastąpienie tekstowych CAPTCHA serwerowymi kontrolami opartymi na ryzyku, włączenie autocomplete we wszystkich polach danych logowania oraz oferowanie alternatyw w postaci kluczy dostępu lub magicznych linków to działania naprawcze o największym wpływie. Zmiany te jednocześnie spełniają wymogi regulacyjne i poprawiają doświadczenie uwierzytelniania dla szacowanych 8.5 miliona osób z niepełnosprawnościami w Turcji, które korzystają z usług cyfrowych.