Krótka odpowiedź: menu cyfrowe i proces zamawiania w samoobsłudze można sprawdzić pod kątem dostępności, testując dziesięć konkretnych kryteriów sukcesu WCAG 2.2: opisy tekstowe zdjęć dań, kontrast etykiet alergenów, pełną obsługę klawiaturą, widoczną i logiczną kolejność fokusu, brak wymuszonych gestów przeciągania, odpowiedni rozmiar elementów dotykowych, brak zbędnego powtarzania danych oraz poprawne odczytywanie nazw i stanów elementów przez czytniki ekranu. Poniższa lista kontrolna prowadzi przez każde z tych kryteriów w kolejności, w jakiej gość faktycznie porusza się po menu — od przeglądania kart dań po finalizację zamówienia.
Dlaczego dostępność menu cyfrowego wymaga osobnego audytu
Menu online i self-checkout to interfejsy o innej charakterystyce niż formularz rezerwacji czy strona główna restauracji. Gość musi jednocześnie odczytać informacje o alergenach, wybrać warianty dania, dodać modyfikatory i przejść przez wieloetapowy koszyk — często na małym ekranie telefonu, czasem w hałaśliwym otoczeniu, czasem korzystając z czytnika ekranu lub wyłącznie z klawiatury. WCAG 2.2, opublikowane przez W3C, definiuje mierzalne kryteria sukcesu, które można testować pojedynczo, dania po daniu, kroku po kroku. Ten artykuł nie interpretuje przepisów — opisuje wyłącznie techniczne testy zgodne z tekstem rekomendacji WCAG 2.2.
Rama testowa: Lista kontrolna dostępności menu mobilnego i zamawiania
Poniższa rama grupuje kryteria WCAG 2.2 według czterech etapów podróży gościa: przeglądanie, etykiety i kontrast, interakcja modyfikatorów oraz finalizacja zamówienia. Każdy wiersz można oznaczyć jako zaliczony lub niezaliczony podczas ręcznego testu.
| Etap podróży gościa | Kryterium WCAG 2.2 | Co sprawdzić |
|---|---|---|
| Przeglądanie zdjęć dań | 1.1.1 Treść nietekstowa | Każde zdjęcie dania ma opis alternatywny opisujący samo danie, nie ogólnikowy tekst typu „zdjęcie” |
| Etykiety alergenów i diet | 1.4.3 / 1.4.11 Kontrast | Kontrast tekstu etykiety wobec tła min. 4.5:1, a ikony/obramowania min. 3:1 |
| Nawigacja po karcie menu | 2.1.1 Klawiatura | Wszystkie zakładki kategorii, filtry i przyciski „dodaj do koszyka” działają bez myszy/dotyku |
| Otwieranie modyfikatorów dania | 4.1.2 Nazwa, rola, wartość | Czytnik ekranu odczytuje nazwę modyfikatora, jego stan (zaznaczony/niezaznaczony) oraz cenę dodatkową |
| Wybór wariantów (np. suwak ostrości) | 2.5.7 Ruchy przeciągania | Każdą funkcję opartą na przeciąganiu da się wykonać alternatywnie, np. przyciskami |
| Przyciski dotykowe w koszyku | 2.5.8 Rozmiar celu | Minimalny rozmiar celu dotykowego zgodny z kryterium, chyba że zastosowano wyjątek dopuszczony przez WCAG |
| Przechodzenie między krokami zamówienia | 2.4.3 Kolejność fokusu | Fokus przechodzi w logicznej kolejności: dane zamówienia → dostawa/odbiór → płatność |
| Widoczność aktywnego pola | 2.4.7 / 2.4.11 Fokus widoczny / niezasłonięty | Zaznaczenie fokusu jest widoczne i nie jest przesłonięte przez sticky nagłówek lub baner |
| Ponowne wpisywanie danych | 3.3.7 Zbędne powtarzanie danych | Dane podane wcześniej (np. adres, numer stolika) nie muszą być wpisywane ponownie w kolejnym kroku |
Jak korzystać z tej listy podczas redesignu
- Wykonaj pełne zamówienie testowe wyłącznie klawiaturą (Tab, Shift+Tab, Enter, Spacja) — bez myszy i bez dotyku.
- Powtórz to samo zamówienie z aktywnym czytnikiem ekranu (np. VoiceOver lub NVDA) i zanotuj, gdzie nazwa lub stan elementu nie jest odczytywany.
- Zmierz kontrast każdej etykiety alergenu i diety narzędziem do pomiaru kontrastu, osobno dla trybu jasnego i ciemnego.
- Sprawdź, czy każdy element wymagający przeciągania (suwaki, karuzele) ma alternatywę w postaci przycisków.
- Prześledź kolejność fokusu przez cały checkout i zapisz, w którym miejscu fokus „gubi się” lub wraca do góry strony.
Ograniczenia tej listy kontrolnej
Ta lista nie zastępuje pełnego audytu zgodności WCAG 2.2, który obejmuje znacznie więcej kryteriów niż te bezpośrednio związane z menu i zamawianiem. Nie obejmuje też widżetów rezerwacji, kalendarzy dostępności stolików ani wzorców interakcji specyficznych dla płatności zewnętrznych dostawców — te obszary wymagają osobnej analizy. Wyniki testu manualnego zależą od konkretnej przeglądarki, czytnika ekranu i wersji systemu operacyjnego użytych podczas testu, dlatego warto powtarzać audyt po każdej istotnej zmianie technicznej platformy zamawiania. Lista nie stanowi też opinii prawnej — decyzje o zgodności z lokalnymi przepisami dotyczącymi dostępności powinny być konsultowane z wykwalifikowanym audytorem dostępności lub prawnikiem.
Pomiar i dokumentowanie wyników
Aby audyt był powtarzalny, warto prowadzić prosty arkusz wyników z trzema kolumnami: kryterium WCAG 2.2, status (zaliczone / niezaliczone / częściowo) oraz konkretny ekran lub krok zamówienia, w którym wykryto problem. Taki arkusz pozwala zespołowi technicznemu priorytetyzować poprawki — na przykład brak alternatywy tekstowej dla zdjęć dań (1.1.1) zwykle da się naprawić szybciej niż przebudowa kolejności fokusu w całym checkoucie (2.4.3). Zaleca się powtarzanie pełnego testu klawiaturowego i testu czytnikiem ekranu po każdej zmianie szablonu karty dania, dodaniu nowego typu modyfikatora lub zmianie dostawcy płatności, ponieważ każda z tych zmian może wpłynąć na strukturę DOM i kolejność fokusu niezależnie od wcześniejszych wyników audytu.
Gdzie w tym obszarze może pojawić się
Przypadki brzegowe pominięte w podstawowej liście kontrolnej
Podstawowa rama testowa obejmuje statyczny przebieg zamawiania, ale realne karty menu zawierają elementy dynamiczne i zmienne w czasie, które wymagają dodatkowych kryteriów WCAG 2.2. Poniższa tabela rozszerza listę kontrolną o scenariusze najczęściej pomijane podczas testów przeprowadzanych tylko na przykładowym, „czystym” zamówieniu.
| Scenariusz brzegowy | Kryterium WCAG 2.2 | Co sprawdzić |
|---|---|---|
| Danie kończy się w trakcie sesji zamawiania | 4.1.3 Komunikaty o stanie | Zmiana dostępności dania (np. „wyprzedane”) jest zgłaszana czytnikowi ekranu bez konieczności przenoszenia fokusu |
| Sesja koszyka wygasa po czasie bezczynności | 2.2.1 Możliwość dostosowania czasu | Gość otrzymuje ostrzeżenie i możliwość przedłużenia czasu przed wylogowaniem lub utratą koszyka |
| Menu dostępne w kilku językach | 3.1.2 Język części | Fragmenty w innym języku (np. nazwy dań oryginalne) mają poprawnie oznaczony atrybut językowy |
| Błąd przy finalizacji zamówienia (np. brak wymaganego modyfikatora) | 3.3.1 Identyfikacja błędu | Błąd jest opisany tekstowo, a nie tylko kolorem pola |
| Sugerowanie poprawki błędu | 3.3.3 Sugestia korekty błędu | System proponuje sposób poprawienia błędu, np. wskazuje brakujące pole |
| Instrukcje przy polach niestandardowych (np. „dopisz uwagi do kucharza”) | 3.3.2 Etykiety lub instrukcje | Pole ma widoczną etykietę lub instrukcję, nie tylko placeholder znikający po kliknięciu |
| Pomoc kontekstowa powtarzana na kilku ekranach zamawiania | 3.2.6 Spójna pomoc | Link do pomocy/kontaktu znajduje się w tym samym miejscu na każdym kroku zamówienia |
Jak włączyć przypadki brzegowe do testu
- Celowo wybierz do testu danie, które oznaczysz jako niedostępne w trakcie sesji, i sprawdź, czy zmiana jest zgłaszana przez czytnik ekranu.
- Pozostaw koszyk bez interakcji na czas dłuższy niż domyślny limit sesji i zanotuj, czy pojawia się ostrzeżenie przed wygaśnięciem.
- Jeśli menu ma wersję wielojęzyczną, przetestuj przełączanie języka z aktywnym czytnikiem ekranu i sprawdź wymowę nazw dań w oryginalnym języku.
- Wywołaj celowo błąd walidacji (np. pomiń wymagany modyfikator) i sprawdź, czy komunikat jest odczytywany i czy wskazuje konkretne pole.
Metodologia pomiaru: dobór próby do testu
Wynik testu manualnego zależy od tego, jakie dania i ścieżki zostały wybrane do sprawdzenia. Aby ograniczyć ryzyko pominięcia problemu, warto objąć testem co najmniej: jedno danie bez modyfikatorów, jedno danie z rozbudowanym zestawem modyfikatorów (warianty, dodatki płatne), jedno danie oznaczone jako czasowo niedostępne oraz jedną pozycję z etykietą alergenu lub diety. Test należy powtórzyć na co najmniej dwóch kombinacjach przeglądarki i czytnika ekranu, ponieważ różnice w renderowaniu DOM mogą ujawniać odmienne błędy w każdej kombinacji. Rekomendowane jest też przeprowadzenie testu na urządzeniu mobilnym i desktopowym osobno, ponieważ kolejność fokusu i rozmiar celów dotykowych mogą różnić się między układami responsywnymi.
Ograniczenia metodologiczne pomiaru
Testy automatyczne (skanery dostępności) wykrywają jedynie część kryteriów z powyższych list — głównie te mierzalne programowo, jak kontrast czy obecność atrybutów tekstu alternatywnego. Kryteria zależne od kontekstu, takie jak trafność opisu zdjęcia dania (1.1.1) czy logiczność kolejności fokusu (2.4.3), wymagają oceny manualnej i nie da się ich w pełni zautomatyzować. Wynik testu manualnego jest też zależny od doświadczenia osoby testującej z danym czytnikiem ekranu — testerzy niebędący codziennymi użytkownikami technologii wspomagających mogą przeoczyć problemy, które są oczywiste dla osób korzystających z tych narzędzi na co dzień. Z tego powodu lista kontrolna opisana w tym artykule powinna być traktowana jako narzędzie wstępnej diagnostyki, a nie zamiennik testów przeprowadzanych z udziałem realnych użytkowników technologii wspomagających.
Kontekst produktowy a ogólne wytyczne WCAG
Powyższa lista kontrolna i przypadki brzegowe opisują ogólne kryteria WCAG 2.2 i mają zastosowanie niezależnie od dostawcy platformy menu cyfrowego czy systemu zamawiania. ChefNet rozwija produkty z zakresu odkrywania restauracji i operacji gastronomicznych, w tym narzędzia związane z prezentacją menu — operatorzy powinni jednak samodzielnie zweryfikować, które konkretne funkcje dostępności są aktualnie dostępne w używanej przez nich wersji platformy, ponieważ zakres wdrożonych kryteriów WCAG może się różnić między produktami i z czasem ulegać zmianie.
Źródła pierwotne
FAQ
Które kryteria WCAG 2.2 są najważniejsze dla menu cyfrowego?
Dla przeglądania menu i składania zamówień kluczowe są kryteria 1.1.1 (treść nietekstowa), 1.4.3 i 1.4.11 (kontrast), 2.1.1 (klawiatura), 2.4.3 (kolejność fokusu), 2.4.7 (widoczność fokusu), 2.4.11 (fokus niezasłonięty), 2.5.7 (ruchy przeciągania), 2.5.8 (rozmiar celu), 3.3.7 (zbędne powtarzanie danych) oraz 4.1.2 (nazwa, rola, wartość). Pełne brzmienie kryteriów publikuje W3C w rekomendacji WCAG 2.2.
Czy spełnienie tej listy oznacza zgodność prawną menu?
Nie. Ta lista kontrolna jest narzędziem testowym opartym na kryteriach sukcesu WCAG 2.2, a nie opinią prawną. Wymogi prawne różnią się w zależności od jurysdykcji i rodzaju działalności, dlatego w kwestiach zgodności warto skonsultować się z wykwalifikowanymi audytorami dostępności lub prawnikiem.
Czym różni się to od dostępności widżetu rezerwacji stolika?
Ta lista obejmuje przeglądanie menu, strony szczegółów dania, wybór modyfikatorów oraz kroki koszyka i finalizacji zamówienia w samoobsłudze. Nie dotyczy kalendarzy, selektorów dat ani wzorców interakcji specyficznych dla rezerwacji, które wymagają innego zestawu kryteriów WCAG.
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-02.