Najważniejsze wnioski
- WCAG 2.4.13 Focus Appearance jest kryterium sukcesu poziomu AAA w WCAG 2.2. Ocena dotyczy jakości widocznego wskaźnika fokusu, a nie samego faktu jego występowania.
- Najprostszy wzorzec techniczny to ciągły wskaźnik o grubości co najmniej 2 CSS px wokół komponentu, z kontrastową zmianą stanu co najmniej 3:1.
- Test trzeba wykonać na rzeczywistych ścieżkach użytkownika: menu, wyszukiwarce, filtrach, formularzu, koszyku, płatności, modalu i elementach osadzonych.
- Kryteria 2.4.7 Focus Visible, 1.4.11 Non-text Contrast oraz 2.4.11 i 2.4.12 Focus Not Obscured badają inne aspekty pracy z fokusem.
- Widget dostępności może wspierać użytkownika dodatkowymi funkcjami skupienia i czytania, ale nie zastępuje naprawy źródłowych stylów fokusu, audytu ani testów klawiaturą.
Dla zarządzającego
Wyraźny fokus ogranicza ryzyko porzucenia procesu zakupowego przez osoby korzystające z klawiatury i porządkuje jakość interfejsu. Wdrożenie warto wpisać w backlog dostępności razem z testami formularzy, koszyka i płatności.
Dla sprzedaży
Jeżeli klient pyta o dostępność sklepu, pokaż fokus na realnej ścieżce zakupu. To prosty, widoczny dowód jakości UX, ale komunikuj uczciwie: funkcje WCAGbot wspierają dostępność i nie zastępują poprawek w kodzie źródłowym.
WCAG 2.4.13 Focus Appearance wymaga, aby użytkownik korzystający z klawiatury nie musiał zgadywać, który element strony jest aktywny. Sam widoczny fokus nie wystarcza: wskaźnik powinien mieć odpowiednią powierzchnię oraz wyraźnie zmieniać wygląd względem stanu bez fokusu. W praktyce oznacza to konieczność przetestowania przycisków, linków, pól formularzy, filtrów, koszyka i modali — nie tylko strony głównej.
Ten artykuł ma charakter informacyjny. Omawia WCAG 2.2 i praktykę projektową; nie zastępuje audytu konkretnego serwisu ani indywidualnej analizy obowiązków prawnych. Stan źródeł technicznych: [DO WERYFIKACJI: data publikacji].
Najważniejsze wnioski
- 2.4.13 Focus Appearance jest kryterium poziomu AAA w WCAG 2.2.
- Najłatwiejszy do utrzymania wzorzec to ciągły obrys lub pierścień odpowiadający obwodowi o grubości 2 CSS px.
- Zmiana pomiędzy stanem bez fokusu a stanem z fokusem powinna osiągać kontrast co najmniej 3:1.
- Nie wystarczy test jednego przycisku. Fokus musi działać na wszystkich ważnych komponentach i podczas całej ścieżki zadaniowej.
- Funkcje skupienia w widżecie mogą ułatwiać korzystanie ze strony, lecz trwałe problemy ze stylami komponentów wymagają poprawy w kodzie.
Czym jest WCAG 2.4.13 Focus Appearance?
Focus Appearance to kryterium sukcesu WCAG 2.2 dotyczące jakości wizualnego wskaźnika fokusu. Fokus to stan aktywnego elementu interfejsu — na przykład linku, przycisku, pola tekstowego, checkboxa lub pozycji menu — gdy użytkownik porusza się po stronie klawiszem Tab, Shift+Tab albo klawiaturą ekranową.
W3C opisuje dwa podstawowe warunki. Widoczny wskaźnik musi mieć powierzchnię co najmniej równą obwodowi o grubości 2 CSS px wokół komponentu w stanie nieaktywnym. Ponadto zmiana wyglądu pomiędzy tymi samymi pikselami przed i po otrzymaniu fokusu musi osiągać kontrast co najmniej 3:1.
Dobry fokus nie jest dekoracją interfejsu. Jest bieżącą informacją nawigacyjną: mówi użytkownikowi, gdzie znajduje się teraz i co uruchomi kolejnym działaniem.
Nie należy utożsamiać tego wymagania z popularnym pytaniem: „czy po Tab coś się pokazuje?”. To domena WCAG 2.4.7 Focus Visible. Kryterium 2.4.13 idzie dalej i pyta, czy wskaźnik jest dostatecznie wyraźny pod względem rozmiaru oraz kontrastu.
Co dokładnie trzeba ocenić?
| Obszar oceny | Pytanie kontrolne | Powiązane kryterium | Praktyczna wskazówka |
|---|---|---|---|
| Obecność fokusu | Czy aktywny element da się rozpoznać? | 2.4.7 Focus Visible | Przejdź całą stronę klawiszem Tab. |
| Powierzchnia wskaźnika | Czy obszar widocznej zmiany odpowiada obwodowi 2 CSS px? | 2.4.13 Focus Appearance | Najbezpieczniejszy jest ciągły ring wokół komponentu. |
| Zmiana stanu | Czy te same piksele wyraźnie zmieniają wygląd? | 2.4.13 Focus Appearance | Porównuj stan przed i po fokusu, nie tylko kolor z tłem. |
| Kontrast z otoczeniem | Czy wskaźnik odróżnia się od sąsiadujących kolorów? | 1.4.11 Non-text Contrast | Sprawdź jasne, ciemne i fotograficzne tła. |
| Zasłonięcie elementu | Czy sticky header, baner lub modal nie przykrywa fokusu? | 2.4.11 i 2.4.12 | Testuj po przewinięciu i w otwartych nakładkach. |
Wskaźnik nie musi być dosłownym border. Może być obrysem, cieniem, zmianą tła lub innym efektem wizualnym. Ważny jest rezultat możliwy do oceny: odpowiednia powierzchnia oraz kontrastowa zmiana stanu. Przy poświatach, gradientach i półprzezroczystościach łatwo błędnie uznać efekt za wystarczający. Do wymaganej powierzchni można zaliczyć tylko tę część wskaźnika, która faktycznie osiąga wymagany kontrast.
Jak wdrożyć wyraźny fokus w CSS?
Wybierz wzorzec, który skaluje się z komponentem
W e-commerce komponenty mają różne rozmiary: mała ikona ulubionych, link w menu, szeroki przycisk „Do koszyka”, filtr z checkboxem oraz pole wyszukiwarki. Dwa krótkie znaczniki przy krawędzi mogą wyglądać dobrze na małej ikonie, ale nie zapewnią wystarczającej powierzchni przy szerokim przycisku. Dlatego zwykle najlepiej sprawdza się obrys otaczający cały element.
WCAGbot Accessibility Path dla widocznego fokusu
:focus-visible {
outline: 2px solid #005fcc;
outline-offset: 2px;
}To punkt wyjścia, a nie automatyczna gwarancja spełnienia wszystkich powiązanych wymagań. Kolor trzeba sprawdzić wobec faktycznego tła i wobec wyglądu elementu przed otrzymaniem fokusu. Jeżeli komponent ma już niebieskie obramowanie, samo dodanie podobnego odcienia nie zapewni dostatecznej zmiany wizualnej.
Stosuj dwa kolory na trudnych tłach
Przy zdjęciach, gradientach, kartach promocyjnych i nakładających się elementach pojedynczy kolor może zlewać się z częścią tła. Rozwiązaniem bywa dwukolorowy wskaźnik: jasna warstwa blisko komponentu oraz kontrastowy ring zewnętrzny.
:focus-visible {
outline: 2px solid #ffffff;
outline-offset: 2px;
box-shadow: 0 0 0 4px #005fcc;
}Ten kod wymaga testu wizualnego w kontekście projektu. Nie zakładaj, że każdy box-shadow spełnia kryterium: rozmyta poświata może nie dawać dostatecznie ostrej, kontrastowej powierzchni.
Nie usuwaj fokusu bez pełnowartościowego zamiennika
Reguła outline: none lub outline: 0 bez alternatywy usuwa podstawową wskazówkę dla osób korzystających z klawiatury. Jeśli design rozróżnia interakcję myszą i klawiaturą, można korzystać z :focus-visible, ale trzeba zachować widoczny wskaźnik w scenariuszach klawiaturowych.
Komponenty budowane samodzielnie — niestandardowe selecty, zakładki, karuzele, menu rozwijane oraz kontrolki filtrów — wymagają szczególnej uwagi. Warto połączyć pracę nad stylem fokusu z zasadami opisanymi w artykułach o semantycznym HTML i ARIA. ARIA nie naprawi niewidocznego fokusu, a element z rolą przycisku musi być równie dobrze obsługiwalny jak natywny przycisk.
WCAGbot Accessibility Path: proces wdrożenia i kontroli
Nazwany schemat WCAGbot Accessibility Path porządkuje pracę nad fokusem tak, aby nie skończyła się na pojedynczej poprawce CSS.
- Zidentyfikuj elementy interaktywne. Zbierz linki, przyciski, pola, checkboxy, radio buttony, menu, akordeony, filtry, kontrolki sliderów i elementy otwierające modale.
- Wyznacz ścieżki krytyczne. W sklepie będą to zwykle wyszukanie produktu, filtracja, karta produktu, wariant, koszyk, logowanie, adres dostawy i płatność.
- Przejdź ścieżkę bez myszy. Użyj Tab, Shift+Tab, Enter, spacji oraz strzałek tam, gdzie stosuje je komponent. Zobacz, czy kolejność jest logiczna, a fokus nie znika.
- Oceń wygląd. Sprawdź powierzchnię wskaźnika, zmianę kontrastu i kontrast z tłem. Testuj także po powiększeniu oraz na widokach mobilnych.
- Napraw u źródła. Wprowadź wspólny token lub klasę stylu w systemie komponentów zamiast poprawiać pojedyncze ekrany.
- Zweryfikuj regresję. Po zmianie motywu, biblioteki, checkoutu lub banera cookie ponownie przejdź istotne ścieżki.
- Uzupełnij wsparcie użytkownika. WCAGbot może dodać funkcje wspierające dostępność, takie jak większy kursor, skupienie, przewodnik do czytania, kontrast czy powiększenie tekstu. Traktuj je jako pomoc dla użytkownika i pierwszy krok, nie jako zastępstwo naprawy kodu.
Jak testować Focus Appearance w sklepie lub serwisie?
Automatyczne narzędzia mogą wskazać część problemów, ale nie ocenią wiarygodnie wszystkich cech wizualnych fokusu ani jego zachowania w złożonych komponentach. Potrzebny jest test manualny.
Checklista testu klawiaturą
- Odśwież stronę i naciśnij Tab, nie używając wcześniej myszy.
- Sprawdź, czy pierwszy fokus nie zaczyna się na ukrytym elemencie lub w treści zasłoniętej banerem.
- Przejdź przez nagłówek, menu, wyszukiwarkę, filtry, karty produktów i stopkę.
- Otwórz modal, menu oraz panel filtrów. Zweryfikuj, czy fokus pozostaje w odpowiednim kontekście i nie ginie pod nakładką.
- Wypełnij formularz błędnymi danymi. Ustal, czy fokus po błędzie jest widoczny oraz czy komunikat jest zrozumiały. Więcej wskazówek zawiera poradnik dostępnego formularza.
- Dodaj produkt do koszyka i przejdź do checkoutu. Testuj także walidację pól adresowych, wybór dostawy i płatności.
- Sprawdź widoki o zmiennym tle, hoverze i stanie disabled.
- Powtórz test po zwiększeniu tekstu oraz na szerokim i wąskim widoku.
Focus Visible a Focus Appearance
Szerszą metodę przejścia strony opisuje artykuł Nawigacja klawiaturą: jak testować stronę zgodnie z WCAG. Jeżeli weryfikujesz doświadczenie z technologią asystującą, przydatny będzie również praktyczny materiał o testowaniu dostępności w NVDA.
Mini-scenariusz: filtr produktów z ledwo widocznym fokusem
Scenariusz ilustracyjny, nie opis realnego wdrożenia klienta: sklep ma filtr rozmiaru z własnymi checkboxami. W stanie zwykłym każdy checkbox ma cienką szarą ramkę. Po przejściu klawiszem Tab ramka robi się nieznacznie ciemniejsza. Użytkownik na ekranie z wieloma filtrami nie wie, który rozmiar jest aktualnie aktywny.
Zespół nie powinien poprzestać na dodaniu ciemniejszego odcienia. Najpierw sprawdza, czy zmiana pomiędzy stanem bez fokusu i stanem z fokusem osiąga 3:1. Następnie zastępuje subtelną zmianę ciągłym ringiem otaczającym kontrolkę, który skaluje się z jej wymiarami. Test obejmuje wariant zaznaczony, niezaznaczony, disabled, panel mobilny i sytuację po przewinięciu. Na końcu zespół przechodzi pełną drogę: filtr, karta produktu, dodanie do koszyka i checkout.
To podejście pomaga uniknąć lokalnej poprawki, która działa wyłącznie na jednym widoku. W sklepach opartych na gotowych motywach należy podobnie przetestować aktualizacje motywu, aplikacje filtrujące i zewnętrzne moduły płatności. Praktyczne plany dla konkretnych platform znajdziesz w tekstach o dostępności WordPress oraz dostępności Shopify.
Jakie błędy pojawiają się najczęściej?
Cienka ramka 1 px
Jednopikselowy outline może być zauważalny, lecz zwykle nie daje powierzchni odpowiadającej obwodowi o grubości 2 CSS px. Nie oceniaj go wyłącznie „na oko”. Wybierz wskaźnik, którego powierzchnia jest łatwa do uzasadnienia i utrzymania w komponentach.
Kontrast liczony wyłącznie wobec tła strony
Dla 2.4.13 istotna jest zmiana tych samych pikseli pomiędzy stanem bez fokusu i stanem fokusu. Równolegle trzeba ocenić kontrast wskaźnika z sąsiadującymi kolorami dla 1.4.11. To dwa odrębne sprawdzenia. Zasady pomiarów omawia poradnik Kontrast strony: jak testować i poprawiać.
Fokus zasłonięty przez sticky header lub baner
Wskaźnik może być dobrze zaprojektowany, a mimo to niewidoczny, gdy po zmianie fokusu przeglądarka przewinie element pod stały nagłówek albo otwarte okno cookie. Testuj długie formularze, rozwijane panele i elementy przy dolnej krawędzi ekranu.
Inny styl w każdym module
Gdy motyw, biblioteka komponentów i aplikacja zewnętrzna mają osobne style, część elementów może mieć mocny fokus, a część niemal niewidoczny. Rozwiązaniem jest wspólny wzorzec projektowy oraz test regresji po zmianach.
Widget dostępności a naprawa fokusu w kodzie
WCAGbot pomaga dodać bez kodowania funkcje wspierające dostępność, między innymi narzędzia skupienia i nawigacji, większy kursor, przewodnik do czytania, tryby kontrastu oraz ustawienia typografii. Może to ułatwić użytkownikowi korzystanie z bieżącej strony i stanowić rozsądny pierwszy krok.
Dwukolorowy wskaźnik fokusu na zmiennym tle
Nie należy jednak przedstawiać widgetu jako rozwiązania wszystkich problemów z kryterium 2.4.13. Jeśli kontrolka ma niewłaściwy, zasłonięty lub niespójny fokus w kodzie źródłowym, trwała naprawa powinna objąć CSS, strukturę komponentu i jego zachowanie. Pełną granicę między pomocą widgetu a pracą źródłową wyjaśnia artykuł Widget WCAG: co pomaga, a czego nie naprawi.
Podsumowanie dla zarządzającego i sprzedaży
Focus Appearance jest konkretnym elementem jakości interfejsu, który można szybko zobaczyć, ale należy poprawiać systemowo. Priorytetem są ścieżki przynoszące wartość biznesową i obsługowe: wyszukiwanie, kontakt, logowanie, formularze, koszyk i płatność. Dla zespołu sprzedaży dobrym punktem rozmowy nie jest obietnica zgodności „jednym narzędziem”, lecz pokaz działania strony klawiszem Tab i plan naprawy wykrytych barier.
Jeśli dopiero zaczynasz porządkowanie dostępności cyfrowej, połącz test fokusu z szerszym planem opisanym w artykule Audyt WCAG i wdrożenie: praktyczny plan krok po kroku. Dzięki temu poprawka nie pozostanie pojedynczą zmianą wizualną, lecz wejdzie do procesu tworzenia i odbioru komponentów.
Chcesz sprawdzić stronę w praktyce? Przejdź po najważniejszej ścieżce klawiszem Tab, otwórz panel WCAGbot i zobacz, jak funkcje kontrastu, powiększenia tekstu oraz skupienia wspierają użytkownika. Następnie zaplanuj audyt i naprawę problemów wykrytych w kodzie oraz treści.
FAQ: WCAG 2.4.13 Focus Appearance
Czy WCAG 2.4.13 Focus Appearance jest wymaganiem poziomu AA?
Nie. W WCAG 2.2 kryterium 2.4.13 ma poziom AAA. Nie należy jednak traktować go jako nieistotnego w projektach celujących w poziom AA: wyraźny fokus wspiera użyteczność, a osobne kryterium 2.4.7 Focus Visible ma poziom AA.
Czy outline 2 px zawsze wystarczy?
To prosty i często bezpieczny punkt wyjścia dla wymogu powierzchni, ale nie zawsze wystarczy w całym kontekście. Trzeba jeszcze sprawdzić kontrast zmiany stanu, kontrast wobec otoczenia oraz to, czy wskaźnik nie jest zasłonięty.
Czy mogę użyć box-shadow zamiast outline?
Tak, kryterium nie narzuca konkretnej właściwości CSS. Cień musi jednak tworzyć wystarczająco duży i kontrastowy obszar. Rozmyta, delikatna poświata może nie być łatwa do obrony podczas oceny.
Jaka jest różnica między 2.4.7 a 2.4.13?
WCAG 2.4.7 odpowiada na pytanie, czy użytkownik może zobaczyć fokus. WCAG 2.4.13 ocenia, czy wskaźnik ma odpowiednią powierzchnię i wystarczającą zmianę kontrastu.
Czy fokus musi być widoczny po kliknięciu myszą?
WCAG 2.4.7 wymaga trybu działania, w którym fokus jest widoczny dla interfejsu obsługiwanego klawiaturą. W praktyce można stosować :focus-visible, aby pokazywać wskaźnik przede wszystkim podczas nawigacji klawiaturą, pod warunkiem że nie ukrywa to potrzebnego fokusu.
Czy domyślny fokus przeglądarki zwalnia z testów?
Nie zawsze. Wyjątki dotyczą sytuacji, w których wskaźnik jest określony przez przeglądarkę i autor nie ma możliwości jego zmiany albo nie zmienił ani wskaźnika, ani jego bezpośredniego tła. Po zmianie tła, motywu lub stylów komponentu należy przeprowadzić własną ocenę.
Czy stan hover może zastąpić fokus?
Nie. Hover zależy od wskaźnika myszy, a użytkownik klawiatury może go nie widzieć. Stan focus musi mieć własną, rozpoznawalną informację wizualną.
Jak testować fokus w formularzu?
Przejdź wszystkie pola klawiszem Tab, wprowadź celowo błędne dane, wyślij formularz i sprawdź, gdzie trafia fokus. Oceń widoczność pola, komunikatu błędu i ewentualnego podsumowania błędów.
Czy WCAGbot naprawia problem niewidocznego fokusu w kodzie strony?
WCAGbot udostępnia funkcje wspierające dostępność, w tym narzędzia skupienia i nawigacji, lecz nie zastępuje audytu ani trwałej naprawy stylów i komponentów w kodzie źródłowym. Problem należy zidentyfikować na stronie i poprawić w jej implementacji.
Źródła i materiały
- W3C, Understanding Success Criterion 2.4.13: Focus Appearance
- W3C, Understanding Success Criterion 2.4.7: Focus Visible
- W3C, Understanding Success Criterion 1.4.11: Non-text Contrast
- www.w3.org
- www.w3.org
- webaim.org
- webaim.org
- www.w3.org
- www.w3.org
- design.homeoffice.gov.uk
- clairesontra.com
- digitalaccessibility.nyu.edu
