WCAG 3.2.3: Spójna nawigacja

Co Oznacza Ta Zasada

Kryterium sukcesu WCAG 3.2.3 — Spójna nawigacja (poziom AA) stanowi, że elementy nawigacyjne powtarzające się na wielu stronach witryny muszą pojawiać się za każdym razem w tej samej względnej kolejności, chyba że to sam użytkownik wywołał zmianę tej kolejności. Kryterium ma zastosowanie do każdego zestawu stron internetowych, które mają wspólny cel lub są częścią tej samej witryny albo aplikacji.

Wyrażenie „ta sama względna kolejność” jest kluczowe: WCAG nie wymaga, aby nawigacja zawsze zawierała tę samą liczbę elementów ani aby między elementami nawigacji nie mogły pojawiać się inne elementy. Wymaga natomiast, aby sekwencja linków nawigacyjnych, tak jak są one postrzegane przez użytkownika poruszającego się po interfejsie, pozostawała spójna z strony na stronę. Na przykład, jeśli w nawigacji głównej na stronie głównej w podanej kolejności widnieją „Home”, „Products”, „About” i „Contact”, te same elementy muszą pojawiać się w tej samej sekwencji na każdej innej stronie, na której występuje ten blok nawigacyjny.

Kryterium obejmuje wszystkie powtarzające się mechanizmy nawigacyjne: główne menu nawigacyjne serwisu, ścieżki okruszkowe (breadcrumbs), grupy linków w stopce, menu boczne, linki „pomiń nawigację”, paski wyszukiwania oraz każdy inny interaktywny komponent, który pomaga użytkownikowi poruszać się po witrynie. Ma zastosowanie niezależnie od tego, czy komponenty te są zaimplementowane jako znaczniki <nav>, listy linków <ul>, niestandardowe menu z ARIA, czy jakikolwiek inny wzorzec znaczników.

Co jest uznawane za spełnienie kryterium: Bloki nawigacji pojawiają się w tej samej względnej kolejności na każdej stronie, na której są powtarzane. Elementy mogą być dodawane, wyróżniane lub oznaczane jako aktywne (np. link do bieżącej strony jest wizualnie odróżniony), o ile ogólna sekwencja nie ulega zmianie. Zmiana kolejności zainicjowana przez użytkownika — na przykład w konfigurowalnym panelu, gdzie użytkownik przeciąga panele w nowe pozycje — również spełnia kryterium, ponieważ zmiana pochodzi od użytkownika.

Co jest uznawane za niespełnienie kryterium: Główna nawigacja, która na stronie głównej wyświetla „Home → Products → Contact → About”, ale na stronie szczegółów produktu wyświetla „Home → About → Products → Contact”, nie spełnia 3.2.3. Podobnie, witryna, która warunkowo wstawia dodatkowe linki w dowolnych miejscach nawigacji na podstawie logiki wewnętrznej (bez działania użytkownika), również nie spełnia kryterium.

Oficjalny wyjątek: Specyfikacja wyraźnie stwierdza, że wymaganie nie ma zastosowania, gdy użytkownik sam zainicjował zmianę kolejności. Jest to jedyny normatywny wyjątek. Zmiany wywołane przez system, logikę serwera lub algorytmy personalizacji — niebędące bezpośrednim skutkiem działania użytkownika — nie kwalifikują się do tego wyjątku.

Dlaczego To Ma Znaczenie

Spójna nawigacja jest fundamentem dostępności poznawczej. Użytkownicy, którzy polegają na pamięci przestrzennej i przewidywalnych wzorcach, aby się orientować — w tym osoby z niepełnosprawnościami poznawczymi, zaburzeniami uwagi, urazami mózgu lub związanym z wiekiem spadkiem funkcji poznawczych — w dużym stopniu opierają się na założeniu, że nawigacja w serwisie będzie za każdym razem w tym samym miejscu i w tej samej kolejności. Gdy nawigacja nieoczekiwanie się zmienia, użytkownicy ci muszą na nowo uczyć się układu na każdej stronie, co dramatycznie zwiększa obciążenie poznawcze oraz ryzyko błędów lub porzucenia zadania.

Dla użytkowników niewidomych i słabowidzących, którzy nawigują za pomocą czytników ekranu (NVDA, JAWS, VoiceOver), spójna nawigacja skraca czas potrzebny na szukanie znanych punktów orientacyjnych. Użytkownik czytnika ekranu, który zapamiętał, że link „Contact” jest czwartym elementem w głównej nawigacji, może na dowolnej stronie nacisnąć klawisz Tab cztery razy, aby do niego dotrzeć — ale tylko wtedy, gdy kolejność jest gwarantowana jako niezmienna. Niespójna kolejność niszczy tę efektywność i zmusza użytkownika do wysłuchania całej nawigacji przy każdym załadowaniu strony.

