BlogBlooooog

Jak opisywać przyciski

2025-06-07

Choć wiele mówi się o kolorach, kontrastach czy tekstach alternatywnych dla obrazków, często pomijany jest temat… zwykłych przycisków. A to właśnie one odgrywają kluczową rolę w nawigacji i interakcji użytkownika z witryną.

Dlaczego to takie ważne? Dla użytkowników korzystających z czytników ekranu czy klawiatury, źle opisany przycisk to jak zamknięte drzwi – nie wiadomo, dokąd prowadzi. W tym wpisie wyjaśnię, jak opisywać przyciski, by były zgodne z wymaganiami WCAG, a jednocześnie pozostawały przyjazne dla każdego użytkownika.

Jak wygląda budowa przycisku?

Aby klawisz pojawił się na stronie wystarczy wprowadzić w kod strony

<button>Dalej</button>

Czytnik przeczyta zgodnie z tym, czego się zapewnie domyślacie “Dalej” dodając w zależności od swojej konfiguracji nazwę elementu, czyli np. Dalej, klawisz. Wszystko jest zatem w jak najlepszym porządku.

Co jednak, jeśli możemy jedynie użyć tak krótkiej nazwy przycisku, a potrzebujemy przekazać użytkownik, że po kliknięciu na ten przycisk, przejdziemy do strony głównej serwisu? Pierwsze co programista by zrobił, to dopisał parametr title.

<button title="Przejdź do strony głownej">Dalej</button>

I ku zaskoczeniu wszystkich, czytnik tak opisany przycisk, przeczyta jako Dalej. Dlaczego? Ponieważ, w treści przycisku znalazł wszystkie niezbędne informacje. Wyszedł z założenia, że jeśli zapisaliśmy coś w treści przycisku, to informacja ta jest najważniejsza. A co z informacją zawartą w title? Zostanie ominięta, ale pokaże nam się, kiedy użytkownik np. najedzie kursorem myszki na tak opisany obiekt. Wtedy zobaczy “dymek” z napisem “Przejdź do strony głównej”. Niekiedy takie działanie jest porządane, więc nie ma co się na nie “obrażać”.

Nie uzyskaliśmy więc nic po naszej zmianie.

Zanim pokażę najlepsze rozwiązanie, zobaczmy co się stanie jeśli wewnątrz naszego przycisku nie znajduje się żaden opis lub kiedy naszym przyciskiem jest np. ikona.

<button><img src="ikona.jpg" alt=""></button>

Teraz czytnik już nic nie wie, ponieważ poszukując tekstu do przeczytania, z jednej strony trafi na obrazek, który nie został opisany, z drugiej trafi na przycisk, który nie ma opisu ale nie ma również title.

Gdyby nasz klawisz miał, tak jak w przykładzie powyżej, tekst alternatywny, np.

<button><img src="ikona.jpg" alt="Przejdź do strony głównej"></button>

wtedy osiągnęlibyśmy dokładnie to czego oczekujemy, czyli usłyszelibyśmy “Przejdź do strony głównej, przycisk”. Dokładnie to samo uzyskamy opisując nasz element tak:

<button title="Przejdź do strony głownej"><img src="ikona.jpg" alt=""></button>

Jak więc widzicie, sposobów dojścia do zadowalających efektów jest wiele ich wybór zależy od konkretnej sytuacji, w jakiej przycisk występuje. I żeby jeszcze bardziej skomplikować sytuację, stworzono kolejną metodę na opisywanie - czyli wykorzystanie znaczników aria.

Lepsze rozwiązanie – aria-label

aria-label to atrybut specjalnie stworzony z myślą o dostępności. Pozwala przypisać opis, który nie jest widoczny na stronie, ale jest odczytywany przez czytniki ekranu.

<button aria-label="Pokaż dodatkowy opis wydarzenia"><img src="ikona.jpg" alt=""></button>

Czytnik taki zapis zinterpretuje jako: “Pokaż dodatkowy opis wydarzenia, przycisk”. Super. Na dodatek nie będzie wyświetlać żadnych dymków, po najechaniu na przycisk kursorem myszki. Dlaczego więc lepiej zastosować opis umieszczony w aria-label, skoro sami powiedzieliśmy wcześniej, że poprawnych dróg jest tak wiele?

Po pierwsze, ponieważ znacznik aria-label przesłania wszystkie inne treści przycisku (w tym alt obrazka i tekst widoczny w przycisku). Mamy więc pewność, że mimo przekazywania innych parametrów, nasz aria-label zawsze zostanie odczytany przez czytnik. Po drugie, wracając do naszego przykładu

<button><img src="ikona.jpg" alt=""></button>

gdzie czytnik nie dostał jasnej informacji z czym ma do czynienia, zastosowanie aria, pozwala na poprawne odsłuchanie i zinterpretowanie przycisku.

Uwaga!
Jeden z naszych czytelników, słusznie zauważył, że nie powinno się używać przycisków w takiej formie:

<button aria-label="Przejdź do strony głównej"><img src="ikona.jpg" alt=""></button>

Pan Paweł, ma absolutną rację. Taki kod jest technicznie działający, ale semantycznie błędny, ponieważ używa przycisku do nawigacji między stronami, co jest sprzeczne z rolą tego elementu w HTML. Jeśli ma służyć do nawigacji między stronami, powinniśmy do tego celu użyć a. Dziękujemy Panie Pawle za uwagę.

A co z aria-labelledby?

To bardziej zaawansowana wersja aria-label. Pozwala wskazać ID innego elementu, z którego czytnik pobierze treść. Przydatne rozwiązanie, jeśli masz dynamiczne opisy, które chcesz aktualizować z poziomu JavaScriptu.

Przykład:

<button aria-labelledby="opis"><img src="ikona.jpg" alt=""></button> <span id="opis" hidden>Przejdź do strony głównej</span>

Czytnik przeczyta „Przejdź do strony głównej”, nawet jeśli tego nie widać na stronie.

Mamy też aria-describedby

aria-describedby służy do przekazania dodatkowych informacji kontekstowych, które czytnik odczyta po głównej etykiecie (aria-label lub tekst).

Przykład:

<p id="info">Otworzy stronę główną w nowej karcie</p> <button aria-label="Przejdź do strony głównej" aria-describedby="info"><img src="ikona.jpg" alt=""></button>

Możemy zatem poprzez dodanie kolejnego parametru, opisywać wcześniej poprawnie skonstruowany przycisk, kolejnymi informacjami. W tym przypadku, czytnik odczyta nasz przycisk jako: „Przejdź do strony głównej, przycisk. Otworzy stronę główną w nowej karcie.”

Warto więc stosować aria-describedby kiedy chcemy dodać kontekst, a nie chcemy zaśmiecać głównej etykiety. Dobrym pomysłem na stosowanie tego parametru jest sytuacja, kiedy chcemy wyjaśnić działanie, np. Działa tylko na urządzeniach mobilnych czy Otworzy się w nowym oknie.

Podsumowanie

Dobrze opisane przyciski to jeden z filarów dostępności. To, co widzisz jako estetyczną ikonę, może być zupełnie niezrozumiałe dla kogoś, kto korzysta z czytnika ekranu. Unikaj title, kiedy możesz. Używaj aria-label, gdy nie ma tekstu.

Pamiętaj: przycisk nie musi wyglądać jak formularz z lat 90. Powinien mówić jasno, co robi – niezależnie od tego, kto go słucha.