Nawigacja klawiaturą — praktyczne wdrażanie
Jak zapewnić pełną nawigację klawiaturą bez myszki. Kolejność tabulacji, focus states i skróty dostępne dla wszystkich użytkowników.
Dlaczego nawigacja klawiaturą ma znaczenie
Wielu użytkowników nie może korzystać z myszki. Osoby z porażeniem mózgowym, osoby niewidome, osoby ze artretyzmem — wszystkie one polegają na klawiszach, aby poruszać się po stronie. To nie jest przywilej, to podstawowe prawo dostępu do internetu.
W Polsce ustawa o dostępności cyfrowej wymaga, aby publiczne podmioty zapewniały pełną nawigację klawiaturą. Ale to nie dotyczy tylko instytucji publicznych — to jest po prostu dobre projektowanie. Prawie 15% populacji ma jakiś rodzaj niepełnosprawności ruchowej. To nie mała grupa.
Kolejność tabulacji — fundament dostępności
Najważniejszy element. Jeśli źle to zrobisz, reszta nie będzie miała znaczenia.
Ustal logiczną kolejność
Porządek tabulacji powinien być naturalny — od lewej do prawej, od góry do dołu. Użytkownik nie powinien skakać po stronie chaotycznie. Jeśli masz logo po lewej, menu główne pośrodku i wyszukiwanie po prawej, taka powinna być kolejność tabulacji.
Używaj atrybutu tabindex rozsądnie
Najlepiej w ogóle go nie używaj. Elementy interaktywne — przyciski, linki, pola formularza — już mają domyślny porządek tabulacji. Jeśli musisz zmienić kolejność, prawdopodobnie masz problem w HTML-u, a nie w CSS-ie. Tabindex dodatni (1, 2, 3) to pułapka, którą powinnaś unikać.
Testuj z klawiaturą codziennie
Weź swoją stronę. Schowaj mysz. Otwórz przeglądarkę. Naciśnij Tab 50 razy i sprawdź, gdzie się znalazłeś. To jest jedyna rzeczywista weryfikacja. Żaden walidator tego za ciebie nie zrobi.
Focus state — nie schowaj mnie
To chyba najczęstsza błąd. Designer patrzy na focus outline i myśli — „to wygląda brzydko, usunę to”. Nie. Właśnie spaliłeś akcesibilność dla 15% użytkowników.
Focus state powinien być widoczny. Kontrast co najmniej 3:1 w stosunku do otaczającego tła. Najlepiej to solidna obramówka o szerokości 2-3 pikseli, w kolorze, który się wyróżnia. Nawet jeśli to nie pasuje do twojej wizji designu.
Może być subtelne, może być eleganckie — ale musi być tam. Użytkownik klawiatury potrzebuje wiedzieć, gdzie jest.
Skróty klawiszowe — zrób to łatwe
Jeśli użytkownik musi 50 razy nacisnąć Tab, aby dostać się do formularza — to nie jest dostępne. Rozwiąż to skrótami klawiszowymi. Alt+S do wyszukiwania, Alt+H do home, Alt+C do kontaktu. Udostępnij je wszystkim, nie tylko osobom z niepełnosprawnościami.
Praktyczne techniki implementacji
To są rzeczy, które faktycznie działają w projektach produkcyjnych.
Skip links
Pierwsze, co powinno się pojawić, gdy użytkownik naciska Tab — link „Przejdź do treści głównej”. Pozwala pominąć nawigację. Uczy się tego na każdym kursie, ale prawie nikogo to nie robi.
Logiczna struktura DOM
Porządek w HTML-u powinien być taki sam jak porządek wizualny. Jeśli zmieniasz układ CSS-em, focus order będzie chaotyczny. CSS Grid może zmienić wizualny porządek, ale nie porządek tabulacji.
Focus visible
Używaj :focus-visible zamiast :focus. To pokazuje outline tylko wtedy, gdy użytkownik naviguje klawiaturą, a nie gdy kliknie myszą. Najlepsze z obu światów.
ARIA attributes
aria-label, aria-describedby, aria-expanded — te atrybuty pomagają czytelnikom ekranu zrozumieć, co się dzieje. Gdy użytkownik klawiatury wchodzi na przycisk, czytnik ekranu mówi, co to jest.
Testowanie automatyczne
Axe DevTools, Lighthouse, Wave — wszystkie mają testy dostępności klawiatury. Nie są doskonałe, ale łapią 80% problemów automatycznie. Użyj ich w CI/CD.
Testy z rzeczywistymi użytkownikami
Nie wystarczy Ty testować z klawiaturą przez 5 minut. Poproś osobę, która rzeczywiście korzysta z klawiatury, aby przeszła przez Twoją stronę. Zobaczysz rzeczy, które nigdy nie przyszłyby Ci do głowy.
Błędy, które się pojawiają ciągle
Focus outline usuniętym bez zamiennika
CSS: outline: none; bez żadnego innego wskaźnika focus. To jest niepełnosprawny, koniec historii.
Wszystko w divach, nic w buttonach
Elementy <div> nie są klikalne z klawiatury. Użyj <button> i <a>. Czytniki ekranu to wiedzą, użytkownicy klawiatury też.
Dropdown menu, które zamyka się gdy wchodzisz na Tab
Menu wyskakuje na hover. Gdy użytkownik klawiatury tab-uje, focus zmienia się, menu się zamyka. Trap. Implementuj to w JavaScript-ie, nie w CSS.
Okna modalne bez focus trap
Gdy modal się otwiera, focus powinien być wewnątrz niego. Gdy Tab-ujesz poza modal, wraca się do wnętrza. Inaczej użytkownik może wcisnąć Tab 50 razy i nigdy się nie wyrwie.
Nawigacja klawiaturą to nie dodatek
To jest podstawowa funkcjonalność. Jeśli Twoja strona nie jest dostępna z klawiatury, to nie działa dla części Twoich użytkowników. Nie dla małej grupy — dla co najmniej kilkunastu procent populacji.
Dobra wiadomość? To nie jest trudne. Potrzebne są: logiczna struktura HTML-u, widoczny focus state i kilka skrótów klawiszowych. To zajmie Ci może 2-3 dni pracy. Gra warta świeczki.
W Polsce mamy już ustawę o dostępności cyfrowej. W UE jest Dyrektywa o dostępności. To nie jest już temat opcjonalny — to wymóg. Ale nawet bez prawnych wymogów, to jest po prostu właściwe.
Przygotowany do działania?
Zacznij od testowania. Weź swoją stronę. Schowaj mysz. Naciśnij Tab. To wszystko, co musisz wiedzieć.
Przeczytaj o podstawach WCAGℹ Informacja edukacyjna
Ten artykuł jest materiałem edukacyjnym opartym na wytycznych WCAG 2.1 i ustawie o dostępności cyfrowej. Zawiera ogólne zasady i best practices. Konkretne wymogi mogą się różnić w zależności od jurysdykcji, typu organizacji i typu treści. Jeśli pracujesz na stanowisku, gdzie dostępność jest wymogiem prawnym, zapoznaj się z odpowiednimi wytycznymi dla Twojego kraju i organizacji. Ta zawartość nie stanowi porady prawnej.
Powiązane artykuły
Podstawy WCAG 2.1 — od czego zacząć
Wyjaśniamy cztery filary WCAG: dostrzegalność, operacyjność, zrozumiałość i odpo…
Czytniki ekranu — jak projektować zgodnie
Techniczne wskazówki dotyczące semantycznego HTML-a, atrybutów aria i struktur…
Ustawa o dostępności cyfrowej — wymogi dla Polski
Co obowiązuje polskie podmioty publiczne i prywatne? Terminy, sankcje i praktycz…