WCAG 2.4.5: Wiele sposobów

Co Oznacza Ta Zasada

WCAG 2.4.5 — Multiple Ways (Wiele sposobów) jest kryterium sukcesu na poziomie AA w ramach zasady Operable (Możliwość obsługi). Wymaga ono, aby każda strona internetowa, która jest częścią większego zbioru stron, była osiągalna za pomocą co najmniej dwóch odrębnych mechanizmów nawigacji. Innymi słowy, użytkownik nigdy nie powinien być zmuszony do polegania na jednej jedynej drodze, aby odnaleźć stronę.

Typowe mechanizmy nawigacji spełniające to kryterium obejmują: wyszukiwarkę działającą w obrębie całej witryny, mapę serwisu (jako osobną stronę lub strukturę wbudowaną), spis treści, spójne menu nawigacyjne lub panel boczny, ścieżki okruszkowe (breadcrumbs) oraz linki między powiązanymi stronami. Dowolne dwa z nich — lub inne równoważne mechanizmy — użyte razem spełniają wymaganie.

Kryterium dotyczy konkretnie zbiorów stron internetowych. Samodzielna strona, która nie należy do większej witryny lub aplikacji, jest zwolniona z tego wymogu. Dodatkowo, strony będące wynikiem procesu lub jego etapem — takie jak strona potwierdzenia zakupu, ekran sukcesu po wysłaniu formularza czy krok kreatora — są również wyraźnie wyłączone. Wynika to z faktu, że takie strony są z natury sekwencyjne i umożliwienie bezpośredniego dostępu do nich poza kolejnością byłoby niewłaściwe lub szkodliwe.

Spełnienie kryterium wymaga, aby co najmniej dwa niezależne mechanizmy nawigacji były obecne, działały poprawnie i były dostępne w całej witrynie. Niespełnienie ma miejsce, gdy istnieje tylko jeden mechanizm — na przykład witryna, która udostępnia wyłącznie górne menu nawigacyjne, bez wyszukiwarki, mapy serwisu czy innej pomocy nawigacyjnej. Kryterium nie jest spełnione również wtedy, gdy mechanizm dodatkowy jest niesprawny lub niedostępny (np. pole wyszukiwania, które nie zwraca wyników, lub mapa serwisu ukryta przed technologiami asystującymi).

Co istotne, kryterium to nie narzuca żadnej konkretnej kombinacji mechanizmów. Elastyczność jest zamierzona: różni użytkownicy mają zasadniczo odmienne strategie wyszukiwania treści, a standard uznaje tę różnorodność, wymagając redundancji zamiast narzucania jednego konkretnego rozwiązania.

Dlaczego To Ma Znaczenie

Nawigacja jest fundamentem każdego doświadczenia w sieci, a bariery w nawigacji w nieproporcjonalny sposób dotykają osoby z niepełnosprawnościami. Gdy istnieje tylko jedna ścieżka nawigacji, użytkownicy, którzy nie mogą z niej skorzystać, są w praktyce odcięci od treści.

Dla użytkowników z niepełnosprawnościami ruchowymi — w tym osób korzystających z przełączników (switch access), urządzeń śledzących ruch gałek ocznych, oprogramowania do sterowania głosem lub nawigacji wyłącznie klawiaturą — złożone, hierarchiczne menu mogą być wyczerpujące lub wręcz niemożliwe do sprawnego przejścia. Wyszukiwarka w witrynie pozwala im przejść bezpośrednio do treści bez konieczności przeklikiwania się przez wiele poziomów menu. Z drugiej strony, użytkownicy z określonymi niepełnosprawnościami poznawczymi lub problemami z pamięcią mogą uznać otwarte pola wyszukiwania za mylące lub trudne w skutecznym użyciu; dla nich znacznie bardziej użyteczna jest jasno zorganizowana mapa serwisu lub przeglądana struktura kategorii.

Dla niewidomych użytkowników polegających na czytnikach ekranu, rozbudowane menu nawigacyjne może stać się powtarzającą się przeszkodą przy każdej wizycie na stronie, nawet przy zastosowaniu linków „przejdź do treści”. Mapa serwisu lub skrót do wyszukiwarki znacząco zmniejsza ten wysiłek poznawczy i fizyczny. Dla użytkowników z niedowidzeniem, korzystających z powiększania ekranu, szerokie menu nawigacyjne może być przy dużym powiększeniu widoczne tylko częściowo, co sprawia, że tekstowa wyszukiwarka lub mapa serwisu staje się kluczowym mechanizmem awaryjnym.

