Najważniejsze wnioski
- Kryterium WCAG 2.4.7 wymaga widocznego fokusu, ale nie określa jego minimalnej grubości ani kontrastu.
- WCAG 2.2 dodaje kryterium 2.4.11 Focus Not Obscured (Minimum): element z fokusem nie może zostać całkowicie zakryty przez treść strony.
- Kryterium 2.4.13 Focus Appearance na poziomie AAA doprecyzowuje minimalny obszar oraz kontrast zmiany wskaźnika fokusu.
- Test widocznego fokusu musi być wykonywany ręcznie na działającej stronie, z użyciem klawisza Tab, Shift+Tab, Enter i Spacji.
- Widget dostępności może wspierać użytkownika funkcjami skupienia, kontrastu i powiększenia, lecz nie zastępuje naprawy niewidocznego fokusu w kodzie źródłowym.
Dla zarządzającego
Widoczny fokus jest podstawowym warunkiem obsługi strony bez myszy. Warto potraktować go jako element jakości ścieżki zakupowej i obsługi klienta, a nie jako drobną decyzję wizualną. Najskuteczniejszy plan obejmuje ręczny test klawiaturą, listę błędów w komponentach wspólnych oraz trwałe poprawki w design systemie i kodzie.
Dla sprzedaży
Jeżeli klient pyta o dostępność sklepu, zaproponuj najpierw przejście ścieżki zakupowej samą klawiaturą: menu, wyszukiwarka, karta produktu, koszyk, formularz i płatność. WCAGbot może szybko dodać funkcje wspierające dostępność, takie jak większy tekst, kontrast czy narzędzia skupienia, ale niewidoczny lub zasłonięty fokus wymaga pracy po stronie interfejsu.
Widoczny fokus w WCAG 2.2 trzeba projektować jako stały element interfejsu, a nie dekorację pojawiającą się przypadkiem po naciśnięciu klawisza Tab. Użytkownik powinien wiedzieć, gdzie znajduje się na stronie, móc przejść do kolejnego elementu i nie tracić orientacji, gdy otworzy menu, koszyk, okno dialogowe albo formularz płatności.
To ważne zwłaszcza w e-commerce. Jeśli fokus jest niewidoczny, zasłonięty lub przeskakuje w nieoczekiwane miejsce, osoba korzystająca z klawiatury może nie wiedzieć, czy aktywuje filtr, usuwa produkt z koszyka czy przechodzi do płatności. W efekcie bariera dotyczy nie tylko zgodności z WCAG, ale też realnej możliwości zakończenia zadania.
Najważniejsze wnioski
- Nie usuwaj domyślnego
outline, jeżeli nie dostarczasz wyraźnego zamiennika. - Testuj fokus na całej ścieżce użytkownika, a nie wyłącznie na stronie głównej.
- Sprawdzaj osobno: widoczność, kolejność, kontrast wskaźnika oraz zasłanianie przez elementy przyklejone.
- Projektuj jeden spójny wzorzec fokusu dla linków, przycisków, pól, kart, komponentów niestandardowych i dialogów.
- Traktuj funkcje wspierające dostępność jako wsparcie dla użytkownika, a nie jako zamiennik poprawki źródłowej.
Fokus nie powinien zmuszać użytkownika do zgadywania, gdzie jest. Powinien jednoznacznie pokazywać, co można zrobić teraz.
Czym jest widoczny fokus i komu pomaga?
Fokus klawiatury to stan elementu interfejsu, który odbiera następne działanie z klawiatury. Po naciśnięciu Tab fokus może przejść na link, przycisk, pole formularza, przełącznik, element menu lub kontrolkę w koszyku. Naciśnięcie Enter albo Spacji uruchamia następnie działanie odpowiednie dla danego komponentu.
Widoczny fokus jest potrzebny osobom, które obsługują stronę bez myszy, ale korzystają też z ekranu. Mogą to być użytkownicy z ograniczeniami motorycznymi, osoby używające powiększenia, osoby słabowidzące oraz osoby, które łączą czytnik ekranu z obserwowaniem interfejsu. Pomaga również użytkownikom bez trwałej niepełnosprawności, na przykład wtedy, gdy touchpad nie działa albo gdy trzeba szybko wykonać powtarzalne zadanie.
Podstawy testu klawiaturą opisujemy w artykule Nawigacja klawiaturą: test strony bez myszy w 15 minut. Widoczny fokus jest jednym z najważniejszych sygnałów, które należy wtedy obserwować.
Jak WCAG 2.2 opisuje fokus?
Wymagania nie znajdują się w jednym kryterium. Dla zespołu projektowego i technicznego najważniejsze jest rozdzielenie pytań: czy można dojść do komponentu, czy kolejność jest logiczna, czy fokus widać oraz czy coś go nie zasłania.
| Kryterium | Poziom | Co sprawdza | Praktyczny przykład błędu |
|---|---|---|---|
| 2.1.1 Keyboard | A | Czy funkcję da się obsłużyć klawiaturą | Filtr produktu działa wyłącznie po kliknięciu myszą |
| 2.4.3 Focus Order | A | Czy fokus przechodzi w logicznej kolejności | Po polu e-mail fokus przeskakuje do stopki |
| 2.4.7 Focus Visible | AA | Czy fokus jest widoczny | CSS usuwa obrys bez zamiennika |
| 2.4.11 Focus Not Obscured (Minimum) | AA | Czy komponent z fokusem nie jest całkowicie zakryty | Sticky footer całkowicie zasłania przycisk „Dalej” |
| 1.4.11 Non-text Contrast | AA | Czy komponent i jego stan mają dostrzegalny kontrast | Obrys stapia się z tłem formularza |
| 2.4.13 Focus Appearance | AAA | Czy wskaźnik ma odpowiedni obszar i zmianę kontrastu | Fokus to ledwo zauważalna jednopykselowa zmiana |
Co oznacza 2.4.7 Focus Visible?
Kryterium 2.4.7 na poziomie AA wymaga, aby każdy interfejs obsługiwany klawiaturą miał tryb działania, w którym wskaźnik fokusu klawiatury jest widoczny. Nie wskazuje konkretnego koloru ani liczby pikseli. Nie oznacza to jednak dowolności: użytkownik musi faktycznie zauważyć, który element jest aktywny.
Błędem jest na przykład globalna reguła *:focus { outline: none; }, jeśli zespół nie zapewnił innego widocznego wskaźnika. Ryzykowne jest też poleganie wyłącznie na subtelnej zmianie odcienia tła, szczególnie w kartach produktów, jasnych formularzach i komponentach z wieloma stanami.
Co nowe kryterium 2.4.11 zmienia w WCAG 2.2?
WCAG 2.4.11 Focus Not Obscured (Minimum) wymaga na poziomie AA, aby komponent z fokusem nie był całkowicie zasłonięty przez treści utworzone przez autora strony. Dotyczy to między innymi sticky headerów, banerów cookies, wysuwanych czatów, pasków promocyjnych, stopek przyklejonych do dołu ekranu i przewijanych kontenerów.
Test widocznego fokusu na ścieżce zakupowej
To istotne doprecyzowanie względem WCAG 2.1. W poprzedniej wersji można było mieć technicznie widoczny styl fokusu, ale użytkownik mógł go nie zobaczyć, bo element znajdował się pod nakładką. W WCAG 2.2 taki przypadek trzeba ocenić również pod kątem 2.4.11.
Jak rozumieć 2.4.13 Focus Appearance?
Kryterium 2.4.13 Focus Appearance ma poziom AAA. Doprecyzowuje, że wskaźnik fokusu powinien mieć obszar co najmniej równy obwodowi o grubości 2 CSS px wokół nieaktywnego komponentu lub jego części. Wymaga także kontrastu co najmniej 3:1 między tymi samymi pikselami w stanie skupionym i nieskupionym.
Nie należy mylić tego z jedynym testem kontrastu obrysu wobec tła. W praktyce warto ocenić dwa zagadnienia: czy wskaźnik odróżnia się od elementów wokół niego oraz czy jego pojawienie się tworzy dostatecznie zauważalną zmianę względem stanu bez fokusu.
WCAG 2.2 nie oznacza automatycznie, że każda organizacja ma indywidualny obowiązek spełnienia poziomu AAA. Kryterium jest jednak dobrym punktem odniesienia dla design systemu, szczególnie gdy projektujesz własny komponent, który ma działać w wielu widokach i motywach.
Jak zaprojektować fokus, który nie ginie w interfejsie?
Najbezpieczniejszym wzorcem jest wyraźny obrys umieszczony na zewnątrz komponentu. Obrys powinien kontrastować z otoczeniem i nie być przycinany przez overflow: hidden. Dodatkowy odstęp między obrysem a komponentem ułatwia odróżnienie fokusu od obramowania walidacyjnego, zaznaczenia lub aktywnego stanu przycisku.
Przykład CSS dla typowych komponentów
:where(a, button, input, select, textarea, summary, [tabindex]):focus-visible {
outline: 3px solid #005fcc;
outline-offset: 3px;
}
@media (forced-colors: active) {
:where(a, button, input, select, textarea, summary, [tabindex]):focus-visible {
outline: 3px solid Highlight;
outline-offset: 3px;
}
}To przykład startowy, a nie gotowa gwarancja zgodności. W konkretnym projekcie trzeba sprawdzić relację kolorów z tłem, zachowanie w jasnym i ciemnym motywie, elementy na obrazach, komponenty wewnątrz kontenerów przewijanych oraz style dostarczane przez przeglądarkę.
Pseudoklasa :focus-visible jest zwykle lepszym wyborem niż globalne stylowanie :focus, ponieważ pozwala pokazać wyraźny wskaźnik wtedy, gdy przeglądarka rozpoznaje potrzebę wizualnego oznaczenia fokusu. Nie zwalnia to jednak z testowania zachowania dla pól formularza, przycisków niestandardowych i elementów obsługiwanych skryptem.
Wybierz wzorzec, a nie pojedynczy kolor
W design systemie warto ustalić zasady obowiązujące dla wszystkich komponentów. Dobra definicja obejmuje: kolor obrysu, grubość, odstęp, zachowanie na tle obrazów, obsługę wymuszonego kontrastu systemowego oraz zasady dla błędu walidacji. Jeśli pole ma czerwone obramowanie z powodu błędu, fokus nie może zniknąć w tym sygnale. Można zastosować dodatkowy zewnętrzny obrys albo wyraźną zmianę tła i obramowania.
W sklepie internetowym szczególnej uwagi wymagają karty produktów. Jeżeli karta jest klikana, jej fokus powinien obejmować logiczny obszar interaktywny. Nie należy jednocześnie tworzyć niepotrzebnie zagnieżdżonych elementów interaktywnych, na przykład całej karty jako linku i osobnego linku wewnątrz karty.
Jak wykonać test akceptacyjny widocznego fokusu?
Automatyczny skaner może wskazać część ryzyk w CSS, ale nie oceni wiarygodnie tego, czy użytkownik widzi fokus po otwarciu menu, czy fokus wraca z modalu do właściwego przycisku ani czy baner zakrywa element w przewijanym panelu. Dlatego test wykonuj na działającej stronie.
Test w sześciu krokach
- Otwórz stronę w zwykłym widoku. Nie klikaj wcześniej w treść. Zacznij od paska adresu lub otwórz stronę ponownie.
- Naciskaj Tab. Przy każdym kroku nazwij element, który ma fokus. Jeśli nie możesz go wskazać wzrokiem w sekundę, zapisz problem.
- Wróć klawiszami Shift+Tab. Sprawdź, czy fokus jest równie widoczny przy przechodzeniu wstecz.
- Uruchamiaj komponenty Enterem i Spacją. Zweryfikuj menu, filtry, akordeony, modal, koszyk oraz walidację formularza.
- Sprawdź nakładki i elementy sticky. Otwórz baner cookies, czat lub promocję. Przejdź fokusem do elementu blisko górnej i dolnej krawędzi widoku.
- Powtórz test w krytycznych stanach. Testuj pusty koszyk, koszyk z produktem, błąd formularza, brak wyników wyszukiwania, zalogowanie i wylogowanie.
Co sprawdzają kryteria fokusu w WCAG
Pełniejszą listę elementów do przejścia znajdziesz w artykule Dostępność sklepu internetowego – checklista pierwszych kroków. Dla formularzy szczególnie ważne jest też powiązanie widocznego fokusu z etykietą, opisem błędu i logiczną kolejnością pól.
Kryteria akceptacji dla zespołu
- Każdy operowalny element osiągalny klawiszem Tab ma jednoznacznie widoczny fokus.
- Fokus nie jest usuwany bez przeniesienia go do logicznego miejsca.
- Po otwarciu dialogu fokus przechodzi do dialogu, a po jego zamknięciu wraca do kontrolki otwierającej, jeśli kontekst zadania tego wymaga.
- Sticky header, stopka, baner i czat nie zasłaniają całkowicie komponentu z fokusem.
- Wskaźnik pozostaje rozpoznawalny przy powiększeniu oraz w dostępnych motywach kolorystycznych.
- Elementy niestandardowe, takie jak karty, przełączniki i menu, mają ten sam lub równoważnie czytelny wzorzec fokusu jak elementy natywne.
Mini-scenariusz: focus w koszyku sklepu
Scenariusz ilustracyjny, nie wynik wdrożenia klienta: sklep ma sticky header, wysuwany panel koszyka i baner cookies. Użytkownik przechodzi Tabem przez listę produktów, otwiera koszyk, a następnie trafia na przycisk „Przejdź do dostawy”. Przycisk otrzymuje fokus, lecz zostaje całkowicie przykryty przez przyklejony baner na dole ekranu. Użytkownik widzi zmianę przewijania, ale nie widzi aktywnego elementu.
Naprawa nie polega na dodaniu kolejnego koloru do przycisku. Zespół powinien zmienić mechanizm przewijania lub pozycjonowanie nakładki tak, aby komponent z fokusem był odsłonięty. Następnie warto sprawdzić cały panel koszyka przy otwartym i zamkniętym banerze, w widoku mobilnym oraz na powiększeniu.
Jeżeli problem powtarza się w wielu widokach, należy naprawić wspólny komponent layoutu, a nie pojedyncze przyciski. To przykład naprawy źródłowej, która powinna trafić do backlogu produktu lub zespołu utrzymaniowego.
WCAGbot Accessibility Path: od szybkiego wsparcia do naprawy
Widoczny fokus można uporządkować według schematu WCAGbot Accessibility Path:
- Rozpoznaj ścieżki krytyczne. W e-commerce będą to zwykle wyszukiwarka, produkt, koszyk, formularz i płatność.
- Wykonaj ręczny test klawiaturą. Zapisuj miejsce, komponent, stan oraz sposób odtworzenia bariery.
- Rozdziel wsparcie od naprawy. Funkcje zwiększenia tekstu, kontrastu i narzędzia skupienia mogą wspierać użytkownika, ale nie naprawiają CSS usuwającego fokus ani błędnego zarządzania fokusem w modalu.
- Napraw wzorzec w kodzie i design systemie. Ustal wspólny styl oraz zasady dla komponentów dynamicznych.
- Przetestuj regresję. Powtórz przejście klawiaturą po wdrożeniu oraz przed publikacją większych zmian.
Możesz teraz otworzyć panel WCAGbot i sprawdzić stronę na własnym przykładzie: zwiększ tekst, przetestuj kontrast i zobacz, czy przy większej skali nadal bez trudu odnajdujesz fokus. To praktyczne doświadczenie pomaga zauważyć bariery wizualne, ale nie zastępuje testu samej kolejności i widoczności fokusu.
Gdzie widget dostępności pomaga, a gdzie nie wystarcza?
WCAGbot pozwala dodać funkcje wspierające dostępność bez kodowania, między innymi tryby kontrastu, powiększenie tekstu, czytelną czcionkę, większy kursor oraz funkcje skupienia i przewodnika do czytania. Takie narzędzia mogą ułatwiać odbiór strony konkretnemu użytkownikowi i być rozsądnym pierwszym krokiem do dostępności.
Nie należy jednak przedstawiać widgetu jako rozwiązania niewidocznego fokusu w kodzie strony. Jeżeli autor CSS usunął obrys, element jest zasłaniany przez banner albo skrypt przenosi fokus w błędne miejsce, konieczna jest analiza i trwała poprawka źródłowa. Więcej o tej granicy wyjaśnia tekst Widget dostępności a zgodność z WCAG: uczciwe porównanie.
Właściciele stron WordPress, Shopify i rozwiązań własnych mogą wdrożyć WCAGbot jedną linią kodu bez przebudowy witryny. Instrukcję techniczną opisuje artykuł Jak zainstalować WCAGbot na stronie w 5 minut. Po instalacji nadal warto prowadzić listę barier wymagających pracy w motywie, szablonie, aplikacji lub treści.
Dobry i ryzykowny wskaźnik fokusu
Jak widoczny fokus ma się do WCAG 2.1, WCAG 2.2 i EN 301 549?
WCAG to wytyczne dostępności treści internetowych. WCAG 2.2 rozwija wymagania znane z WCAG 2.1 między innymi o kryterium dotyczące zasłoniętego fokusu. EN 301 549 jest europejską normą dotyczącą wymagań dostępności produktów i usług ICT; obejmuje szerszy kontekst niż sama zawartość stron internetowych.
W materiałach dotyczących Polskiego Aktu o Dostępności trzeba rozróżniać ustawę, normę EN 301 549 oraz wytyczne WCAG. Nie należy sprowadzać wymagań prawnych wyłącznie do hasła „WCAG 2.1 AA” lub „WCAG 2.2 AA”. Kontekst wyjaśniają publikacje WCAG 2.1, WCAG 2.2 i EN 301 549 – czym się różnią? oraz EN 301 549 dla e-commerce: wymagania poza samym WCAG.
Ten artykuł ma charakter informacyjny i techniczny. Ocena obowiązków konkretnej firmy zależy od rodzaju usługi, zakresu działalności i aktualnych przepisów. Informacje o zastosowaniu PAD dla sklepów warto sprawdzać w aktualnych źródłach urzędowych oraz w przewodniku Czy Polski Akt o Dostępności dotyczy sklepu online?.
Podsumowanie dla zarządzającego i sprzedaży
Widoczny fokus to kontrola jakości podstawowej interakcji. Nie wymaga kosztownej przebudowy wtedy, gdy zespół ma wspólny wzorzec komponentów i testuje go przed publikacją. Największe ryzyko powstaje, gdy fokus jest traktowany jako detal CSS, a nie jako informacja nawigacyjna dla użytkownika.
Dla zespołu sprzedażowego praktyczny punkt rozmowy jest prosty: poproś klienta, aby przeszedł bez myszy od strony głównej do finalizacji zakupu. Jeśli nie potrafi w każdej chwili wskazać aktywnego elementu, ma konkretny obszar do audytu i naprawy. WCAGbot może równolegle wspierać użytkowników narzędziami kontrastu, tekstu i skupienia, lecz trwałe usunięcie bariery wymaga poprawy interfejsu.
Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot jako pierwszy krok. Następnie zaplanuj ręczny test klawiaturą oraz naprawy źródłowe dla wszystkich wykrytych problemów z fokusem.
FAQ: widoczny fokus w WCAG 2.2
Czy WCAG 2.2 wymaga widocznego fokusu?
Tak. Kryterium 2.4.7 Focus Visible na poziomie AA wymaga widocznego wskaźnika fokusu dla interfejsu obsługiwanego klawiaturą.
Czy sam domyślny outline przeglądarki wystarczy?
Może wspierać spełnienie wymogu widoczności, jeżeli nie został zmodyfikowany i jest faktycznie dostrzegalny. W praktyce należy go sprawdzić w kontekście konkretnego interfejsu, tła, motywów i komponentów niestandardowych.
Czy można użyć outline: none?
Tak tylko wtedy, gdy równocześnie zapewnisz inny, wyraźny wskaźnik fokusu. Usunięcie obrysu bez zamiennika jest typowym błędem.
Jaka grubość obramowania fokusu jest najlepsza?
WCAG 2.4.7 nie narzuca grubości. Jako praktyczny wzorzec często stosuje się obrys o grubości 2 lub 3 CSS px oraz wyraźny odstęp od komponentu. Dla poziomu AAA kryterium 2.4.13 odwołuje się do obszaru odpowiadającego obwodowi o grubości 2 CSS px.
Czy fokus może być zasłonięty częściowo?
Kryterium 2.4.11 Focus Not Obscured (Minimum) na poziomie AA zabrania całkowitego zasłonięcia komponentu z fokusem przez treść autora. Częściowe zasłonięcie może nadal być problemem użyteczności, dlatego warto projektować tak, aby element był w pełni widoczny.
Czy baner cookies może zasłonić przycisk z fokusem?
Jeżeli całkowicie zasłania komponent z fokusem, jest to problem względem 2.4.11. Należy zmienić zachowanie nakładki, przewijania lub pozycjonowania elementu.
Czy test automatyczny wykryje niewidoczny fokus?
Nie w sposób kompletny. Narzędzie może wykryć część podejrzanych reguł CSS, ale nie zastąpi ręcznego przejścia przez dynamiczne widoki, modale, koszyk i formularze.
Czy :focus-visible jest lepsze niż :focus?
Najczęściej tak, ponieważ pozwala wyświetlać styl wtedy, gdy przeglądarka uznaje wizualny wskaźnik za potrzebny. Trzeba jednak przetestować wszystkie obsługiwane przeglądarki i komponenty, zwłaszcza niestandardowe kontrolki.
Czy widget dostępności naprawi fokus usunięty w CSS?
Nie należy tego zakładać. Widget może oferować funkcje wspierające dostępność użytkownika, ale niewidoczny fokus w kodzie źródłowym wymaga poprawki w CSS, komponencie lub mechanizmie zarządzania fokusem.
Czy widoczny fokus dotyczy tylko komputerów?
Najczęściej analizuje się go w kontekście obsługi klawiaturą, ale warto badać go również w środowiskach z klawiaturą ekranową, przełącznikami, powiększeniem oraz urządzeniami hybrydowymi.
