WCAG 2.4.7: Widoczny fokus

Co oznacza ta zasada

WCAG 2.4.7 Focus Visible wymaga, aby każdy interaktywny element na stronie internetowej — linki, przyciski, pola formularzy, niestandardowe widżety i każdy inny komponent obsługiwany z klawiatury — wyświetlał widoczny wskaźnik fokusu, gdy otrzyma fokus klawiatury. Mówiąc prościej: gdy użytkownik naciska klawisz Tab, aby poruszać się po stronie, musi dokładnie widzieć, który element jest aktualnie aktywny.

Kryterium nie narzuca konkretnego stylu wizualnego wskaźnika fokusu. Wymaga jedynie, aby nastąpiła jakaś widoczna zmiana. Niemniej jednak ledwo dostrzegalny wskaźnik — na przykład jednopiixelowa kropkowana obwódka zlewająca się z tłem — może technicznie spełniać 2.4.7, ale wciąż nie spełniać bardziej wymagającego WCAG 2.4.11 (Focus Appearance) wprowadzonego w WCAG 2.2. W ramach samego 2.4.7 wystarczająca jest każda dostrzegalna zmiana wizualna.

Co uznaje się za spełnienie wymogu: Wskaźnik fokusu spełnia kryterium, jeśli widzący użytkownik, przechodząc po stronie klawiszem Tab, może zidentyfikować, który element ma fokus, bez polegania na komunikatach czytnika ekranu ani innych niewizualnych wskazówkach. Typowe akceptowalne implementacje obejmują domyślne obwódki przeglądarki, niestandardowe reguły CSS outline lub box-shadow, zmianę podkreślenia lub koloru tła zastosowaną przy :focus lub :focus-visible.

Co uznaje się za niespełnienie wymogu: Do naruszenia dochodzi, gdy deweloper usuwa domyślny pierścień fokusu przeglądarki — zazwyczaj za pomocą outline: none lub outline: 0 w CSS — i nie zastępuje go równoważnym niestandardowym wskaźnikiem. Naruszenia występują także wtedy, gdy komponent niestandardowy (zbudowany z elementów <div> lub <span>) jest uczyniony dostępnym z klawiatury za pomocą tabindex, ale nie otrzymuje żadnej widocznej zmiany stylu przy fokusie.

Oficjalne wyjątki: WCAG zaznacza, że kryterium dotyczy wyłącznie interfejsów obsługiwanych z klawiatury. Komponenty, które są czysto dekoracyjne lub celowo wyłączone z kolejności tabulacji (za pomocą tabindex='-1'), nie muszą wyświetlać wskaźnika fokusu, ponieważ nie mogą otrzymać fokusu w normalnej nawigacji klawiaturą.

Dlaczego to ma znaczenie

Widoczność fokusu jest podstawą dostępności z klawiatury, a dostępność z klawiatury jest bramą do dostępu dla szerokiego zakresu grup osób z niepełnosprawnościami. Około 26% dorosłych w Stanach Zjednoczonych żyje z jakąś formą niepełnosprawności według CDC i wiele z tych osób polega na klawiaturach lub technologiach asystujących emulujących klawiaturę, a nie na urządzeniach wskazujących.

Użytkownicy z niepełnosprawnością ruchową — w tym osoby z takimi schorzeniami jak ALS, porażenie mózgowe, urazy wynikające z powtarzalnego przeciążenia czy choroba Parkinsona — często polegają na klawiaturach, urządzeniach przełącznikowych, kontrolerach typu sip-and-puff lub oprogramowaniu śledzącym ruch gałek ocznych. Wszystkie te metody wprowadzania danych opierają się na modelu fokusu klawiatury przeglądarki. Jeśli wskaźnik fokusu jest niewidoczny, użytkownicy ci nie mogą określić, gdzie znajdują się na stronie, nie mogą aktywować właściwego kontrolki i mogą być całkowicie pozbawieni możliwości wykonania krytycznych zadań, takich jak wysłanie formularza, dokończenie zakupu czy nawigacja po menu.