Dla użytkowników z niepełnosprawnościami poznawczymi, takimi jak dysleksja czy zaburzenia uwagi, możliwość wyszukiwania przy użyciu przybliżonych lub częściowych haseł — zamiast konieczności zapamiętania lub rozpoznania dokładnej hierarchii menu — może decydować o tym, czy samodzielnie odnajdą treść, czy całkowicie zrezygnują.

Konkretny scenariusz z życia: wyobraźmy sobie użytkownika z reumatoidalnym zapaleniem stawów odwiedzającego turecką platformę e-commerce, korzystającego wyłącznie z klawiatury. Mega-menu witryny wymaga precyzyjnych interakcji z najechaniem kursorem, aby odsłonić podkategorie, a zachowanie fokusu klawiatury jest nieprzewidywalne. Jeśli witryna udostępnia również pasek wyszukiwania i mapę serwisu, użytkownik ten nadal może odnaleźć potrzebną stronę produktu. Bez tych alternatyw witryna jest dla niego w praktyce nieużywalna — co oznacza utraconego klienta i potencjalne ryzyko prawne.

Poza dostępnością, wiele mechanizmów nawigacji przynosi wymierne korzyści SEO i użyteczności. Mapy serwisu poprawiają możliwość indeksowania przez roboty wyszukiwarek. Funkcja wyszukiwania w witrynie zwiększa zaangażowanie użytkowników i zmniejsza współczynnik odrzuceń. Ścieżki okruszkowe poprawiają współczynnik klikalności w wynikach wyszukiwania, gdy są wdrożone z użyciem danych strukturalnych. Oznacza to, że spełnienie 2.4.5 nie jest jedynie ćwiczeniem z zakresu zgodności — to po prostu dobra praktyka projektowania stron.

Powiązane Reguły Axe-core

WCAG 2.4.5 wymaga testów manualnych, ponieważ żadne narzędzie automatyczne nie jest w stanie wiarygodnie określić, czy witryna zapewnia wystarczającą różnorodność mechanizmów nawigacji. Skanery automatyczne mogą sprawdzić, czy określone elementy istnieją i są poprawne składniowo, ale nie są w stanie ocenić architektury nawigacyjnej w skali całej witryny ani stwierdzić, czy dana kombinacja mechanizmów jest faktycznie wystarczająca. Poniższe kwestie kierują oceną manualną:

• Obecność wyszukiwarki w witrynie (sprawdzenie manualne): Narzędzia automatyczne nie mogą potwierdzić, czy pole wyszukiwania działa, zwraca sensowne wyniki ani czy jest dostępne w całej witrynie. Tester musi ręcznie zweryfikować, że mechanizm wyszukiwania istnieje, jest osiągalny z klawiatury i zwraca trafne wyniki dla reprezentatywnych zapytań.
• Obecność mapy serwisu lub alternatywnego mechanizmu nawigacji (sprawdzenie manualne): Narzędzia nie są w stanie ustalić, czy strona mapy serwisu istnieje, czy jest podlinkowana ze wszystkich stron ani czy obejmuje całą zawartość witryny. Recenzent musi potwierdzić, że co najmniej jeden dodatkowy mechanizm poza nawigacją główną jest dostępny i dostępny dla użytkowników.
• Spójność nawigacji (powiązane z 2.4.3 i 3.2.3, sprawdzenie manualne): Narzędzia automatyczne mogą oznaczyć niespójne uporządkowanie komponentów na stronach, ale nie są w stanie ocenić, czy ogólna strategia nawigacji pozostaje spójna i wystarczająca dla użytkowników z niepełnosprawnościami. Wymagana jest manualna ocena wielu reprezentatywnych typów stron.
• Dostępność mechanizmów dodatkowych (sprawdzenie manualne): Nawet jeśli mapa serwisu lub wyszukiwarka istnieje, skan automatyczny może nie wykryć sytuacji, w których mechanizmy te są niedostępne z klawiatury, mają słabe etykiety dla czytników ekranu lub są wizualnie ukryte w sposób wpływający na użyteczność. Manualne testy z użyciem klawiatury i czytnika ekranu muszą potwierdzić, że każdy mechanizm działa od początku do końca.

Jak Testować