Dla użytkowników z niepełnosprawnością ruchową, polegających na nawigacji wyłącznie klawiaturą, przełącznikach lub śledzeniu ruchu gałek ocznych, każdy dodatkowy klawisz lub ruch głowy ma realny koszt. Przewidywalna nawigacja zmniejsza liczbę interakcji potrzebnych do dotarcia do często odwiedzanych miejsc. Według Światowej Organizacji Zdrowia ponad 1,3 miliarda osób na świecie żyje z jakąś formą niepełnosprawności, z których wiele polega na technologiach asystujących, bezpośrednio korzystających ze spójnych, przewidywalnych interfejsów.

Dla użytkowników z trudnościami w czytaniu, takimi jak dysleksja, skanowanie paska nawigacyjnego już samo w sobie jest wysiłkiem. Spójne położenie i kolejność oznacza, że mogą polegać na wizualnych punktach odniesienia — położeniu, kształcie, kolorze — zamiast za każdym razem ponownie czytać etykiety.

Konkretny scenariusz z życia: wyobraź sobie pacjenta korzystającego z witryny szpitala, aby zarezerwować wizytę kontrolną. Nawigacja na stronie głównej w podanej kolejności zawiera „Services”, „Appointments”, „Doctors” i „Contact”. Pacjent przechodzi do strony profilu lekarza i szuka „Appointments” na drugiej pozycji — ale na tej stronie nawigacja została przeorganizowana tak, że na pierwszym miejscu jest „Doctors”, a dopiero potem „Appointments”. Pacjent, już zestresowany, musi ponownie przeskanować całe menu. Dla użytkownika z niepełnosprawnością poznawczą lub ograniczoną umiejętnością czytania ten rodzaj tarcia może stanowić różnicę między ukończeniem zadania a całkowitym zrezygnowaniem.

Poza dostępnością, spójna nawigacja przynosi mierzalne korzyści SEO i użyteczności. Roboty wyszukiwarek przechodzą po linkach nawigacyjnych, aby odkrywać i indeksować treści; stabilna struktura linków poprawia efektywność indeksowania i dystrybucję wewnętrznego autorytetu linków. Badania użyteczności konsekwentnie pokazują, że przewidywalna nawigacja skraca czas realizacji zadań i zmniejsza liczbę błędów dla wszystkich użytkowników, nie tylko osób z niepełnosprawnościami.

Powiązane Reguły Axe-core

WCAG 3.2.3 wymaga ręcznego testowania. Nie istnieje zautomatyzowana reguła axe-core, która mogłaby wykrywać niespójną kolejność nawigacji, ponieważ narzędziom automatycznym brakuje kontekstu międzystronicowego potrzebnego do porównywania sekwencji nawigacji. Automatyczny skaner ocenia pojedynczą stronę w izolacji i nie jest w stanie zaobserwować, czy nawigacja na tej stronie różni się od nawigacji na dwudziestu innych stronach w tej samej witrynie.

• Ręczne porównanie między stronami (brak ID reguły axe): Testerzy muszą odwiedzić wiele stron w tej samej witrynie i ręcznie zapisać kolejność elementów nawigacji na każdej stronie, a następnie porównać te zapisy. Narzędzia automatyczne nie mogą wykonać tego sprawdzenia, ponieważ musiałyby analizować wiele stron jednocześnie, utrzymywać stan między przeładowaniami stron i stosować ocenę semantyczną, które elementy stanowią „ten sam” komponent nawigacyjny — wszystkie te zadania wymagają ludzkiego rozumienia kontekstu.
• Dlaczego automatyzacja jest niewystarczająca: Nawet narzędzia heurystyczne, które sygnalizują problemy związane z nawigacją, zazwyczaj sprawdzają obecność punktów orientacyjnych nawigacji (takich jak reguła axe landmark-one-main lub region), a nie spójność kolejności między stronami. Porównywanie kolejności wymaga metodyki audytu obejmującej całą witrynę, a nie skanowania pojedynczej strony. Dlatego 3.2.3 jest klasyfikowane jako wymagające ręcznego przeglądu we wszystkich głównych ramach testowania dostępności, w tym axe-core, Lighthouse i IBM Equal Access Checker.

Jak Testować