Użytkownicy słabowidzący, którzy nie korzystają z czytnika ekranu, ale powiększają ekran, również polegają na widocznym fokusie. Gdy powiększają fragment strony, widoczny pierścień fokusu informuje ich, który element jest aktywny i prowadzi ich interakcję.

Osoby z niepełnosprawnościami poznawczymi i związanymi z uwagą również odnoszą korzyści z wyraźnych wskaźników fokusu. Użytkownicy z ADHD lub trudnościami z pamięcią często tracą orientację na złożonej stronie; wyraźny wskaźnik fokusu zapewnia im niezawodny wizualny punkt odniesienia.

Konkretny scenariusz z życia: wyobraźmy sobie osobę ze stwardnieniem rozsianym, która przegląda stronę e-commerce, używając wyłącznie klawiatury, ponieważ precyzyjne operowanie myszą stało się trudne. Przechodzi klawiszem Tab przez stronę produktu, aby dotrzeć do przycisku „Add to Cart”. Jeśli deweloper ukrył pierścień fokusu, użytkownik nie widzi żadnej informacji o tym, gdzie znajduje się fokus. Naciska Enter i albo nic się nie dzieje (fokus trafił na element nieinteraktywny), albo wywoływana jest niewłaściwa akcja. Skutkiem jest frustracja, porzucenie zadania i utracony przychód dla firmy — wszystko to możliwe do uniknięcia za pomocą jednej reguły CSS.

Poza niepełnosprawnością wskaźniki fokusu przynoszą korzyści wszystkim użytkownikom w sytuacjach, gdy korzystanie z myszy jest niewygodne: zaawansowanym użytkownikom nawigującym skrótami klawiaturowymi, użytkownikom laptopów bez zewnętrznej myszy oraz osobom wypełniającym długie formularze. Widoczny fokus pośrednio poprawia też SEO, zachęcając do stosowania semantycznego HTML i prawidłowej kolejności tabulacji, co jest premiowane przez roboty wyszukiwarek.

Powiązane reguły Axe-core

WCAG 2.4.7 wymaga testów manualnych, ponieważ narzędzia automatyczne nie są w stanie wiarygodnie określić, czy wskaźnik fokusu jest widoczny. Axe-core i podobne silniki mogą wykryć, że istnieje reguła CSS taka jak outline: none, ale nie są w stanie ocenić renderowanego efektu wizualnego we wszystkich motywach, trybach wysokiego kontrastu i silnikach renderujących przeglądarek. Poniżej wyjaśniono krajobraz testowania:

• Wymagane testy manualne — ukrywanie focus-visible: Axe-core nie dostarcza dedykowanej reguły, która jednoznacznie oznaczałaby naruszenia 2.4.7, ponieważ wymagałoby to renderowania strony, przechodzenia klawiszem Tab przez każdy element i wykonywania analizy kontrastu na poziomie pikseli dla wskaźnika fokusu — zadania wykraczającego poza analizę statyczną lub na poziomie DOM. Zamiast tego testerzy muszą ręcznie przechodzić klawiszem Tab po stronie i wizualnie potwierdzać, że każdy interaktywny element pokazuje zmianę fokusu.
• Częściowy sygnał z css-orientation-lock i kontroli stylów: Niektóre konfiguracje axe-core oznaczają obecność outline: 0 lub outline: none w arkuszach stylów jako ostrzeżenie dotyczące dobrych praktyk, ale jest to heurystyka, a nie definityczna kontrola naruszenia, ponieważ reguła może być nadpisana przez prawidłowy niestandardowy styl fokusu w innym miejscu kaskady.
• Dlaczego automatyzacja jest niewystarczająca: Wskaźnik fokusu może być ukryty tylko w określonych stanach (np. gdy otwarte jest okno modalne), tylko dla określonych typów elementów lub tylko w określonych motywach kolorystycznych. Takie warunkowe naruszenia wymagają, aby tester człowiek nawigował po każdym interaktywnym elemencie w rzeczywistym renderowanym środowisku i potwierdził widoczność. Narzędzia takie jak axe DevTools Pro mogą pomóc, podświetlając elementy, do których zastosowano outline: none, ale ostateczna decyzja o spełnieniu lub niespełnieniu wymogu musi należeć do człowieka.

