Najważniejsze wnioski
- WCAG 2.4.11 na poziomie AA wymaga, aby element otrzymujący fokus nie był całkowicie zasłonięty przez treść utworzoną przez autora strony.
- Widoczny focus ring nie wystarcza, gdy sam przycisk, link lub pole formularza znajduje się pod sticky headerem, stopką albo banerem cookies.
- Najprostsza poprawka dla stałych elementów zasłaniających treść to zwykle CSS scroll-padding dopasowany do rzeczywistej wysokości nagłówka i stopki.
- Banery, czaty i dialogi trzeba testować także po otwarciu, zamknięciu, zmianie szerokości ekranu, powiększeniu tekstu oraz podczas przechodzenia klawiszami Tab i Shift+Tab.
- Widget dostępności może wspierać użytkownika funkcjami skupienia i nawigacji, ale nie zastępuje źródłowej naprawy układu, który zasłania elementy z fokusem.
Dla zarządzającego
Problem z zasłoniętym fokusem blokuje obsługę strony klawiaturą w kluczowych ścieżkach, takich jak wyszukiwanie, koszyk, logowanie i płatność. Warto potraktować go jako element jakości produktu: poprawka zwykle wymaga decyzji dotyczącej sticky elementów, banerów i komponentów zewnętrznych, a następnie testów na rzeczywistych widokach.
Dla sprzedaży
Jeżeli klient nie może zobaczyć aktywnego pola, przycisku lub linku, może nie wiedzieć, gdzie znajduje się w procesie zakupu. W rozmowie o dostępności warto rozróżnić szybkie funkcje wspierające użytkownika od koniecznych zmian w kodzie źródłowym, na przykład w zachowaniu nagłówka, banera cookies lub czatu.
WCAG 2.4.11 Focus Not Obscured (Minimum) dotyczy sytuacji, w której osoba poruszająca się po stronie klawiaturą przechodzi do linku, przycisku lub pola formularza, ale aktywny element znika pod przyklejoną warstwą interfejsu. Jeżeli komponent z fokusem jest całkowicie ukryty przez nagłówek, stopkę, baner lub niepoprawnie działający dialog, strona nie spełnia tego kryterium na poziomie AA.
To problem częsty w sklepach internetowych, serwisach usługowych i panelach klienta. Występuje zwłaszcza tam, gdzie interfejs ma sticky header, pływające CTA, baner cookies, komunikat promocyjny, czat albo przyklejone podsumowanie koszyka.
Najważniejsze wnioski
- Test 2.4.11 wykonuje się przede wszystkim klawiaturą, obserwując, czy element otrzymujący fokus pozostaje widoczny w viewportcie.
- Kryterium ocenia komponent, a nie wyłącznie jego obramowanie. Widoczny fragment focus ringa nie pomaga, jeśli cały przycisk lub input znajduje się pod nakładką.
- Częściowe zasłonięcie może przejść poziom AA, ale nadal jest ryzykiem użyteczności. Dobra praktyka to pozostawienie całego komponentu w widoku.
- Najczęściej potrzebna jest naprawa źródłowa w CSS, JavaScripcie lub architekturze komponentu.
- Funkcje wspierające dostępność, takie jak większy kursor, podświetlanie skupienia czy narzędzia typograficzne, mogą poprawić komfort korzystania ze strony, ale nie naprawią layoutu zasłaniającego fokus.
Czym jest WCAG 2.4.11 Focus Not Obscured?
Kryterium sukcesu 2.4.11 Focus Not Obscured (Minimum) należy do WCAG 2.2 i ma poziom AA. Wymaga, aby komponent, który otrzymuje fokus klawiatury, nie był całkowicie zasłonięty przez treść stworzoną przez autora strony.
W praktyce komponentem może być między innymi link, przycisk, checkbox, element menu, pole formularza, kontrolka galerii, przycisk zamknięcia komunikatu lub element interaktywny w koszyku.
Nie każdy element stale widoczny na ekranie jest problemem. Sam przyklejony nagłówek nie narusza WCAG. Problem zaczyna się wtedy, gdy podczas nawigacji klawiszem Tab przeglądarka doprowadza fokus do elementu znajdującego się pod nagłówkiem, a użytkownik nie widzi już aktywnego komponentu.
Dostępny fokus to nie tylko kolorowa ramka. Użytkownik musi jeszcze widzieć element, z którym ma wykonać kolejną czynność.
Jak odróżnić 2.4.11 od innych kryteriów fokusu?
Problemy związane z fokusem często są wrzucane do jednego worka. To utrudnia właściwe zaplanowanie poprawki. Kryterium 2.4.11 nie zastępuje wymagań dotyczących widoczności ani wyglądu wskaźnika fokusu.
| Kryterium | Główne pytanie testowe | Przykładowy problem | Typowa poprawka |
|---|---|---|---|
| 2.4.7 Focus Visible | Czy wiadomo, który element ma fokus? | Brak stylu :focus lub niewidoczny wskaźnik. | Widoczny styl :focus-visible. |
| 2.4.11 Focus Not Obscured (Minimum) | Czy komponent z fokusem nie jest całkowicie ukryty? | Przycisk znajduje się pod sticky headerem. | scroll-padding, zmiana sticky layoutu lub zachowania komponentu. |
| 2.4.12 Focus Not Obscured (Enhanced) | Czy żadna część komponentu nie jest zasłonięta? | Dolna część pola input znika pod stopką. | Pełne odsunięcie obszaru przewijania od warstw stałych. |
| 2.4.13 Focus Appearance | Czy wskaźnik fokusu ma odpowiedni rozmiar i kontrast? | Cienka ramka zlewa się z tłem. | Zmiana stylu, kontrastu i obszaru wskaźnika. |
Jeżeli chcesz uporządkować różnicę między widocznym focusem a zasłoniętym komponentem, przeczytaj także poradnik WCAG 2.4.7 Focus Visible oraz materiał o WCAG 2.4.13 Focus Appearance.
Gdzie najczęściej pojawia się zasłonięty fokus?
Sticky header i pasek promocyjny
Nawigacja przyklejona do górnej krawędzi ekranu jest popularna w e-commerce. Może jednak zasłonić linki, filtry, pola wyszukiwarki albo nagłówki z linkami, gdy przeglądarka przewija stronę do aktywnego elementu. Ryzyko rośnie, gdy nad menu pojawia się dodatkowy pasek informacyjny lub nagłówek zmienia wysokość po rozwinięciu menu.
Focus Not Obscured: poprawny i błędny widok
Sticky footer i podsumowanie zamówienia
Przyklejony przycisk „Przejdź do kasy”, pasek zgody lub podsumowanie koszyka może przykrywać elementy na dole widoku. Warto sprawdzić nie tylko przejście klawiszem Tab do przodu, lecz także powrót z użyciem Shift+Tab.
Baner cookies
Baner cookies może zostać wyświetlony przy dolnej krawędzi, ale nie powinien pozostawiać fokusu na elementach, których użytkownik nie może zobaczyć ani obsłużyć. W zależności od projektu właściwe może być zastosowanie prawdziwego dialogu modalnego, odsunięcie obszaru przewijania albo zamykanie powiadomienia w określonym momencie interakcji. Decyzja zależy od funkcji i sposobu wyświetlania banera.
Widget czatu i nie-modalne okna
Otwarty czat albo panel pomocy może przykryć treść strony. Jeżeli fokus nadal przechodzi do linków i przycisków pod tym panelem, użytkownik może stracić orientację. Dialog modalny powinien przejąć fokus, zapewniać przewidywalne zamknięcie i nie pozwalać na przypadkowe przechodzenie po zasłoniętej treści.
Jak wdrożyć poprawkę dla sticky headera?
Najczęściej stosowanym rozwiązaniem jest zarezerwowanie przestrzeni przewijania dla elementów przyklejonych do początku lub końca viewportu. W CSS służy do tego między innymi scroll-padding.
:root {
--header-offset: 5rem;
--footer-offset: 4rem;
}
html {
scroll-padding-block-start: var(--header-offset);
scroll-padding-block-end: var(--footer-offset);
}
Wartości w przykładzie nie są wymogiem WCAG. Muszą odpowiadać rzeczywistej wysokości elementów, które mogą zasłonić treść. Stała wartość bywa niewystarczająca, gdy nagłówek zmienia wysokość na różnych breakpointach, po zmianie języka, przy powiększeniu tekstu albo po rozwinięciu menu.
Jeżeli wysokość jest dynamiczna, można aktualizować zmienną CSS na podstawie realnego rozmiaru nagłówka:
const header = document.querySelector('.site-header');
function updateHeaderOffset() {
const height = header.getBoundingClientRect().height;
document.documentElement.style.setProperty('--header-offset', `${height}px`);
}
const observer = new ResizeObserver(updateHeaderOffset);
observer.observe(header);
updateHeaderOffset();
To rozwiązanie trzeba przetestować po zmianie rozmiaru viewportu, zmianie orientacji urządzenia oraz w sytuacji, gdy nagłówek jest czasowo wyższy. Jeżeli kod strony korzysta z restrykcyjnej polityki bezpieczeństwa, uwzględnij też zasady opisane w poradniku CSP: jak wdrożyć Content Security Policy.
Kiedy lepiej zmienić projekt zamiast dodawać offset?
scroll-padding jest użyteczne, ale nie rozwiązuje każdego przypadku. Rozważ zmianę komponentu, gdy:
- sticky header zajmuje zbyt dużą część małego viewportu;
- baner dynamicznie zmienia wysokość i nie da się wiarygodnie przewidzieć jego wymiaru;
- widget zewnętrzny zasłania najważniejsze kontrolki sklepu;
- dialog wygląda jak modalny, lecz technicznie nim nie jest;
- na urządzeniach mobilnych klawiatura ekranowa dodatkowo ogranicza dostępny obszar.
W niektórych projektach lepszym wyborem będzie rezygnacja z przyklejenia na małych ekranach, przeniesienie paska do zwykłego przepływu dokumentu albo zastosowanie poprawnego dialogu modalnego.
WCAGbot Accessibility Path: jak przejść od wykrycia do retestu?
- Wybierz ścieżkę krytyczną. Dla sklepu będzie to na przykład wyszukiwanie produktu, lista produktów, karta produktu, koszyk, logowanie i płatność.
- Przejdź ścieżkę klawiszami Tab i Shift+Tab. Nie używaj myszy do ustawiania fokusu między krokami.
- Zanotuj warstwę zasłaniającą. Określ, czy problem powoduje header, footer, baner, chat, menu czy komponent zewnętrzny.
- Wybierz rodzaj naprawy. Użyj offsetu przewijania, zmień pozycjonowanie, popraw zarządzanie fokusem albo przeprojektuj dialog.
- Sprawdź widoki skrajne. Testuj małą szerokość, małą wysokość, powiększony tekst, otwarte menu i aktywny baner.
- Wykonaj retest. Sprawdź tę samą ścieżkę od początku, również wstecz klawiszem Shift+Tab.
- Włącz problem do audytu. Jeśli podobny wzorzec występuje w wielu szablonach, napraw komponent współdzielony i zweryfikuj wszystkie jego użycia.
WCAGbot Accessibility Path dla zasłoniętego fokusu
Mini-scenariusz: zasłonięty przycisk w koszyku
Scenariusz ilustracyjny: sklep ma przyklejony pasek na dole ekranu z kwotą zamówienia i przyciskiem przejścia do kasy. Użytkownik przechodzi klawiszem Tab przez pole kodu rabatowego, przycisk „Zastosuj” i linki dotyczące dostawy. Gdy fokus trafia do linku umieszczonego przy dolnej granicy widoku, pasek podsumowania całkowicie go przykrywa.
Właściwy proces naprawy wygląda następująco:
- zespół sprawdza, czy dolny pasek musi pozostać sticky na każdym widoku;
- jeśli tak, dodaje offset przewijania odpowiadający aktualnej wysokości paska;
- testuje wariant z dłuższą treścią, większym tekstem i inną szerokością ekranu;
- sprawdza fokus na kontrolkach formularza, w tym komunikatach błędów;
- ponownie przechodzi całą ścieżkę koszyka klawiaturą.
W przypadku formularzy nie wystarczy upewnić się, że pole jest częściowo widoczne. Użytkownik powinien móc zobaczyć aktywne pole, jego etykietę oraz istotny komunikat. Więcej praktycznych wskazówek zawiera artykuł Dostępny formularz: jak projektować i testować zgodnie z WCAG.
Jak testować Focus Not Obscured?
Podstawowy test nie wymaga specjalistycznego narzędzia automatycznego. Potrzebujesz przeglądarki, klawiatury oraz listy reprezentatywnych widoków strony.
Checklista testu ręcznego
- Otwórz stronę bez ustawiania fokusu myszą.
- Używaj klawisza Tab, aby przechodzić po elementach interaktywnych.
- Używaj Shift+Tab, aby sprawdzić nawigację wstecz.
- Obserwuj, czy aktywny komponent jest całkowicie widoczny, a nie tylko czy pojawia się obramowanie.
- Otwórz menu, baner cookies, czat, filtr produktów i inne warstwy nakładane na treść.
- Sprawdź widoki z małą wysokością okna oraz widok mobilny.
- Powiększ tekst lub zmień skalę strony, jeśli interfejs może przez to zmienić wysokość.
- Przetestuj formularze, koszyk i płatność jako osobne ścieżki.
Test klawiaturą warto łączyć z oceną semantyki HTML i zachowania komponentów. Pomogą w tym materiały: Nawigacja klawiaturą: jak testować stronę, HTML semantyczny oraz ARIA: praktyczny poradnik wdrożenia i testowania.
Co może zrobić widget dostępności, a czego nie zrobi?
WCAGbot może być szybkim pierwszym krokiem do dostępności cyfrowej. Po dodaniu jednej linii kodu udostępnia między innymi funkcje wspierające czytelność, kontrast, powiększenie tekstu, większy kursor, skupienie i przewodnik do czytania. Użytkownik może dopasować sposób korzystania ze strony do swoich potrzeb.
Widget nie powinien jednak być traktowany jako zamiennik naprawy źródłowej. Jeżeli sticky header, baner cookies lub komponent czatu całkowicie przykrywa aktywny element, problem wymaga poprawy w kodzie strony albo konfiguracji danego komponentu. Tego rodzaju usterkę należy uwzględnić w audycie i backlogu technicznym.
Przed decyzją o zakresie działań przeczytaj: Widget WCAG: co pomaga, a czego nie naprawi, jak wybrać zakres audytu WCAG oraz WCAG dla e-commerce.
Doświadczeniowe CTA: otwórz panel WCAGbot na własnej stronie testowej i sprawdź, jak zmiana kontrastu, powiększenie tekstu oraz funkcje skupienia wpływają na komfort obsługi. Następnie wykonaj osobny test Tab, aby potwierdzić, że elementy z fokusem nie są zasłaniane przez układ strony.
Podsumowanie dla zespołu
WCAG 2.4.11 Focus Not Obscured to kryterium dotyczące realnej orientacji użytkownika podczas obsługi klawiaturą. Nie wystarczy dodać wyraźnego stylu fokusu. Trzeba sprawdzić, czy użytkownik widzi aktywny link, przycisk albo formularz w obecności wszystkich warstw interfejsu.
Kontrola fokusu w koszyku sklepu
Najlepsze efekty daje testowanie krytycznych ścieżek, naprawa współdzielonych komponentów oraz retest na różnych rozmiarach viewportu. W sklepie internetowym szczególnego sprawdzenia wymagają filtr produktów, koszyk, kod rabatowy, logowanie, adres dostawy i przejście do płatności.
Dodaj funkcje dostępności i przetestuj WCAGbot jako wsparcie dla użytkowników, równolegle planując audyt i naprawę źródłową barier w interfejsie.
FAQ: WCAG 2.4.11 Focus Not Obscured
Czy WCAG 2.4.11 wymaga, aby cały element z fokusem był widoczny?
Na poziomie AA kryterium 2.4.11 wymaga, aby komponent nie był całkowicie zasłonięty. Częściowe zasłonięcie może spełniać minimum, ale nadal może utrudniać korzystanie ze strony. Pełny brak zasłonięcia jest wymagany przez kryterium 2.4.12 na poziomie AAA.
Czy sticky header jest niezgodny z WCAG?
Nie. Przyklejony nagłówek sam w sobie nie jest błędem. Staje się problemem wtedy, gdy całkowicie zakrywa komponent, do którego przechodzi fokus klawiatury.
Czy wystarczy dodać styl :focus-visible?
Nie. Styl :focus-visible pomaga spełnić wymagania dotyczące rozpoznawalności fokusu, ale nie rozwiązuje sytuacji, w której komponent znajduje się pod nagłówkiem, stopką lub inną nakładką.
Czy focus ring jest tym samym co komponent z fokusem?
Nie. Focus ring to wizualny wskaźnik aktywnego elementu. Kryterium 2.4.11 koncentruje się na widoczności samego komponentu. Brak widocznego wskaźnika może jednocześnie powodować problem z 2.4.7 Focus Visible.
Jak sprawdzić Focus Not Obscured bez automatycznego testera?
Przejdź przez interaktywną zawartość klawiszami Tab i Shift+Tab. Podczas testu otwieraj menu, banery, czaty oraz inne nakładki. Obserwuj, czy element z fokusem nie znika całkowicie za żadną warstwą.
Czy scroll-padding rozwiązuje każdy problem z zasłoniętym fokusem?
Nie. Jest dobrym rozwiązaniem dla przewidywalnych elementów sticky, ale nie zastąpi poprawnego zarządzania fokusem w dialogu modalnym ani zmiany projektu, gdy przyklejony komponent zajmuje zbyt dużą część ekranu.
Jak poprawić baner cookies zasłaniający fokus?
Najpierw ustal, czy baner powinien działać jak dialog modalny. Jeżeli nie, zapewnij, że fokus nie przechodzi do całkowicie zasłoniętej treści, a obszar przewijania uwzględnia wysokość banera. Koniecznie testuj także zamykanie banera klawiaturą.
Czy widget czatu może powodować naruszenie 2.4.11?
Tak. Otwarty widget czatu może zasłonić elementy strony. Jeśli fokus nadal przechodzi do zakrytych kontrolek w tle, należy zmienić zachowanie widżetu, sposób zarządzania fokusem albo pozycję komponentu.
Czy WCAGbot naprawia zasłonięty fokus przez sticky header?
Nie należy zakładać, że widget naprawi problem układu strony. WCAGbot wspiera dostępność funkcjami ułatwiającymi czytanie i orientację, ale zasłanianie elementów przez header, stopkę lub baner wymaga weryfikacji i naprawy źródłowej.
Czy należy testować 2.4.11 na urządzeniach mobilnych?
Tak. Na małym ekranie sticky elementy zajmują proporcjonalnie większą część viewportu, a zmiana orientacji, wysokość klawiatury ekranowej i powiększenie tekstu mogą ujawnić problemy niewidoczne na desktopie.
Czy problem z Focus Not Obscured powinien trafić do audytu WCAG?
Tak, szczególnie gdy występuje w komponentach używanych w wielu szablonach. Audyt pomaga określić skalę problemu, jego wpływ na ścieżki użytkownika oraz zależności z innymi kryteriami, takimi jak Focus Visible, Focus Appearance, struktura HTML i dostępność formularzy.