1. Uruchom skan automatyczny dla kontekstu bazowego: Użyj axe DevTools, Lighthouse lub rozszerzenia przeglądarki na reprezentatywnych stronach, aby potwierdzić, że elementy nawigacji są poprawnie oznaczone jako znaczniki <nav> lub z role='navigation'. Choć narzędzia te nie wykryją niespójności kolejności, pomogą zidentyfikować, co jest traktowane jako nawigacja na poszczególnych stronach. Udokumentuj wszelkie problemy ze strukturą punktów orientacyjnych, zanim przejdziesz do ręcznych kontroli.
2. Wybierz reprezentatywną próbkę stron: Wybierz co najmniej pięć do dziesięciu stron z różnych sekcji witryny — stronę główną, stronę kategorii, stronę szczegółów produktu lub artykułu, stronę formularza oraz stronę kontaktową. Jeśli witryna ma tysiące stron, użyj próby warstwowej obejmującej wszystkie główne szablony. Zapisz adres URL i typ strony dla każdej z nich.
3. Ręcznie zmapuj kolejność nawigacji: Na każdej wybranej stronie otwórz drzewo dostępności przeglądarki (Chrome DevTools → panel Accessibility lub Firefox Accessibility Inspector) i wypisz wszystkie linki w ramach nawigacji głównej w kolejności, w jakiej pojawiają się w DOM. Zanotuj również kolejność, w jakiej pojawiają się wizualnie. Jeśli CSS zmienia kolejność wizualną elementów (np. używając flex-direction: row-reverse lub właściwości order), kolejność wizualna może różnić się od kolejności w DOM — obie muszą być spójne.
4. Porównaj między stronami: Ułóż listy kolejności nawigacji obok siebie. Oznacz każdą stronę, na której sekwencja wspólnych elementów nawigacji różni się od wzorca ustalonego na stronie głównej. Zanotuj, które elementy się przesunęły i w jakim kierunku.
5. Test nawigacji klawiaturą (NVDA + Firefox): Uruchom NVDA, włącz Firefox i przejdź do strony głównej. Naciśnij D, aby przejść do następnego regionu punktu orientacyjnego i zlokalizować główną nawigację. Użyj klawisza Tab, aby przechodzić między linkami nawigacji, i na głos wypowiadaj lub zapisuj kolejność. Następnie przejdź do drugiej strony (np. wewnętrznej strony artykułu) i powtórz. Nasłuchuj wszelkich zmian w sekwencji zapowiadanych linków.
6. Test z czytnikiem ekranu (VoiceOver + Safari na macOS): Włącz VoiceOver (Command + F5), otwórz Safari i użyj Web Rotor (Control + Option + U), aby otworzyć menu Links lub Landmarks. Przejdź do głównej nawigacji i zanotuj kolejność elementów. Powtórz na co najmniej trzech różnych typach stron i porównaj.
7. Test JAWS + Chrome: Uruchom JAWS, włącz Chrome i naciśnij R, aby przechodzić między regionami, aż dotrzesz do głównej nawigacji. Przechodź między linkami klawiszem Tab i zapisuj kolejność. Powtórz na różnych typach stron.
8. Sprawdź wyjątki inicjowane przez użytkownika: Jeśli witryna oferuje funkcje personalizacji lub dostosowywania nawigacji, zweryfikuj, że zmiana kolejności następuje wyłącznie po wyraźnym działaniu użytkownika (np. użytkownik klika „Customize Menu” i przeciąga elementy). Potwierdź, że zmieniony stan jest następnie utrwalany w sposób spójny — nowa kolejność sama w sobie powinna pozostawać spójna na wszystkich stronach po jej ustawieniu przez użytkownika.

Jak Naprawić

Niespójne renderowanie po stronie serwera — Nieprawidłowe

<!-- Homepage navigation -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<!-- Product detail page navigation — order changed by CMS template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/products'>Products</a></li>
  </ul>
</nav>

Niespójne renderowanie po stronie serwera — Prawidłowe

<!-- Shared navigation partial (e.g., _nav.html or a component) used on every page -->
<!-- The active page is indicated with aria-current, not by reordering -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/' aria-current='page'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- On the Products page, only aria-current moves — the order stays identical -->

Wizualna zmiana kolejności przez CSS powodująca niespójność — Nieprawidłowe

<!-- DOM order: Home, Products, About, Contact -->
<!-- CSS on interior pages uses flex order to visually move Contact first -->
<style>
  /* Applied only on interior page templates */
  nav ul li:last-child { order: -1; }
