Stany fokusu na stronie internetowej są podstawowym elementem orientacji dla osób, które korzystają z klawiatury lub innych urządzeń działających za pośrednictwem interfejsu klawiaturowego. Fokus wskazuje, który komponent jest aktualnie aktywny, dzięki czemu użytkownik może śledzić przebieg interakcji bez użycia myszy. Jego widoczność nie jest dodatkiem do projektu, lecz częścią jakości interfejsu, sposobu wdrożenia marki i odpowiedzialnego zarządzania doświadczeniem użytkownika.
Projektowanie tego mechanizmu wymaga rozdzielenia trzech kwestii: samej widoczności fokusu, ochrony elementu przed zasłonięciem oraz spójności wizualnej całego systemu interakcji. WCAG nie narzuca jednego stylu graficznego, dlatego organizacja może opracować własne rozwiązanie. Powinno ono jednak pozostać jednoznaczne, konsekwentne i możliwe do zweryfikowania w działającym, responsywnym interfejsie.
Dlaczego stany fokusu są elementem jakości interfejsu
Podczas nawigacji klawiszem Tab lub Shift+Tab użytkownik przemieszcza fokus pomiędzy elementami dostępnymi z klawiatury. Widoczny wskaźnik pozwala rozpoznać, gdzie w danym momencie znajduje się aktywność. Bez niego nawet poprawnie działające linki, przyciski, pola formularzy czy elementy menu mogą stać się trudne do użycia, ponieważ użytkownik nie otrzymuje informacji o aktualnym miejscu interakcji.
Z perspektywy organizacji jest to również kwestia jakości procesu projektowego. Fokus powinien zostać uwzględniony podczas definiowania komponentów, stanów interakcji i zasad wdrożenia, a nie dopiero na końcu prac. Pozwala to ograniczyć niespójności pomiędzy widokami oraz ryzyko, że poszczególne elementy będą reagować inaczej. Sama makieta nie wystarcza do oceny dostępności. Trzeba sprawdzić rzeczywiste zachowanie komponentów, ich kolejność, automatyczne przewijanie i reakcję na elementy nakładane.
Warto traktować fokus jako część systemu interfejsu, obok stanów domyślnych, hover, pressed, selected i disabled. Każdy z nich przekazuje inną informację. Dobrze zaprojektowany system ułatwia wdrożenie strony, rozwój kolejnych komponentów i zachowanie spójności marki w różnych widokach.
Czym jest widoczny stan fokusu
Kryterium WCAG 2.4.7 Focus Visible wymaga, aby interfejs obsługiwany klawiaturą miał co najmniej jeden tryb działania, w którym wskaźnik fokusu klawiaturowego jest widoczny. Wskaźnik powinien pozostać widoczny przez cały czas, gdy element ma fokus. Nie powinien być ograniczony czasowo ani pojawiać się wyłącznie w wybranych sytuacjach, których użytkownik nie może przewidzieć.
Widoczny stan może przyjąć formę obramowania, wyróżnienia tła, zmiany obwódki albo innego jednoznacznego oznaczenia. Istotne jest nie to, który wariant zostanie wybrany, lecz czy aktywny komponent można łatwo rozpoznać na tle strony i pozostałych stanów. Rozwiązanie powinno obejmować linki, przyciski, pola formularzy, elementy menu oraz komponenty niestandardowe, jeżeli są dostępne z klawiatury.
Fokus a pozostałe stany komponentu
Fokus nie jest odpowiednikiem stanu hover. Hover wynika zazwyczaj z położenia wskaźnika myszy, natomiast fokus musi być możliwy do rozpoznania bez użycia myszy. Nie należy również utożsamiać go ze stanem pressed, który informuje o aktywacji, selected, który oznacza wybór, ani disabled, który wskazuje ograniczoną dostępność komponentu.
Rozróżnienie tych stanów ma znaczenie operacyjne. Jeżeli ten sam efekt wizualny oznacza kilka różnych sytuacji, użytkownik może nie wiedzieć, czy element jest aktualnie aktywny, wybrany, naciśnięty czy tylko wskazywany przez kursor. Zasady powinny być stosowane konsekwentnie w całym interfejsie, a ich znaczenie jasno opisane w dokumentacji komponentów.
Jak projektować wyraźny i spójny wskaźnik fokusu
Projektowanie wskaźnika należy rozpocząć od określenia, jak ma on wyróżniać komponent na różnych tłach i w różnych stanach. Można wykorzystać obramowanie, zmianę obwódki, wyróżnienie tła lub inne rozwiązanie, o ile pozostaje ono wyraźne. Wskaźnik nie powinien zlewać się z komponentem, tłem strony ani elementami sąsiadującymi.
Spójność nie oznacza identycznego wyglądu każdego elementu za wszelką cenę. Oznacza raczej przyjęcie rozpoznawalnych zasad, które można zastosować do linków, przycisków, formularzy i menu. Należy sprawdzić, czy wskaźnik zachowuje czytelność przy różnych tłach, długościach etykiet, stanach aktywnych oraz w układach responsywnych. Projekt powinien wynikać z zasad dostępności i identyfikacji wizualnej organizacji, a nie z kopiowania rozwiązań konkretnych marek.
Stany interakcji w systemie projektowym
W systemie projektowym warto opisać fokus razem z pozostałymi stanami komponentu. Dokumentacja powinna wskazywać zasady dotyczące kolorów, obramowań, grubości linii, kształtów i sposobu zachowania wskaźnika. Dzięki temu osoba rozwijająca serwis nie musi za każdym razem tworzyć rozwiązania od początku.
Taki opis powinien obowiązywać w wielu widokach i dla różnych typów komponentów. Należy również uwzględnić elementy niestandardowe oraz sytuacje, w których komponent zmienia położenie lub jest otwierany dynamicznie. Ostateczną ocenę trzeba przeprowadzić w działającym interfejsie. Sam wygląd biblioteki komponentów lub makiety nie potwierdza, że fokus będzie widoczny podczas rzeczywistej nawigacji.
Focus Appearance w WCAG 2.2
Kryterium 2.4.13 Focus Appearance w WCAG 2.2 dotyczy bardziej szczegółowych wymagań dotyczących rozmiaru i kontrastu wskaźnika fokusu. Wskazuje ono, że obszar wskaźnika powinien być co najmniej równy obszarowi obwodu o grubości 2 pikseli CSS wokół nieaktywnego komponentu. Określa także kontrast co najmniej 3:1 między odpowiednimi pikselami stanu aktywnego i nieaktywnego.
Istotne jest prawidłowe określenie zakresu tych wymagań. Focus Appearance należy do poziomu AAA, dlatego nie powinien być przedstawiany jako minimalny wymóg poziomu AA. Formalne kryteria WCAG należy oddzielać od rekomendacji projektowych, takich jak przyjęcie własnego, spójnego stylu obramowania czy określenie zasad dla całej biblioteki komponentów.
W praktyce wymagania dotyczące wielkości i kontrastu są użytecznym punktem odniesienia przy ocenie wyrazistości. Nie oznacza to jednak, że sama ocena wskaźnika potwierdza pełną dostępność serwisu. Potrzebne są również testy kolejności fokusu, działania komponentów, widoków responsywnych i warstw dynamicznych.
Jak sprawdzić, czy fokus nie jest zasłaniany
Test należy rozpocząć od przejścia strony wyłącznie za pomocą klawiszy Tab i Shift+Tab. Trzeba obserwować każdy element otrzymujący fokus i sprawdzić, czy pozostaje co najmniej częściowo widoczny. Szczególną uwagę należy zwrócić na automatyczne przewijanie. Element nie powinien po zmianie fokusu trafić pod przyklejoną warstwę interfejsu.
Weryfikację trzeba powtórzyć w obecności elementów, które mogą zasłaniać treść. Dotyczy to między innymi przyklejonego nagłówka, przyklejonej stopki, banera cookies, powiadomień, rozwijanego menu, dialogów oraz innych warstw nakładanych na stronę. Należy sprawdzić zarówno normalny widok, jak i sytuacje, w których elementy te pojawiają się lub znikają podczas interakcji.
Test powinien obejmować różne rozmiary ekranu oraz dynamicznie otwierane komponenty. Układ, który pozostaje poprawny na jednym widoku, może zachowywać się inaczej po zmianie szerokości albo po pojawieniu się dodatkowej warstwy. Sam przegląd kodu lub projektu wizualnego nie zastępuje rzeczywistej nawigacji klawiaturą.
Minimum i Enhanced w praktyce testowej
WCAG 2.2 rozróżnia dwa kryteria dotyczące zasłaniania fokusu. Focus Not Obscured (Minimum), czyli kryterium 2.4.11, należy do poziomu AA i wymaga, aby komponent otrzymujący fokus nie był całkowicie ukryty przez treści utworzone przez autora. Dopuszczenie częściowego zasłonięcia na tym poziomie nie oznacza, że jest ono optymalnym rozwiązaniem projektowym.
Focus Not Obscured (Enhanced), czyli kryterium 2.4.12, należy do poziomu AAA i wymaga pełnej widoczności komponentu z fokusem. Podczas oceny trzeba więc jasno wskazać, czy weryfikowany jest minimalny poziom AA, czy bardziej rygorystyczny poziom AAA. W obu przypadkach ocena powinna uwzględniać nakładane warstwy, automatyczne przewijanie i różne stany interfejsu.
Jak połączyć dostępność z identyfikacją wizualną marki
Fokus warto traktować jako element identyfikacji interfejsu, a nie przypadkowy efekt dodany po zakończeniu prac. Można wykorzystać kolory marki, kształt obramowania, promień narożnika, grubość linii lub charakterystyczny sposób wyróżnienia. Warunkiem jest zachowanie czytelności i wyraźnego odróżnienia aktywnego elementu od tła oraz pozostałych stanów.
Takie podejście pozwala połączyć dostępność klawiatury ze spójnością wizualną bez sprowadzania brandingu do dekoracji. System powinien być opisany w dokumentacji projektowej lub bibliotece komponentów i konsekwentnie stosowany w całym serwisie. Własne rozwiązanie jest bezpieczniejszym kierunkiem niż kopiowanie stylów konkretnych marek.
Pseudoklasa :focus-visible może pomóc wskazać fokus klawiaturowy, ale sama nie gwarantuje zgodności. Zastosowany styl musi rzeczywiście zapewniać widoczny wskaźnik. Weryfikacja powinna odbywać się w działającym interfejsie, także przy różnych rozmiarach ekranu i komponentach dynamicznych.
Najczęstsze błędy i końcowa lista kontrolna
Najpoważniejszym błędem jest usunięcie domyślnego outline lub innego oznaczenia fokusu bez zapewnienia równoważnego, wyraźnego wskaźnika. Nie należy także uznawać stanu hover za odpowiednik fokusu ani oceniać interfejsu wyłącznie na podstawie wyglądu pojedynczej makiety.
Przed wdrożeniem warto sprawdzić, czy:
- każdy komponent dostępny z klawiatury ma rozpoznawalny stan fokusu;
- wskaźnik pozostaje widoczny przez cały czas aktywnego fokusu;
- fokus różni się od stanów hover, pressed, selected i disabled;
- sticky header, sticky footer, baner cookies, powiadomienia, menu i dialogi nie zasłaniają komponentu całkowicie;
- automatyczne przewijanie nie umieszcza elementu pod przyklejoną warstwą;
- rozwiązanie działa w różnych rozmiarach ekranu i przy dynamicznych zmianach interfejsu;
- zasady są spójne dla linków, przycisków, formularzy, menu i komponentów niestandardowych;
- wymagania WCAG są odróżnione od rekomendacji projektowych i celów poziomu AAA.
Lista kontrolna porządkuje proces, ale nie zastępuje pełnego testowania dostępności. Szczególnie ważna jest rzeczywista nawigacja klawiaturą, ponieważ dopiero ona pokazuje, jak system zachowuje się podczas użytkowania.
Widoczny fokus jest jednocześnie wymaganiem dostępności, elementem jakości interfejsu i częścią systemu wizualnego marki. Najpierw należy zapewnić jednoznaczność wskaźnika oraz jego widoczność podczas nawigacji klawiaturą, a następnie zweryfikować, czy komponenty nie są całkowicie zasłaniane przez warstwy interfejsu. Warto pamiętać, że Focus Not Obscured Minimum i Focus Appearance dotyczą różnych poziomów WCAG, a wymagania AAA nie powinny być przedstawiane jako minimum AA. Spójność projektu trzeba potwierdzić testami w działającym serwisie, również w widokach responsywnych i dynamicznych. Umów konsultację z BrandingHouse, aby stworzyć spójny wizerunek marki i materiały dopasowane do celów Twojej firmy.
