Lista kontrolna WCAG 2.2 dla nawigacji i wyszukiwarki na stronie restauracji

Dlaczego nawigacja i wyszukiwarka wymagają osobnego audytu

Menu z daniami, koszyk zamówień czy formularz rezerwacji zwykle stają się przedmiotem audytu dostępności w pierwszej kolejności, bo to one generują transakcje. Nawigacja główna, stopka i wewnętrzna wyszukiwarka są jednak używane wcześniej, na każdej podstronie, zanim odwiedzający w ogóle dotrze do treści transakcyjnej. Jeśli osoba korzystająca wyłącznie z klawiatury utknie w menu głównym albo nie zrozumie komunikatu po nieudanym wyszukiwaniu, opuści witrynę, zanim zobaczy ofertę czy panel rezerwacji.

Wytyczne WCAG 2.2, opublikowane przez W3C, nie wprowadzają osobnej kategorii dla nawigacji witryn restauracyjnych – te same kryteria sukcesu, które stosuje się do widżetów zamawiania, dotyczą też menu rozwijanych, linków w stopce i pola wyszukiwania. Dlatego warto potraktować te elementy jako oddzielny, powtarzalny punkt kontrolny w cyklu utrzymania strony.

Rama KFB: Klawiatura, Fokus, Błąd

Poniższa rama porządkuje audyt wokół trzech filarów, które odpowiadają grupom kryteriów sukcesu WCAG 2.2 mających bezpośrednie zastosowanie do nawigacji i wyszukiwarki: Klawiatura (operowalność), Fokus (kolejność i widoczność) oraz Błąd (identyfikacja i pomoc). Każdy filar da się przetestować bez specjalistycznego sprzętu — wystarczy klawiatura i przeglądarka.

Filar 1: Klawiatura

• Odłącz mysz i spróbuj dotrzeć do każdego elementu głównego menu wyłącznie klawiszem Tab oraz strzałkami, jeśli menu używa własnej logiki nawigacji.
• Sprawdź, czy da się otworzyć i zamknąć rozwijane podmenu klawiszem Enter lub spacją, bez konieczności użycia myszy.
• Upewnij się, że żaden element (np. modal z wyszukiwarką, karuzela w stopce) nie tworzy pułapki fokusu, z której nie da się wyjść klawiszem Tab lub Escape.
• Zweryfikuj, że linki w stopce — regulamin, polityka prywatności, dane kontaktowe — są osiągalne w tej samej sekwencji tabulacji co reszta strony, bez pomijania.

Filar 2: Fokus

• Prześledź kolejność, w jakiej fokus przechodzi przez nawigację — czy odpowiada ona logicznemu, wizualnemu układowi strony, czy skacze w nieprzewidywalny sposób.
• Sprawdź, czy wskaźnik fokusu (obwódka, podkreślenie, zmiana koloru) jest widoczny na każdym elemencie nawigacji i wyszukiwarki, również po najechaniu na element przyklejony (sticky header).
• Zweryfikuj, czy widoczny wskaźnik fokusu nie jest zasłaniany przez inne elementy interfejsu, na przykład stały pasek promocyjny lub baner cookies.
• Po otwarciu i zamknięciu okna wyszukiwania sprawdź, gdzie wraca fokus — powinien wrócić w przewidywalne, sensowne miejsce, a nie na początek dokumentu.

Filar 3: Błąd

• Wpisz w wyszukiwarkę zapytanie celowo błędne lub puste i sprawdź, czy komunikat o braku wyników jest odczytywany przez technologie wspomagające, a nie tylko wyświetlany wizualnie.
• Sprawdź, czy komunikat błędu jasno opisuje problem i, jeśli to możliwe, sugeruje dalsze kroki (np. sprawdzenie pisowni, przeglądanie kategorii).
• Zweryfikuj, czy pole wyszukiwania ma widoczną etykietę tekstową lub jej programowy odpowiednik, a nie tylko symbol lupy.
• Jeśli witryna oferuje pomoc kontekstową (np. link „jak szukać”), sprawdź, czy jest ona dostępna w spójny sposób na różnych podstronach.

Tabela robocza: kryteria WCAG 2.2 do przypisania

Poniższa tabela nie jest wyczerpującą listą wszystkich kryteriów WCAG 2.2, lecz punktem odniesienia do wykorzystania przy audycie nawigacji i wyszukiwarki. Numery kryteriów pochodzą z dokumentu W3C i mają służyć jako słownik do zaznaczania statusu, nie jako gwarancja pełnej zgodności po ich sprawdzeniu.

Ograniczenia tej metody

