Krótka, subiektywna lista kontrolna dostępnych przycisków w webie

Problem z poradami dotyczącymi dostępności przycisków

Większość wskazówek dotyczących dostępności przycisków wpada do jednego z dwóch obozów: albo jest to 40-stronicowa interpretacja WCAG, której nikt nie czyta, albo niejasna sugestia, aby „tworzyć dostępne przyciski”, bez konkretnych kroków. Żadna z nich nie pomaga, gdy w czwartek wdrażasz funkcję.

Ta lista kontrolna obejmuje pięć najczęstszych błędów dostępności przycisków, które widzimy na produkcji. Nie zrobi z Ciebie eksperta WCAG, ale pozwoli wyłapać problemy, które faktycznie dotykają użytkowników.

1. Używaj elementu button dla przycisków

Jeśli coś działa jak przycisk, powinno być elementem <button>. Nie <div> z onclick, nie <span> z role="button", nie <a> z href="#" i preventDefault.

Element <button> daje Ci nawigację klawiaturą, zarządzanie fokusem i komunikaty czytnika ekranu bez dodatkowej pracy. Gdy używasz <div>, odtwarzasz to wszystko od zera — i zrobisz to źle.

Jedyny wyjątek: jeśli akcja prowadzi do nowej strony albo zmienia URL, użyj elementu <a>. Linki i przyciski różnią się semantycznie. Użytkownicy czytników ekranu nawigują według typu elementu i oczekują, że przyciski wykonują akcje, a linki służą do nawigacji.

2. Zapewnij obszar trafienia co najmniej 44×44 piksele

WCAG 2.5.5 (poziom AAA) wymaga, aby elementy interaktywne miały minimalny rozmiar celu 44×44 piksele CSS. Nie chodzi o rozmiar wizualny — chodzi o obszar, który można kliknąć.

Możesz mieć mały wizualnie przycisk z odpowiednim paddingiem albo powiększyć obszar trafienia za pomocą pseudoelementu. Ważne jest to, aby użytkownik nie musiał celować z dużą precyzją.

Użytkownicy mobilni, osoby z niepełnosprawnościami ruchowymi i każdy, kto korzysta z urządzenia w ruchu, będzie chybiał w małe cele. Przycisk ikonowy 24×24 piksele może wyglądać czysto, ale jest porażką użyteczności.

3. Zapewnij widoczne stany fokusu, które nie są tylko domyślne dla przeglądarki

Domyślna obwódka fokusu w przeglądarce jest lepsza niż nic, ale jest niespójna między przeglądarkami i często niewidoczna na niektórych tłach. Potrzebujesz własnego stanu fokusu, który działa w Twoim systemie projektowym.

Dobry wskaźnik fokusu ma trzy cechy:

• Wysoki kontrast: co najmniej 3:1 względem sąsiadujących kolorów
• Widoczne odsunięcie: nie jest ukryty przez własną ramkę lub tło przycisku
• Spójny kształt: użytkownicy powinni rozpoznawać go jako wskaźnik fokusu w całym interfejsie

Nie usuwaj outline: none bez zastąpienia go czymś lepszym. I nie rób stanów fokusu tak subtelnych, że tylko Ty widzisz je w idealnym oświetleniu.

4. Pisz etykiety przycisków, które mają sens poza kontekstem

Użytkownicy czytników ekranu często nawigują, przeskakując między przyciskami. Gdy to robią, słyszą listę etykiet przycisków bez otaczającego kontekstu.

Przycisk oznaczony „Dowiedz się więcej” jest na takiej liście bezużyteczny. Podobnie „Kliknij tutaj” albo „Wyślij”. Etykieta powinna opisywać akcję: „Pobierz listę kontrolną dostępności”, „Subskrybuj aktualizacje”, „Usuń ten komentarz”.

Jeśli Twój projekt wymaga krótkiej etykiety wizualnej, użyj aria-label, aby dostarczyć opisową alternatywę. Lepszym rozwiązaniem jest jednak pisanie etykiet, które działają dla wszystkich.

W przypadku przycisków składających się wyłącznie z ikon aria-label jest obowiązkowe. Przycisk z samą ikoną lupy potrzebuje aria-label="Search" lub równoważnego tekstu. Ikona nie jest dostępna dla czytników ekranu.

5. Zapewnij wystarczający kontrast kolorów

WCAG 2.1 wymaga współczynnika kontrastu co najmniej 4.5:1 dla zwykłego tekstu i 3:1 dla dużego tekstu (18pt lub 14pt pogrubionego). Etykiety przycisków zwykle są zwykłym tekstem.

Jasnoszary tekst na białym przycisku nie spełnia wymagań. Blady niebieski na jasnoniebieskim tle też nie. Takie zestawienia mogą wyglądać elegancko, ale wykluczają użytkowników słabowidzących, osoby z zaburzeniami rozpoznawania kolorów oraz każdego, kto ogląda ekran w ostrym słońcu.

Używaj narzędzia do sprawdzania kontrastu na etapie projektowania, nie po uruchomieniu. Naprawianie problemów z kontrastem na produkcji jest kosztowne, bo często wymaga zmian w systemie projektowym.

Jeśli pracujesz z narzędziami do przetwarzania obrazów, przetwarzanie po stronie klienta może pomóc chronić prywatność podczas generowania dostępnych zasobów wizualnych — szczególnie przy testowaniu kombinacji kolorów lub generowaniu stanów podglądu.

Czego ta lista kontrolna nie obejmuje

Ta lista jest celowo niepełna. Nie obejmuje semantyki stanów wyłączonych, stanów ładowania, obsługi błędów ani złożonych wzorców przycisków, takich jak przyciski dzielone czy wyzwalacze list rozwijanych. Te wzorce wymagają osobnych wskazówek.

