WCAG 1.4.13: Treść po najechaniu kursorem lub uzyskaniu fokusu

Co oznacza ta zasada

WCAG 1.4.13 dotyczy powszechnego wzorca interakcji w sieci: treści, która staje się widoczna, gdy użytkownik najeżdża wskaźnikiem na element lub przenosi na niego fokus klawiatury. Obejmuje to podpowiedzi (tooltips), podmenu, niestandardowe podpowiedzi w rozwijanych listach, wyskakujące okienka selektora daty oraz wszelkie inne nakładki pojawiające się w odpowiedzi na zdarzenia hover lub focus. Kryterium ma zastosowanie zawsze, gdy taka treść nie jest kontrolowana natywnie przez przeglądarkę (na przykład natywna podpowiedź atrybutu title jest wyłączona z tego wymogu) i ustanawia trzy podstawowe wymagania, które muszą być spełnione jednocześnie.

Możliwość zamknięcia: Użytkownik musi mieć możliwość zamknięcia dodatkowej treści bez zmiany fokusu wskaźnika lub fokusu klawiatury. Standardowym mechanizmem jest naciśnięcie klawisza Escape. Zapobiega to sytuacji, w której nakładka zasłania inną treść strony w sposób, którego użytkownik nie może samodzielnie rozwiązać — co jest szczególnie istotne dla osób powiększających ekran i niemogących po prostu spojrzeć w inne miejsce.

Możliwość najechania: Jeśli dodatkowa treść pojawiła się, ponieważ użytkownik najechał wskaźnikiem na element wyzwalający, użytkownik musi móc przenieść wskaźnik na nowo wyświetloną treść bez jej znikania. Jeśli podpowiedź znika w momencie, gdy kursor opuszcza element wyzwalający, użytkownicy nie mogą przeczytać dłuższej treści, skopiować z niej tekstu ani aktywować znajdujących się w niej linków lub kontrolek.

Trwałość: Dodatkowa treść musi pozostać widoczna do momentu usunięcia wyzwalacza hover lub focus, zamknięcia jej przez użytkownika (na przykład klawiszem Escape) lub utraty aktualności informacji. Treść nie może znikać po upływie czasu ani po arbitralnym opóźnieniu, gdy wskaźnik użytkownika lub fokus nadal znajduje się na elemencie wyzwalającym lub na samej nakładce.

Pozytywny wynik wymaga spełnienia wszystkich trzech warunków. Negatywny wynik występuje, jeśli brakuje choć jednego warunku — na przykład podpowiedź, która znika, gdy wskaźnik przesuwa się z elementu wyzwalającego w kierunku podpowiedzi (brak możliwości najechania), taka, która automatycznie zamyka się po trzech sekundach (brak trwałości), lub taka, której nie można zamknąć bez przeniesienia fokusu (brak możliwości zamknięcia). Jedyny oficjalny wyjątek przewidziany przez WCAG dotyczy sytuacji, gdy wizualna prezentacja dodatkowej treści jest w pełni kontrolowana przez agent użytkownika — natywne podpowiedzi przeglądarki generowane wyłącznie przez atrybut title należą do tej kategorii i są wyłączone, choć mają własne ograniczenia dostępności.

Dlaczego to ma znaczenie

Kryterium to przynosi przede wszystkim korzyści użytkownikom, którzy mają trudności z kontrolowaniem standardowych interakcji myszą lub klawiaturą, użytkownikom polegającym na powiększeniu ekranu oraz użytkownikom wolniej przetwarzającym informacje. Zrozumienie, kogo dotyczy problem, pomaga zespołom właściwie ustalić priorytet naprawy.

