WCAG 2.4.11: Fokus nieprzesłonięty (minimum)

Co Oznacza Ta Zasada

WCAG 2.4.11 Focus Not Obscured (Minimum) to kryterium na poziomie AA wprowadzone w WCAG 2.2, które dotyczy powszechnego, ale poważnego problemu z dostępnością: sytuacji, gdy element z fokusem jest całkowicie ukryty za inną warstwą treści na stronie. Kryterium stanowi, że gdy dowolny komponent interfejsu użytkownika otrzymuje fokus z klawiatury, komponent ten nie może być w całości zasłonięty przez treści stworzone przez autora.

Kluczowym słowem jest tutaj całkowicie. WCAG 2.4.11 wyznacza minimalny próg — wymaga jedynie, aby jakaś część elementu z fokusem pozostała widoczna. Jeśli przyklejony pasek nawigacyjny zachodzi na górną połowę przycisku z fokusem, ale dolna połowa jest nadal widoczna, to technicznie spełnia 2.4.11. Bardziej rygorystyczne kryterium towarzyszące, WCAG 2.4.12 Focus Not Obscured (Enhanced) na poziomie AAA, idzie dalej, wymagając, aby komponent z fokusem nie był zasłonięty przez treści stworzone przez autora w ogóle — nawet częściowo.

Typy treści tworzonych przez autorów, które najczęściej odpowiadają za ten problem, obejmują przyklejone lub o stałym położeniu nagłówki i stopki, banery zgody na pliki cookie, widżety czatu wsparcia, powiadomienia typu toast, nakładki modalne, pływające przyciski akcji oraz dolne paski nawigacyjne w układach responsywnych na urządzeniach mobilnych. Elementy te są renderowane z użyciem właściwości CSS, takich jak position: fixed, position: sticky lub wysokie wartości z-index, co powoduje, że unoszą się ponad normalnym przepływem dokumentu i potencjalnie zasłaniają interaktywne elementy, które otrzymują fokus.

Spełnienie oznacza, że gdy użytkownik klawiatury przechodzi klawiszem Tab przez elementy interaktywne, przynajmniej część wizualnego wskaźnika każdego elementu z fokusem jest cały czas widoczna na ekranie — nawet jeśli przyklejony element interfejsu zachodzi na jego fragment. Niespełnienie ma miejsce, gdy element z fokusem jest całkowicie ukryty pod warstwą stworzoną przez autora, co oznacza, że użytkownik nie ma żadnej wizualnej wskazówki, gdzie aktualnie znajduje się fokus. Treści renderowane przez przeglądarkę, takie jak własny pasek narzędzi przeglądarki, nie są uznawane za treści stworzone przez autora i dlatego są wyłączone z zakresu tego kryterium. Podobnie, treści, które użytkownik sam przemieścił (np. panel przeciągany przez użytkownika), są również wyłączone.

Kryterium to ma zastosowanie do wszystkich interaktywnych elementów HTML, które domyślnie mogą otrzymać fokus z klawiatury lub zostały do tego przystosowane za pomocą tabindex, w tym <a>, <button>, <input>, <select>, <textarea> oraz elementów z tabindex='0' lub dodatnimi wartościami tabindex.

Dlaczego To Ma Znaczenie

Nawigacja klawiaturą jest fundamentalna dla dostępności dla wielu grup użytkowników. Osoby z niepełnosprawnościami ruchowymi, które nie mogą używać myszy, polegają wyłącznie na klawiaturach, urządzeniach przełącznikowych lub sterownikach typu sip-and-puff, aby poruszać się po stronie internetowej. Osoby niewidome używają czytników ekranu w połączeniu z klawiaturą. Osoby słabowidzące, które korzystają z nawigacji klawiaturą bez czytnika ekranu, w dużym stopniu polegają na widocznym wskaźniku fokusu, aby zrozumieć, gdzie się znajdują. Gdy element z fokusem jest ukryty za przyklejonym nagłówkiem lub pływającym widżetem, użytkownicy ci są de facto zagubieni — muszą wielokrotnie naciskać Tab, zgadywać swoje położenie lub całkowicie porzucić zadanie.