Ta lista kontrolna nie zastępuje pełnego audytu zgodności z WCAG 2.2 i nie obejmuje wszystkich kryteriów sukcesu dotyczących np. kontrastu kolorów, struktury nagłówków treści menu czy formularzy rezerwacyjnych — te wymagają osobnych przebiegów testowych. Skanery automatyczne mogą wychwycić część problemów technicznych, takich jak brakujący atrybut czy zduplikowany tekst linku, ale nie ocenią wiarygodnie, czy kolejność fokusu jest logiczna z perspektywy użytkownika, ani czy komunikat błędu jest faktycznie zrozumiały. Ręczne testowanie klawiaturą, a w miarę możliwości także z udziałem osób korzystających na co dzień z technologii wspomagających, pozostaje niezbędnym uzupełnieniem. Wyniki tego audytu należy traktować jako punkt wyjścia do dalszej pracy, nie jako ostateczne stwierdzenie zgodności prawnej czy formalnej.

Jak mierzyć postęp audytu

Praktyczny sposób pomiaru to prowadzenie prostego rejestru: dla każdego elementu nawigacji, stopki i wyszukiwarki zapisujesz status „przetestowano klawiaturą — zaliczone / niezaliczone / wymaga poprawki” wraz z datą i nazwiskiem osoby testującej. Powtarzaj cały cykl KFB po każdej istotnej zmianie w motywie strony, wtyczce wyszukiwania lub układzie menu — nawet drobna aktualizacja szablonu może zmienić kolejność fokusu. Warto też prowadzić listę zgłoszonych i naprawionych pułapek fokusu jako wskaźnik postępu w czasie, zamiast jednorazowego „zaliczenia” audytu.