Użytkownicy słabowidzący często korzystają z oprogramowania powiększającego ekran, takiego jak ZoomText, lub wbudowanego powiększenia systemu operacyjnego, co oznacza, że widzą tylko niewielką część ekranu przy wysokim poziomie powiększenia. Gdy pojawia się podpowiedź, może być częściowo poza ekranem i użytkownik musi przesunąć widok w jej kierunku. Jeśli podpowiedź znika w momencie, gdy wskaźnik opuszcza element wyzwalający, użytkownik nie może przesunąć widoku, aby ją przeczytać. Według Światowej Organizacji Zdrowia około 2,2 miliarda osób na świecie żyje z jakąś formą upośledzenia wzroku, a znacząca część tych, którzy korzystają z komputerów, polega na powiększeniu, a nie na czytniku ekranu.

Użytkownicy z niepełnosprawnością ruchową — w tym osoby z chorobą Parkinsona, drżeniem lub ograniczoną precyzją ruchów — mogą korzystać z alternatywnych urządzeń wskazujących, wskaźników nagłownych lub systemów śledzenia wzroku. Precyzyjne sterowanie wskaźnikiem jest dla tych użytkowników trudne, co oznacza, że przejście z małego elementu wyzwalającego na małą podpowiedź bez przypadkowego opuszczenia obu może być niemal niemożliwe, jeśli obszar hover nie jest „wybaczający”. Wymóg możliwości najechania bezpośrednio to adresuje.

Użytkownicy z niepełnosprawnościami poznawczymi mogą czytać wolno lub potrzebować wielokrotnego przeczytania treści. Podpowiedź, która automatycznie znika po kilku sekundach, nie daje tym użytkownikom wystarczająco dużo czasu na przyswojenie informacji, a podpowiedź, której nie można zamknąć bez zmiany fokusu, może uwięzić ich uwagę w mylącym stanie interakcji.

Rozważmy konkretny scenariusz: strona bankowości internetowej wyświetla szczegóły oprocentowania rachunku w podpowiedzi, która pojawia się, gdy użytkownik najedzie na małą ikonę informacyjną. Użytkownik słabowidzący, powiększający do 400%, widzi jednocześnie tylko część strony. Najeżdża na ikonę, pojawia się podpowiedź i zaczyna przesuwać wskaźnik w kierunku podpowiedzi, aby przeczytać drobny druk — ale podpowiedź natychmiast znika, ponieważ jest powiązana wyłącznie ze stanem hover elementu nadrzędnego. Użytkownik nie ma dostępu do wymaganych informacji o ujawnieniu. Nie jest to jedynie niedogodność użyteczności; w regulowanych branżach może to stanowić prawnie istotną barierę w dostępności.

Poza wpływem specyficznym dla niepełnosprawności, prawidłowa implementacja tego kryterium poprawia również ogólną użyteczność dla wszystkich użytkowników na urządzeniach hybrydowych dotykowo‑klawiaturowych, zmniejsza liczbę zgłoszeń do wsparcia spowodowanych „znikającymi” elementami interfejsu oraz sygnalizuje jakość interfejsu zarówno użytkownikom, jak i audytorom.

Powiązane reguły Axe-core

WCAG 1.4.13 wymaga testów manualnych. Narzędzia automatyczne nie mogą wiarygodnie wykrywać naruszeń, ponieważ kryterium dotyczy zachowań zależnych od czasu i ruchu wskaźnika, których statyczna analiza DOM nie jest w stanie ocenić. Żadna pojedyncza reguła axe-core nie odwzorowuje bezpośrednio tego kryterium, ale poniższe uwagi wyjaśniają, dlaczego automatyzacja jest niewystarczająca i na co zwracać uwagę podczas przeglądu manualnego.