Nie obejmuje też szerszego pytania o to, kiedy używać przycisku zamiast innych elementów interaktywnych. Do tego trzeba rozumieć semantyczny HTML i drzewo dostępności — tematy, które zasługują na osobne artykuły.

Obejmuje natomiast najłatwiejsze do zebrania owoce: błędy, które pojawiają się w prawie każdym code review, wpływają na największą liczbę użytkowników i najłatwiej naprawić je w trakcie developmentu.

Jak włączyć to do swojego workflow

Listy kontrolne dostępności działają tylko wtedy, gdy są częścią procesu developmentu, a nie dodatkiem doklejonym później. Oto jak to osiągnąć:

W projekcie: dodaj stany fokusu i adnotacje dotyczące obszaru trafienia do plików projektowych. Nie zostawiaj tych kwestii developerom do odgadnięcia.

W code review: sprawdzaj elementy <button>, aria-label na przyciskach ikonowych oraz CSS stanu fokusu. To rzeczy, które łatwo zauważyć.

W testach: przejdź przez interfejs klawiaturą, używając klawisza Tab. Jeśli nie możesz dotrzeć do przycisku albo nie widzisz, gdzie jest fokus, Twoi użytkownicy też nie będą mogli.

W dokumentacji: uwzględnij wymagania dostępności przycisków w bibliotece komponentów. Spraw, aby zrobienie właściwej rzeczy było łatwiejsze niż zrobienie niewłaściwej.

Jeśli debugujesz problemy na produkcji, narzędzia do sprawdzania nagłówków HTTP i przekierowań mogą pomóc zrozumieć, jak technologie asystujące interpretują Twój markup — szczególnie podczas rozwiązywania problemów z zarządzaniem fokusem po nawigacji.

Koszt pominięcia tej pracy

Niedostępne przyciski nie tylko łamią zgodność z WCAG — one psują przepływy pracy. Użytkownik, który nie może kliknąć przycisku wysyłania, nie ukończy formularza. Użytkownik, który nie widzi stanów fokusu, nie będzie nawigował klawiaturą. Użytkownik, który nie potrafi odróżnić tekstu przycisku od tła, nie przeczyta etykiety.

To nie są przypadki brzegowe. Około 15% globalnej populacji ma jakąś formę niepełnosprawności, a czasowe ograniczenia (zepsuta mysz, ostre słońce, trzymanie dziecka) prędzej czy później dotykają każdego.

Dobra wiadomość jest taka, że dostępność przycisków to w większości rozwiązane problemy. Nie musisz wymyślać nowych wzorców ani czekać na wsparcie przeglądarek. Musisz po prostu poprawnie używać platformy i testować swoją pracę.

Najważniejsze wnioski

• Używaj elementów <button> dla przycisków i elementów <a> do nawigacji — semantyczna różnica ma znaczenie dla technologii asystujących
• Upewnij się, że obszary trafienia mają co najmniej 44×44 piksele CSS, aby uwzględnić niepełnosprawności ruchowe i użytkowników mobilnych
• Zapewnij widoczne, wysokokontrastowe stany fokusu, które działają w całym systemie projektowym
• Pisz etykiety przycisków, które mają sens czytane osobno, i używaj aria-label dla przycisków składających się wyłącznie z ikon
• Sprawdzaj kontrast kolorów na etapie projektowania, nie po uruchomieniu, aby uniknąć kosztownych poprawek

FAQ

Q: Czy mogę użyć role="button" na <div>, jeśli dodam obsługę klawiatury?

A: Możesz, ale nie powinieneś. Będziesz musiał ręcznie obsłużyć Enter, Space, zarządzanie fokusem i stany wyłączone — i nieuchronnie coś pominiesz. Element <button> robi to wszystko poprawnie domyślnie. Używaj go.

Q: A co z przyciskami, które przełączają stan, jak przycisk odtwarzania/pauzy?

A: Użyj aria-pressed="true" lub aria-pressed="false", aby wskazać bieżący stan. Etykieta przycisku powinna również odzwierciedlać akcję, która nastąpi po kliknięciu („Pauza” podczas odtwarzania, „Odtwórz” podczas pauzy), a nie bieżący stan. Użytkownicy czytników ekranu muszą wiedzieć, co zrobi przycisk, a nie w jakim stanie jest system.

Q: Czy wyłączone przyciski muszą spełniać wymagania kontrastu?

A: WCAG 2.1 zwalnia wyłączone kontrolki z wymagań kontrastu (1.4.3), ale jest to kontrowersyjne. Wyłączone przyciski o słabym kontraście są trudne do zauważenia dla wszystkich. Jeśli zamierzasz pokazać wyłączony przycisk, spraw, aby był czytelny. A jeszcze lepiej: ukryj go albo wyjaśnij, dlaczego jest wyłączony.

Q: Jak testować dostępność przycisków bez czytnika ekranu?

A: Użyj klawiatury. Przejdź przez interfejs klawiszem Tab i sprawdź, czy możesz dotrzeć do każdego przycisku, zobaczyć, gdzie jest fokus, oraz aktywować przyciski klawiszem Enter lub Space. To wyłapuje większość problemów. Do głębszych testów użyj inspektora dostępności w Chrome lub Firefox DevTools, aby sprawdzić wyliczoną rolę i etykietę.

Q: Jaka jest różnica między aria-label a aria-labelledby?

A: aria-label dostarcza bezpośrednio ciąg tekstowy. aria-labelledby odwołuje się do ID innego elementu, którego treść tekstowa staje się etykietą. Używaj aria-labelledby, gdy tekst etykiety istnieje już gdzie indziej w DOM. Używaj aria-label, gdy musisz dostarczyć etykietę, która nie jest widoczna na ekranie.

Źródła

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM