Button czy div? Semantyczny HTML w praktyce

W kodzie można zrobić „przycisk” praktycznie ze wszystkiego. <div>, <span>, link bez adresu — wystarczy dodać JavaScript i kliknięcie zaczyna działać.

Problem w tym, że kliknięcie myszą to tylko jedna z metod obsługi interfejsu. Natywny element <button> ma już wbudowaną semantykę i zachowanie, które w przypadku zwykłego <div> trzeba odtworzyć samemu.

Co dostajesz za darmo z <button>?

Przeglądarka wie, że <button> jest elementem interaktywnym. Można do niego dojść klawiszem Tab, aktywować go klawiaturą, a technologia asystująca rozpoznaje jego rolę.

<button type="button">Otwórz filtry</button>

Jeżeli tę samą rzecz zrobisz jako div:

<div onclick="openFilters()">Otwórz filtry</div>

mysz zadziała, ale element nie staje się przez to automatycznie przyciskiem dla klawiatury ani czytnika ekranu.

ARIA nie dodaje zachowania

Można dopisać role="button". To jednak nadal tylko informacja o roli. W3C określa to bardzo trafnie: rola ARIA jest obietnicą, że komponent zachowuje się tak, jak oczekuje tego użytkownik.

Jeżeli budujesz przycisk z diva, musisz zadbać między innymi o możliwość otrzymania fokusu oraz obsługę klawiszy Enter i Space. Dochodzi więcej kodu, więcej miejsc na błąd i więcej testowania.

<div role="button" tabindex="0">Otwórz filtry</div>

To nadal nie jest kompletna implementacja. Sam tabindex i rola nie dodają automatycznie całego zachowania natywnego przycisku.

Pierwsza zasada ARIA: jeśli możesz użyć HTML, użyj HTML

Dokumentacja W3C dotycząca ARIA mówi wprost: jeżeli natywny element HTML ma potrzebną semantykę i zachowanie, należy użyć właśnie jego zamiast przebudowywać zwykły element za pomocą ról i właściwości ARIA.

Dotyczy to nie tylko przycisków. Link powinien być linkiem, pole formularza prawdziwym polem formularza, lista listą, a nagłówek nagłówkiem. Natywny HTML jest zwykle najprostszym punktem wyjścia do dostępnego interfejsu.

Kiedy użyć linku, a kiedy buttona?

Prosta zasada pomaga uniknąć wielu pomyłek:

link przenosi użytkownika do innego adresu lub miejsca,
button wykonuje akcję w interfejsie.

„Przejdź do kontaktu” może być linkiem. „Otwórz formularz”, „Pokaż filtry”, „Dodaj do koszyka” albo „Zapisz” to zazwyczaj przyciski.

Styl wizualny nie powinien decydować o semantyce. Link może wyglądać jak duży przycisk CTA, a button jak niewielka ikona. Liczy się funkcja elementu.

Semantyka upraszcza także audyt

W serwisach budowanych z własnych komponentów często spotykamy ten sam problem w wielu miejscach: klikane divy, niestandardowe selecty, własne checkboxy albo linki udające przyciski. Każdy taki komponent wymaga osobnego sprawdzenia obsługi klawiatury, nazwy dostępnej, stanów i komunikacji z technologiami asystującymi.

Dobry komponent oparty na natywnym HTML ogranicza liczbę rzeczy, które można zepsuć. Nie usuwa potrzeby testów, ale zdecydowanie zmniejsza ryzyko.

Jeśli w istniejącym serwisie masz dużo własnych komponentów i nie wiesz, które z nich wymagają przebudowy, możesz napisać na redakcja@dostepnoscwcag.pl. Możemy przejrzeć komponenty, wskazać problemy i wycenić poprawki bez przebudowywania strony w ciemno.

Źródła

Komentarze

Nie ma jeszcze komentarzy. Możesz być pierwszą osobą, która się wypowie.

Cookies i statystyki