• Wymagane testy manualne — zachowanie hover: Skanery automatyczne analizują DOM i CSSOM w danym momencie; nie mogą zasymulować przesuwania wskaźnika z elementu wyzwalającego w kierunku nowo wyrenderowanej podpowiedzi i obserwować, czy podpowiedź pozostaje widoczna. Teoretycznie narzędzie mogłoby wykryć, że pseudoklasa CSS :hover ukrywa element potomny, gdy element nadrzędny traci hover, ale nie jest w stanie odróżnić zamierzonego zamknięcia od naruszenia wymogu możliwości najechania bez symulowania ścieżek wskaźnika.
• Wymagane testy manualne — zamykanie klawiszem Escape: Wykrycie, czy naciśnięcie Escape zamyka nakładkę, wymaga symulacji zdarzeń JavaScript wykraczającej poza obecny zestaw reguł axe-core. Axe może oznaczyć brakujące role ARIA w wyskakujących oknach lub brak atrybutów aria-expanded, ale nie może zweryfikować, czy nasłuchiwacz zdarzenia keydown dla Escape jest powiązany z funkcją zamykania i faktycznie ukrywa element.
• Wymagane testy manualne — trwałość / auto‑zamykanie: Podpowiedź, która ukrywa się za pomocą wywołania setTimeout po trzech sekundach, będzie wyglądała na w pełni poprawną w statycznym skanie wykonanym w tym oknie czasowym. Tylko tester, który obserwuje nakładkę w czasie — lub przegląda kod źródłowy JavaScript — może zidentyfikować timer auto‑zamykania jako naruszenie.
• Uzupełniające reguły axe do uruchomienia równolegle z testami manualnymi: Choć nie testują bezpośrednio 1.4.13, uruchomienie reguł takich jak aria-tooltip-name (zapewnienie, że podpowiedzi mają dostępne nazwy), color-contrast (zapewnienie czytelności tekstu w podpowiedzi) oraz focus-visible (zapewnienie widocznej identyfikacji elementów z fokusem) może ujawnić powiązane problemy, które potęgują skutki naruszeń 1.4.13.

Jak testować

1. Automatyczny skan bazowy: Uruchom axe DevTools lub Lighthouse na stronie zawierającej treści wyzwalane przez hover/focus. Zanotuj wszelkie zgłoszone problemy z rolami podpowiedzi, kontrastem lub widocznością fokusu — nie potwierdzają one zgodności z 1.4.13, ale tworzą punkt odniesienia. Zapisz, które elementy wyzwalają treści nakładkowe, aby móc je uwzględnić w krokach manualnych.
2. Identyfikacja wszystkich treści wyzwalanych przez hover/focus: Przewiń stronę i systematycznie najeżdżaj na każdy element interaktywny — przyciski‑ikony, linki z dodatkowymi opisami, podpowiedzi pól formularzy, elementy nawigacji, nagłówki tabel danych i punkty danych na wykresach. Wypisz każdy element, który powoduje pojawienie się dodatkowej treści.
3. Test wymogu możliwości najechania: Dla każdego zidentyfikowanego wyzwalacza najedź na niego, aby wyświetlić nakładkę, a następnie powoli przenieś wskaźnik z elementu wyzwalającego na samą treść nakładki. Nakładka musi pozostać widoczna przez cały ten ruch. Jeśli znika, zanim wskaźnik do niej dotrze, kryterium nie jest spełnione.
4. Test wymogu możliwości zamknięcia: Gdy nakładka jest widoczna (wyzwolona przez hover lub fokus klawiatury), naciśnij klawisz Escape. Nakładka musi się zamknąć. Jeśli się nie zamyka, kryterium nie jest spełnione. Wykonaj ten test zarówno z wskaźnikiem nadal na elemencie wyzwalającym, jak i z wskaźnikiem nad nakładką.
5. Test wymogu trwałości: Wyzwól nakładkę, a następnie pozostaw wskaźnik nieruchomo na elemencie wyzwalającym lub na nakładce przez co najmniej 10–15 sekund. Nakładka musi pozostać widoczna przez cały ten czas. Jeśli zanika, wygasa lub znika bez działania użytkownika, kryterium nie jest spełnione.
6. Test wyłącznie klawiaturą: Przechodź po stronie za pomocą klawiatury, używając klawisza Tab. Gdy fokus trafi na wyzwalacz, który ujawnia dodatkową treść, sprawdź: (a) czy treść się pojawia, (b) czy naciśnięcie Escape ją zamyka oraz (c) czy treść nie znika sama, gdy fokus pozostaje na wyzwalaczu. Użyj NVDA z Firefoxem, JAWS z Chrome oraz VoiceOver z Safari, aby potwierdzić, że czytniki ekranu również poprawnie udostępniają tę treść.
7. Test z powiększeniem ekranu: Ustaw powiększenie przeglądarki na 400% lub włącz powiększenie na poziomie systemu operacyjnego. Powtórz testy hover. Upewnij się, że użytkownik, który musi przesuwać widok, aby dotrzeć do podpowiedzi, może to zrobić bez jej znikania.
8. Przegląd kodu JavaScript: Wyszukaj w bazie kodu obsługę setTimeout, mouseleave, mouseout i blur powiązaną z logiką ukrywania nakładek. Potwierdź, że logika ukrywania nie jest wyzwalana, gdy wskaźnik znajduje się nad nakładką lub gdy wyzwalacz zachowuje fokus, oraz że nie jest ustawiony żaden timer auto‑zamykania.

