WCAG 3.3.9: Dostępne uwierzytelnianie (rozszerzone)

Kryterium sukcesu WCAG 2.1 SC 3.3.9 „Dostępne Uwierzytelnianie (rozszerzone)” (Accessible Authentication (Enhanced)) na poziomie AAA, koncentruje się na zapewnieniu, że procesy uwierzytelniania są dostępne dla jak najszerszego grona użytkowników. W szczególności dotyczy to osób z niepełnosprawnościami poznawczymi, pamięciowymi lub ruchowymi. Wymaga, aby każdy etap uwierzytelniania, który opiera się na teście funkcji poznawczych (np. zapamiętywanie haseł, przepisywanie tekstu z CAPTCHA), oferował co najmniej jedną alternatywną metodę uwierzytelniania, która nie wymaga takiego testu, lub aby dostępny był mechanizm wspomagający użytkownika w jego ukończeniu.

Dlaczego to jest ważne?

Wpływ na dostępność i grupy użytkowników:

  • Użytkownicy z niepełnosprawnościami poznawczymi i pamięciowymi: Mogą mieć trudności z zapamiętywaniem skomplikowanych haseł, przepisywaniem zniekształconego tekstu z CAPTCHA, rozwiązywaniem zagadek lub przypominaniem sobie szczegółów, co jest często wymagane w testach funkcji poznawczych.
  • Użytkownicy z niepełnosprawnościami ruchowymi: Mogą mieć problemy z precyzyjnym wpisywaniem złożonych danych lub szybkim przepisywaniem tekstu, co jest dodatkowo utrudnione, gdy nie mogą korzystać z menedżerów haseł (np. brak możliwości wklejenia hasła).
  • Użytkownicy technologii wspomagających: Czytniki ekranu i inne technologie mogą mieć trudności z interpretacją i interakcją z niektórymi formami testów poznawczych, zwłaszcza wizualnymi CAPTCHA, które nie są odpowiednio opisane lub nie posiadają alternatyw.
  • Użytkownicy w warunkach stresu lub rozproszenia: Każdy użytkownik może mieć trudności z uwierzytelnieniem, gdy jest pod presją czasu lub w środowisku rozpraszającym, co sprawia, że łatwe i alternatywne metody są kluczowe.

Kryterium sukcesu i wymagania

Kryterium sukcesu 3.3.9 (AAA) stwierdza:

Dla każdego etapu procesu uwierzytelniania, który opiera się na teście funkcji poznawczych, dostępna jest co najmniej jedna inna metoda uwierzytelniania, która nie opiera się na teście funkcji poznawczych, albo dostępny jest mechanizm wspomagający użytkownika w ukończeniu testu funkcji poznawczych.

„Test funkcji poznawczych” odnosi się do wszelkiego rodzaju zadań, które wymagają od użytkownika zapamiętywania informacji (np. haseł, nazw użytkownika), transkrypcji (przepisywanie tekstów z obrazków lub kodów jednorazowych), rozwiązywania zadań (zagadki, identyfikacja obiektów na obrazkach) lub innych złożonych procesów myślowych. Celem jest minimalizacja tych barier, oferując elastyczne i różnorodne opcje.

Praktyczne wytyczne dotyczące zgodności

  • Zezwól na korzystanie z menedżerów haseł: Upewnij się, że użytkownicy mogą swobodnie wklejać hasła z menedżerów haseł. Nie blokuj funkcji „wklej” w polach haseł. Pozwól także na automatyczne uzupełnianie (autocomplete="current-password" lub autocomplete="username").
  • Oferuj uwierzytelnianie bez hasła: Zapewnij alternatywne metody, takie jak:
    • Logowanie za pomocą „magicznego linku” wysyłanego na adres e-mail.
    • Logowanie za pomocą jednorazowego kodu wysyłanego SMS-em lub e-mailem (upewnij się, że użytkownik nie musi go przepisywać ręcznie; preferowane jest automatyczne wypełnianie pola lub kliknięcie w link).
    • Uwierzytelnianie biometryczne (odcisk palca, rozpoznawanie twarzy) za pośrednictwem platformy (np. WebAuthn).
    • Użycie kluczy bezpieczeństwa FIDO2 (np. YubiKey).
  • Alternatywy dla CAPTCHA: Jeśli musisz użyć CAPTCHA, zapewnij co najmniej jedną alternatywę, która nie wymaga złożonego testu poznawczego:
    • Audio CAPTCHA, które jest czytelne i pozwala na łatwą transkrypcję (lub kopiowanie numerów/liter).
    • Proste pytanie bazujące na ogólnej wiedzy zamiast interpretacji wizualnej (np. „Ile nóg ma pies?”).
    • Weryfikacja oparta na ryzyku (np. reCAPTCHA v3 lub reCAPTCHA v2 „nie jestem robotem”, jeśli nie wymaga wyboru obrazków).
    • Proste zadania, które nie obciążają pamięci ani złożonych funkcji poznawczych.
  • Unikaj skomplikowanych pytań bezpieczeństwa: Pytania wymagające pamiętania bardzo specyficznych lub dawnych informacji (np. „nazwisko panieńskie matki twojej babci”) mogą być trudne i nieskuteczne. Preferuj pytania z łatwo dostępnymi odpowiedziami lub inne metody, które nie polegają wyłącznie na pamięci.