</style>
<nav aria-label='Main navigation'>
  <ul style='display:flex'>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Visual order becomes Contact, Home, Products, About — inconsistent with homepage -->

Wizualna zmiana kolejności przez CSS powodująca niespójność — Prawidłowe

<!-- Use consistent DOM order and consistent CSS across all templates -->
<!-- Do not use CSS 'order' property to rearrange navigation items differently per template -->
<nav aria-label='Main navigation'>
  <ul style='display:flex'>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Same DOM order and same CSS flex order on every page template -->

Dynamiczna nawigacja zmieniana przez algorytm — Nieprawidłowe

<!-- JavaScript reorders nav links based on most-visited analytics without user action -->
<script>
  // Anti-pattern: fetches user behaviour data and reorders nav items automatically
  fetch('/api/user-nav-preferences').then(r => r.json()).then(order => {
    const nav = document.querySelector('nav ul');
    order.forEach(id => nav.appendChild(document.getElementById(id)));
  });
</script>
<nav aria-label='Main navigation'>
  <ul>
    <li id='nav-home'><a href='/'>Home</a></li>
    <li id='nav-products'><a href='/products'>Products</a></li>
    <li id='nav-about'><a href='/about'>About</a></li>
    <li id='nav-contact'><a href='/contact'>Contact</a></li>
  </ul>
</nav>

Dynamiczna nawigacja zmieniana przez algorytm — Prawidłowe

<!-- If personalisation is desired, require an explicit user action and keep order stable otherwise -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Personalisation button lets user reorder — change only applies after they interact -->
<button type='button' aria-controls='main-nav-list' id='customize-nav'>Customize Navigation Order</button>
<!-- The user-chosen order is then persisted consistently across all pages -->

Typowe Błędy

• Używanie różnych szablonów CMS, z których każdy definiuje nawigację niezależnie, co powoduje, że z czasem pojawiają się subtelne różnice w kolejności, gdy szablony są aktualizowane osobno zamiast z jednego wspólnego komponentu lub części.
• Promowanie „wyróżnionych” lub „sezonowych” elementów nawigacji na różne pozycje w zależności od kampanii marketingowych, bez zapewnienia, że reszta kolejności nawigacji pozostaje niezmieniona — na przykład tymczasowe przeniesienie „Sale” na pozycję drugą na niektórych stronach i na pozycję piątą na innych.
• Używanie CSS order, flex-direction: row-reverse lub rozmieszczenia w CSS Grid do wizualnej zmiany kolejności elementów nawigacji w różny sposób w zależności od szablonu strony, co tworzy rozbieżność między kolejnością wizualną (którą widzą użytkownicy widzący) a kolejnością w DOM (według której poruszają się użytkownicy klawiatury i czytników ekranu).
• Wstawianie kontekstowych elementów nawigacji w dowolnych pozycjach — na przykład dodanie linku „Back to Category” jako drugiego elementu na stronach produktów, ale nie na innych stronach, co przesuwa wszystkie kolejne elementy o jedną pozycję i łamie oczekiwaną sekwencję.
• Pozwalanie platformom A/B testów lub analitycznym na zmianę kolejności linków nawigacji w ramach wariantów eksperymentów, bez uwzględnienia, że zmiana kolejności jest stosowana niespójnie między stronami i sesjami.
• Traktowanie ścieżki okruszkowej jako wyłączonej z tego kryterium, podczas gdy w rzeczywistości jest ona powtarzającym się mechanizmem nawigacyjnym — breadcrumbs, które pojawiają się w różnych pozycjach względem innych elementów strony w różnych szablonach, również naruszają 3.2.3.
• Zmiana kolejności nawigacji w stopce w inny sposób niż w nawigacji głównej, gdy linki w stopce duplikują główną nawigację — jeśli oba bloki pojawiają się na każdej stronie, oba muszą zachowywać spójną kolejność niezależnie i względem siebie.
• Stosowanie ulepszeń nawigacji sterowanych JavaScriptem, które zmieniają kolejność elementów na podstawie pozycji przewijania, rozmiaru okna lub danych sesji bez inicjatywy użytkownika — na przykład mega-menu, które dynamicznie wyświetla różne kategorie najwyższego poziomu w zależności od tego, w której sekcji witryny znajduje się użytkownik.
• Brak audytu spójności nawigacji po przeprojektowaniu witryny lub migracji CMS, przy założeniu, że deweloperzy naturalnie odtworzą pierwotną kolejność, podczas gdy w rzeczywistości różne typy stron są budowane od zera przez różne zespoły.
• Mylenie „spójnej nawigacji” z „taką samą nawigacją na każdej stronie” — zespoły czasem błędnie wnioskują, że dodawanie lub usuwanie elementów nawigacji dla określonych ról użytkowników (np. zalogowany vs. gość) narusza 3.2.3. Tak nie jest, o ile względna kolejność wspólnych elementów pozostaje niezmieniona.

