WCAG 3.3.8: Dostępne uwierzytelnianie (minimum)
Kryterium Sukcesu 3.3.8: Dostępne Uwierzytelnianie (Minimum), wprowadzone w WCAG 2.1, ma na celu ułatwienie procesów logowania i weryfikacji tożsamości dla wszystkich użytkowników. Jest to szczególnie ważne dla osób, które mogą mieć trudności z zapamiętywaniem i odtwarzaniem złożonych informacji, takich jak hasła, lub które korzystają z technologii wspomagających, takich jak menedżery haseł. Kryterium to wymaga, aby procesy uwierzytelniania nie opierały się wyłącznie na testach pamięci.
Zrozumienie Kryterium Sukcesu 3.3.8: Dostępne Uwierzytelnianie (Minimum)
To kryterium na poziomie AA wymaga, aby witryny internetowe i aplikacje nie wymagały od użytkowników pamiętania skomplikowanych ciągów znaków (takich jak hasła) jako jedynej metody uwierzytelnienia. Zamiast tego, musi być dostępny mechanizm alternatywny, który nie polega na pamięci, lub mechanizm, który pomaga użytkownikowi w uwierzytelnieniu bez konieczności przypominania sobie hasła z pamięci.
Oznacza to, że jeśli system wymaga od użytkownika podania hasła lub innej informacji wymagającej zapamiętania, musi również zaoferować co najmniej jedną z następujących opcji:
Dlaczego To Kryterium Ma Znaczenie?
Bariery związane z tradycyjnymi metodami uwierzytelniania mogą wykluczać wiele grup użytkowników. Zapewnienie dostępnych alternatyw ma kluczowe znaczenie z kilku powodów:
Praktyczne Wskazówki dla Zgodności
1. Oferowanie Alternatywnych Metod Uwierzytelniania
Zapewnienie co najmniej jednej metody uwierzytelniania, która nie polega na pamięci, jest najlepszym sposobem na spełnienie tego kryterium.
2. Wspieranie Menedżerów Haseł i Funkcji Autouzupełniania
Jeśli uwierzytelnianie opiera się na haśle, kluczowe jest wsparcie dla narzędzi pomagających użytkownikom zarządzać hasłami.
3. Uwierzytelnianie Wieloskładnikowe (MFA)
Choć nie jest to bezpośrednio wymagane przez SC 3.3.8, wdrożenie MFA często spełnia jego wymagania. Jeśli jeden ze składników MFA nie polega na pamięci (np. kod OTP z aplikacji autoryzacyjnej, klucz sprzętowy), stanowi to dostępną alternatywę.
Przykłady Implementacji
Poprawne Implementacje
Przykład 1: Uwierzytelnianie SMS-em (OTP)
Użytkownik podaje numer telefonu, aby otrzymać kod jednorazowy. Nie musi pamiętać żadnego hasła.
Przykład 2: Uwierzytelnianie za pomocą linku wysłanego na e-mail
Użytkownik podaje adres e-mail, na który otrzymuje link do logowania. Nie musi pamiętać żadnego hasła.
Przykład 3: Standardowe logowanie z pełnym wsparciem dla menedżerów haseł
System oferuje logowanie za pomocą nazwy użytkownika i hasła, ale w pełni wspiera menedżery haseł, umożliwiając autouzupełnianie i wklejanie.
Niepoprawne Implementacje
Przykład 1: Uwierzytelnianie wyłącznie za pomocą hasła z blokowaniem menedżerów haseł
System wymaga tylko hasła, a dodatkowo utrudnia lub uniemożliwia korzystanie z menedżerów haseł poprzez atrybut autocomplete="off".
Przykład 2: Blokowanie wklejania do pola hasła
Uwierzytelnianie opiera się wyłącznie na pamięci, a dodatkowo blokuje możliwość wklejenia hasła, co jest poważną barierą dla użytkowników menedżerów haseł.
Najlepsze Praktyki i Typowe Pułapki
Najlepsze Praktyki
Typowe Pułapki
Zasoby Dodatkowe
Powiązane wpisy
- WCAG 5.2.3: Pełne procesy
- WCAG 5.2.4: Tylko sposoby korzystania z technologii wspierające dostępność
- WCAG 5.2.5: Brak zakłóceń
- WCAG 5.3.1: Wymagane elementy oświadczenia o zgodności
- WCAG 5.3.2: Opcjonalne elementy oświadczenia o zgodności
Nadal szukasz odpowiedzi?
Zapytaj naszych specjalistów używając czatu online.