Jak naprawić

Podpowiedź wyłącznie w CSS, znikająca przy mouseleave — niepoprawne

<!-- Tooltip only shown via CSS :hover on parent; disappears as soon as
     the pointer moves off the trigger toward the tooltip text -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip'>This is the tooltip content.</span>
</span>

<!-- CSS (illustrative) -->
<!--
.tooltip { display: none; }
.tip-wrapper:hover .tooltip { display: block; }
-->

Podpowiedź wyłącznie w CSS, znikająca przy mouseleave — poprawne

<!-- Correct: tooltip is also shown when the pointer is over the tooltip itself,
     and the gap between trigger and tooltip is covered so pointer movement
     does not accidentally dismiss the overlay. -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip' role='tooltip' id='tip1'>This is the tooltip content.</span>
</span>

<!-- CSS (illustrative) -->
<!--
.tooltip { display: none; position: absolute; }
.tip-wrapper:hover .tooltip,
.tooltip:hover { display: block; }
/* Use padding or a transparent pseudo-element bridge between trigger and tooltip */
-->

Podpowiedź w JavaScript bez zamykania klawiszem Escape — niepoprawne

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
// Only mouseenter/mouseleave — no keyboard or Escape handling
document.querySelector('button').addEventListener('mouseenter', () => {
  document.getElementById('tip2').removeAttribute('hidden');
});
document.querySelector('button').addEventListener('mouseleave', () => {
  document.getElementById('tip2').setAttribute('hidden', '');
});
</script>

Podpowiedź w JavaScript bez zamykania klawiszem Escape — poprawne

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
const btn = document.querySelector('button');
const tip = document.getElementById('tip2');

function showTip() { tip.removeAttribute('hidden'); }
function hideTip() { tip.setAttribute('hidden', ''); }

// Show on hover and focus
btn.addEventListener('mouseenter', showTip);
btn.addEventListener('focus', showTip);

// Hide only when pointer leaves BOTH trigger AND tooltip
btn.addEventListener('mouseleave', (e) => {
  // Short delay allows pointer to reach the tooltip
  setTimeout(() => {
    if (!tip.matches(':hover') && !btn.matches(':hover')) hideTip();
  }, 100);
});
tip.addEventListener('mouseleave', () => {
  if (!btn.matches(':hover')) hideTip();
});

// Hide on blur (keyboard)
btn.addEventListener('blur', hideTip);

// Dismissible via Escape key — required by 1.4.13
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape' && !tip.hidden) hideTip();
});
</script>

Podpowiedź auto‑zamykania z użyciem setTimeout — niepoprawne

<button id='info-btn'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
document.getElementById('info-btn').addEventListener('mouseenter', () => {
  const t = document.getElementById('tip3');
  t.removeAttribute('hidden');
  // Violation: auto-dismisses after 3 seconds regardless of user state
  setTimeout(() => t.setAttribute('hidden', ''), 3000);
});
</script>

Podpowiedź auto‑zamykania z użyciem setTimeout — poprawne

<button id='info-btn' aria-describedby='tip3'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
const btn2 = document.getElementById('info-btn');
const tip3 = document.getElementById('tip3');

