3.3.8 Dostępne uwierzytelnianie (minimum)

Krótko

Użytkownik powinien móc zalogować się bez obowiązku samodzielnego zapamiętywania, przepisywania albo rozwiązywania testu poznawczego, jeśli dostępna jest pomoc lub alternatywa.

Problem w praktyce

Użytkownik zna swoje dane i ma prawo dostępu do konta, ale proces logowania wymaga od niego dodatkowego wysiłku poznawczego: zapamiętania hasła, przepisania kodu, rozwiązania zagadki albo rozpoznania obiektów na zdjęciach.

Problem pojawia się na przykład wtedy, gdy strona blokuje wklejanie hasła lub kodu, wymusza przepisywanie znaków z obrazka, każe wybrać wszystkie zdjęcia z sygnalizacją, nie działa z menedżerem haseł albo passkey, albo daje bardzo krótki czas na wpisanie kodu bez sensownego ponowienia.

3.3.8 nie zakazuje haseł, kodów ani zabezpieczeń. Wymaga, żeby przy teście funkcji poznawczych istniała pomoc, mechanizm wspierający albo dostępna alternatywa.

Kogo to dotyczy

• Osób z trudnościami poznawczymi, dla których zapamiętywanie haseł, kodów i instrukcji może być barierą.
• Osób z dysleksją, które mogą popełniać błędy przy przepisywaniu krótkich kodów albo zniekształconych znaków.
• Osób niewidomych i słabowidzących, gdy proces opiera się na obrazkowej CAPTCHA bez dostępnej alternatywy.
• Osób z ograniczeniami motorycznymi, dla których szybkie przepisywanie kodu z innego urządzenia jest trudne.
• Osób starszych, osób w stresie i użytkowników logujących się w pośpiechu.
• Wszystkich, którzy korzystają z menedżerów haseł, wklejania kodów, passkey albo linków logowania.

Dobry przykład

Dostępny proces logowania nie zmusza użytkownika do samodzielnego zapamiętywania i przepisywania danych, jeśli można mu pomóc. Dobre rozwiązania to na przykład:

• pola logowania zgodne z menedżerami haseł, z etykietami i właściwym `autocomplete`,
• możliwość wklejenia hasła i kodu jednorazowego,
• kod jednorazowy możliwy do skopiowania i wklejenia w całości,
• link logowania wysłany e-mailem,
• passkey albo WebAuthn jako dodatkowa dostępna alternatywa,
• CAPTCHA z dostępną alternatywą, jeśli musi wystąpić.

Ważne: passkey, WebAuthn albo logowanie zewnętrznym dostawcą mogą pomagać, ale nie należy ich opisywać jako zweryfikowanej techniki W3C dla 3.3.8, jeśli Quick Reference oznacza je tylko jako potencjalne przyszłe techniki.

Zły przykład

Niedostępne logowanie wymaga od użytkownika rozwiązania testu poznawczego i nie daje mu realnej pomocy ani alternatywy.

• Strona blokuje wklejanie w polu hasła albo kodu jednorazowego.
• CAPTCHA jest wyłącznie obrazkowa i wymaga przepisania zniekształconych znaków.
• Użytkownik musi rozpoznać obiekty na zdjęciach, a nie ma innej ścieżki logowania.
• Formularz wymaga wpisania wybranych znaków hasła, np. drugiego, szóstego i ostatniego.
• Kod jednorazowy trzeba przepisać do kilku pól, a wklejenie całego kodu nie działa.
• Proces nie pozwala używać menedżera haseł.

Przykłady kodu

<form method="post" action="/login">
  <label for="login-email">
    Adres e-mail
  </label>
  <input
    id="login-email"
    name="email"
    type="email"
    autocomplete="email"
  >

  <label for="login-password">
    Hasło
  </label>
  <input
    id="login-password"
    name="password"
    type="password"
    autocomplete="current-password"
  >

  <button type="submit">
    Zaloguj się
  </button>
</form>

Pola mają widoczne etykiety i atrybuty `autocomplete`, które pomagają przeglądarce oraz menedżerowi haseł rozpoznać dane logowania. Strona nie powinna blokować wklejania ani automatycznego uzupełniania.

<label for="one-time-code">
  Kod jednorazowy
</label>
<p id="one-time-code-hint">
  Możesz wkleić cały kod z wiadomości SMS albo e-mail.
</p>
<input
  id="one-time-code"
  name="one-time-code"
  type="text"
  inputmode="numeric"
  autocomplete="one-time-code"
  aria-describedby="one-time-code-hint"
>

Użytkownik może wkleić cały kod w takim formacie, w jakim go otrzymał. `aria-describedby` łączy pole z instrukcją, ale sama instrukcja pozostaje widoczna.

passwordInput.addEventListener("paste", function (event) {
  event.preventDefault();
});

