Zacznij od zadań i małej architektury informacji
Architektura informacji to sposób grupowania, nazywania i łączenia treści oraz funkcji. Wypisz zadania odwiedzających, a następnie zmapuj stronę startową każdego zadania, stronę następną i stan końcowy sukcesu. To pokaże, czy pozycja w menu jest przydatna, czy raczej wewnętrzną etykietą, którą użytkownicy muszą rozszyfrować. Trzymaj główną nawigację skoncentrowaną na sekcjach, które rozpoczynają te zadania.
Nawigacja to nie mapa witryny. GOV.UK radzi wypisywać użyteczne sekcje najwyższego poziomu zamiast każdej części usługi. Gdy podróż wymaga określonej kolejności, pokaż ją w treści lub w liście zadań zamiast zmuszać ludzi do wywnioskowania jej z globalnego menu.
Łącz strony, gdy odwiedzający oczekują tej samej odpowiedzi lub celu, a nie dlatego, że jedne posiada inny zespół.
Używaj stron docelowych i linków kontekstowych dla szczegółów zamiast gęstego nagłówka.
Używaj etykiet, które przewidują cel
Etykieta to obietnica tego, co nastąpi dalej. Preferuj znane nazwy takie jak „Cennik”, „Dokumentacja”, „Wsparcie” lub „Zarządzaj kontem”, gdy odpowiadają one docelowemu miejscu. Unikaj niejasnych etykiet typu „Zasoby” czy „Eksploruj”, chyba że odwiedzający mogą przewidzieć, co się pod nimi znajduje. Zachowaj spójność słownictwa i kolejności.
Google zaleca zwięzły, istotny tekst linków zrozumiały poza kontekstem. Ogólne „kliknij tutaj” i nadmierne upychanie słów kluczowych tego nie robią. Kontrolce tylko z ikoną nadaj dostępny (accessible) name opisujący jej działanie.
Użyj „Zobacz plany” zamiast „Dowiedz się więcej”, gdy cel to plany.
Oznacz aktywne miejsce wizualnie i programowo; W3C opisuje aria-current=page dla wyświetlanej strony.
Spraw, by miejsca docelowe były crawlable i strukturalnie jasne
Miejsce docelowe nawigacji powinno być zwyczajowo kotwicą HTML z atrybutem href wskazującym realny adres internetowy. Google mówi, że zwykle potrafi przeszukać taką formę, włącznie z dynamicznie wstawionymi kotwicami, gdy renderowany markup zachowuje tę strukturę. Sam handler kliknięcia lub niestandardowy atrybut nie jest niezawodnym substytutem. Sprawdzaj renderowany output, nie tylko kod źródłowy frameworka.
Używaj semantycznej struktury wokół głównej nawigacji. W3C rekomenduje element nav i, dla zwykłej nawigacji strony, listę. Jeśli strona ma kilka regionów nawigacyjnych, oznacz każdy, aby użytkownik czytnika ekranu mógł odróżnić nawigację główną od stopki czy nawigacji lokalnej.
Potwierdź, że ważne destynacje na desktopie i mobilnie mają kotwice i wartości href po wyrenderowaniu po stronie klienta.
URL Inspection dostarcza informacji o crawl, index i serving w Google; nie dowodzi, że odwiedzający faktycznie mogą znaleźć stronę.
Zaprojektuj menu mobilne jako kompletną interakcję
Responsywna nawigacja może się zwijać, ale destynacje, które pozostają, powinny zachować to samo słownictwo, kolejność i cel na wszystkich rozmiarach ekranu. W3C dopuszcza zwijanie lub ukrywanie pozycji w subnawigacji, jednocześnie postulując spójność. Nie czyn więc krytycznej ścieżki dostępną tylko na desktopie, bo nagłówek jest zapchany; przenieś materiały o niższym priorytecie lub przemyśl hierarchię.
Dla menu typu show-and-hide użyj przycisku do kontrolowania grupy linków i komunikuj, czy jest otwarte. Przykład disclosure-navigation W3C używa aria-expanded i aria-controls oraz opisuje Tab, Shift+Tab i Escape. To przykład edukacyjny, więc testuj swój komponent z kombinacjami używanymi przez twoją grupę odbiorców.
Gdy potrzebna jest zarówno strona nadrzędna, jak i linki potomne, rozróżnij link do strony od kontrolki rozwijającej ją.
Wszystko ujawnione przez najechanie wskaźnikiem musi być wykrywalne przy fokusie klawiatury i dotyku.
Wspieraj orientację i podróż klawiaturą
Dostępność klawiaturowa to nie dodatek na końcu. WCAG 2.1 Success Criterion 2.1.1 wymaga, by funkcjonalność była obsługiwana przez interfejs klawiaturowy z wyjątkiem wejścia zależnego od ścieżki. W nagłówku odwiedzający powinni móc Tabować przez kontrolki, widzieć fokus, aktywować linki i przyciski oraz wychodzić bez utknięcia (no trap).
Powtarzające się linki nagłówka mogą spowalniać poruszanie się po stronie. Skip link blisko początku daje użytkownikom klawiatury drogę do głównej treści. GOV.UK wyjaśnia, że link jest ukryty wizualnie aż do momentu aktywacji klawiaturą. Testuj, czy prowadzi do sensownego celu.
Nie usuwaj wskaźnika fokusu przeglądarki bez jasnej alternatywy, która pozostaje widoczna przy powiększeniu.
Użyj Tab, Shift+Tab, Enter, Space i Escape od nagłówka do strony docelowej.
Testuj odnajdywalność przed i po wydaniu
Poproś reprezentatywnych ludzi, aby wykonali realistyczne zadanie, np. znalezienie instrukcji anulowania lub porównanie planów. Obserwuj, gdzie oczekują trafienia, które etykiety źle odczytują i czy uciekają się do wyszukiwarki, bo nawigacja ich zawiodła. Nie kieruj ich do zamierzonej etykiety. Zarejestruj każdą przeszkodę i najmniejszą zmianę, która ją usunie.
Połącz testy z kontrolami technicznymi. Easy Checks W3C zaleca testowanie bez myszy, w tym widoczność fokusu, porządek tabulacji, pułapki klawiaturowe i dropdowny. Powtórz kluczowe zadania przy wąskich szerokościach i większych rozmiarach tekstu. Automatyczne kontrole mogą wskazać problemy z markupem, ale nie potwierdzą, że etykieta ma sens.
Zanotuj zamierzony punkt końcowy i obsługiwane urządzenie lub metodę wejścia przed testowaniem.
Testuj starą i nową trasę na tych samych zadaniach, zamiast polegać na preferencjach interesariuszy.
Traktuj zmiany nawigacji jako wydania wrażliwe na dostępność
Nagłówek może się załadować, podczas gdy krytyczna ścieżka jest faktycznie niedostępna: koszyk, logowanie, trasa do wsparcia czy strona dokumentacji może być za złym stanem, przestarzałym linkiem lub błędnym przekierowaniem. Przed wydaniem zinwentaryzuj krytyczne destynacje, przetestuj trasy na desktopie i mobilnie oraz potwierdź, że renderowane linki prowadzą do oczekiwanej strony. Używaj autoryzowanych środowisk dla ścieżek wymagających uwierzytelnienia lub ograniczeń regionalnych.
Rola SIU to proaktywne naprawianie: wykonaj preflight, zweryfikuj niezbędne ścieżki po wdrożeniu i spraw, by poprawka była odwracalna. Przechowuj wersjonowaną konfigurację menu, wskaż osobę, która może ją przywrócić, i zwaliduj przywrócone trasy. To ogranicza wpływ wydania; nie zastępuje badań użyteczności ani monitorowania statusu w czasie rzeczywistym.
Zablokuj publikację, gdy krytyczne miejsce docelowe jest brakujące, błędne lub nieosiągalne klawiaturą i dotykiem.
Udokumentuj poprzednią konfigurację, właściciela, warunek wyzwalający i kroki walidacji przed przekształceniem.