// No setTimeout — tooltip persists until user removes hover/focus or presses Escape
function show() { tip3.removeAttribute('hidden'); }
function hide() {
  setTimeout(() => {
    if (!tip3.matches(':hover') && !btn2.matches(':hover') && document.activeElement !== btn2) {
      tip3.setAttribute('hidden', '');
    }
  }, 100);
}

btn2.addEventListener('mouseenter', show);
btn2.addEventListener('focus', show);
btn2.addEventListener('mouseleave', hide);
btn2.addEventListener('blur', hide);
tip3.addEventListener('mouseleave', hide);
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') tip3.setAttribute('hidden', '');
});
</script>

Typowe błędy

• Używanie wyłącznie CSS :hover bez zakrycia przerwy między wyzwalaczem a podpowiedzią: Gdy istnieje choćby 1–2 px przerwy między elementem wyzwalającym a kontenerem podpowiedzi, przesunięcie wskaźnika między nimi powoduje utratę stanu hover, ukrywając podpowiedź, zanim użytkownik do niej dotrze. Użyj przezroczystego pseudoelementu lub nakładającego się wypełnienia (padding), aby zlikwidować tę przerwę.
• Powiązanie logiki ukrywania z mouseleave na wyzwalaczu bez sprawdzania, czy wskaźnik przeszedł na podpowiedź: Podpowiedź znika w chwili, gdy kursor opuszcza wyzwalacz, nawet jeśli celem jest sama podpowiedź. Zawsze sprawdzaj tip.matches(':hover') przed ukryciem lub użyj krótkiego opóźnienia (debounce).
• Zapominanie o powiązaniu zdarzeń focus i blur wraz z mouseenter i mouseleave: Użytkownicy korzystający wyłącznie z klawiatury, którzy przechodzą Tabem do wyzwalacza, nigdy nie zobaczą podpowiedzi, jeśli obsługiwane są tylko zdarzenia myszy, co czyni powiązane informacje całkowicie niedostępnymi bez myszy.
• Brak dodania nasłuchiwacza klawisza Escape przy założeniu, że kliknięcie poza nakładką wystarczy: Użytkownicy klawiatury i użytkownicy powiększenia ekranu nie mogą łatwo „kliknąć poza” nakładką. Escape jest oczekiwanym i wymaganym mechanizmem zamykania dla tego kryterium.
• Umieszczanie nasłuchiwacza Escape wyłącznie na elemencie wyzwalającym zamiast na document: Jeśli użytkownik przeniesie fokus na podpowiedź lub inny element, nasłuchiwacz ograniczony do wyzwalacza nie zadziała. Obsługa Escape musi być umieszczona na dokumencie lub wspólnym przodku, który zawsze otrzymuje zdarzenia klawiatury, gdy nakładka jest otwarta.
• Używanie setTimeout do automatycznego zamykania podpowiedzi po stałym czasie: Każde zamykanie oparte na timerze, które uruchamia się, gdy wskaźnik nadal znajduje się na wyzwalaczu lub podpowiedzi, lub gdy wyzwalacz nadal ma fokus klawiatury, jest bezpośrednim naruszeniem wymogu trwałości. Usuń wszystkie timery auto‑zamykania z nakładek wyzwalanych przez hover/focus.
• Wyzwalanie widoczności podpowiedzi wyłącznie poprzez zastąpienie atrybutu title niestandardowym stylowaniem: Programiści, którzy usuwają natywną podpowiedź title i zastępują ją wersją niestandardową, muszą samodzielnie zaimplementować wszystkie trzy wymagania 1.4.13. Wyłączenie dla natywnych podpowiedzi przeglądarki nie obejmuje niestandardowych implementacji JavaScript odtwarzających ten sam wzorzec.
• Brak testów z powiększeniem ekranu do 400%: Podpowiedź, która wydaje się dostępna przy normalnym powiększeniu, może być częściowo poza ekranem przy wysokim powiększeniu, co wymaga od użytkownika przesuwania widoku — a jeśli znika, zanim użytkownik zdąży do niej przesunąć widok, test, który przeszedł przy 100% powiększeniu, zawodzi w rzeczywistych warunkach użycia.
• Stosowanie pointer-events: none do kontenera podpowiedzi: Ta właściwość CSS uniemożliwia uznanie wskaźnika za „znajdujący się nad” podpowiedzią, co sprawia, że spełnienie wymogu możliwości najechania jest niemożliwe niezależnie od innej logiki. Podpowiedzi, z którymi użytkownicy mogą potrzebować wchodzić w interakcję lub po prostu najechać na nie, aby utrzymać je widoczne, nigdy nie powinny mieć pointer-events: none.
• Traktowanie samego ARIA role='tooltip' jako wystarczającego dla zgodności: Dodanie role='tooltip' i aria-describedby jest ważne dla dostępności w czytnikach ekranu, ale dotyczy innej warstwy problemu. Te atrybuty ARIA nie sprawiają automatycznie, że treść staje się możliwa do zamknięcia, najechania i trwała — zachowanie interakcji musi być nadal zaimplementowane wprost.

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