Związek z Przepisami Dostępności w Turcji

Turecka Okólnik Prezydencki nr 2025/10, opublikowany w Dzienniku Urzędowym (nr 32933) 21 czerwca 2025 r., ustanawia wiążące obowiązki w zakresie dostępności dla szerokiego zakresu podmiotów publicznych i prywatnych prowadzących usługi cyfrowe w Turcji. Okólnik nakazuje zgodność z międzynarodowo uznanymi standardami dostępności — przy czym WCAG 2.2 poziom AA stanowi główny punkt odniesienia technicznego — i wiąże zgodność z Erişilebilirlik Logosu (Logo Dostępności), znakiem certyfikacyjnym wydawanym przez Ministerstwo Rodziny i Usług Społecznych podmiotom, które spełniają wymagany próg dostępności.

WCAG 3.2.3 Spójna nawigacja jest kryterium poziomu AA, co oznacza, że jest to wymóg obowiązkowy dla podmiotów ubiegających się o Erişilebilirlik Logosu. Organizacje, które nie zapewniają spójnej nawigacji w swoich usługach cyfrowych, nie osiągną pełnego profilu zgodności AA wymaganego do certyfikacji, niezależnie od wyników w innych kryteriach.

Następujące typy podmiotów są objęte Okólnikiem Prezydenckim 2025/10 i muszą zatem traktować zgodność z 3.2.3 jako obowiązek prawny, a nie jedynie zalecenie dobrych praktyk:

• Instytucje publiczne i agencje rządowe na wszystkich poziomach, w tym ministerstwa, gminy i podmioty powiązane z państwem, których witryny i portale cyfrowe muszą być nawigowalne w sposób spójny we wszystkich sekcjach.
• Platformy e-commerce działające w Turcji, gdzie spójność nawigacji jest szczególnie krytyczna, ponieważ użytkownicy poruszają się między stroną główną, kategoriami, produktami, koszykiem i stronami płatności — które zazwyczaj współdzielą ten sam pasek nawigacyjny.
• Banki i instytucje finansowe regulowane przez tureckie prawo bankowe, których portale bankowości internetowej i witryny informacyjne muszą zapewniać przewidywalną nawigację dla wszystkich klientów, w tym osób z niepełnosprawnościami poznawczymi lub ruchowymi.
• Szpitale i świadczeniodawcy opieki zdrowotnej, gdzie pacjenci — często w sytuacjach stresowych — polegają na spójnej nawigacji, aby bez zbędnych trudności poznawczych znaleźć rezerwację wizyt, wyniki badań i informacje kontaktowe w nagłych wypadkach.
• Przedsiębiorstwa telekomunikacyjne z 200,000 lub większą liczbą abonentów, których portale klienta, serwisy wsparcia i interfejsy zarządzania kontem muszą utrzymywać spójność nawigacji na potencjalnie tysiącach stron i szablonów skierowanych do użytkownika.
• Biura podróży i prywatne firmy transportowe, gdzie wieloetapowe procesy rezerwacji obejmujące wyszukiwanie, wybór, dane pasażera i płatność muszą prezentować nawigację w spójnej kolejności przez całą ścieżkę.
• Prywatne szkoły autoryzowane przez Ministerstwo Edukacji Narodowej (MoNE), których witryny obsługują uczniów, rodziców i personel — w tym osoby z trudnościami w uczeniu się, które w dużym stopniu polegają na przewidywalnej nawigacji, aby uzyskać dostęp do zasobów edukacyjnych.

Dla organizacji w Turcji budujących lub audytujących usługi cyfrowe, 3.2.3 powinno zostać włączone do procesu zapewniania jakości na etapie projektowania szablonów i komponentów. Użycie współdzielonego komponentu nawigacji renderowanego z jednego źródła prawdy — niezależnie od tego, czy jest to include po stronie serwera, komponent frameworka front-endowego, czy globalny element headless CMS — jest zarówno najbardziej niezawodnym podejściem technicznym, jak i najbardziej defensywną postawą w zakresie zgodności z wymaganiami Okólnika. Audyty dostępności składane w ramach procesu ubiegania się o Erişilebilirlik Logosu powinny zawierać weryfikację kolejności nawigacji między stronami jako udokumentowany krok testowy.