Baner cookies to często pierwsza rzecz, którą trzeba „obsłużyć” na stronie. Naukowcy z University of Surrey i Royal Holloway sprawdzili automatycznie, z czytnikiem ekranu NVDA, 2061 stron i znalezione na nich 1058 banerów. Prawie każdy baner da się odczytać, ale tylko 37% ma nagłówek, 39% jest ogłaszanych od razu, a 42% ma przyciski, z których wiadomo, na co się zgadzamy. Co gorsza, banery łamiące przepisy o zgodzie wypadały też gorzej pod względem dostępności.

O jakie badanie chodzi

Praca „A Large-Scale Evaluation of Cookie Notice Privacy and Accessibility for Blind and Low Vision Users” (James M. Clarke, Maryam Mehrnezhad) ukazała się 31 października 2026 r. w serwisie arXiv. To preprint, czyli tekst, który nie przeszedł jeszcze recenzji naukowej. Warto o tym pamiętać, czytając liczby.

Jak wyglądało badanie:

  • autorzy wylosowali 3000 stron z rankingu popularności Tranco (po 1000 z trzech grup: najpopularniejsze, średnie i mniej popularne); 2061 udało się wczytać,
  • crawl trwał od 5 do 18 maja 2026 r. i był prowadzony z Wielkiej Brytanii, a zgodność oceniano według brytyjskich przepisów (UK GDPR i PECR),
  • każdą stronę otwierano w prawdziwej przeglądarce trzy razy: bez reakcji na baner, po akceptacji i po odrzuceniu,
  • dostępność oceniano narzędziami WAVE i Lighthouse oraz specjalnym dodatkiem do NVDA, który zapisywał, co czytnik ekranu faktycznie mówi.

Baner cookies wykryto na 1058 stronach (51%). Kod badania jest publiczny na GitHubie.

Najważniejsze liczby o dostępności

Autorzy ocenili banery według siedmiu kryteriów dla użytkowników czytników ekranu. Wyniki dla stron z banerem:

  • 95% banerów czytnik ekranu w ogóle odczytuje,
  • 93% da się obsłużyć klawiaturą (w uproszczonym, automatycznym teście),
  • 42% ma przyciski z opisową nazwą, np. „Akceptuj wszystkie cookies”, a nie samo „OK” czy „Zgadzam się”,
  • 39% jest ogłaszanych od razu, czyli przed banerem czytnik przeczytał najwyżej 30 słów,
  • 37% ma nagłówek, po którym użytkownik czytnika rozpozna, że to okno zgody na cookies.

W połowie stron przed pierwszym słowem związanym z cookies czytnik ekranu czytał ponad 100 słów. Mediana wyniosła 165 słów. Dla osoby niewidomej oznacza to, że często najpierw słucha menu, nagłówka i fragmentu treści, a dopiero potem dowiaduje się, że strona prosi o decyzję.

Baner znika, a z nim nawigacja

Najbardziej zaskakujący wynik dotyczy tego, co dzieje się po zamknięciu banera. Po akceptacji błąd Lighthouse „Document does not have a main landmark” (brak głównego regionu strony) pojawił się na 184 stronach więcej, a po odrzuceniu na 118 więcej. Autorzy szacują, że na mniej więcej co piątej stronie baner był jedynym elementem <main> albo go obejmował.

Skutek: po kliknięciu „Akceptuj” czy „Odrzuć” użytkownik czytnika ekranu traci skrót do głównej treści i musi przechodzić stronę element po elemencie. I to niezależnie od tego, jaką decyzję podjął.

Prywatność i dostępność idą w parze, niestety w złą stronę

Badanie łączy dostępność z ochroną prywatności. Według autorów:

  • 50% banerów nie spełnia brytyjskich wymogów zgody: 33% nie ma bezpośredniego przycisku odrzucenia, a kolejne 17% go ma, ale wizualnie wyróżnia przycisk akceptacji,
  • 35% banerów, które dają wybór, wyróżnia „Akceptuj” (np. wypełniony przycisk obok przycisku z samą ramką albo zwykłego linku),
  • po akceptacji średnia liczba zapytań do serwerów śledzących rośnie z 43,4 do 218,5 na stronę, czyli mniej więcej pięciokrotnie,
  • na 62% stron, na których udało się odrzucić cookies, zapytań śledzących i tak było więcej niż przed decyzją.

Banery niezgodne z przepisami wypadały wyraźnie gorzej w testach z czytnikiem. Opisowe nazwy przycisków miało 54% banerów zgodnych i 31% niezgodnych, a obsługę klawiaturą odpowiednio 98% i 88%. Najgorzej wypadł model „zaakceptuj albo zapłać” (25 stron): tylko 8% takich banerów miało opisowe przyciski.

Autorzy zauważają też, że popularne serwisy częściej mają opisowe przyciski (51% w grupie najpopularniejszych wobec 27% w grupie najmniej popularnych), ale ich rozbudowane platformy zgód częściej psują strukturę strony.

Uwaga na ograniczenia

Zanim przeniesiesz te liczby na polskie strony, weź pod uwagę, że:

  • to preprint, bez recenzji,
  • wszystkie testy były automatyczne; w badaniu nie brały udziału osoby niewidome, a autorzy sami piszą, że wyniki to przybliżenie, które nie oddaje realnych strategii nawigacji,
  • testowano tylko strony główne, tylko na komputerze i tylko z NVDA (bez JAWS, VoiceOver i urządzeń mobilnych),
  • kryteria są autorskie i w części surowsze niż WCAG. Na przykład przycisk „Akceptuj” bez słowa „cookies” w nazwie oblewał test, choć według WCAG 2.4.4 cel przycisku może wynikać z kontekstu,
  • próba była globalna, a ocena prawna brytyjska. To nie jest badanie polskich stron.

