WCAG 2.4.13: Wygląd fokusu

Co oznacza ta zasada

WCAG 2.4.13 Focus Appearance to kryterium na poziomie AAA wprowadzone w WCAG 2.2, które określa precyzyjne, mierzalne wymagania dotyczące wizualnego wyglądu wskaźników fokusu klawiatury. Podczas gdy niżej poziomowe kryterium 2.4.11 (Focus Not Obscured, poziom AA) zapewnia, że element z fokusem nie jest całkowicie ukryty, a 2.4.7 (Focus Visible, poziom AA) jedynie wymaga, aby jakiś wskaźnik fokusu istniał, 2.4.13 idzie dalej, definiując, jak bardzo widoczny musi być ten wskaźnik.

Aby spełnić to kryterium, wskaźnik fokusu klawiatury musi spełniać wszystkie poniższe warunki:

• Minimalna powierzchnia: Wskaźnik fokusu musi mieć powierzchnię co najmniej równą obwodowi nieaktywnego komponentu pomnożonemu przez 2 piksele CSS. W praktyce, dla typowego prostokątnego przycisku oznacza to, że obrys fokusu musi mieć powierzchnię równą lub większą niż obwód przycisku pomnożony przez 2px — pierścień fokusu o grubości co najmniej 2px wokół całej krawędzi spełnia ten warunek.
• Współczynnik kontrastu wskaźnika fokusu: Piksele tworzące wskaźnik fokusu muszą mieć współczynnik kontrastu co najmniej 3:1 między stanem z fokusem a stanem bez fokusu. Jeśli więc przycisk ma białe tło w stanie domyślnym, pierścień fokusu narysowany wokół niego musi mieć kontrast co najmniej 3:1 względem tego białego tła.
• Brak obniżenia kontrastu dla zawartości wewnętrznej: Wskaźnik fokusu nie może obniżać kontrastu tekstu ani innej treści wewnątrz komponentu z fokusem poniżej 4.5:1 (dla tekstu poniżej 18pt / 14pt pogrubionego) lub 3:1 (dla dużego tekstu i treści nietekstowej).

Wszystkie trzy warunki muszą być spełnione jednocześnie, aby komponent przeszedł test. Wskaźnik fokusu, który jest wystarczająco duży, ale ma niewystarczający kontrast, nie spełnia wymagań. Podobnie, wskaźnik o wysokim kontraście, ale zbyt mały, również nie spełnia wymagań.

Specyfikacja WCAG definiuje jeden istotny wyjątek: jeśli domyślny wskaźnik fokusu przeglądarki (domyślny wskaźnik agenta użytkownika) spełnia wymagania, autor nie musi dodawać niestandardowego stylu. Jednak domyślne ustawienia przeglądarek znacząco się różnią — przeglądarki oparte na Chromium zazwyczaj zapewniają niebieski obrys, podczas gdy Safari może renderować pierścień, który w niektórych schematach kolorów nie ma wystarczającego kontrastu. Autorzy powinni zweryfikować, czy domyślny wskaźnik spełnia próg, lub zapewnić solidny styl niestandardowy.

Kryterium ma zastosowanie do wszystkich interaktywnych i fokusowalnych komponentów: linków, przycisków, pól formularzy, menu select, pól wyboru (checkbox), przycisków opcji (radio), niestandardowych komponentów widżetów zbudowanych z użyciem ról ARIA oraz dowolnego elementu uczynionego fokusowalnym za pomocą tabindex. Dotyczy także wskaźników fokusu tworzonych wyłącznie za pomocą CSS na pseudoelementach lub poprzez zmiany klas kontrolowane przez JavaScript.

Dlaczego to ma znaczenie

Widoczność fokusu jest kluczową wskazówką nawigacyjną dla szerokiej grupy użytkowników. Gdy wskaźniki fokusu są cienkie, o niskim kontraście lub całkowicie nieobecne, użytkownicy ci tracą orientację przestrzenną na stronie — nie są w stanie stwierdzić, gdzie się znajdują ani dokąd mogą przejść dalej.

Użytkownicy korzystający wyłącznie z klawiatury — w tym osoby z niepełnosprawnościami ruchowymi, takimi jak drżenia, paraliż czy urazy przeciążeniowe — polegają całkowicie na klawiaturze w nawigacji. Dla tych użytkowników niewidoczny lub ledwo widoczny wskaźnik fokusu to nie tylko niedogodność; sprawia, że cały interfejs staje się nieużywalny. Według Światowej Organizacji Zdrowia około 1,3 miliarda osób żyje z jakąś formą niepełnosprawności, a niepełnosprawności ruchowe stanowią jedną z największych kategorii wśród osób, które unikają używania myszy lub nie mogą z niej korzystać.