1. Skan automatyczny — ustalenie punktu wyjścia: Uruchom axe DevTools lub Lighthouse na reprezentatywnych stronach witryny. Choć żadne z narzędzi nie zgłasza bezpośrednio naruszeń 2.4.5, wykorzystaj audyt do zidentyfikowania komponentów nawigacyjnych (menu, pola wyszukiwania, breadcrumbs) z podstawowymi problemami dostępności, takimi jak brakujące etykiety, nieprawidłowe role ARIA czy problemy z zarządzaniem fokusem. Najpierw napraw te kwestie, ponieważ niesprawny mechanizm nawigacji nie może być uznany za ważny „sposób” w rozumieniu 2.4.5.
2. Sporządzenie katalogu mechanizmów nawigacji: Ręcznie przejrzyj witrynę i wypisz każdy odrębny mechanizm, którego użytkownik mógłby użyć, aby dotrzeć do danej strony: górne menu nawigacyjne, linki w stopce, wyszukiwarka, strony mapy serwisu, breadcrumbs, linki do powiązanych treści, indeksy kategorii itd. Potwierdź, że co najmniej dwa z tych mechanizmów są obecne, działają i są dostępne na każdej stronie, która nie jest częścią procesu sekwencyjnego.
3. Test nawigacji wyłącznie klawiaturą: Używając wyłącznie klawiszy Tab, Enter, strzałek i Escape (bez myszy), spróbuj dotrzeć do konkretnej strony innej niż strona główna za pomocą dwóch różnych mechanizmów. Na przykład użyj paska wyszukiwania, aby znaleźć stronę produktu, a następnie użyj mapy serwisu lub menu nawigacyjnego, aby dotrzeć do tej samej strony. Potwierdź, że obie ścieżki są w pełni obsługiwalne bez myszy.
4. Test z czytnikiem ekranu NVDA + Firefox: Uruchom NVDA, otwórz Firefox i przejdź na stronę główną. Użyj trybu przeglądania NVDA (F6 dla obszarów typu landmark, H dla nagłówków), aby zlokalizować obszar wyszukiwania (search landmark) oraz linki do mapy serwisu lub nawigacji. Potwierdź, że oba mechanizmy są poprawnie anonsowane, pola formularzy mają dostępne etykiety, a strony z wynikami lub strony docelowe ładują się i są czytelne.
5. Test z czytnikiem ekranu VoiceOver + Safari (macOS/iOS): Aktywuj VoiceOver (Cmd+F5) i użyj Rotora (VO+U), aby przejrzeć kontrolki formularzy i linki na stronie. Potwierdź, że pole wyszukiwania jest widoczne na liście i poprawnie opisane, a linki nawigacyjne prowadzące do mapy serwisu lub alternatywnego indeksu są obecne i działają.
6. Test z czytnikiem ekranu JAWS + Chrome: Użyj skrótów nawigacyjnych JAWS (F, aby przejść do formularzy, Insert+F7, aby wyświetlić listę linków), aby zweryfikować, że pole wyszukiwania i linki do mapy serwisu są wykrywalne i używalne zarówno z klawiatury, jak i za pomocą wirtualnego kursora.
7. Sprawdzenie zwolnienia dla procesów sekwencyjnych: Zidentyfikuj strony, które są krokami w procesie (zakup, wieloetapowe formularze, logowanie). Potwierdź, że strony te nie muszą spełniać wymogu wielu sposobów nawigacji. Udokumentuj to w audycie dostępności, aby uniknąć fałszywych negatywnych wyników.
8. Weryfikacja działania wyników wyszukiwania: Wykonaj kilka reprezentatywnych wyszukiwań (nazwy produktów, tytuły artykułów, tematy pomocy). Potwierdź, że wyniki się pojawiają, są trafne, a strona z wynikami jest dostępna i możliwa do nawigowania za pomocą klawiatury i czytnika ekranu.

Jak Naprawić

Brak wyszukiwarki w witrynie — Niepoprawne

<!-- Site only has a navigation menu; no search or sitemap provided -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>
<!-- No search, no sitemap link, no other navigation mechanism -->

Brak wyszukiwarki w witrynie — Poprawne

<!-- Navigation menu retained, and a site search is added as a second mechanism -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>

<!-- Second navigation mechanism: accessible site search -->
<form role='search' action='/arama' method='get'>
  <label for='site-search'>Sitede Ara</label>
  <input
    type='search'
    id='site-search'
    name='q'
    placeholder='Ürün veya konu arayın...'
    aria-label='Site genelinde arama'
  />
  <button type='submit'>Ara</button>
</form>

Niedostępna mapa serwisu — Niepoprawne

<!-- Sitemap link is present but visually hidden and unreachable by keyboard -->
<footer>
  <a href='/site-haritasi' style='display:none;'>Site Haritası</a>
</footer>
<!-- display:none removes the element from both visual display AND
     the accessibility tree, so screen reader users cannot reach it.
     This sitemap cannot count as a valid second navigation mechanism. -->

Niedostępna mapa serwisu — Poprawne