Rozważmy konkretny scenariusz z życia: użytkownik poruszający się na wózku, z ograniczoną sprawnością rąk, wypełnia formularz rezerwacji lotu na stronie tureckich linii lotniczych. Używa klawisza Tab, aby przechodzić przez pola formularza. Strona ma przyklejony baner zgody na pliki cookie na dole obszaru widoku. Gdy użytkownik przechodzi Tabem do ostatniego pola wyboru potwierdzenia, pole to jest renderowane całkowicie pod banerem cookie. Użytkownik nie ma żadnej wizualnej wskazówki, że pole wyboru ma fokus. Nie może stwierdzić, czy naciśnięcie Tab zadziałało, czy musi nacisnąć Tab ponownie, ani czy pole wyboru jest w ogóle wymagane. To zamieszanie może prowadzić do porzucenia formularza, nieudanych wysyłek lub powtarzających się naciśnięć klawiszy powodujących niezamierzone działania.

Wpływ wykracza poza osoby z niepełnosprawnościami. Zaawansowani użytkownicy, którzy preferują nawigację klawiaturą ze względu na szybkość — deweloperzy, osoby wprowadzające dane i biegli użytkownicy — również korzystają z wyraźnej widoczności fokusu. Według Światowej Organizacji Zdrowia około 1,3 miliarda ludzi na świecie żyje z jakąś formą niepełnosprawności, a znacząca część z nich polega na technologiach asystujących lub nawigacji klawiaturą. W samej Turcji, według Tureckiego Instytutu Statystycznego (TÜİK), około 12,7% populacji ma jakąś formę niepełnosprawności, co przekłada się na około 10 milionów osób, które mogą bezpośrednio skorzystać z lepszego zarządzania fokusem na platformach cyfrowych.

Z perspektywy biznesowej zasłonięte wskaźniki fokusu zwiększają wskaźniki porzucania zadań, obniżają konwersję i narażają organizacje na ryzyko prawne i regulacyjne. Strony, które nie spełniają tego kryterium, prawdopodobnie nie przejdą również audytów dostępności wymaganych przez prawo tureckie, co zagraża ich zdolności do uzyskania lub utrzymania oficjalnego Erişilebilirlik Logosu (Logotypu Dostępności).

Powiązane Zasady Axe-core

WCAG 2.4.11 jest sklasyfikowane w axe-core jako wymagające testów manualnych. Nie istnieje zautomatyzowana reguła axe-core, która bezpośrednio wykrywa to naruszenie. Zrozumienie, dlaczego narzędzia automatyczne nie mogą wiarygodnie oznaczać tego problemu, pomaga zespołom budować lepsze procesy testów manualnych.

• Wymagane testy manualne — fokus zasłonięty przez pozycjonowanie fixed: Narzędzia automatyczne nie są w stanie wykryć, czy element z fokusem jest wizualnie zasłonięty, ponieważ wymaga to wyrenderowania strony, obliczenia prostokątów ograniczających wszystkich elementów fixed lub sticky w czasie rzeczywistym i porównania ich z prostokątem ograniczającym aktualnie fokusowany element w momencie nadania fokusu. Wymiary obszaru widoku, pozycja przewinięcia i dynamiczny stan strony (np. czy baner cookie został już zamknięty) wpływają na wynik. Żadna analiza statyczna ani inspekcja DOM nie jest w stanie wiarygodnie odtworzyć tego obliczenia wizualnego we wszystkich możliwych stanach. Axe-core oznacza to kryterium jako manualne, ponieważ wymaga ono testera — człowieka lub zaawansowanego narzędzia do regresji wizualnej — który faktycznie przejdzie Tabem przez stronę i zaobserwuje, czy komponenty z fokusem znikają za nakładającymi się warstwami.
• Wymagane testy manualne — dynamiczne treści nakładek: Wiele elementów zasłaniających jest wstrzykiwanych dynamicznie za pomocą JavaScript po początkowym załadowaniu strony — widżety czatu firm trzecich, banery zgodności z RODO, wyskakujące promocje i pływające menu nawigacyjne. Automatyczne skanery, które analizują początkowy zrzut DOM, mogą w ogóle nie wychwycić tych elementów lub uchwycić je w stanie zwiniętym lub ukrytym, który nie odzwierciedla rzeczywistego doświadczenia użytkownika. Testy manualne wykonywane przez użytkownika klawiatury, który wchodzi w interakcję ze stroną w jej w pełni wyrenderowanym, dynamicznym stanie, są jedynym wiarygodnym sposobem wykrycia tych scenariuszy.

