Obietnica decyzji — dla kogo i co dostaniesz
Decyzja: po przeczytaniu wiesz, który typ nawigacji ma sens w twoim design systemie i jakie są najważniejsze pułapki.
Grupa: designerzy i developerzy budujący bibliotekę komponentów dla produktów web i mobilnych.
Pytania, które szybko rozstrzygniemy:
Kiedy użyć top bar vs drawer? Szybka decyzja: top bar — proste, mało poziomów; drawer — gdy potrzebujesz wiele top‑level linków.
Czy trzeba stosować ARIA/landmarki? Tak — zawsze używaj semanticznych elementów i etykietowania, żeby ekranowe czytniki mogły znaleźć nawigację.
Bottom navigation na mobile — kiedy tak? Gdy masz 3–5 równorzędnych, często używanych widoków.
Co to jest nawigacja w kontekście biblioteki komponentów
Nawigacja to zestaw komponentów i reguł, które pozwalają użytkownikowi przemieszczać się między głównymi obszarami produktu (np. home, wyszukiwanie, profil). W praktyce to nie tylko paski i menu, lecz także reguły semantyczne (element <nav>, role/landmark) oraz zachowania (focus, aria-label). Zaleca się trzymać się standardów WAI‑ARIA dla landmarków — szczegóły znajdziesz na stronie W3C [Landmark regions i ARIA]. ([w3.org)
Jak zacząć — 3‑krokowy plan (5–30 minut)
Zrób szybki audit: policz, ile różnych miejsc na stronie pełni funkcję „nawigacyjnego punktu wejścia” (top, side, footer).
Nadaj semanticzną strukturę: użyj <nav> dla głównych menu i unikalnych aria‑label dla wielu navów — to poprawi dostępność i ułatwi testy. Jeśli nie wiesz jak to sprawdzić, otwórz stronę wczytywaną przez czytnik ekranu lub użyj narzędzia accessibility tree. ([developer.mozilla.org)
Zdefiniuj reguły w bibliotece: kiedy stosować top bar, kiedy drawer, jakie propsy muszą być dostępne (label, active state, keyboard handlers).
Fakt → Skutek → Werdykt
Fakt: HTML5 oferuje element <nav> i ARIA ma rolę navigation; semantyka pomaga czytnikom i skraca ścieżkę nawigacji.
Skutek: brak semantyki → utrudniona orientacja dla osób korzystających z technologii pomocniczych.
Werdykt: zawsze używaj <nav> + aria-label tam, gdzie masz więcej niż jedną nawigację. ([developer.mozilla.org)
Fakt: Material Design rozróżnia wzorce (tabs, bottom nav, drawer) i podaje rekomendacje kiedy który wzorzec stosować.
Skutek: zastosowanie niewłaściwego wzorca → zmniejszona użyteczność na danym urządzeniu (np. drawer na desktopie może ukryć ważne destynacje).
Werdykt: dobierz wzorzec do hierarchii informacji i typu urządzenia; stosuj drawer dla wielu top‑level destynacji, tabs/bottom dla szybko przełączanych widoków. ([m1.material.io)
Porównanie: kiedy użyć którego wzorca
| Typ nawigacji | Kiedy stosować | Główna wada | Mini‑werdykt |
|---|---|---|---|
| Top bar (sticky) | Kilka ważnych linków, prosta struktura | Mniej miejsca na długie menu | Dobre dla stron informacyjnych |
| Side nav / Drawer | Wiele top‑level elementów, głębokie struktury | Może ukrywać opcje na mobile | Użyj jeśli >6 destynacji |
| Bottom navigation | Mobile, 3–5 równorzędnych widoków | Nie nadaje się do wielu opcji | Świetne dla aplikacji mobilnych |
| Tabs | Przełączanie między widokami tego samego kontekstu | Nie obsłuży głębokiej hierarchii | Dobre dla filtrowania / widoków sekcji |
Plusy, typowe skargi i jak to wygląda po wdrożeniu
Plusy:
Jasna reguła: semantyka + etykiety → lepsza dostępność i prostsze testy.
Jednolita biblioteka przyspiesza wdrożenia w produktach.
Typowe skargi po wdrożeniu:
"Drawer ukrywa ważne opcje" — oznacza, że architektura informacji nie była przeprojektowana przed wprowadzeniem wzorca.
"Brak focus styles/keyboard navigation" — często brakuje reguł dostępności w komponentach.
Synteza: implementacja nawigacji w bibliotece to nie tylko komponenty UI, to reguły użycia, aria‑props i zestaw testów (klawiatura, czytniki). Brak tych reguł skutkuje błędami użyteczności. ([developer.mozilla.org)
Werdykt — kto powinien wybrać co
Jeśli twój produkt ma proste, rzadko zmieniające się destynacje: top bar lub tabs.
Jeśli masz dużo sekcji i potrzebujesz miejsca na dodatkowe linki: side nav / drawer (ale z jasnym regułami kiedy jest widoczny).
Jeśli budujesz aplikację mobilną z 3–5 kluczowymi widokami: bottom navigation.
Ostateczny werdykt: najpierw uporządkuj hierarchię informacji; potem dobierz wzorzec.
Szybki next step (konkretnie)
Zrób listę wszystkich miejsc z linkami i oznacz ich rolę (global/sekcyjny/footer).
Dodaj semanticzne elementy <nav> i unikalne aria‑label tam, gdzie są więcej niż jeden nav. Przykłady techniczne i wytyczne znajdziesz na stronie W3C [Landmark regions]. ([w3.org)
Przetestuj keyboard-only i z czytnikiem — to wykryje większość problemów.
Źródła i dalej do czytania
WAI‑ARIA Authoring Practices — landmark regions (W3C): [Landmark regions]. ([w3.org)
ARIA: navigation role (MDN): [navigation role]. ([developer.mozilla.org)
Material Design — Navigation patterns: [Navigation patterns]. ([m1.material.io)
Podsumowanie: jeśli priorytetem jest dostępność i przewidywalność — zacznij od semantyki, zdefiniuj reguły użycia wzorców i przetestuj na klawiaturze; to minimalny zestaw, który zmniejszy ryzyko poważnych błędów użyteczności.