Jak testować

1. Automatyczny skan wstępny: Uruchom axe DevTools (rozszerzenie przeglądarki lub CLI) albo Google Lighthouse na stronie. Wyszukaj ostrzeżenia dotyczące dobrych praktyk lub eksperymentalne związane ze stylami fokusu. Choć nie potwierdzają one jednoznacznie naruszenia 2.4.7, wskazują elementy warte sprawdzenia. W Lighthouse sprawdź kategorię „Accessibility” pod kątem ustaleń związanych z fokusem. Wyeksportuj raport i zanotuj wszystkie oznaczone elementy interaktywne.
2. Ręczny test tabulacji klawiaturą: Odłącz lub odsuń mysz. Naciskaj wielokrotnie Tab od góry strony i nawiguj przez każdy interaktywny element — linki, przyciski, pola, listy rozwijane, okna modalne, zakładki, akordeony i selektory dat. Na każdym zatrzymaniu potwierdź, że element z fokusem jest wizualnie odróżnialny od sąsiadujących elementów bez fokusu. Zanotuj każdy element, dla którego pojawienie się fokusu nie powoduje żadnej widocznej zmiany.
3. Test odwrotnej tabulacji: Użyj Shift+Tab, aby nawigować wstecz po stronie i powtórz kontrolę wizualną. Niektóre implementacje psują widoczność fokusu tylko w jednym kierunku z powodu problemów ze specyficznością CSS.
4. Test NVDA + Firefox: Otwórz Firefox z uruchomionym NVDA. Użyj trybu Browse (klawisze strzałek), a następnie przełącz się na Forms Mode (Enter), aby wchodzić w interakcje z kontrolkami formularzy. Potwierdź, że każdy element, który NVDA ogłasza jako mający fokus, ma również widoczny wskaźnik na ekranie — przydatne do wychwytywania rozbieżności między fokusem AT a fokusem przeglądarki.
5. Test VoiceOver + Safari (macOS/iOS): Włącz VoiceOver i używaj Tab lub VO+Strzałka w prawo, aby przechodzić przez elementy interaktywne. Wizualnie zweryfikuj, że pierścień fokusu na ekranie odpowiada temu, co ogłasza VoiceOver.
6. Test JAWS + Chrome: Użyj JAWS w trybie wirtualnego kursora, a następnie w trybie aplikacji. Przechodź klawiszem Tab przez kontrolki interaktywne i potwierdź, że widoczny wskaźnik fokusu pojawia się na każdym elemencie z fokusem.
7. Test trybu wysokiego kontrastu: Włącz Windows High Contrast Mode (lub macOS Increase Contrast) i powtórz test z Tab. Niektóre wskaźniki fokusu opierają się na kolorach, które znikają w motywach wysokiego kontrastu; wskaźnik musi pozostać widoczny w tych trybach.
8. Inspekcja CSS: Otwórz DevTools przeglądarki, wybierz element interaktywny, ustaw na nim fokus, naciskając Tab, aż będzie aktywny, i sprawdź obliczone style. Zweryfikuj, że żadna reguła nie ustawia outline: none ani outline: 0 bez kompensującego stylu fokusu. Sprawdź też :focus-visible vs :focus, aby upewnić się, że fokus wywołany klawiaturą jest objęty.

Jak naprawić

Globalne usuwanie outline bez zastąpienia — nieprawidłowe