Jak Testować

1. Najpierw uruchom automatyczny skan dostępności. Użyj axe DevTools (rozszerzenie przeglądarki), Lighthouse w Chrome DevTools lub skanu axe-core zintegrowanego z CI, aby zidentyfikować wszelkie automatycznie wykrywalne problemy na stronie. Choć samo 2.4.11 wymaga weryfikacji manualnej, skan automatyczny może ujawnić powiązane problemy, takie jak brak wskaźników fokusu (2.4.7) lub nieprawidłowe nakładanie się z-index sugerujące nachodzące na siebie elementy. Zanotuj wszystkie elementy oznaczone jako potencjalnie problematyczne przed rozpoczęciem testów manualnych.
2. Zidentyfikuj wszystkie elementy fixed i sticky na stronie. Otwórz DevTools przeglądarki i sprawdź CSS strony. Wyszukaj elementy używające position: fixed lub position: sticky. Sprawdź także elementy z wysokimi wartościami z-index (np. 100 lub wyżej). Udokumentuj każdy z tych elementów — nagłówki, stopki, banery, widżety czatu, komunikaty o cookie — ponieważ to one najczęściej zasłaniają komponenty z fokusem. Zmień rozmiar okna przeglądarki, aby zasymulować różne rozmiary obszaru widoku, w tym szerokości tabletów i urządzeń mobilnych, ponieważ elementy sticky/fixed często zachowują się inaczej w zależności od breakpointów.
3. Wykonaj pełne przejście Tabem przez stronę. Kliknij poza jakimkolwiek elementem interaktywnym, aby upewnić się, że fokus zaczyna się od góry strony, a następnie wielokrotnie naciskaj Tab, aby przejść przez każdy element mogący otrzymać fokus. Uważnie obserwuj każdy element w momencie, gdy otrzymuje fokus. Zwróć szczególną uwagę na elementy pojawiające się blisko górnej lub dolnej krawędzi obszaru widoku, gdzie przyklejone nagłówki lub stopki najczęściej nachodzą na treść. Jeśli w którymkolwiek momencie widoczny pierścień fokusu lub wyróżniony element całkowicie znika za warstwą fixed, jest to niespełnienie 2.4.11. Użyj także Shift+Tab, aby przechodzić wstecz, ponieważ pozycja przewinięcia i układ mogą się różnić.
4. Testuj z NVDA i Firefox. Uruchom NVDA (bezpłatny, otwartoźródłowy czytnik ekranu dla Windows) i otwórz Firefox. Włącz tryb przeglądania NVDA i używaj Tab, aby poruszać się po stronie. Choć NVDA będzie dźwiękowo ogłaszać każdy element z fokusem, obserwuj również ekran wizualnie. Zanotuj każdy element, dla którego NVDA ogłasza fokus, ale żaden wizualny wskaźnik fokusu nie jest widoczny z powodu zasłaniającej treści. To połączenie jest szeroko używane w Turcji i na świecie i stanowi kluczową parę technologii asystujących.
5. Testuj z VoiceOver i Safari na macOS/iOS. Włącz VoiceOver (Command+F5 na Macu) i używaj Tab lub gestów nawigacyjnych VoiceOver, aby przechodzić przez elementy mogące otrzymać fokus. Na iOS używaj gestów przesunięcia. Zweryfikuj, że elementy z fokusem są wizualnie obecne i nie są ukryte pod warstwami fixed interfejsu, szczególnie na urządzeniach mobilnych, gdzie paski nawigacyjne i banery cookie mogą zajmować większą część obszaru widoku.
6. Testuj z JAWS i Chrome. Uruchom JAWS (Job Access With Speech) i używaj Chrome. Przechodź Tabem przez wszystkie elementy interaktywne i monitoruj każdy moment, w którym kursor JAWS przechodzi do elementu, który jest wizualnie ukryty pod warstwą fixed. JAWS jest szeroko używany w środowiskach korporacyjnych i administracji publicznej, co czyni to połączenie szczególnie ważnym przy testowaniu stron sektora publicznego i korporacyjnych.
7. Testuj po interakcjach użytkownika zmieniających układ. Zamykaj banery cookie, otwieraj i zamykaj menu nawigacyjne, wywołuj powiadomienia typu toast i otwieraj widżety czatu. Po każdej zmianie stanu wykonaj ponowne przejście Tabem, aby upewnić się, że nowy układ nie wprowadza nowych przypadków zasłonięcia fokusu. Treści dynamiczne są częstym źródłem niespełnień 2.4.11, które pojawiają się dopiero po interakcji użytkownika.
8. Testuj przy różnych pozycjach przewinięcia. Przewiń do środka lub do dołu długiej strony, a następnie przechodź Tabem przez elementy w tym obszarze. Przyklejone nagłówki mogą nie zasłaniać elementów blisko góry strony, ale mogą zakrywać elementy pojawiające się przy górnej krawędzi obszaru widoku, gdy użytkownik przewinie w dół. Upewnij się, że żadna kombinacja pozycji przewinięcia i elementu z fokusem nie skutkuje całkowitym ukryciem wizualnym.

