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:

• Alternatywną metodę uwierzytelniania, która nie polega na pamięci (np. link wysłany na e-mail, kod jednorazowy SMS/e-mail, uwierzytelnianie biometryczne, logowanie przez dostawcę tożsamości).
• Mechanizm wspomagający uwierzytelnianie, który pomaga użytkownikowi w wypełnianiu pól bez konieczności odtwarzania hasła z pamięci (np. wsparcie dla menedżerów haseł, opcja wklejania hasła do pola).

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:

• Osoby z dysfunkcjami poznawczymi, dysleksją lub zaburzeniami pamięci: Dla tych osób zapamiętywanie, a następnie dokładne odtwarzanie złożonych haseł, zwłaszcza pod presją czasu, może być niezwykle trudne lub niemożliwe.
• Osoby starsze: Mogą doświadczać naturalnych trudności z pamięcią, a także problemów z precyzyjnym wprowadzaniem długich i skomplikowanych ciągów znaków.
• Osoby z niepełnosprawnościami motorycznymi: Wprowadzanie długich lub trudnych do zapamiętania haseł może być czasochłonne i frustrujące, zwłaszcza jeśli wymagane jest precyzyjne wprowadzanie znaków specjalnych.
• Osoby korzystające z technologii wspomagających: Menedżery haseł są nieocenionym narzędziem dla wielu użytkowników. Blokowanie ich funkcjonalności (np. przez autocomplete="off" lub blokowanie wklejania) uniemożliwia im efektywne działanie, tworząc barierę.
• Zwiększenie bezpieczeństwa i wygody dla wszystkich: Ułatwienie dostępu do alternatywnych metod uwierzytelniania może prowadzić do używania silniejszych, losowo generowanych haseł (przez menedżery haseł) oraz redukuje frustrację, poprawiając ogólne doświadczenie użytkownika.

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.

• Kody jednorazowe (OTP): Umożliwienie logowania za pomocą kodu wysłanego na zarejestrowany numer telefonu (SMS) lub adres e-mail.
• Link do logowania e-mailem: Wysyłanie unikalnego, tymczasowego linku do logowania na zarejestrowany adres e-mail, eliminując potrzebę hasła.
• Uwierzytelnianie biometryczne: Jeśli jest to technicznie możliwe i bezpieczne, wykorzystanie funkcji biometrycznych urządzenia (np. odcisk palca, rozpoznawanie twarzy) za zgodą użytkownika.
• Dostawcy tożsamości (SSO): Integracja z zaufanymi dostawcami tożsamości, takimi jak Google, Facebook, Apple ID, którzy oferują własne metody uwierzytelniania, często już uwzględniające dostępność.

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.

• Nie używaj autocomplete="off": Nigdy nie używaj atrybutu autocomplete="off" na polach formularzy, zwłaszcza dla nazwy użytkownika i hasła. Ten atrybut blokuje funkcjonalność menedżerów haseł i przeglądarek.
• Używaj odpowiednich wartości autocomplete: Stosuj zalecane wartości atrybutu autocomplete (np. username, current-password, new-password) aby pomóc przeglądarkom i menedżerom haseł prawidłowo identyfikować pola.
• Zezwalaj na wklejanie hasła: Upewnij się, że użytkownicy mogą wklejać hasła do pól. Blokowanie tej funkcji (np. za pomocą JavaScriptu) jest poważną barierą.

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

<!-- Etap 1: Wprowadzenie numeru telefonu -->
<form aria-labelledby="login-heading" action="/request-otp" method="post">
    <h2 id="login-heading">Logowanie</h2>
    <p>Wprowadź swój numer telefonu, aby otrzymać kod jednorazowy SMS.</p>

    <label for="phone">Numer telefonu:</label>
    <input type="tel" id="phone" name="phone" autocomplete="tel" required>

    <button type="submit">Wyślij kod SMS</button>
</form>

<!-- Etap 2: Wprowadzenie kodu OTP -->
<form aria-labelledby="otp-heading" action="/verify-otp" method="post">
    <h2 id="otp-heading">Wprowadź kod SMS</h2>
    <p>Kod jednorazowy został wysłany na Twój numer telefonu.</p>

    <label for="otp">Kod jednorazowy (OTP):</label>
    <input type="text" id="otp" name="otp" inputmode="numeric" pattern="[0-9]{6}" autocomplete="one-time-code" required>

    <button type="submit">Weryfikuj</button>