Użytkownicy słabowidzący, którzy używają oprogramowania powiększającego, ale nie pełnego czytnika ekranu, również polegają na pierścieniu fokusu, aby się orientować. Przy wysokich poziomach powiększenia domyślny obrys 1px może zostać przycięty przez obszar widoku lub po prostu być niewidoczny na tle podobnie zabarwionego tła. Użytkownicy ci często nawigują za pomocą klawiatury właśnie dlatego, że precyzyjne celowanie myszą jest trudne przy dużym powiększeniu.

Niepełnosprawności poznawcze i związane z uwagą, takie jak ADHD, zaburzenia lękowe czy urazy mózgu, mogą utrudniać śledzenie informacji wizualnych na stronie. Wysoce widoczny, wyraźnie odróżniający się wskaźnik fokusu zmniejsza obciążenie poznawcze nawigacji, zapewniając jednoznaczny punkt odniesienia dla aktualnej pozycji użytkownika.

Niepełnosprawności sytuacyjne również mają znaczenie: deweloper testujący na laptopie z niską jasnością ekranu na zewnątrz lub starsza osoba z wiekowym spadkiem wrażliwości na kontrast może mieć trudności z cienkimi lub niskokontrastowymi pierścieniami fokusu, nawet bez klinicznej diagnozy.

Rozważmy scenariusz z życia wzięty: internetowy formularz banku do przelewu środków zawiera dziesięć pól wejściowych i cztery przyciski akcji. Użytkownik z chorobą Parkinsona przechodzi przez formularz za pomocą klawiatury. Jeśli wskaźnik fokusu to domyślny przerywany obrys 1px w jasnoszarym kolorze na białym tle, użytkownik nie może wiarygodnie śledzić, które pole aktualnie edytuje. Może przypadkowo zlecić przelew na niewłaściwe konto, ponieważ nie widział, że fokus przesunął się poza pole odbiorcy. Solidny, wysokokontrastowy obrys fokusu całkowicie by temu zapobiegł.

Poza dostępnością, wyraźny wskaźnik fokusu jest ulepszeniem użyteczności dla wszystkich użytkowników. Zaawansowani użytkownicy, którzy często nawigują po formularzach i menu za pomocą klawiatury — co jest powszechnym wzorcem wśród deweloperów, pracowników wprowadzających dane i użytkowników czytników ekranu — korzystają z szybkiej, niezawodnej orientacji. Istnieje także pośredni sygnał SEO: witryny o wysokiej dostępności mają tendencję do niższych współczynników odrzuceń i wyższej realizacji zadań, co koreluje z pozytywnymi czynnikami rankingowymi.

Powiązane reguły Axe-core

WCAG 2.4.13 wymaga testów manualnych, ponieważ narzędzia automatyczne nie są w stanie w pełni ocenić rozmiaru i kontrastu wskaźnika fokusu w każdym możliwym kontekście renderowania przeglądarki. Axe-core nie ma pojedynczej automatycznej reguły, która bezpośrednio oznacza naruszenia 2.4.13. Powody są techniczne:

• Dlaczego automatyzacja jest niewystarczająca: Obliczenie dokładnej powierzchni pikselowej wskaźnika fokusu wymaga zasymulowania fokusu klawiatury na każdym interaktywnym elemencie, zmierzenia geometrii renderowanego obrysu (która zależy od przeglądarki, systemu operacyjnego, poziomu powiększenia i CSS), obliczenia współczynnika kontrastu pikseli wskaźnika względem ich sąsiadów oraz zweryfikowania, że żaden z tych aspektów nie narusza wymogu kontrastu dla zawartości wewnętrznej. Żaden obecny silnik automatycznej dostępności nie wykonuje niezawodnie wszystkich tych kroków dla wszystkich komponentów. Axe-core może oznaczyć brak jakiegokolwiek stylu fokusu (powiązane z 2.4.7), ale nie może zmierzyć, czy styl, który jest obecny, spełnia progi powierzchni i kontrastu 2.4.13.
• Częściowe pokrycie poprzez reguły związane z fokusem: Reguła focus-visible w axe-core sprawdza, czy elementy w ogóle mają widoczny wskaźnik fokusu. Jeśli element ma outline: none lub outline: 0 bez alternatywnego wskaźnika wizualnego, reguła to oznaczy. Jednak przejście tej reguły nie gwarantuje zgodności z 2.4.13 — element może mieć technicznie widoczny obrys, który nadal jest zbyt cienki lub o zbyt niskim kontraście.
• Testy manualne jako metoda rozstrzygająca: Testerzy muszą wizualnie sprawdzić każdy interaktywny komponent w stanie z fokusem, zmierzyć lub oszacować wymiary obrysu oraz zweryfikować współczynniki kontrastu za pomocą analizatora kontrastu kolorów. Dlatego WCAG wymienia 2.4.13 jako kryterium wymagające wyłącznie testów manualnych na potrzeby axe-core.