codeInput.addEventListener("paste", function (event) {
  event.preventDefault();
});

To zły przykład. Blokowanie wklejania utrudnia użycie menedżera haseł i zmusza użytkownika do przepisywania hasła albo kodu. Taki JavaScript jest pokazany tylko jako fragment edukacyjny, nie działa na tej stronie.

<form method="post" action="/login-link">
  <label for="login-link-email">
    Adres e-mail
  </label>
  <input
    id="login-link-email"
    name="email"
    type="email"
    autocomplete="email"
  >

  <button type="submit">
    Wyślij link do logowania
  </button>
</form>

Link logowania wysłany e-mailem może być alternatywną ścieżką, która nie wymaga pamiętania hasła. Trzeba go zaprojektować bezpiecznie, ale polityka bezpieczeństwa nie jest głównym tematem tego kryterium.

Przykład graficzny

Jak sprawdzić

1. Znajdź wszystkie kroki logowania i ponownego uwierzytelniania.
2. Sprawdź, czy którykolwiek krok wymaga pamiętania, przepisywania, liczenia, rozwiązywania zagadki albo rozpoznawania treści.
3. Jeśli tak, sprawdź, czy istnieje mechanizm pomocy, np. menedżer haseł, wklejanie kodu, autouzupełnianie albo link logowania.
4. Sprawdź, czy pola logowania mają widoczne etykiety i nie blokują menedżera haseł.
5. Wklej hasło i kod jednorazowy. Test nie przechodzi, jeśli strona blokuje wklejanie bez alternatywy.
6. Sprawdź, czy kod jednorazowy można wpisać albo wkleić w formacie, w którym został dostarczony.
7. Jeśli występuje CAPTCHA, sprawdź, czy istnieje dostępna alternatywa.
8. Przejdź proces klawiaturą i z czytnikiem ekranu.
9. Nie oceniaj wyłącznie automatem. Najważniejsze jest, czy użytkownik może przejść proces bez niepotrzebnego testu poznawczego.

Co sprawdzi automat, a czego nie

Automat może wykryć część problemów technicznych, ale nie oceni całego procesu uwierzytelniania.

Automat może wykryć

• część pól bez etykiet,
• część błędów w atrybutach `autocomplete`,
• część problemów z relacją instrukcji i pola,
• część kodu blokującego zdarzenia użytkownika, jeśli jest objęty testem statycznym.

Automat nie oceni pewnie

• czy proces wymaga testu funkcji poznawczych,
• czy alternatywa logowania jest rzeczywiście dostępna,
• czy kod można wkleić w praktyce na wszystkich krokach,
• czy limit czasu daje użytkownikowi realną możliwość ponowienia,
• czy CAPTCHA ma użyteczną alternatywę,
• czy menedżer haseł działa w konkretnym formularzu.

Typowe błędy

• Blokowanie wklejania hasła albo kodu jednorazowego.
• Dzielenie kodu na kilka pól bez obsługi wklejenia całego kodu.
• Prośba o wpisanie wybranych znaków hasła.
• Obrazkowa CAPTCHA bez dostępnej alternatywy.
• Logowanie zależne wyłącznie od rozpoznawania obiektów na zdjęciach.
• Krótki limit czasu na kod bez jasnej możliwości ponownego wysłania.
• Pola logowania bez etykiet albo z nazwami, których menedżer haseł nie rozpoznaje.
• Zakładanie, że każdy użytkownik może zapamiętać silne hasło i przepisać je ręcznie.

Powiązane kryteria

• 1.3.5 Określenie celu danych wejściowych: gdy pola danych osobowych powinny mieć możliwy do rozpoznania cel.
• 3.3.2 Etykiety lub instrukcje: gdy użytkownik potrzebuje jasnych informacji przed wpisaniem danych.
• 3.3.7 Powtarzające się wpisy: gdy użytkownik nie powinien ponownie wpisywać tej samej informacji w jednym procesie.
• 4.1.2 Nazwa, rola, wartość: gdy komponenty logowania muszą mieć poprawną nazwę, rolę i stan.
• 4.1.3 Komunikaty o stanie: gdy komunikaty po wysłaniu kodu albo zmianie stanu powinny być dostępne bez przenoszenia fokusu.

Źródła

• WCAG 2.2: 3.3.8 Accessible Authentication (Minimum) (otwiera się w nowym oknie)
• Understanding WCAG 3.3.8: Accessible Authentication (Minimum) (otwiera się w nowym oknie)
• How to Meet WCAG 3.3.8: Accessible Authentication (Minimum) (otwiera się w nowym oknie)
• G218: Email link authentication (otwiera się w nowym oknie)
• H100: Providing properly marked up email and password inputs (otwiera się w nowym oknie)
• F109: Failure due to preventing password or code re-entry in the same format (otwiera się w nowym oknie)