Jak Naprawić

Przyklejony nagłówek nachodzący na linki z fokusem — nieprawidłowo

<!-- Sticky header with no scroll offset accommodation -->
<header style='position: fixed; top: 0; left: 0; width: 100%; height: 60px; z-index: 1000; background: white;'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- No scroll-margin-top set; focused link at top of main scrolls under the header -->
  <a href='/section-one'>Go to Section One</a>
  <a href='/section-two'>Go to Section Two</a>
</main>

Przyklejony nagłówek nachodzący na linki z fokusem — prawidłowo

<!-- Fixed header with scroll-margin-top applied to all focusable elements -->
<header class='site-header'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top ensures the browser scrolls the element into view
       with enough clearance so the fixed header does not cover it -->
  <a href='/section-one' class='content-link'>Go to Section One</a>
  <a href='/section-two' class='content-link'>Go to Section Two</a>
</main>

<!-- In your stylesheet: -->
<!-- .site-header { position: fixed; top: 0; height: 60px; z-index: 1000; } -->
<!-- * { scroll-margin-top: 70px; } -->
<!-- The 70px (header height + 10px buffer) keeps focused elements
     visible below the fixed header when the browser auto-scrolls. -->

Baner cookie zasłaniający dolne pole formularza z fokusem — nieprawidłowo

<!-- Cookie banner fixed at bottom with no accommodation for form fields above it -->
<div id='cookie-banner' class='cookie-overlay'>
  <p>We use cookies. <button>Accept</button></p>
</div>

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <!-- This checkbox renders in the viewport area covered by the cookie banner -->
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Baner cookie zasłaniający dolne pole formularza z fokusem — prawidłowo

<!-- Cookie banner pushes page content up instead of overlapping it -->
<div id='cookie-banner' class='cookie-banner-flow'>
  <p>We use cookies. <button id='accept-cookies'>Accept</button></p>
</div>

<!-- In your stylesheet: -->
<!-- .cookie-banner-flow { position: static; } instead of position: fixed -->
<!-- Alternatively, if fixed positioning is required for design reasons,
     add scroll-margin-bottom to all focusable elements equal to the
     banner height, or apply padding-bottom to <body> equal to
     the banner height so content is never hidden beneath it. -->

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Widżet czatu firmy trzeciej nachodzący na przycisk z fokusem — nieprawidłowo

<!-- Third-party chat widget injected in bottom-right corner
     with a high z-index, obscuring the focused Submit button -->
<div id='chat-widget' class='chat-fixed'>
  <!-- Injected by third-party script, covers 120x120px in bottom-right -->
</div>

<section class='cta-section'>
  <!-- Button positioned in the bottom-right area of the layout;
       when focused, it is completely hidden beneath the chat widget -->
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

Widżet czatu firmy trzeciej nachodzący na przycisk z fokusem — prawidłowo

