Najważniejsze wnioski
- WCAG 2.4.7 na poziomie AA wymaga widocznego wskaźnika dla elementu obsługiwanego z klawiatury. Samo techniczne otrzymanie fokusu nie wystarcza.
- Nie usuwaj globalnie <code>outline</code> bez zaprojektowania i przetestowania wyraźnego zamiennika. Dobrym punktem wyjścia jest styl dla <code>:focus-visible</code> oraz fallback dla <code>:focus</code>.
- Widoczność fokusu trzeba sprawdzać ręcznie: klawiszem Tab, Shift+Tab, Enter, spacją, strzałkami i Escape — zwłaszcza w menu, formularzu, modalu, koszyku i płatności.
- Focus Visible nie jest tym samym co Focus Not Obscured. W WCAG 2.2 należy dodatkowo sprawdzić, czy przyklejony nagłówek, baner lub panel nie zasłania aktualnego fokusu.
- Widget dostępności może wspierać użytkownika dodatkowymi funkcjami, ale trwałe usunięcie błędu niewidocznego fokusu wymaga poprawy stylów i komponentów w kodzie źródłowym.
Dla zarządzającego
Widoczny fokus jest podstawowym elementem obsługi strony bez myszy. Warto potraktować go jako stały standard komponentów, a nie pojedynczą poprawkę wizualną przed audytem.
Dla sprzedaży
W rozmowie o dostępności warto wyjaśnić klientowi, że fokus wpływa na przejście przez ofertę, formularz, koszyk i płatność klawiaturą. WCAGbot może być szybkim pierwszym krokiem wspierającym użytkowników, lecz nie zastępuje naprawy stylów fokusu w serwisie.
Focus Visible 2.4.7 oznacza, że użytkownik obsługujący stronę klawiaturą musi widzieć aktualne położenie fokusu. Jeśli po naciśnięciu klawisza Tab nie wiadomo, który link, przycisk lub element formularza zostanie aktywowany, interfejs nie spełnia praktycznego celu tego kryterium.
To wymaganie ma poziom AA w WCAG i dotyczy każdego komponentu interfejsu, który można obsłużyć z klawiatury. Nie chodzi wyłącznie o przyciski i linki. Zakres obejmuje również pola formularzy, zakładki, menu, filtry, suwaki, modale oraz komponenty JavaScript.
Najważniejsze wnioski
- Widoczny fokus to informacja o aktualnym miejscu interakcji, a nie efekt dekoracyjny.
- Nie należy usuwać
outlineglobalnie, jeśli strona nie dostarcza równie widocznego zamiennika. - Test automatyczny nie wystarczy: widoczność fokusu wymaga przejścia przez rzeczywistą ścieżkę klawiaturą.
- W sklepie internetowym należy sprawdzić fokus od menu przez produkt i koszyk aż po potwierdzenie płatności.
- Widget może wspierać dostępność użytkownika, ale nie naprawia źródłowo CSS ani zachowania komponentów, których fokus jest niewidoczny.
Czym dokładnie jest WCAG 2.4.7 Focus Visible?
Kryterium WCAG 2.4.7 Focus Visible wymaga, aby interfejs możliwy do obsługi klawiaturą zapewniał tryb, w którym wskaźnik fokusu klawiatury jest widoczny. W praktyce użytkownik powinien bez zgadywania rozpoznać, gdzie znajduje się po naciśnięciu Tab, Shift+Tab, strzałek lub po programowym przeniesieniu fokusu.
Fokus nie jest tym samym co stan :hover, :active, zaznaczenie tekstu ani aktywna karta wizualnie wyróżniona po kliknięciu. Hover działa tylko przy wskaźniku myszy. Fokus musi działać także wtedy, gdy użytkownik korzysta z klawiatury, przełącznika albo technologii emulującej klawiaturę.
Widoczny fokus nie powinien być nagrodą za znalezienie elementu. Powinien być stałą wskazówką, która pomaga użytkownikowi go znaleźć.
Jeżeli dopiero rozpoczynasz porządkowanie wymagań, przeczytaj również poradnik WCAG 2.1 AA: co oznacza i jak wdrożyć na stronie oraz materiał Dostępność cyfrowa: jak zacząć poprawiać stronę.
Dla kogo widoczny fokus ma znaczenie?
Widoczny wskaźnik jest szczególnie ważny dla osób, które nie używają myszy z powodu ograniczeń ruchowych, korzystają z klawiatury jako preferowanej metody pracy albo używają urządzeń wspomagających opartych na obsłudze klawiatury. Pomaga też osobom słabowidzącym oraz użytkownikom, którym trudno utrzymać uwagę podczas przechodzenia przez długą stronę lub formularz.
Czytnik ekranu może zakomunikować nazwę i rolę elementu, ale nie zastępuje wizualnego wskaźnika dla osoby widzącej, która porusza się wyłącznie klawiaturą. Dlatego warto łączyć test klawiaturą z testem czytnikiem ekranu, na przykład według wskazówek z artykułu NVDA: praktyczny poradnik testowania dostępności.
Jak Focus Visible łączy się z innymi kryteriami WCAG?
| Kryterium | Pytanie kontrolne | Co sprawdzić w praktyce? |
|---|---|---|
| 2.4.7 Focus Visible, AA | Czy wiadomo, który element ma fokus? | Przejdź po wszystkich kontrolkach klawiszem Tab i obserwuj wskaźnik. |
| 1.4.11 Non-text Contrast, AA | Czy wskaźnik da się odróżnić od tła i komponentu? | Oceń kontrast na jasnych, ciemnych i kolorowych tłach oraz w stanach disabled i error. |
| 2.4.11 Focus Not Obscured, AA w WCAG 2.2 | Czy element z fokusem nie jest całkowicie zasłonięty? | Sprawdź sticky header, banner cookies, czat, stopkę i wysuwane panele. |
| 2.4.13 Focus Appearance, AAA w WCAG 2.2 | Czy wskaźnik spełnia rozszerzone wymagania wyglądu? | Oceń obszar oraz zmianę kontrastu zgodnie z kryterium AAA. |
Nie należy mylić tych wymagań. Kryterium 2.4.7 nie narzuca jednej grubości obrysu ani konkretnego koloru. Wymaganie 2.4.13 na poziomie AAA opisuje bardziej szczegółowo wielkość i kontrast wskaźnika. Z kolei 2.4.11 skupia się na tym, aby element z fokusem nie został całkowicie zasłonięty przez treść utworzoną przez autora strony.
WCAGbot Accessibility Path dla widocznego fokusu
Jak wdrożyć widoczny fokus bez ryzyka dla interfejsu?
1. Nie usuwaj domyślnego outline bez zamiennika
Najczęstszy błąd to globalna reguła ukrywająca obrys:
*:focus {
outline: none;
}Takie CSS może sprawić, że użytkownik nadal technicznie przechodzi po elementach, lecz traci informację o swojej pozycji. W3C wskazuje usunięcie lub ukrycie wskaźnika fokusu jako typowy sposób niespełnienia kryterium.
Jeżeli projekt nie wymaga niestandardowego wyglądu, rozsądnym rozwiązaniem jest pozostawienie domyślnego fokusu przeglądarki. Jest to często lepsze niż szybkie, niedostatecznie przetestowane zastępstwo.
2. Stosuj wyraźny styl :focus-visible
Jeśli zespół projektuje własny system komponentów, zacznij od czytelnego stylu obejmującego elementy natywne i kontrolki niestandardowe:
:where(a, button, input, select, textarea, [tabindex]):focus-visible {
outline: 3px solid #005fcc;
outline-offset: 3px;
}Wartości 3px są przykładem projektowym, a nie uniwersalnym wymogiem WCAG. Należy ocenić wynik na konkretnym tle, przy danym rozmiarze komponentu i w jego różnych stanach. Reguła :focus-visible pozwala przeglądarce pokazywać mocny wskaźnik przede wszystkim wtedy, gdy jest potrzebny do obsługi klawiaturą.
3. Zapewnij fallback i przetestuj go
W projektach, które chcą utrzymać podstawowe zachowanie także poza nowoczesnym selektorem, można zacząć od stylu :focus, a później ograniczyć go w warunkach obsługi :focus-visible:
:where(a, button, input, select, textarea, [tabindex]):focus {
outline: 3px solid #005fcc;
outline-offset: 3px;
}
:where(a, button, input, select, textarea, [tabindex]):focus:not(:focus-visible) {
outline: none;
}Nie kopiuj tego wzorca automatycznie do każdego projektu. Sprawdź go w używanych przeglądarkach, na urządzeniach oraz w komponentach, które programowo ustawiają fokus przez element.focus().
4. Wybierz efekt, który nie gubi się na tle
Outline zwykle dobrze sprawdza się jako wskaźnik fokusu, bo nie zmienia wymiarów elementu w taki sposób jak dodatkowy border. Border może powodować przesunięcie układu, gdy jego grubość zmienia się po uzyskaniu fokusu. Box-shadow bywa dobry dla zaokrąglonych kart i przycisków, ale trzeba zweryfikować, czy cień nie znika na podobnym tle lub w ustawieniach wysokiego kontrastu.
Dobry wskaźnik często łączy więcej niż jeden sygnał: kontrastujący kontur, odsunięcie od elementu i subtelną zmianę tła. Więcej o samej ocenie barw znajdziesz w tekście Kontrast strony: jak testować i poprawiać zgodnie z WCAG.
Jak testować Focus Visible krok po kroku?
Najprostszy test rozpoczyna się od odłożenia myszy. Otwórz stronę w nowej karcie, odśwież ją i poruszaj się wyłącznie klawiaturą. Pełniejszą procedurę opisuje artykuł Nawigacja klawiaturą: jak testować stronę zgodnie z WCAG.
- Naciśnij Tab i sprawdź, czy pierwszy fokus jest widoczny oraz logiczny. Zwykle będzie to link „przejdź do treści” albo pierwszy element nagłówka.
- Przejdź przez nagłówek, menu, wyszukiwarkę, filtry, treść, stopkę oraz wszystkie widoczne przyciski.
- Użyj Shift+Tab. Upewnij się, że wskaźnik działa również podczas cofania.
- W menu, zakładkach, listach i suwakach sprawdź strzałki, Enter, spację i Escape, jeśli komponent przewiduje ich obsługę.
- Otwórz modal, wysuwany koszyk oraz baner cookies. Zweryfikuj, czy fokus jest widoczny, nie przechodzi pod tło modalu i wraca we właściwe miejsce po zamknięciu.
- Sprawdź formularze: pola, checkboxy, radio buttony, listy wyboru, błędy walidacji oraz przycisk wysłania.
- Przetestuj widoki mobilne, powiększenie strony i różne schematy kolorów, jeżeli interfejs je oferuje.
Focus Visible, kontrast i zasłonięty fokus
Przy formularzach sam fokus nie rozwiązuje całego problemu. Element musi mieć też poprawną etykietę, instrukcję oraz zrozumiały komunikat błędu. Zobacz poradnik Dostępny formularz: jak projektować i testować zgodnie z WCAG.
WCAGbot Accessibility Path: proces poprawy fokusu
Nazwa WCAGbot Accessibility Path porządkuje pracę nad widocznym fokusem w sytuacji, gdy zespół potrzebuje szybkiego pierwszego kroku, ale planuje również trwałe poprawki źródłowe.
- Wykryj: spisz elementy interaktywne i przejdź kluczowe ścieżki klawiszem Tab.
- Oceń: ustal, czy wskaźnik jest widoczny, ma odpowiedni kontrast i nie znika pod nakładkami.
- Popraw źródło: zmień style CSS, komponenty lub zarządzanie fokusem w JavaScript.
- Sprawdź interakcje: przetestuj menu, modal, formularz, koszyk, płatność oraz stany błędów.
- Utrzymaj: dodaj test do checklisty QA i wracaj do niego po zmianach motywu, biblioteki lub checkoutu.
WCAGbot można dodać jedną linią kodu jako funkcje wspierające dostępność, między innymi narzędzia kontrastu, typografii, skupienia i przewodnika do czytania. To może ułatwić użytkownikowi korzystanie ze strony już na etapie pierwszych działań. Nie zastępuje jednak poprawki CSS, gdy element aplikacji nie ma własnego widocznego wskaźnika, ani audytu zachowania niestandardowych komponentów. Granice tego podejścia opisujemy szerzej w artykule Widget WCAG: co pomaga, a czego nie naprawi.
CTA doświadczeniowe: dodaj funkcje wspierające dostępność i sprawdź na własnej stronie, jak odbierasz kontrast, większy tekst oraz funkcje skupienia. Następnie wykonaj niezależny test Tab w swoim menu, formularzu i koszyku.
Mini-scenariusz: sklep z niewidocznym fokusem w koszyku
Scenariusz ilustracyjny — nie opisuje wdrożenia u klienta. Sklep ma własny wysuwany koszyk. Projektant usunął outline dla wszystkich elementów, aby uniknąć domyślnego obramowania. Po dodaniu produktu użytkownik otwiera koszyk i naciska Tab. Fokus przechodzi po przycisku zamknięcia, zmianie liczby produktów, kodzie rabatowym i przycisku przejścia do płatności, ale żaden z tych elementów nie jest wizualnie oznaczony.
W pierwszym kroku zespół przywraca wyraźny styl :focus-visible dla przycisków i pól. W drugim sprawdza, czy po otwarciu koszyka fokus trafia do jego wnętrza, a po zamknięciu wraca do przycisku „Dodaj do koszyka”. W trzecim weryfikuje, czy sticky pasek promocyjny nie zasłania przycisku płatności. Efektem nie jest deklaracja pełnej zgodności całego sklepu, lecz usunięcie konkretnej bariery i utworzenie testu regresji dla tego komponentu.
Jakie błędy występują najczęściej?
- Globalne ukrywanie outline: CSS usuwa wskaźnik bez alternatywy.
- Fokus widoczny tylko na linkach: przyciski, checkboxy, selecty lub własne komponenty nie mają stylu.
- Za słaby kontrast: obrys jest obecny, lecz zlewa się z tłem albo krawędzią komponentu.
- Fokus pod sticky headerem: strona przewija element pod przyklejony nagłówek lub banner.
- Brak fokusu po zmianie widoku: po otwarciu modalu, filtrowaniu lub błędzie formularza użytkownik nie wie, gdzie się znalazł.
- Niestandardowy komponent bez zachowania klawiaturowego: element z rolą ARIA wygląda jak kontrolka, ale nie ma poprawnego fokusu ani obsługi klawiszy.
Własne komponenty wymagają szczególnej ostrożności. Przed dodaniem ARIA warto zapewnić semantyczny HTML, a następnie uzupełnić zachowanie zgodnie z potrzebą. Pomocne będą teksty HTML semantyczny: praktyczny poradnik wdrożenia oraz ARIA w praktyce: kiedy wspiera dostępność strony.
Przykładowa ścieżka klawiaturowa w e-commerce
Dlaczego nie wystarczy skaner automatyczny?
Automatyczne narzędzia są przydatne do wykrywania części problemów, ale nie potrafią wiarygodnie ocenić całego doświadczenia klawiaturowego: logicznej kolejności, widoczności wskaźnika na każdym tle, zachowania modalu czy zasłonięcia fokusu przez element sticky. Raport WebAIM Million 2025 obejmował 1 000 000 stron głównych, lecz sam WebAIM zaznacza, że brak wykrytych błędów automatycznych nie stanowi dowodu dostępności ani zgodności z WCAG.
Najlepszy proces łączy skan automatyczny, ręczny test klawiaturą, test komponentów dynamicznych oraz audyt odpowiedni do ryzyka i zakresu serwisu. Jeżeli potrzebujesz ustalić kolejność działań, zobacz Audyt WCAG i wdrożenie: praktyczny plan krok po kroku.
Podsumowanie dla zarządzającego i sprzedaży
Dla zarządzającego widoczny fokus jest konkretnym kryterium jakości interfejsu: można go zobaczyć i przetestować na realnej ścieżce użytkownika. Warto wpisać go do definicji gotowości komponentu oraz checklisty przed publikacją zmian w sklepie, formularzu lub panelu klienta.
Dla zespołu sprzedaży i obsługi klienta ważne jest uczciwe rozróżnienie: WCAGbot wspiera dostępność przez funkcje dostępne użytkownikowi bez przebudowy serwisu, ale widoczny fokus w autorskich elementach wymaga naprawy źródłowej. Taka rozmowa pomaga zaplanować pierwszy krok i dalszy audyt zamiast obiecywać pełną zgodność samą instalacją widgetu.
Dodaj funkcje dostępności swojej strony i potraktuj je jako wsparcie użytkowników równolegle z planem testów oraz trwałych poprawek w kodzie i treści.
FAQ: Focus Visible 2.4.7
Czy WCAG 2.4.7 Focus Visible jest wymaganiem na poziomie AA?
Tak. Kryterium 2.4.7 Focus Visible ma poziom AA w WCAG. Wymaga widocznego wskaźnika fokusu dla interfejsu obsługiwanego z klawiatury.
Czy domyślny outline przeglądarki wystarcza?
Może wystarczyć, jeżeli pozostaje widoczny w używanym interfejsie i nie jest zasłonięty. Nie ma obowiązku zastępowania go własnym stylem tylko dlatego, że nie odpowiada wizualnie projektowi.
Czy mogę użyć tylko :focus-visible?
To dobre rozwiązanie dla nowoczesnych przeglądarek, ale wdrożenie trzeba sprawdzić w środowiskach wspieranych przez serwis. W praktyce warto zaplanować też bezpieczny styl bazowy dla :focus i przetestować jego zachowanie.
Czy focus i hover mogą wyglądać tak samo?
Mogą, o ile wskaźnik fokusu nadal jest jednoznacznie widoczny podczas obsługi klawiaturą. Nie należy jednak polegać wyłącznie na hoverze, bo użytkownik klawiatury nie musi korzystać z myszy.
Czy niebieski obrys jest wymagany przez WCAG?
Nie. WCAG nie wymaga konkretnego koloru ani jednego wzoru wskaźnika. Wskaźnik ma być widoczny i odróżnialny w kontekście danego komponentu oraz jego tła.
Czy box-shadow jest lepszy od outline?
Nie zawsze. Outline zwykle nie wpływa na układ elementu, a box-shadow może dobrze działać w niektórych projektach. Każde rozwiązanie należy ocenić pod kątem widoczności, kontrastu i działania w używanych konfiguracjach.
Czy focus visible dotyczy modali i wysuwanych koszyków?
Tak. Po otwarciu modalu lub koszyka trzeba sprawdzić zarówno widoczność wskaźnika, jak i poprawne przeniesienie fokusu, jego utrzymanie w aktywnym dialogu oraz powrót po zamknięciu.
Czy baner cookies może zasłaniać fokus?
To ryzykowne, szczególnie w kontekście WCAG 2.2 i kryterium 2.4.11 Focus Not Obscured. Element z fokusem nie powinien być całkowicie ukryty przez treść dodaną przez autora strony.
Czy test Tab wystarczy do sprawdzenia fokusu?
Nie. Tab i Shift+Tab są podstawą, ale w zależności od komponentu trzeba testować także Enter, spację, Escape i strzałki. Dotyczy to między innymi menu, zakładek, comboboxów oraz list wyboru.
Czy widget WCAG naprawi brak focus visible w kodzie strony?
Nie należy zakładać, że widget naprawi każdy autorski komponent i wszystkie jego style. WCAGbot oferuje funkcje wspierające dostępność, ale brak widocznego fokusu w źródłowym CSS lub JavaScript wymaga diagnozy i trwałej poprawy w serwisie.