Jak testować

1. Skan automatyczny (tylko sygnał częściowy): Uruchom axe DevTools lub Lighthouse na stronie. Wyszukaj wszelkie naruszenia związane z focus-visible lub focus-order-semantics. Choć nie wskażą one bezpośrednio naruszeń 2.4.13, mogą ujawnić elementy, w których styl fokusu został całkowicie wyłączony, co jest wstępnym naruszeniem. W Chrome DevTools otwórz panel Accessibility i użyj trybu inspekcji „Tab”, aby przechodzić przez elementy fokusowalne.
2. Wizualny test nawigacji klawiaturą: Odłącz lub odłóż mysz. Naciskaj Tab, aby przechodzić przez każdy interaktywny element na stronie. Dla każdego elementu z fokusem wizualnie sprawdź wskaźnik fokusu. Zapytaj: Czy jest wyraźnie widoczny pierścień lub inny wskaźnik? Czy wydaje się mieć co najmniej 2px grubości? Czy silnie kontrastuje z otaczającym tłem? Zanotuj wszelkie elementy, przy których się wahasz lub masz trudność z dostrzeżeniem, gdzie znajduje się fokus.
3. Pomiary kontrastu: Użyj WebAIM Contrast Checker lub narzędzia desktopowego Colour Contrast Analyser. Przy ustawionym fokusie na komponencie wykonaj zrzut ekranu. Pobierz próbkę koloru pikseli wskaźnika fokusu oraz koloru tła bezpośrednio do niego przylegającego. Zweryfikuj, że współczynnik kontrastu wynosi co najmniej 3:1.
4. Pomiary wymiarów: Użyj narzędzi deweloperskich przeglądarki (Chrome lub Firefox). Wybierz element z fokusem i sprawdź jego style obliczone. Sprawdź outline-width, outline-offset oraz wszelkie box-shadow używane jako pierścień fokusu. Pomnóż obwód elementu (2 × szerokość + 2 × wysokość) przez 2px, aby obliczyć minimalną powierzchnię. Zweryfikuj, że renderowana powierzchnia wskaźnika spełnia lub przekracza tę wartość.
5. Test czytnika ekranu + klawiatury (NVDA + Firefox): Otwórz stronę w Firefox z uruchomionym NVDA. Nawiguj za pomocą klawiszy Tab i strzałek. Potwierdź, że wizualny wskaźnik fokusu przemieszcza się synchronicznie z ogłaszanym przez NVDA fokusem. Zwróć szczególną uwagę na niestandardowe widżety (karuzele, modalne okna dialogowe, akordeony), w których zarządzanie fokusem może być obsługiwane przez JavaScript.
6. VoiceOver + Safari (macOS/iOS): Włącz VoiceOver skrótem Command + F5. Używaj Tab, aby nawigować po elementach interaktywnych. Zweryfikuj, że kursor VoiceOver (czarny obrysowy prostokąt) nie zastępuje właściwego wskaźnika fokusu CSS — sama strona musi zapewniać go niezależnie.
7. Test w trybie wysokiego kontrastu: W systemie Windows włącz tryb High Contrast (Ustawienia → Ease of Access → High Contrast). Przeładuj stronę i powtórz test nawigacji klawiaturą. Niektóre style fokusu CSS są nadpisywane przez system operacyjny w trybie wysokiego kontrastu; zweryfikuj, że nadal pojawia się widoczny wskaźnik. Użyj zapytania medialnego CSS forced-colors: active, aby w razie potrzeby warunkowo dostosować style.

Jak naprawić

Domyślny obrys przeglądarki usunięty — niepoprawne

<!-- Many stylesheets globally suppress the default focus outline -->
<style>
  * {
    outline: none; /* Removes ALL focus indicators site-wide */
  }
  a:focus, button:focus {
    outline: 0; /* Redundant removal; no replacement provided */
  }
</style>
<button>Submit Payment</button>