<!-- Approach 1: Reposition the chat widget to avoid overlapping focusable content -->
<div id='chat-widget' class='chat-fixed-adjusted'>
  <!-- Widget repositioned to bottom-left, away from the CTA button -->
</div>

<!-- Approach 2: Ensure the button has scroll-margin that keeps it
     clear of the widget when focused -->
<section class='cta-section'>
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

<!-- Approach 3: Use JavaScript to detect focus events on elements
     near the widget's bounding box and temporarily collapse or
     move the widget so the focused element is visible. -->
<script>
  // Example: collapse widget when nearby element gains focus
  document.querySelectorAll('.cta-button').forEach(function(btn) {
    btn.addEventListener('focus', function() {
      var widget = document.getElementById('chat-widget');
      if (widget) widget.setAttribute('aria-hidden', 'false');
      // Additional logic to reposition or minimize widget
    });
  });
</script>

Typowe Błędy

• Stosowanie position: fixed do nagłówków i stopek bez dodania scroll-margin-top lub scroll-margin-bottom do elementów mogących otrzymać fokus. Natywne przewijanie fokusu przez przeglądarkę nie uwzględnia nakładających się elementów fixed, więc elementy z fokusem przewijają się do góry lub dołu obszaru widoku i kończą ukryte za warstwą fixed. Globalna reguła CSS, taka jak * { scroll-margin-top: [header-height]px; }, rozwiązuje to efektywnie.
• Ustawienie body { padding-top: 60px; } w celu skompensowania nagłówka fixed, ale bez dodania równoważnego scroll-margin-top dla fokusu klawiatury. Padding zapewnia, że treść nie jest początkowo ukryta, ale gdy fokus klawiatury wywołuje automatyczne przewijanie przez przeglądarkę, cel przewijania może nadal znaleźć się pod nagłówkiem. Oba podejścia muszą być stosowane razem.
• Używanie z-index: 9999 na banerach promocyjnych lub widżetach czatu bez audytu, które elementy mogące otrzymać fokus znajdują się w ich obszarze. Wysoki z-index gwarantuje, że nakładka renderuje się ponad wszystkim, w tym nad przyciskami i linkami z fokusem, co czyni to najczęstszą przyczyną niespełnień 2.4.11.
• Zamykanie banerów cookie za pomocą JavaScript bez natychmiastowego usunięcia ich z układu. Jeśli element DOM banera pozostaje z visibility: hidden lub opacity: 0, ale nadal zajmuje miejsce lub ma niezerowy z-index, może nadal wizualnie zasłaniać elementy z fokusem w niektórych scenariuszach renderowania przeglądarki.
• Osadzanie widżetów firm trzecich (czat na żywo, nakładki dostępności, menedżery RODO) bez weryfikacji ich wpływu na widoczność fokusu klawiatury. Skrypty firm trzecich często wstrzykują elementy o położeniu fixed z bardzo wysokimi wartościami z-index. Zespoły muszą testować te integracje wprost w ramach procesu QA dostępności.
• Brak testowania 2.4.11 po zmianach breakpointów responsywnych. Pasek nawigacyjny sticky, który ma 60px wysokości na desktopie, może rozszerzyć się do 120px na tablecie po otwarciu menu hamburgerowego, nagle zasłaniając znacznie większy obszar i tworząc nowe niespełnienia na breakpointach, które przechodziły testy na desktopie.
• Stosowanie scroll-margin-top tylko do celów kotwic (<h2>, <section>), ale nie do elementów interaktywnych, takich jak <input>, <button> i <a>. Offset przewijania dla kotwic jest często uwzględniany, ale automatyczne przewijanie fokusu klawiatury do elementów niebędących kotwicami jest tak samo dotknięte i musi być objęte tą samą regułą CSS.
• Założenie, że skoro element z fokusem jest ogłaszany przez czytnik ekranu, to jest również wizualnie widoczny. Czytniki ekranu korzystają z drzewa dostępności, a nie z renderowania wizualnego. Element może być całkowicie ukryty za nakładką fixed, a mimo to być poprawnie ogłaszany przez NVDA lub JAWS. Są to dwa odrębne zagadnienia — 2.4.11 dotyczy konkretnie widoczności fokusu wizualnego dla widzących użytkowników klawiatury.
• Zaniedbywanie testowania zasłonięcia fokusu po zmianach tras w aplikacjach typu single-page (SPA). W aplikacjach React, Vue lub Angular przejścia między trasami często ponownie renderują nagłówki fixed z zaktualizowanym stanem, a zarządzanie fokusem podczas nawigacji może umieścić fokus na elementach, które są natychmiast zasłonięte przez ponownie zamontowany nagłówek sticky, zanim użytkownik zobaczy nową stronę.
• Poleganie wyłącznie na narzędziach testów automatycznych i wnioskowanie, że nie ma problemów 2.4.11, ponieważ żadna reguła automatyczna nie oznaczyła strony. Ponieważ axe-core nie ma zautomatyzowanej reguły dla tego kryterium, czysty raport automatyczny nie oznacza, że strona je spełnia. Manualne przejście klawiaturą przez wszystkie rozmiary obszaru widoku i stany strony jest obowiązkowe.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

