Dostępne uwierzytelnianie na stronie internetowej nie ogranicza się do poprawnego wyświetlenia formularza logowania. Jest częścią całego procesu cyfrowego, który obejmuje podanie danych, przejście kolejnych etapów, obsługę błędów, odzyskiwanie dostępu oraz powrót do serwisu po użyciu dodatkowego mechanizmu. Każdy z tych elementów może ułatwiać korzystanie ze strony albo tworzyć niepotrzebną barierę.
Projektowanie procesu logowania powinno łączyć wymagania WCAG 2.2, użyteczność i analizę bezpieczeństwa. Nie oznacza to rezygnacji z uwierzytelniania wieloskładnikowego ani dodatkowych zabezpieczeń. Oznacza natomiast potrzebę zaplanowania dostępnej ścieżki dla całego procesu oraz sprawdzenia jej przed wdrożeniem. Poniżej omówiono kryteria normatywne, formularz logowania, logowanie bez hasła przez magic link oraz metody testowania.
Dlaczego dostępne uwierzytelnianie jest częścią jakości procesu cyfrowego
Logowanie bywa pierwszym warunkiem dostępu do funkcji przeznaczonych dla klientów, pracowników lub partnerów biznesowych. Jeżeli użytkownik nie może przejść tego etapu, nie skorzysta z dalszej części serwisu, niezależnie od jakości pozostałych ekranów. Z perspektywy organizacji oznacza to konieczność traktowania uwierzytelniania jako elementu projektowanego, wdrażanego i kontrolowanego razem z całą stroną.
Ocenie należy poddać nie tylko wygląd widoku logowania, lecz także sposób obsługi klawiatury, fokus, komunikaty, autouzupełnianie, kolejne składniki uwierzytelniania, błędne dane i odzyskiwanie konta. Dostępność powinna być rozpatrywana równolegle z użytecznością, ale odrębnie od oceny odporności mechanizmu na zagrożenia.
Logowanie jako pełny przepływ
Pełny przepływ rozpoczyna się od formularza, lecz nie kończy po wybraniu przycisku „zaloguj”. Obejmuje każdą czynność wymaganą do uzyskania dostępu oraz sytuacje, w których dane są nieprawidłowe, wiadomość nie dociera albo użytkownik potrzebuje odzyskać konto. Taki zakres warto ustalić już na etapie projektu, aby testy nie ograniczyły się do jednego widoku.
WCAG 2.2: kryteria 3.3.8 i 3.3.9
WCAG 2.2 definiuje dwa kryteria dotyczące dostępnego uwierzytelniania. Kryterium 3.3.8, Accessible Authentication (Minimum), należy do poziomu AA. Kryterium 3.3.9, Accessible Authentication (Enhanced), należy do poziomu AAA. Są to wymagania normatywne, dlatego trzeba odróżnić je od rekomendacji projektowych oraz od decyzji dotyczących architektury i bezpieczeństwa systemu.
Minimum AA a Enhanced AAA
Kryterium 3.3.8 ogranicza sytuacje, w których użytkownik musi wykonać test funkcji poznawczej, na przykład zapamiętać hasło albo rozwiązać zagadkę. Taki test nie powinien być wymagany na żadnym etapie uwierzytelniania, chyba że dostępna jest alternatywna metoda, mechanizm wsparcia, rozpoznawanie obiektów albo identyfikacja treści dostarczonej wcześniej przez użytkownika. Kryterium 3.3.9 ustanawia bardziej restrykcyjny poziom AAA, dlatego nie należy utożsamiać go z minimalnym wymaganiem AA.
WCAG nie narzuca jednej technologii logowania. Logowanie bez hasła, formularz z menedżerem haseł czy inna metoda mogą być sposobami realizacji dostępnego procesu, jeżeli spełniają odpowiednie wymagania. Sama obecność konkretnej funkcji nie przesądza jeszcze o pełnej dostępności.
Wieloetapowe uwierzytelnianie
Jeżeli uwierzytelnianie składa się z kilku etapów, każdy z nich musi zostać uwzględniony w ocenie. Dotyczy to również logowania wieloskładnikowego, w którym po haśle pojawia się dodatkowy kod lub inna czynność. Cały proces powinien zapewniać ścieżkę, która nie opiera się na niedostępnym teście funkcji poznawczej. Uproszczenie jednego ekranu nie rozwiązuje problemu, jeżeli bariera występuje na kolejnym etapie.
Formularz logowania bez zbędnych barier
Dostępny formularz logowania powinien być projektowany z myślą o rozpoznawaniu pól, swobodnym wprowadzaniu danych i zrozumiałej obsłudze błędów. Bariery często wynikają nie z braku funkcji, lecz z ograniczeń narzuconych użytkownikowi: zablokowanego wklejania, wybiórczego przepisywania znaków albo niedostępnego testu.
Pola rozpoznawalne dla przeglądarki i menedżera haseł
Pola adresu e-mail i hasła powinny mieć prawidłowe, programowo dostępne nazwy oraz właściwie określone przeznaczenie. Dzięki temu przeglądarka i menedżer haseł mogą rozpoznać, jakie dane należy wprowadzić. Formularz nie powinien blokować autouzupełniania ani korzystania z menedżerów haseł, ponieważ są to mechanizmy ograniczające obciążenie poznawcze.
Nie należy także blokować kopiowania i wklejania danych. Dotyczy to haseł oraz kodów, jeżeli dany proces ich używa. Wymaganie przepisywania tylko wybranych znaków lub dzielenie wartości w sposób uniemożliwiający wklejenie całości może zwiększać trudność obsługi bez uzasadnienia wynikającego z samego interfejsu.
Interakcje, błędy i klawiatura
Obsługa klawiatury, logiczna kolejność fokusu i możliwość poprawienia danych powinny być częścią projektu, a nie działaniem wykonywanym dopiero po zgłoszeniu problemu. Komunikaty błędów muszą być zrozumiałe i dostępne, ale ich treść należy również dopasować do modelu zagrożeń systemu. Nie powinny ujawniać nadmiarowych informacji o tym, czy konkretny adres e-mail jest zarejestrowany, jeżeli zwiększałoby to ryzyko enumeracji kont.
CAPTCHA lub inny test funkcji poznawczej nie powinien być wymagany bez dostępnej alternatywy albo mechanizmu wsparcia. W praktyce warto sprawdzić także, czy użytkownik może przejść formularz bez nieprzewidzianych zmian fokusu i czy każda informacja potrzebna do ukończenia procesu jest dostępna w odpowiedniej kolejności.
Magic link jako alternatywa dla hasła
Magic link, czyli logowanie przez link e-mail, może ograniczyć konieczność zapamiętywania i wpisywania hasła lub kodu. Jest to przykład mechanizmu, który może poprawić dostępność, gdy cały przepływ został zaprojektowany i sprawdzony jako jedna całość.
Przebieg logowania przez link e-mail
Typowy scenariusz obejmuje podanie adresu e-mail, otrzymanie wiadomości z odnośnikiem, a następnie wybranie linku i powrót na stronę, gdzie użytkownik zostaje uwierzytelniony bez wpisywania hasła. Taki proces może być pomocny dla osób, dla których zapamiętywanie lub przepisywanie danych stanowi barierę.
Ocena nie może jednak kończyć się na samym formularzu adresu e-mail. Należy sprawdzić jasność komunikatów, działanie linku, obsługę klawiatury i czytników ekranu, powrót na stronę na różnych urządzeniach oraz proces odzyskiwania konta. Znaczenie ma również kontrola dostępu do skrzynki e-mail i sposób zabezpieczenia samego przepływu.
Technika, nie uniwersalny standard wdrożenia
Technika G218 W3C opisuje logowanie przez link e-mail jako przykład sposobu spełnienia kryteriów dotyczących dostępnego uwierzytelniania. Nie jest to obowiązkowa implementacja dla każdego systemu. Decyzję należy podjąć po analizie całego procesu, potrzeb użytkowników i wymagań bezpieczeństwa.
W szczególności trzeba uwzględnić unieważnianie lub wygaszanie linków, ochronę przed ponownym użyciem oraz bezpieczne przekierowanie po uwierzytelnieniu. Research nie określa uniwersalnych parametrów tych mechanizmów, dlatego ich konfiguracja wymaga odrębnej weryfikacji bezpieczeństwa. Nie należy upraszczać logowania kosztem kontroli dostępu.
Testowanie procesu logowania przed wdrożeniem
Ocena dostępności powinna rozpocząć się na etapie projektu i być prowadzona w całym procesie tworzenia lub przebudowy strony. Wczesna weryfikacja pozwala rozpoznać bariery zanim zostaną utrwalone w interfejsie, komponentach i kolejnych etapach systemu.
Model testów łączący automatyzację i ocenę człowieka
Testy automatyczne mogą pomóc wykryć część problemów, lecz żadne pojedyncze narzędzie nie potwierdza pełnej dostępności strony. Konieczna jest ręczna ocena człowieka, obejmująca między innymi przejście procesu z klawiaturą, sprawdzenie nazw pól, komunikatów, autouzupełniania oraz kopiowania i wklejania.
Jeżeli proces obejmuje kilka składników, każdy z nich powinien zostać sprawdzony. Gdy jest to możliwe, warto uwzględnić udział użytkowników z różnymi potrzebami. Ich doświadczenie może ujawnić bariery, których nie pokaże ani skaner, ani pojedyncza kontrola ekspercka.
Scenariusze i dokumentowanie wyników
Zakres testów powinien obejmować ścieżkę prawidłową, błędne dane, odzyskiwanie konta oraz powrót z linku e-mail, jeśli taki mechanizm zastosowano. Należy także sprawdzić wszystkie etapy uwierzytelniania wieloskładnikowego i zachowanie interfejsu po zmianie fokusu.
Wyniki warto zapisać w raporcie zawierającym zakres, kryteria, scenariusze, wykryte problemy, ich status oraz wynik ponownej weryfikacji po poprawkach. Taka dokumentacja porządkuje decyzje przed wdrożeniem i ułatwia rozdzielenie problemów dostępności od kwestii wymagających osobnej analizy bezpieczeństwa.
Lista kontrolna dla właściciela strony i zespołu projektowego
Przed akceptacją rozwiązania właściciel strony i zespół projektowy powinni sprawdzić nie tylko sam ekran logowania, lecz cały proces prowadzący do uzyskania i odzyskania dostępu. Poniższe pytania pomagają uporządkować decyzje projektowe i kontrolne.
Pytania przed akceptacją rozwiązania
- Czy każdy etap uwierzytelniania ma dostępną ścieżkę bez niedostępnego testu funkcji poznawczej?
- Czy przeglądarka i menedżer haseł mogą prawidłowo rozpoznać pola?
- Czy użytkownik może wkleić hasło lub kod w dozwolonym formacie?
- Czy komunikaty, fokus i obsługa klawiatury zostały sprawdzone w całym procesie?
- Czy magic link, jeśli jest rozważany, oceniono jako pełny przepływ wraz z kwestiami bezpieczeństwa?
- Czy zakres testów, ustalenia i poprawki zostały udokumentowane przed wdrożeniem?
Dostępne uwierzytelnianie wymaga spojrzenia na cały proces, a nie tylko na formularz logowania. Najważniejsze jest rozdzielenie kryteriów WCAG 2.2 od technik implementacyjnych oraz od analizy bezpieczeństwa. Kontroli wymagają wszystkie etapy, obsługa menedżerów haseł i wklejania, komunikaty, ewentualny magic link oraz testy automatyczne i ręczne. Lista kontrolna nie zastępuje audytu konkretnej strony, kodu, dostawcy tożsamości ani konfiguracji systemu. Umów konsultację z BrandingHouse, aby stworzyć spójny wizerunek marki i materiały dopasowane do celów Twojej firmy.