Domyślny obrys przeglądarki usunięty — poprawne

<!-- Remove the default only when providing a superior custom indicator -->
<style>
  /* Only suppress default outline when :focus-visible applies, then provide a strong replacement */
  :focus-visible {
    outline: 3px solid #0057b8; /* 3px ensures area requirement is met for typical elements */
    outline-offset: 2px;       /* Offset separates indicator from element edge for clarity */
  }
  /* Respect forced-colors (Windows High Contrast) by using system keywords */
  @media (forced-colors: active) {
    :focus-visible {
      outline: 3px solid ButtonText;
    }
  }
</style>
<button>Submit Payment</button>

Niskokontrastowy pierścień fokusu na kolorowym tle — niepoprawne

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus {
    outline: 2px solid #3399ff; /* Light blue outline on dark blue background: contrast ratio ~1.4:1 — fails */
  }
</style>
<button class='cta-button'>Book Now</button>

Niskokontrastowy pierścień fokusu na kolorowym tle — poprawne

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus-visible {
    /* White outline contrasts strongly against the dark blue button (contrast ~8:1) */
    outline: 3px solid #ffffff;
    outline-offset: 2px;
    /* A dark offset box-shadow behind the white ring ensures contrast against light page backgrounds */
    box-shadow: 0 0 0 5px #0057b8;
  }
</style>
<button class='cta-button'>Book Now</button>

Niestandardowy interaktywny widżet oparty na div bez stylu fokusu — niepoprawne

<style>
  .tab-item { cursor: pointer; padding: 12px 20px; }
  /* No :focus or :focus-visible style defined for custom tab */
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Niestandardowy interaktywny widżet oparty na div bez stylu fokusu — poprawne

<style>
  .tab-item {
    cursor: pointer;
    padding: 12px 20px;
    border-radius: 4px;
  }
  /* Explicit :focus-visible style — outline-width 3px with offset meets area threshold */
  .tab-item:focus-visible {
    outline: 3px solid #d4550a; /* 3:1+ contrast against white background */
    outline-offset: 3px;
  }
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Cienki box-shadow użyty jako wskaźnik fokusu — niepoprawne