1. Wybierz jedną przeglądarkę i jedno urządzenie jako punkt odniesienia dla każdego cyklu testów.
2. Przejdź przez wszystkie elementy nawigacji, stopki i wyszukiwarki wyłącznie klawiaturą, zapisując wynik każdego kroku.
3. Odnotuj wszystkie miejsca, w których f

   Przygotowanie środowiska testowego przed audytem

   Zanim zaczniesz stosować ramę KFB, ustal, na jakim zestawie przeglądarki i systemu operacyjnego będziesz powtarzać testy — wyniki nawigacji klawiaturą mogą się różnić między przeglądarkami ze względu na różną obsługę fokusu przez silniki renderujące. WCAG 2.2 (W3C) nie wskazuje konkretnych kombinacji do testowania, dlatego wybór należy do zespołu, ale powinien być spisany i powtarzany przy każdym cyklu.

   Minimalny zestaw kombinacji

   • Jedna przeglądarka desktopowa z klawiaturą fizyczną, bez myszy i touchpada.
   • Jedna przeglądarka mobilna z klawiaturą zewnętrzną podłączoną do telefonu lub tabletu, jeśli menu ma inny układ na mobile (np. hamburger).
   • Jedna sesja z włączonym czytnikiem ekranu, nawet jeśli audyt koncentruje się na klawiaturze — pozwala wychwycić rozbieżność między tym, co widać, a tym, co jest ogłaszane.

   Przypadki graniczne charakterystyczne dla nawigacji restauracyjnych witryn

   Niektóre wzorce interfejsu spotykane na stronach restauracji wymagają dodatkowej uwagi, bo standardowe testy Tab/Enter mogą ich nie uchwycić.

   • Mega menu z wielopoziomowymi kategoriami (np. „Menu” → „Dania główne” → „Wegetariańskie”) — sprawdź, czy strzałki lub Tab pozwalają wejść na trzeci poziom i wrócić bez utraty miejsca w strukturze.
   • Podpowiedzi w wyszukiwarce (autocomplete) — jeśli lista podpowiedzi pojawia się podczas pisania, zweryfikuj, czy da się ją przejrzeć klawiszami strzałek i zatwierdzić Enterem, oraz czy pojawienie się listy jest ogłaszane technologiom wspomagającym, a nie tylko widoczne wizualnie.
   • Menu „hamburger” na urządzeniach mobilnych z klawiaturą zewnętrzną — po otwarciu powinno przechwytywać fokus w obrębie siebie do zamknięcia (bez tworzenia trwałej pułapki), a po zamknięciu fokus powinien wrócić do przycisku, który je otworzył.
   • Link „przejdź do treści” (skip link) — jeśli istnieje, sprawdź, czy jest pierwszym elementem osiągalnym Tabem i czy faktycznie przenosi fokus do głównej treści, a nie tylko przewija widok.
   • Banery promocyjne i cookies nałożone na nagłówek — jeśli pojawiają się po wczytaniu strony, sprawdź, czy nie przechwytują fokusu bez możliwości powrotu do nawigacji.
   • Przełącznik języka w stopce — zweryfikuj, że jest osiągalny w tej samej sekwencji Tab co inne linki stopki i że zmiana języka nie przenosi fokusu w nieprzewidywalne miejsce.

   Klasyfikacja znalezionych problemów

   Nie każdy problem wymaga natychmiastowej naprawy w tym samym tempie. Warto przypisać każdemu wpisowi w rejestrze poziom istotności, aby ustalić kolejność pracy zespołu deweloperskiego.

   Poziom	Opis	Przykład
   Blokujący	Uniemożliwia dokończenie zadania klawiaturą	Pułapka fokusu w modalu wyszukiwania
   Utrudniający	Zadanie możliwe, ale wymaga obejścia lub zgadywania	Niewidoczny wskaźnik fokusu w podmenu
   Kosmetyczny	Nie wpływa na wykonanie zadania, ale odbiega od oczekiwań	Niespójny odstęp między elementami fokusu

   Dodatkowe ograniczenia, o których warto pamiętać

   Rama KFB i tabela robocza opisane w głównej części artykułu nie obejmują wszystkich kryteriów sukcesu WCAG 2.2 istotnych dla interfejsów nawigacyjnych. Warto osobno zweryfikować między innymi kryteria dotyczące rozmiaru celu dotykowego (Target Size) oraz ruchów przeciągania (Dragging Movements), jeśli nawigacja lub wyszukiwarka zawiera elementy przesuwane gestem, a także kryterium dotyczące powtarzania wpisanych danych (Redundant Entry), jeśli wyszukiwarka jest częścią wieloetapowego formularza. Te obszary wykraczają poza zakres niniejszej listy kontrolnej i wymagają odrębnego przebiegu testowego opartego na pełnym tekście WCAG 2.2 opublikowanym przez W3C.

   Należy też pamiętać, że wyniki testów z czytnikiem ekranu mogą się różnić w zależności od wersji oprogramowania i przeglądarki, z którą jest sparowany — rozbieżność między kombinacjami nie oznacza automatycznie błędu w kodzie strony, ale wskazuje potrzebę przetestowania szerszego zestawu konfiguracji przed wyciągnięciem ostatecznych wniosków.

   Źródła pierwotne

   • W3C: Web Content Accessibility Guidelines 2.2

   FAQ

   Czy WCAG 2.2 dotyczy konkretnie nawigacji na stronie restauracji?

   WCAG 2.2 obejmuje całą treść internetową, w tym strony restauracji, i nie wyłącza nawigacji, stopki ani wyszukiwarki jako wyjątków. Kryteria sukcesu dotyczące obsługi klawiaturą, kolejności fokusu i identyfikacji błędów mają zastosowanie tak samo, jak w przypadku dowolnej strony z interaktywnymi menu i formularzami. Operatorzy restauracji powinni traktować główną nawigację i pasek wyszukiwania jako pełnoprawne interfejsy interaktywne, podlegające tym samym kryteriom co widżety zamówień czy rezerwacji.

   Czym różni się audyt nawigacji od audytu procesu zamawiania lub rezerwacji?

   Nawigacja, linki w stopce i wyszukiwarka witryny zazwyczaj występują na każdej podstronie i są używane, zanim odwiedzający w ogóle dotrze do menu, koszyka zamówień czy formularza rezerwacji. Osoba, która nie może przejść tabulatorem przez menu główne lub nie potrafi wyjść z nieudanego wyszukiwania, może opuścić stronę, zanim w ogóle zobaczy interfejsy rezerwacyjne czy transakcyjne. Ta lista kontrolna izoluje te wcześniejsze warstwy strony, zamiast powielać audyty skierowane już na procesy transakcyjne.

   Czy automatyczne skanery mogą w pełni wykonać taki audyt?

   Narzędzia automatyczne potrafią wykryć część problemów, na przykład brak wskaźnika fokusu w kodzie czy powielony tekst linków, ale zwykle nie są w stanie wiarygodnie ocenić logicznej kolejności fokusu, zrozumiałości komunikatów o błędach ani obecności pułapek klawiaturowych w niestandardowych widżetach. Ręczne testowanie wyłącznie klawiaturą, a tam gdzie to możliwe także z użyciem realnych technologii wspomagających, pozostaje konieczne. Wyniki automatyczne warto traktować jako punkt wyjścia, a nie werdykt zgodności.

   Nota redakcyjna: ChefNet publikuje ten przewodnik i rozwija produkty wspierające odkrywanie restauracji oraz ich działalność. Ogólne zalecenia operacyjne są oddzielone od twierdzeń o produkcie. Funkcje mogą się zmieniać wraz z rozwojem pilotaży. Opublikowano 2026-08-03.