Należy używać natywnych elementów sterujących, zachować logiczną kolejność w DOM, pozostawić wyraźnie widoczny fokus i przy otwieraniu lub zamykaniu warstwy przenosić go w przewidywalny sposób.
Strony obsługiwanej za pomocą klawiatury potrzebują osoby, które nie korzystają z myszy, pracują z czytnikiem ekranu lub sterowaniem głosowym albo po prostu wybrały szybszy sposób obsługi. Funkcja nie jest dostępna tylko dlatego, że do elementów można dotrzeć klawiszem Tab. Kolejność, widoczny focus i zachowanie dynamicznych komponentów muszą odpowiadać temu, co użytkownik widzi i czego oczekuje.
Najczęstsze problemy pojawiają się przy własnych przyciskach, przestawianiu elementów za pomocą CSS, oknach modalnych i skryptach, które usuwają focus lub go więżą. Rozwiązaniem jest oparcie się na natywnym HTML, zdefiniowanie modelu obsługi klawiaturą dla każdego komponentu i testowanie całego zadania. ARIA może uzupełnić znaczenie, ale nie stworzy brakującego zachowania.
Natywny element zapewnia oczekiwane zachowanie bez skrótów
Link należy stosować do nawigacji, a przycisk do akcji. Oba elementy mogą otrzymać fokus, mają rolę i reagują na oczekiwane klawisze. Klikalny div nie ma tych właściwości, a ręczne dodanie tabindexu nie odtworzy pełnego zachowania. Własny komponent potrzebuje nazwy, roli, stanu, wartości i obsługi klawiatury zgodnej z odpowiednim wzorcem.
Nie należy dodawać dodatnich wartości tabindex, które tworzą odrębną, sztuczną kolejność. Zwykły element powinien podążać za DOM, a programowo fokusowalny kontener może w razie potrzeby użyć wartości ujemnej. Element wyłączony i element tymczasowo niedostępny wymagają zrozumiałego wyjaśnienia, a nie jedynie usunięcia z sekwencji bez kontekstu.
Kolejność fokusu powinna odpowiadać znaczeniu i przepływowi wizualnemu
DOM należy uporządkować zgodnie z naturalną kolejnością czytania i obsługi. Wizualne przesunięcie za pomocą grid lub flex nie może tworzyć rozbieżności, przy której focus skacze po ekranie. Powtarzające się bloki mogą mieć link pomijający, prowadzący do głównej treści. Po jego aktywacji cel musi być prawidłowo oznaczony, a focus lub pozycja zmienione w zrozumiały sposób.
Ukryte menu, nieaktywny panel karuzeli i zamknięte okno dialogowe nie mogą zawierać elementów w sekwencji tabulacji. Z kolei wizualnie dostępny element sterujący nie powinien być nieosiągalny. Przy dodawaniu treści należy zachować pozycję użytkownika, chyba że zadanie wymaga przeniesienia do nowego komunikatu lub początku kroku.
- Kolejność w DOM odpowiada kolejności czytania strony
- brak dodatnich wartości tabindex
- ukryte elementy nie otrzymują fokusu
- link pomijający działa także wizualnie
Widoczny focus musi być wyraźny w każdym stanie i motywie
Nie usuwajcie domyślnego outline bez równoważnego lub lepszego zamiennika. Wskaźnik powinien być widoczny na jasnym, ciemnym i kolorowym tle i nie może go zasłaniać przyklejony (sticky) nagłówek. Sam kolor może zawieść; łączcie kontrast, obrys, grubość lub odsunięcie zgodnie z aktualnymi kryteriami dostępności.
Rozróżniaj stany focus, hover, active, selected i error. Użytkownik klawiatury musi wiedzieć, którym elementem właśnie steruje, a nie tylko który jest wybrany. Testuj styl na wszystkich komponentach systemu projektowego, w tym na linkach w tekście, przyciskach z ikonami, formularzach, kartach i elementach w warstwie nakładki.
Okna modalne i dynamiczne zmiany wymagają kontrolowanego przenoszenia focusu
Po otwarciu modalnego okna dialogowego przenieście fokus na jego nagłówek, wstęp lub pierwszy odpowiedni element sterujący, zależnie od zadania. Fokus powinien pozostawać w oknie, dopóki modalność jest aktywna, a klawisz Escape powinien je zamykać, chyba że istnieje poważny powód, by było inaczej. Tło nie może być obsługiwalne ani ogłaszane jako część okna dialogowego.
Po zamknięciu należy przywrócić fokus na element, który otworzył okno dialogowe, lub na logiczny zamiennik, jeśli został usunięty. Przy routingu po stronie klienta należy ogłosić nowy nagłówek i umieścić fokus zgodnie ze spójnym modelem. Toast lub komunikat na żywo nie powinny bez powodu przejmować fokusu; wystarczy je odpowiednio ogłosić.
- focus po otwarciu w zrozumiałym miejscu
- brak wycieku do nieaktywnego tła
- Escape i widoczny przycisk zamknięcia
- powrót do pierwotnego lub logicznego elementu
- kontrola kolejności w przód i w tył
- żaden fokus pod przyklejonym nagłówkiem
- natywne klawisze zgodne z typem komponentu
- test regresyjny po dynamicznej zmianie DOM
Test manualny przechodzi przez całe zadanie w obu kierunkach
Proszę odłożyć mysz i za pomocą klawiszy Tab, Shift+Tab, Enter, Space, strzałek i Escape przejść przez nawigację, formularz, okno dialogowe, karuzelę oraz własne widżety. Właściwe klawisze zależą od typu komponentu. Należy sprawdzić, czy do każdego elementu można dotrzeć, zrozumieć jego stan, aktywować go i bezpiecznie go opuścić.
Test zopakujte z powiększeniem, czytnikiem ekranu i w kilku przeglądarkach. Narzędzie automatyczne może wykryć brakującą nazwę lub dodatni tabindex, ale nie wykryje nielogicznego przeskoku fokusu ani pułapki w złożonym zadaniu. Test regresyjny dodajcie zarówno do systemu projektowego, jak i do krytycznych ścieżek użytkownika.
Najczęstsze pytania
Czy możemy usunąć outline, jeśli nie pasuje do designu?
Tylko jeśli zastąpią go Państwo wyraźnym, spójnym i wystarczająco widocznym wskaźnikiem fokusu we wszystkich motywach i stanach. Bez zamiennika nie należy go usuwać.
Czy każdy element tekstowy powinien otrzymywać fokus?
Nie. Do sekwencji tabulacji należą elementy interaktywne i konkretne cele programowe. Zwykły tekst czytnik ekranu udostępni bez tabindex.
Czy wystarczy dodać role i tabindex do klikalnego diva?
Nie. Musieliby Państwo dodać także obsługę klawiszy, stany i inne zachowania. Natywny przycisk lub link jest zwykle bardziej niezawodną podstawą.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