Przykłady implementacji

Przykłady poprawne:

1. Pozwolenie na wklejanie hasła z menedżera haseł i automatyczne uzupełnianie:

<label for="username">Nazwa użytkownika / E-mail</label>
<input type="text" id="username" name="username" autocomplete="username" required>

<label for="password">Hasło</label>
<input type="password" id="password" name="password" autocomplete="current-password" required>
<!-- Aplikacja nie blokuje zdarzeń 'paste' ani modyfikacji inputu, aby menedżery haseł mogły działać. -->

2. Alternatywne uwierzytelnianie bez hasła (np. "magiczny link"):

<p>Zaloguj się za pomocą hasła lub:</p>
<form action="/send-magic-link" method="post">
    <label for="email-magic-link">Adres e-mail</label>
    <input type="email" id="email-magic-link" name="email" autocomplete="email" required>
    <button type="submit">Wyślij link do logowania</button>
</form>

3. CAPTCHA z alternatywą audio:

<p>Wpisz tekst widoczny na obrazku:</p>
<img src="captcha-image.png" alt="Wpisz kod z obrazka">
<audio src="captcha-audio.mp3" controls aria-label="Odtwórz kod CAPTCHA w wersji audio">
    Twoja przeglądarka nie obsługuje elementu audio.
    <a href="captcha-audio.mp3">Pobierz wersję audio</a>.
</audio>
<label for="captcha-input">Kod z CAPTCHA</label>
<input type="text" id="captcha-input" name="captcha-input" autocomplete="off" autocapitalize="off" autocorrect="off" spellcheck="false">
<button type="button">Odśwież CAPTCHA</button>
<button type="button">Odtwórz audio</button>

Przykłady niepoprawne:

1. Blokowanie funkcji wklejania w polu hasła:

<label for="password-no-paste">Hasło</label>
<input type="password" id="password-no-paste" name="password" onpaste="return false;">
<!-- Użytkownik nie może wkleić hasła z menedżera haseł, co jest barierą dla wielu osób, w tym z niepełnosprawnościami ruchowymi i poznawczymi. -->

2. CAPTCHA tylko wizualne, bez alternatywy:

<p>Wpisz tekst widoczny na obrazku:</p>
<img src="complex-distorted-captcha.png" alt="Wprowadź tekst z obrazka">
<label for="captcha-visual-only">Kod z CAPTCHA</label>
<input type="text" id="captcha-visual-only" name="captcha-visual-only">
<!-- Brak alternatywy audio lub innego mechanizmu dla użytkowników niewidomych, z dysleksją lub innymi niepełnosprawnościami poznawczymi. -->

Najlepsze praktyki i typowe pułapki

  • Najlepsze praktyki:
    • Passwordless jako domyślne: Rozważ wprowadzenie metod bezhasłowych jako podstawowej opcji uwierzytelniania, co znacząco obniża obciążenie poznawcze.
    • WebAuthn: Implementuj standard WebAuthn dla silnego, odpornego na phishing i wysoce dostępnego uwierzytelniania, wykorzystującego biometrię lub klucze sprzętowe.
    • Jasne instrukcje: Zawsze dostarczaj jasne, zwięzłe i łatwe do zrozumienia instrukcje dla każdej metody uwierzytelniania.
    • Testowanie z użytkownikami: Przeprowadzaj testy użyteczności z osobami z różnymi niepełnosprawnościami, aby upewnić się, że procesy uwierzytelniania są faktycznie dostępne i intuicyjne.
    • Automatyczne wypełnianie dla OTP: Tam, gdzie to możliwe, zezwalaj na automatyczne wypełnianie pól z kodami jednorazowymi (np. z SMS-ów).
  • Typowe pułapki:
    • Nadmierne poleganie na pamięci: Wymaganie od użytkowników zapamiętywania wielu złożonych haseł lub odpowiedzi na trudne pytania bezpieczeństwa.
    • Zbyt trudne CAPTCHA: Używanie CAPTCHA, które są trudne do rozwiązania nawet dla osób bez niepełnosprawności, a jednocześnie brak alternatyw lub mechanizmów wspomagających.
    • Brak obsługi menedżerów haseł: Blokowanie możliwości wklejania haseł lub automatycznego wypełniania przez menedżery haseł.
    • Wymaganie transkrypcji kodów: Gdy kody jednorazowe (OTP) są wysyłane, wymaganie ręcznego przepisania ich, zamiast zapewnienia mechanizmu automatycznego wypełniania lub prostego kliknięcia w link.
    • Brak elastyczności: Oferowanie tylko jednej metody uwierzytelniania, która może być barierą dla niektórych grup użytkowników.

Zgodność z WCAG 2.1 SC 3.3.9 jest kluczowa dla budowania włączających systemów uwierzytelniania, które są dostępne dla wszystkich użytkowników, niezależnie od ich zdolności poznawczych lub fizycznych. Implementacja tego kryterium przyczynia się do większej satysfakcji użytkownika i bezpieczeństwa.

Powiązane wpisy

Nadal szukasz odpowiedzi?

Zapytaj naszych specjalistów używając czatu online.

Skontaktuj się z nami