<style>
  .form-input:focus {
    outline: none;
    /* 1px box-shadow spread: likely too small in area for most input sizes */
    box-shadow: 0 0 0 1px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Cienki box-shadow użyty jako wskaźnik fokusu — poprawne

<style>
  .form-input:focus-visible {
    outline: none;
    /*
      3px spread provides sufficient area around a typical 300px-wide input.
      #005fcc on white background yields ~5.9:1 contrast — passes both 2.4.13 (3:1) and 1.4.3 (4.5:1).
    */
    box-shadow: 0 0 0 3px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Typowe błędy

• Używanie outline: none w resetach CSS bez zapewnienia jakiegokolwiek zastępczego wskaźnika fokusu. Wiele popularnych resetów CSS (starsze wersje Normalize.css, niestandardowe resety) hurtowo usuwa obrysy. Zawsze łącz usunięcie z zastępczym :focus-visible, który spełnia wymagania dotyczące rozmiaru i kontrastu.
• Zapewnianie stylu fokusu tylko dla :focus, ale nie dla :focus-visible, co powoduje pierścienie fokusu po kliknięciu myszą na przyciskach, irytujące widzących użytkowników myszy — co prowadzi do tego, że deweloperzy usuwają je całkowicie zamiast użyć właściwego rozdzielenia pseudo-klas.
• Dobór koloru pierścienia fokusu bardzo zbliżonego do koloru tła komponentu. Na przykład jasnoniebieski pierścień #99ccff na białym tle #ffffff ma współczynnik kontrastu około 1.5:1, znacznie poniżej wymaganego 3:1.
• Używanie outline-width: 1px na małych komponentach, takich jak przyciski ikonowe lub pola wyboru. Pierścień 1px wokół ikony 24×24px ma powierzchnię około 96 pikseli kwadratowych, ale wymagana minimalna powierzchnia dla elementu 24×24 to (24+24+24+24) × 2 = 192 piksele kwadratowe — dokładnie 2px grubości. Obrys 1px nie spełnia tego obliczenia.
• Zapominanie o testowaniu wyglądu fokusu na niestandardowych widżetach ARIA, takich jak role='combobox', role='listbox' czy role='slider'. Komponenty te często mają fokus zarządzany przez JavaScript, który omija natywne pseudoklasy CSS, jeśli nie zostanie to wyraźnie obsłużone.
• Stosowanie stylu fokusu tylko do tagów a i button przy jednoczesnym pomijaniu input, select, textarea oraz dowolnego elementu z tabindex='0'.
• Nadpisywanie stylów fokusu głęboko w bibliotece komponentów lub widżecie zewnętrznym bez świadomości, że nadpisanie usuwa widoczny wskaźnik. Typowymi winowajcami są zestawy UI, takie jak Bootstrap 4 (który ustawia box-shadow na subtelną poświatę), które mogą nie spełniać progu 2.4.13.
• Brak testowania wyglądu fokusu w trybie wysokiego kontrastu w Windows. Niektóre techniki obrysu i box-shadow w CSS renderują się jako niewidoczne w trybie High Contrast. Użyj bloku @media (forced-colors: active), aby zapewnić widoczny, oparty na kolorach systemowych fallback.
• Używanie outline-offset z bardzo dużą wartością ujemną, aby przesunąć obrys do wnętrza obramowania elementu. Może to spowodować, że wskaźnik będzie nachodził na tło elementu, obniżając efektywny kontrast poniżej 3:1.
• Zakładanie, że wskaźnik fokusu na kontenerze nadrzędnym jest wystarczający dla podrzędnych elementów interaktywnych. Każdy fokusowalny element musi niezależnie spełniać kryterium; wyróżniony wiersz w tabeli nie spełnia wymogu dla komórki z linkiem w tym wierszu.

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

Prezydencki okólnik Turcji 2025/10, opublikowany 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 przyjmuje WCAG 2.2 jako techniczny standard referencyjny i nakazuje zgodność na poziomie AA dla objętych podmiotów. WCAG 2.4.13 Focus Appearance jest kryterium na poziomie AAA i dlatego nie jest bezpośrednio wymagane przez okólnik dla standardowej zgodności.

Zakres okólnika jest jednak bardzo szeroki. Podmioty objęte obejmują instytucje publiczne i agencje rządowe, banki i dostawców usług finansowych, szpitale i organizacje opieki zdrowotnej, operatorów telekomunikacyjnych z 200,000 lub większą liczbą abonentów, platformy e-commerce, biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE). Dla wszystkich tych organizacji wykazanie zgodności na poziomie AAA w odniesieniu do odpowiednich kryteriów — w tym 2.4.13 — sygnalizuje zaangażowanie w najlepszą w swojej klasie dostępność, wykraczającą poza prawne minimum.

Istnieją praktyczne i wizerunkowe powody, dla których objęte tureckie podmioty powinny dobrowolnie wdrożyć 2.4.13. Banki i dostawcy usług finansowych w szczególności obsługują klientów z niepełnosprawnościami ruchowymi, którzy polegają na nawigacji klawiaturą przy bezpiecznych transakcjach. Portal bankowości internetowej tureckiego banku, który spełnia 2.4.13, nie tylko przekracza wymagania regulacyjne, ale także zmniejsza ryzyko błędów użytkownika i demonstruje społeczną odpowiedzialność biznesu. Podobnie szpitale i portale opieki zdrowotnej, w których pacjenci rezerwują wizyty lub uzyskują dostęp do dokumentacji medycznej, powinny zapewnić, że wszyscy użytkownicy — w tym starsi pacjenci z obniżoną precyzją ruchów lub słabym wzrokiem — mogą nawigować po tych interfejsach z pewnością.

Operatorzy telekomunikacyjni z dużą bazą abonentów należą do najczęściej odwiedzanych usług cyfrowych w Turcji. Ich portale klienta i aplikacje samoobsługowe docierają do milionów użytkowników, w tym znaczącej części osób starszych i użytkowników z niepełnosprawnościami. Dobrowolne wdrożenie 2.4.13 na tych platformach zapewnia równy dostęp wszystkim abonentom i stawia operatora w korzystnej pozycji w obliczu ewentualnego zaostrzenia regulacji, które mogłoby rozszerzyć obowiązkową zgodność na kryteria AAA.

Dla organizacji dążących do pełnej zgodności z WCAG 2.2 AAA — czy to z powodu wymogów przetargowych, eksportu na rynki UE objęte Europejskim Aktem o Dostępności, czy wewnętrznych polityk dostępności — wdrożenie 2.4.13 jest niezbędnym elementem. Nakładkowy SDK Accsible zapewnia konfigurowalne funkcje ulepszania fokusu, które mogą pomóc organizacjom w zapewnieniu silnych, zgodnych wskaźników fokusu w całych ich interfejsach, uzupełniając poprawki CSS po stronie autora opisane w tym artykule.