<!-- Sitemap link is visible and accessible to all users -->
<footer>
  <nav aria-label='Footer navigation'>
    <ul>
      <li><a href='/site-haritasi'>Site Haritası</a></li>
      <li><a href='/gizlilik'>Gizlilik Politikası</a></li>
      <li><a href='/iletisim'>İletişim</a></li>
    </ul>
  </nav>
</footer>
<!-- The sitemap page itself should list all major sections and pages
     of the site using <nav>, <ul>, and <a> elements. -->

Formularz wyszukiwania bez dostępnej etykiety — Niepoprawne

<!-- Search input has no label; screen readers announce only 'edit text' -->
<form action='/search'>
  <input type='text' name='q' placeholder='Search...' />
  <button type='submit'><img src='search-icon.png' /></button>
</form>

Formularz wyszukiwania bez dostępnej etykiety — Poprawne

<!-- role='search' identifies the landmark; label associates text with input;
     submit button has an accessible name via aria-label -->
<form role='search' action='/arama' method='get'>
  <label for='global-search'>Arama</label>
  <input
    type='search'
    id='global-search'
    name='q'
    autocomplete='off'
  />
  <button type='submit' aria-label='Aramayı başlat'>
    <img src='search-icon.png' alt='' aria-hidden='true' />
  </button>
</form>

Najczęstsze Błędy

• Traktowanie mapy serwisu XML jako mechanizmu nawigacji dla użytkownika: Mapa serwisu XML przesyłana do wyszukiwarek (np. /sitemap.xml) jest plikiem odczytywanym przez maszyny i nie może być używana przez zwykłych odwiedzających. Tylko strona mapy serwisu w HTML, możliwa do przeglądania przez ludzi, liczy się jako ważny drugi mechanizm nawigacji.
• Udostępnienie formularza wyszukiwania, który jest wyłącznie dekoracyjny lub niesprawny: Pole wyszukiwania, które zawsze zwraca puste wyniki, generuje błędy przy wysyłaniu lub przekierowuje na stronę 404, nie spełnia 2.4.5. Mechanizm musi faktycznie działać, aby kryterium było spełnione.
• Ukrywanie linku do mapy serwisu za pomocą JavaScript, który zawodzi lub jest wyłączony: Jeśli jedyny link do mapy serwisu znajduje się w dynamicznie wstrzykiwanym oknie modalnym lub rozwijanym elemencie zależnym od JavaScript, który nie działa w niektórych środowiskach, użytkownicy, którzy nie mogą uruchomić tego JavaScriptu (w tym niektóre konfiguracje technologii asystujących), tracą dostęp do tego mechanizmu nawigacji.
• Stosowanie display:none lub visibility:hidden do mechanizmu nawigacji w widokach mobilnych: Całkowite ukrycie paska wyszukiwania lub linku do mapy serwisu w układzie mobilnym usuwa ten mechanizm dla użytkowników mobilnych, co jest naruszeniem — nawet jeśli układ desktopowy spełnia wymogi. Złożenie mechanizmu za dostępnym przyciskiem przełączającym jest akceptowalne; usunięcie go z DOM lub drzewa dostępności — nie.
• Traktowanie breadcrumbs jako samodzielnego drugiego mechanizmu bez dodatkowego wsparcia: Breadcrumbs pokazują jedynie ścieżkę do bieżącej strony i same w sobie nie są wystarczające, aby pomóc użytkownikowi odkrywać i nawigować do dowolnych stron w witrynie. Mogą uzupełniać inne mechanizmy, ale zazwyczaj nie mogą samodzielnie pełnić roli jednego z dwóch wymaganych mechanizmów.
• Nieprawidłowe zwalnianie stron z wymogu: Zwolnienie dla procesów sekwencyjnych dotyczy wyłącznie stron, które są dosłownie krokami w procesie (np. krok 2 z 4 w procesie zakupu). Strony kategorii, strony szczegółów produktu i wpisy na blogu nie są zwolnione, nawet jeśli użytkownik dotarł do nich przez lejek.
• Używanie pola wyszukiwania z type='text' zamiast type='search' i pomijanie role='search' w formularzu: Choć nie jest to bezpośrednie naruszenie 2.4.5, oznacza to, że użytkownicy czytników ekranu przeglądający obszary typu landmark nie znajdą regionu wyszukiwania. Mechanizm technicznie istnieje, ale jest praktycznie trudniejszy do odkrycia, co podważa intencję kryterium.
• Udostępnianie dwóch mechanizmów, które są w praktyce identyczne: Górne menu nawigacyjne i menu w stopce zawierające dokładnie te same linki w dokładnie tej samej strukturze nie stanowią dwóch znacząco różnych mechanizmów nawigacji. Intencją jest, aby użytkownicy o różnych potrzebach mogli znaleźć alternatywne strategie — a nie, by ta sama strategia pojawiała się dwukrotnie na stronie.
• Wyłączanie określonych typów stron z systemu nawigacji: Niektóre konfiguracje CMS umieszczają wpisy na blogu, strony prawne lub strony kont użytkowników poza główną mapą serwisu lub indeksem wyszukiwania. Jeśli użytkownicy nie mogą znaleźć tych stron za pomocą co najmniej dwóch mechanizmów, strony te nie spełniają 2.4.5, niezależnie od tego, jak dobrze zorganizowana jest reszta witryny.
• Brak testowania mechanizmów z użyciem technologii asystujących: Ponieważ 2.4.5 wymaga testów manualnych, zespoły polegające wyłącznie na narzędziach automatycznych przeoczą problemy spowodowane pułapkami klawiaturowymi w formularzach wyszukiwania, nieopisanymi polami czy mapami serwisu obecnymi w DOM, ale nieosiągalnymi za pomocą nawigacji po obszarach typu landmark w czytnikach ekranu.

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

