Obietnica decyzji i dla kogo
Ten artykuł daje Ci krótkie, konkretne decyzje: co koniecznie poprawić w przyciskach, linkach i modalach, aby nie zepsuć UX-u użytkownikom klawiaturowym i osobom używającym czytników ekranu. Dla zespołów produktowych, projektantów i frontendów.
Szybkie pytania — od razu decyzja
Czy element wygląda jak przycisk, ale jest linkiem? Zmień: link = nawigacja; button = akcja. (W praktyce: jeśli prowadzi do nowej strony, użyj <a href>.) ([medium.com)
Czy focus jest widoczny po naciśnięciu Tab? Popraw natychmiast — to krytyczny brak dostępności. WCAG wymaga widocznego focusu (2.4.7) i są też bardziej szczegółowe normy dla wyglądu focusu (2.4.13). ([boia.org)
Czy modal blokuje interakcję poza oknem i nie wypuszcza focusu? Nie zostawiaj — modal musi przechwycić focus i przywrócić go po zamknięciu. Zobacz wzorzec dialogu modalnego. W3C dialog pattern. ([w3.org)
Czym są te komponenty i co zwykle psuje UX
Przycisk — element wykonujący akcję (submit, toggle, otwórz modal). Problem: brak semantyki (div/span z role="button" bez obsługi klawiatury), brak nazwy dostępnej (brak widocznego tekstu lub aria-label). W praktyce użytkownik klawiaturowy nie użyje takiego elementu. ([developer.mozilla.org)
Link — element nawigacyjny. Problem: tekst „kliknij tutaj” lub linky-bez-href, które nie dają kontekstu przy skanowaniu linków przez czytniki. W praktyce zwiększa to czas znalezienia celu i powoduje porzucenia. ([ala.org)
Modal — okno nakładkowe, które powinno uczynić treść poza nim inertną. Problem: brak trapu focusu, brak aria-modal/aria-describedby, nieprzywracanie focusu po zamknięciu. W praktyce osoby na czytnikach i poruszające się klawiaturą tracą kontekst. ([w3.org)
Jak zacząć — 5-minutowy check (krok po kroku)
Szybki test ręczny
Użyj tylko klawiatury: naciśnij Tab i Shift+Tab — wszystkie interaktywne elementy powinny być dostępne i mieć widoczny focus. (To weryfikuje SC 2.4.7). ([boia.org)
Otwórz modal i spróbuj wyjść focusem poza okno: jeśli przechodzisz poza, modal nie trzyma focusu — to błąd. Sprawdź, czy Esc zamyka modal. ([w3.org)
Przeczytaj linki bez kontekstu (szybkie skanowanie): czy linki są zrozumiałe samodzielnie? Jeśli nie — popraw tekst linku. ([ala.org)
Jeżeli nie wiesz, czy dana implementacja spełnia wymagania techniczne — użyj narzędzi: VoiceOver/NVDA + Chrome DevTools Accessibility lub prosty skaner (np. WAVE). To da szybki sygnał, co poprawić.
Detale: przyciski — fakt → skutek → werdykt
Fakt: elementy powinny używać natywnego <button> lub mieć kompletną obsługę klawiatury i nazwy dostępnej. ([developer.mozilla.org)
Skutek: jeśli używasz span/div z rolą i nie implementujesz Enter/Space, użytkownik klawiaturowy nie uruchomi akcji.
Werdykt: domyślnie używaj <button>; jeśli używasz ikon, dodaj aria-label. Wyjątek: link wizualnie jak przycisk — tylko jeśli rzeczywiście nawigujesz, zostaw <a href> z opisowym tekstem.
Detale: linki — fakt → skutek → werdykt
Fakt: linki są skanowane przez czytniki i powinny mieć sens poza kontekstem. ([ala.org)
Skutek: „kliknij tutaj” albo nieopisany link utrudnia zrozumienie celu i obniża konwersję.
Werdykt: Zadbaj o samodzielny tekst linku; używaj href tam, gdzie następuje nawigacja.
Detale: modale — fakt → skutek → werdykt
Fakt: modal powinien uczynić zawartość poza nim inert i trzymać focus w swoim obszarze; aria-modal i opis są istotne. ([w3.org)
Skutek: brak trapu focusu dezorientuje użytkownika i może ukryć elementy potrzebne do zamknięcia.
Werdykt: Modal = focus trap + aria-modal + widoczne przyciski zamknięcia; jeśli nie da się tego łatwo zrobić, zamiast modalnego użyj panelu bocznego lub nowej strony.
Tabela: szybkie porównanie i mini-werdykty
| Komponent | Typowy problem | Wpływ UX | Werdykt |
|---|---|---|---|
| Przyciski | Semantyka zastąpiona div/span | Klawiatura nie działa | Użyj <button> |
| Linki | „kliknij tutaj”, brak href | Trudne skanowanie | Zrób opisowy tekst |
| Modale | Brak trapu focusu | Utrata kontekstu | Focus trap + aria-modal |
Plusy i typowe skargi — synteza
Plusy naprawionych komponentów: mniejsza liczba porzuconych formularzy, lepsze wskaźniki konwersji, niższe ryzyko skarg/prawnych problemów. Typowe skargi po złej implementacji: „nie mogę zamknąć okna klawiaturą”, „nie widzę, co jest aktywne”, „linki bez sensu”.
Co sprawdzić technicznie (krótkie checklisty)
Przyciski: natywny element lub komplet Enter/Space + aria-label dla ikon. ([developer.mozilla.org)
Focus: nie usuwaj domyślnego outline bez alternatywy; sprawdź Tab, Shift+Tab. ([boia.org)
Modale: aria-modal / aria-describedby, trap focusu, Esc do zamknięcia, przywrócenie focusu po zamknięciu. ([w3.org)
Podsumowanie — decyzja finalna
Idealne dla Ciebie: jeśli priorytetem jest dostępność i niskie ryzyko problemów prawnych, napraw focus i semantykę przycisków/linków oraz modal jako pierwsze.
Będzie frustrować: jeśli ignorujesz focus i używasz elementów bez semantyki — użytkownicy klawiaturowi i korzystający z czytników będą blokowani, a współczynnik porzuceń wzrośnie.
Następny krok (prosty): wykonaj 5-minutowy test klawiaturą z opisanym wyżej checklistem i otwórz dokumentację wzorca modalnego: W3C dialog pattern. ([w3.org)