Prezydenckie Okólniki Turcji 2025/10, opublikowane w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawiają formalny obowiązek zapewnienia dostępności, który włącza standardy WCAG przez odesłanie. Okólnik wymaga od podmiotów objętych regulacją wdrożenia środków dostępności stron internetowych zgodnych z międzynarodowo uznanymi wytycznymi, a zgodność na poziomie AA — obejmująca WCAG 1.4.13 — jest zarówno silnie zalecana, jak i wymagana dla podmiotów ubiegających się o Logo Dostępności (Erişilebilirlik Logosu) wydawane przez Ministerstwo Rodziny i Usług Społecznych (Aile ve Sosyal Hizmetler Bakanlığı).

Okólnik obejmuje szeroki zakres typów podmiotów działających w Turcji. Instytucje publiczne i organy administracji rządowej na wszystkich poziomach są zobowiązane do zapewnienia dostępności swoich usług cyfrowych. W sektorze prywatnym obowiązek ten rozciąga się na platformy e‑commerce, banki i dostawców usług finansowych, szpitale i prywatne placówki opieki zdrowotnej, operatorów telekomunikacyjnych z 200,000 lub większą liczbą abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne działające na podstawie upoważnienia Ministerstwa Edukacji Narodowej (Millî Eğitim Bakanlığı).

WCAG 1.4.13 jest szczególnie istotne w tureckich kontekstach cyfrowych, w których wzorce podpowiedzi i popoverów są szeroko stosowane w portalach e‑administracji (takich jak integracje e‑Devlet), interfejsach bankowości i fintech wyświetlających informacje o opłatach lub stawkach w podpowiedziach oraz systemach rezerwacji wizyt medycznych, które prezentują dodatkowe instrukcje za pomocą nakładek wyzwalanych przez hover. Platforma bankowa niespełniająca 1.4.13 może uniemożliwić klientom słabowidzącym odczytanie informacji o oprocentowaniu przekazywanych w podpowiedzi — scenariusz ten ma konsekwencje zarówno dla dostępności, jak i ochrony konsumentów usług finansowych.

Dla podmiotów ubiegających się o Erişilebilirlik Logosu audyt dostępności będzie obejmował testy manualne zachowań hover i focus właśnie dlatego, że narzędzia automatyczne nie są w stanie wykryć tych naruszeń. Organizacje korzystające z zestawu SDK nakładki dostępności, takiego jak Accsible, powinny upewnić się, że wszelkie podpowiedzi, wyskakujące okienka przewodników po interfejsie czy panele pomocy kontekstowej wstrzykiwane przez sam SDK w pełni spełniają wszystkie trzy wymagania 1.4.13 — możliwość zamknięcia klawiszem Escape, możliwość najechania bez zamknięcia oraz trwałość do czasu działania użytkownika. Niespełnienie tych wymogów wprowadziłoby nowe bariery za pośrednictwem narzędzia, które miało poprawić dostępność, podważając zarówno zgodność regulacyjną, jak i zaufanie użytkowników.