WCAG 2.4.11 Focus Not Obscured (Minimum) ma bezpośrednie znaczenie dla rozwijających się ram prawnych dotyczących dostępności w Turcji. Okrężnik Prezydencki Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dotyczące dostępności cyfrowej, które są zgodne z WCAG 2.2. Okrężnik ten stanowi istotne rozszerzenie zaangażowania Turcji w inkluzję cyfrową i nakłada egzekwowalne obowiązki na szeroką gamę podmiotów działających na tureckim rynku cyfrowym.

Okrężnik obejmuje szeroki zakres organizacji, w tym instytucje publiczne i agencje rządowe, platformy e-commerce, banki i dostawców usług finansowych, szpitale i organizacje opieki zdrowotnej, firmy telekomunikacyjne z ponad 200 000 abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE). Od wszystkich tych podmiotów oczekuje się, że zapewnią, aby ich interfejsy cyfrowe — strony internetowe, aplikacje mobilne i narzędzia webowe — były zgodne z poziomem AA WCAG 2.2.

Ponieważ WCAG 2.4.11 jest kryterium na poziomie AA w WCAG 2.2, zgodność z tą zasadą nie jest opcjonalna dla objętych podmiotów. Organizacje dążące do uzyskania lub utrzymania oficjalnego Erişilebilirlik Logosu (Logotypu Dostępności), wydawanego przez Ministerstwo Rodziny i Usług Społecznych (Aile ve Sosyal Hizmetler Bakanlığı), muszą spełniać wymagania zgodności na poziomie AA. Logotyp Dostępności służy jako publiczny sygnał zaangażowania w inkluzję cyfrową i jest coraz częściej oczekiwany przez tureckich konsumentów oraz organy zamówień publicznych.

W praktyce oznacza to, że strony internetowe tureckich instytucji publicznych z przyklejonymi nagłówkami nawigacyjnymi, serwisy e-commerce z trwałymi banerami promocyjnymi, portale bankowe z pływającymi widżetami pomocy oraz systemy rezerwacji wizyt medycznych z nakładkami zgody na pliki cookie muszą być testowane i poprawiane pod kątem zasłonięcia fokusu zgodnie z 2.4.11. Niespełnienia tego kryterium są szczególnie prawdopodobne w złożonych, silnie marketingowych interfejsach — dokładnie tego typu serwisach, które prowadzą duże podmioty komercyjne objęte okrężnikiem.

Organizacje działające w ramach okrężnika powinny włączyć testowanie 2.4.11 do swoich regularnych cykli audytów dostępności. Biorąc pod uwagę, że kryterium to wymaga testów manualnych, poleganie wyłącznie na skanowaniu automatycznym nie spełni obowiązków należytej staranności. Tureckim podmiotom dążącym do pełnej zgodności zaleca się przeprowadzanie manualnych testów przejścia klawiaturą we wszystkich rozmiarach obszaru widoku i dynamicznych stanach strony jako części dokumentacji zgodności oraz usuwanie wszelkich zidentyfikowanych problemów z zasłonięciem fokusu w ramach planu naprawczego przed złożeniem wniosku o logotyp dostępności lub jego odnowienie.