</form>

<form aria-labelledby="login-heading" action="/request-login-link" method="post">
    <h2 id="login-heading">Logowanie</h2>
    <p>Wprowadź swój adres e-mail, aby otrzymać link do logowania.</p>

    <label for="email">Adres e-mail:</label>
    <input type="email" id="email" name="email" autocomplete="email" required>

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

<form aria-labelledby="login-heading" action="/login" method="post">
    <h2 id="login-heading">Logowanie</h2>

    <div>
        <label for="username">Nazwa użytkownika:</label>
        <input type="text" id="username" name="username" autocomplete="username" required>
    </div>

    <div>
        <label for="password">Hasło:</label>
        <input type="password" id="password" name="password" autocomplete="current-password" required>
        <!-- Domyślnie przeglądarki i systemy operacyjne zezwalają na wklejanie,
             chyba że jest to aktywnie blokowane przez JavaScript. -->
    </div>

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

Niepoprawne Implementacje

<form aria-labelledby="login-heading" action="/login" method="post">
    <h2 id="login-heading">Logowanie</h2>

    <div>
        <label for="username">Nazwa użytkownika:</label>
        <input type="text" id="username" name="username" autocomplete="off" required>
    </div>

    <div>
        <label for="password">Hasło:</label>
        <input type="password" id="password" name="password" autocomplete="off" required>
    </div>

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

<form aria-labelledby="login-heading" action="/login" method="post">
    <h2 id="login-heading">Logowanie</h2>

    <div>
        <label for="username">Nazwa użytkownika:</label>
        <input type="text" id="username" name="username" autocomplete="username" required>
    </div>

    <div>
        <label for="password">Hasło:</label>
        <input type="password" id="password" name="password" autocomplete="current-password" required onpaste="return false;" oncopy="return false;">
    </div>

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

<!-- Dodatkowy skrypt JS blokujący wklejanie (choć w HTML powyżej jest już w onpaste) -->
<script>
    document.getElementById('password').addEventListener('paste', function(e) {
        e.preventDefault();
    });
    document.getElementById('password').addEventListener('copy', function(e) {
        e.preventDefault();
    });
</script>

Najlepsze Praktyki i Typowe Pułapki

Najlepsze Praktyki

• Zawsze oferuj alternatywy: Upewnij się, że zawsze istnieje co najmniej jedna metoda uwierzytelniania, która nie polega na pamięci, lub mechanizm wspomagający.
• Wspieraj menedżery haseł: Nigdy nie blokuj funkcjonalności menedżerów haseł; zawsze używaj prawidłowych wartości autocomplete i zezwalaj na wklejanie.
• Jasne instrukcje: Zapewnij klarowne i zrozumiałe instrukcje dla każdej oferowanej metody uwierzytelniania, zwłaszcza dla alternatywnych.
• Komunikaty błędów: W przypadku błędu uwierzytelnienia, dostarczaj pomocne i jasne komunikaty, które nie wymagają od użytkownika ponownego odtwarzania skomplikowanych danych z pamięci.
• Rozważ WebAuthn: Dla najwyższego poziomu bezpieczeństwa i dostępności, rozważ implementację standardu WebAuthn, który umożliwia uwierzytelnianie bezhasłowe za pomocą kluczy bezpieczeństwa lub wbudowanych biometrycznych funkcji urządzenia.

Typowe Pułapki

• Poleganie wyłącznie na haśle: Najczęstsza niezgodność z tym kryterium to brak jakichkolwiek alternatyw dla logowania hasłem.
• Blokowanie funkcjonalności menedżerów haseł: Używanie autocomplete="off" lub blokowanie wklejania haseł za pomocą JavaScriptu.
• Zbyt skomplikowane procesy odzyskiwania konta: Procesy odzyskiwania konta, które są zbyt złożone lub wymagają zapamiętywania wielu pytań bezpieczeństwa bez alternatyw, również mogą stanowić barierę.
• Niejasne komunikaty: Brak informacji o dostępnych alternatywnych metodach uwierzytelniania lub trudne do zrozumienia instrukcje.

Zasoby Dodatkowe

• Understanding SC 3.3.8: Accessible Authentication (Minimum)
• WCAG 2.1 Quick Reference – SC 3.3.8