Kierunek wniosków jest jednak zbieżny z wcześniejszymi, mniejszymi badaniami, na które powołują się autorzy. Opisywały one m.in. brak nagłówków, opóźnione ogłaszanie banera i słabą obsługę klawiatury.

Co z tego wynika według WCAG

Większość problemów z badania da się przypisać do konkretnych kryteriów WCAG 2.2:

  • Okno zgody bez nazwy. Specyfikacja WAI-ARIA 1.2 wymaga, żeby element z rolą dialog miał dostępną nazwę (aria-labelledby lub aria-label). Bez niej czytnik nie powie, że to okno zgody (WCAG 4.1.2 Nazwa, rola, wartość; 2.4.6 Nagłówki i etykiety).
  • Baner na końcu kolejności czytania. Jeśli baner jest wstawiony na końcu kodu strony, a wizualnie wisi na dole ekranu, czytnik dojdzie do niego na końcu (WCAG 1.3.2 Zrozumiała kolejność, 2.4.3 Kolejność fokusu).
  • Baner zasłania fokus. Według objaśnień do kryterium 2.4.11 przyklejony baner cookies nie spełnia tego kryterium, jeśli całkowicie zasłania element z fokusem. W3C podpowiada dwa wyjścia: okno modalne albo scroll-padding.
  • Struktura strony po zamknięciu banera. Region <main> powinien należeć do strony, nie do banera (WCAG 1.3.1 Informacje i relacje, 2.4.1 Możliwość pominięcia bloków).
  • Etykiety niezgodne z tym, co widać. Lighthouse po zamknięciu banerów rzadziej zgłaszał błąd „widoczny tekst nie pasuje do dostępnej nazwy”, więc ten błąd często dotyczył właśnie banerów (WCAG 2.5.3 Etykieta w nazwie).

Autorzy proponują, żeby W3C dodało do WCAG technikę albo kryterium dla okien zgody. Przypominają, że w szkicu WCAG 3 jest już wytyczna 2.10 „Policy and protection”, według której użytkownik ma rozumieć konsekwencje wyborów, także tych dotyczących prywatności. O samym szkicu pisaliśmy w tekście o WCAG 3 z września 2026 r.

A co z polskim prawem?

W Polsce zasady zgody na cookies wynikają z art. 399 Prawa komunikacji elektronicznej. Wyjaśniamy je w poradniku o dostępnych banerach cookies. Badanie pokazuje, że te dwa obowiązki trzeba sprawdzać razem. Jeśli osoba z czytnikiem ekranu nie znajdzie przycisku „Odrzuć” albo nie wie, co oznacza przycisk „OK”, trudno mówić o świadomej zgodzie.

Do tego dochodzi dostępność. Baner jest częścią strony, więc jeśli serwis musi być dostępny (strona urzędu według ustawy o dostępności cyfrowej albo sklep internetowy czy bank według Polskiego Aktu o Dostępności), baner też powinien być dostępny. To nasza interpretacja, nie stanowisko organu nadzoru. Autorzy badania piszą podobnie o Europejskim Akcie o Dostępności i zauważają, że mimo jego stosowania od czerwca 2025 r. niedostępne banery są nadal powszechne.

Lista kontrolna: dostępny baner cookies

  • [ ] Baner ma rolę dialog (lub jest regionem) z dostępną nazwą, np. aria-labelledby wskazującym nagłówek „Ustawienia plików cookie”.
  • [ ] Baner jest w kodzie na początku strony, żeby czytnik ekranu przeczytał go od razu, nawet jeśli wizualnie wisi na dole.
  • [ ] Przyciski mają nazwy opisujące skutek: „Akceptuj wszystkie cookies”, „Odrzuć opcjonalne cookies”, „Ustawienia cookies”.
  • [ ] Widoczny tekst przycisku zawiera się w jego dostępnej nazwie (WCAG 2.5.3).
  • [ ] „Odrzuć” jest na pierwszym poziomie i wygląda tak samo jak „Akceptuj”.
  • [ ] Wszystko działa z klawiatury: Tab, Shift+Tab, Enter, spacja. Fokus jest widoczny i nie ucieka pod baner (WCAG 2.4.7, 2.4.11).
  • [ ] Jeśli baner jest modalny, fokus trafia do niego po otwarciu i wraca na stronę po zamknięciu.
  • [ ] Element <main> należy do strony, nie do banera, i zostaje po jego zamknięciu.
  • [ ] Skróty (RODO, CMP, IAB) są rozwinięte, a treść napisana prostym językiem.
  • [ ] Panel ustawień ma poprawnie opisane przełączniki z widocznym stanem (włączone/wyłączone).
  • [ ] Po odrzuceniu cookies nie ładują się skrypty śledzące. Sprawdź to w narzędziach deweloperskich przeglądarki, w zakładce Sieć.
  • [ ] Zgodę można później zmienić łatwo dostępnym linkiem, np. w stopce.
  • [ ] Baner przetestowano ręcznie z NVDA i VoiceOver, nie tylko skanerem. Według autorów WAVE i Lighthouse nie wychwytują większości tych problemów.

Źródła