<!-- CSS resets that remove all focus indicators globally -->
<style>
  * {
    outline: none; /* Removes focus ring from every element */
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>

Globalne usuwanie outline bez zastąpienia — prawidłowe

<!-- Remove the global outline: none reset.
     Provide a custom focus style that is visually clear. -->
<style>
  /* Respect users who prefer reduced motion */
  :focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>
<!-- Now both elements show a high-contrast blue outline when focused via keyboard -->

Niestandardowy przycisk oparty na div bez stylu fokusu — nieprawidłowe

<!-- A div styled as a button, made focusable, but missing :focus CSS -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  /* No :focus or :focus-visible rule defined */
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>

Niestandardowy przycisk oparty na div bez stylu fokusu — prawidłowe

<!-- Add :focus-visible to the custom component so keyboard
     users see a clear indicator when this element is focused -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  .fake-btn:focus-visible {
    outline: 3px solid #ffcc00;
    outline-offset: 3px;
  }
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>
<!-- The yellow outline appears only on keyboard focus, not on mouse click -->

Pierścień fokusu ukryty wewnątrz nakładki modalnej — nieprawidłowe

<!-- Modal applies overflow:hidden and a stacking context that clips
     the default outline, making it invisible -->
<style>
  .modal-body {
    overflow: hidden; /* Clips outlines that extend beyond the element */
    border-radius: 8px;
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Pierścień fokusu ukryty wewnątrz nakładki modalnej — prawidłowe

<!-- Use box-shadow instead of outline so it renders
     inside the stacking context and is never clipped -->
<style>
  .modal-body {
    overflow: hidden;
    border-radius: 8px;
  }
  .modal-body button:focus-visible {
    /* box-shadow is not clipped by overflow:hidden --
       it stays within the element's own box -->
    box-shadow: 0 0 0 3px #005fcc;
    outline: none; /* Remove default to avoid double ring */
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Typowe błędy

• Dodanie outline: none do bazowego resetu CSS bez przeanalizowania, które elementy to obejmuje. Wiele popularnych resetów (np. starsze wersje normalize.css lub narzędzia Bootstrap) globalnie ukrywa pierścienie fokusu. Zawsze uzupełniaj to wyraźną regułą :focus-visible, która przywraca widoczność dla użytkowników klawiatury.
• Poleganie wyłącznie na :focus, gdy :focus-visible byłoby bardziej odpowiednie — lub odwrotnie. Użycie tylko :focus powoduje zastosowanie wskaźnika także przy kliknięciach myszą, co może wyglądać dziwnie. Użycie tylko :focus-visible bez zapasowego :focus może pozostawić starsze przeglądarki bez jakiegokolwiek wskaźnika. Testuj we wszystkich docelowych przeglądarkach.
• Zastosowanie outline: none w nadpisaniu motywu biblioteki komponentów bez zrozumienia kaskady. Pojedyncze nadpisanie w pliku motywu może po cichu usunąć wskaźniki fokusu dla każdego komponentu, który po nim dziedziczy, w tym widżetów firm trzecich.
• Użycie koloru fokusu o niewystarczającym kontraście względem elementu lub tła strony. Jasnoszara obwódka na białym tle technicznie dodaje obrys, ale może być niedostrzegalna. Choć 2.4.7 nie narzuca konkretnego współczynnika kontrastu, 2.4.11 już tak — a wskaźniki fokusu o niskim kontraście są częstym źródłem niepowodzeń audytów, nawet gdy deweloperzy są przekonani, że spełnili wymogi.
• Ustawienie overflow: hidden lub clip-path na kontenerze, co przycina domyślną obwódkę przeglądarki. Rozwiązaniem jest przejście na wskaźniki fokusu oparte na box-shadow, które renderują się w obrębie własnego pudełka elementu i nie są przycinane przez reguły overflow rodzica.
• Zapominanie o wskaźnikach fokusu dla elementów interaktywnych wewnątrz komponentów SVG lub Canvas. Niestandardowe dymki wykresów, przyciski ikon oparte na SVG i narzędzia rysunkowe oparte na canvas często nie mają natywnego stylu fokusu. Wymagają one jawnych ról ARIA, tabindex oraz CSS :focus-visible lub wizualnej informacji zwrotnej sterowanej JavaScriptem.
• Usuwanie widoczności fokusu tylko w produkcyjnym CSS (np. przez postprocesor lub krok build), przy jednoczesnym pozostawieniu go widocznym w środowisku deweloperskim. Powoduje to, że zespół deweloperski przechodzi lokalne QA, jednocześnie dostarczając użytkownikom końcowym niedostępną wersję.
• Zastosowanie wskaźnika fokusu tylko do elementu <a>, ale nie do elementów role='link' typu span używanych dla linków nawigacyjnych SPA. Każdy element dostępny z klawiatury — niezależnie od natywnego znacznika — potrzebuje widocznego stanu fokusu.
• Ukrywanie pierścieni fokusu tylko w określonych szerokościach viewportu za pomocą zapytań medialnych, przy założeniu, że użytkownicy mobilni zawsze dotykają ekranu. Użytkownicy tabletów z klawiaturami Bluetooth oraz użytkownicy w orientacji poziomej, którzy polegają na wejściu z klawiatury, pozostają bez jakiegokolwiek wskaźnika fokusu.
• Używanie JavaScript do wywołania .blur() natychmiast po programowym ustawieniu fokusu, aby zapobiec pojawieniu się pierścienia fokusu. Jest to krytyczny błąd, który całkowicie usuwa widoczność fokusu i nigdy nie powinien być stosowany jako skrót projektowy.

Związek z tureckimi regulacjami dotyczącymi dostępności

Turecka Okólnik Prezydencki 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia wiążące wymagania dotyczące dostępności stron internetowych i aplikacji mobilnych dla szerokiego zakresu podmiotów działających w Turcji. Okólnik nakazuje zgodność z WCAG 2.2 na poziomie AA dla objętych organizacji, czyniąc WCAG 2.4.7 Focus Visible wymogiem bezpośrednio egzekwowalnym, a nie jedynie zaleceniem dobrych praktyk.

Podmioty objęte okólnikiem obejmują instytucje i agencje publiczne, platformy e-commerce, banki i dostawców usług finansowych, szpitale i organizacje opieki zdrowotnej, firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE). Dla wszystkich tych organizacji brak widocznych wskaźników fokusu w ich interfejsach cyfrowych stanowi problem niezgodności regulacyjnej, a nie tylko niedociągnięcie w zakresie użyteczności.

Erişilebilirlik Logosu (Logo Dostępności), wydawane przez Ministerstwo Rodziny i Usług Społecznych, pełni rolę oficjalnego znaku certyfikacji, który objęte podmioty mogą wyświetlać, aby wykazać zgodność. Uzyskanie Logo Dostępności wymaga przejścia formalnego audytu na poziomie WCAG 2.2 AA. WCAG 2.4.7 jest jednym z kryteriów AA, które audytorzy będą oceniać, zazwyczaj poprzez ręczne testy klawiaturą, jak opisano w sekcji testowania powyżej. Organizacja, której strona ukrywa pierścienie fokusu lub nie implementuje widocznego fokusu w komponentach niestandardowych, nie przejdzie audytu wymaganego do uzyskania logo.

Dla tureckich platform e-commerce w szczególności widoczność fokusu ma bezpośrednie implikacje komercyjne: dostępne strony docierają do szerszej bazy użytkowników, w tym klientów z niepełnosprawnością ruchową, którzy robią zakupy wyłącznie za pomocą klawiatury lub dostępu przełącznikowego, a zgodność z Okólnikiem Prezydenckim 2025/10 chroni organizacje przed działaniami administracyjnymi. Wbudowanie wzorców focus-visible w bibliotekę komponentów od samego początku — zamiast wprowadzania poprawek po audycie — jest najbardziej opłacalną drogą do utrzymania Erişilebilirlik Logosu i spełnienia tureckich obowiązków w zakresie dostępności.