Prezydencki Okólnik Turcji nr 2025/10, opublikowany w Dzienniku Urzędowym (Resmî Gazete) nr 32933 w dniu 21 czerwca 2025 r., ustanawia wiążące obowiązki w zakresie dostępności stron internetowych dla szerokiego zakresu podmiotów publicznych i prywatnych. Okólnik nakazuje zgodność z międzynarodowo uznanymi standardami dostępności, dostosowując tureckie wymagania prawne do WCAG 2.1 i WCAG 2.2 na poziomie AA jako podstawowego oczekiwania.

WCAG 2.4.5 — Multiple Ways jest kryterium na poziomie AA, co oznacza, że mieści się dokładnie w poziomie zgodności wymaganym przez Okólnik. Podmioty objęte regulacją muszą zapewnić, że wszystkie strony internetowe należące do zbioru udostępniają co najmniej dwa mechanizmy nawigacji, zgodnie z opisem w tym kryterium. Niespełnienie tego wymogu stanowi bezpośredny brak zgodności z nakazem regulacyjnym.

Podmioty objęte Prezydenckim Okólnikiem 2025/10 obejmują: instytucje publiczne i organy rządowe na wszystkich szczeblach; banki i instytucje finansowe; szpitale i świadczeniodawców opieki zdrowotnej; platformy handlu elektronicznego; operatorów telekomunikacyjnych z 200,000 lub większą liczbą abonentów; biura podróży; prywatne firmy transportowe oraz szkoły prywatne działające na podstawie zezwolenia Ministerstwa Edukacji Narodowej (Millî Eğitim Bakanlığı, MEB). Od każdego z tych typów podmiotów oczekuje się utrzymywania dostępnej, wielościeżkowej nawigacji w ich serwisach internetowych.

Oprócz obowiązkowych wymogów zgodności, Ministerstwo Rodziny i Usług Społecznych (Aile ve Sosyal Hizmetler Bakanlığı) przyznaje Erişilebilirlik Logosu (Logo Dostępności) organizacjom, które wykazują się wysokim poziomem praktyk w zakresie dostępności. Uzyskanie tego logo wymaga pełnej zgodności z poziomem AA, w tym spełnienia 2.4.5. Dla firm działających na konkurencyjnym tureckim rynku cyfrowym — w szczególności platform e-commerce, banków i świadczeniodawców opieki zdrowotnej — Logo Dostępności pełni zarówno rolę sygnału zaufania dla użytkowników z niepełnosprawnościami, jak i dowodu dobrej woli regulacyjnej.

W praktyce tureckie witryny obsługujące zróżnicowane populacje użytkowników odnoszą znaczące korzyści z wdrożenia wielu mechanizmów nawigacji. Turcja ma dużą populację starszych użytkowników internetu oraz użytkowników z regionów o niższej alfabetyzacji cyfrowej, którzy obaj korzystają z redundancji wymaganej przez 2.4.5. Wyszukiwarka w witrynie z obsługą języka tureckiego (w tym poprawną obsługą specyficznych dla tureckiego znaków, takich jak ı, İ, ş, ğ, ü, ö, ç) w połączeniu z jasno zorganizowaną mapą serwisu w HTML stanowi dostępną, zgodną z regulacjami implementację, która dobrze służy tej grupie użytkowników. Organizacje dążące do uzyskania lub utrzymania Erişilebilirlik Logosu powinny traktować zgodność z 2.4.5 nie jako opcjonalne udoskonalenie, lecz jako podstawowy wymóg swojego programu dostępności.