O listă scurtă și asumată pentru butoane web accesibile

Problema cu sfaturile despre accesibilitatea butoanelor

Cele mai multe recomandări despre accesibilitatea butoanelor se împart în două tabere: fie sunt o interpretare WCAG de 40 de pagini pe care nu o citește nimeni, fie sunt o sugestie vagă de a „face butoanele accesibile”, fără pași acționabili. Niciuna nu ajută atunci când livrezi o funcționalitate joi.

Această listă acoperă cele mai frecvente cinci eșecuri de accesibilitate ale butoanelor pe care le vedem în producție. Nu te va transforma într-un expert WCAG, dar va prinde problemele care chiar îi afectează pe utilizatori.

1. Folosește elementul button pentru butoane

Dacă se comportă ca un buton, ar trebui să fie un element <button>. Nu un <div> cu onclick, nu un <span> cu role="button", nu un <a> cu href="#" și preventDefault.

Elementul <button> îți oferă gratuit navigare cu tastatura, gestionarea focusului și anunțuri pentru cititoarele de ecran. Când folosești un <div>, reconstruiești toate acestea de la zero — și le vei implementa greșit.

Singura excepție: dacă acțiunea navighează către o pagină nouă sau schimbă URL-ul, folosește un element <a>. Linkurile și butoanele sunt diferite semantic. Utilizatorii de cititoare de ecran navighează după tipul elementului și se așteaptă ca butoanele să execute acțiuni, iar linkurile să navigheze.

2. Fă zona de interacțiune de cel puțin 44×44 pixeli

WCAG 2.5.5 (Level AAA) cere ca elementele interactive să aibă o dimensiune minimă a țintei de 44×44 pixeli CSS. Nu este vorba despre dimensiunea vizuală — ci despre zona pe care se poate da clic.

Poți avea un buton vizual mic, cu padding adecvat, sau poți extinde zona de interacțiune cu un pseudo-element. Contează ca utilizatorul să nu fie nevoit să țintească precis.

Utilizatorii mobili, persoanele cu deficiențe motorii și oricine folosește un dispozitiv în mișcare vor rata țintele mici. Un buton cu pictogramă de 24×24 pixeli poate arăta curat, dar este un eșec de utilizabilitate.

3. Oferă stări de focus vizibile, nu doar valorile implicite ale browserului

Inelul de focus implicit al browserului este mai bun decât nimic, dar este inconsistent între browsere și adesea invizibil pe anumite fundaluri. Ai nevoie de o stare de focus personalizată care funcționează în sistemul tău de design.

Un indicator de focus bun are trei calități:

• Contrast ridicat: cel puțin 3:1 față de culorile adiacente
• Decalaj vizibil: nu este ascuns de bordura sau fundalul propriu al butonului
• Formă consistentă: utilizatorii ar trebui să îl recunoască drept indicator de focus în întreaga interfață

Nu folosi outline: none fără să îl înlocuiești cu ceva mai bun. Și nu face stările de focus atât de subtile încât doar tu să le poți vedea în condiții perfecte de iluminare.

4. Scrie etichete de butoane care au sens în afara contextului

Utilizatorii de cititoare de ecran navighează adesea sărind între butoane. Când fac asta, aud o listă de etichete de butoane fără contextul din jur.

Un buton etichetat „Află mai multe” este inutil în acea listă. La fel și „Click aici” sau „Trimite”. Eticheta ar trebui să descrie acțiunea: „Descarcă lista de accesibilitate”, „Abonează-te la actualizări”, „Șterge acest comentariu”.

Dacă designul tău necesită o etichetă vizuală scurtă, folosește aria-label pentru a oferi o alternativă descriptivă. Dar soluția mai bună este să scrii etichete care funcționează pentru toată lumea.

Pentru butoanele doar cu pictogramă, aria-label este obligatoriu. Un buton doar cu o pictogramă de lupă are nevoie de aria-label="Search" sau de text echivalent. Pictograma nu este accesibilă pentru cititoarele de ecran.

5. Asigură un contrast de culoare suficient

WCAG 2.1 cere un raport de contrast de cel puțin 4.5:1 pentru text normal și 3:1 pentru text mare (18pt sau 14pt bold). Etichetele de butoane sunt, de obicei, text normal.

Text gri deschis pe un buton alb nu trece. Albastru pal pe un fundal albastru deschis nu trece. Aceste combinații pot părea sofisticate, dar exclud utilizatorii cu vedere slabă, daltonism sau pe oricine privește ecranul în lumina puternică a soarelui.

Folosește un verificator de contrast în timpul designului, nu după lansare. Repararea problemelor de contrast în producție este costisitoare, pentru că adesea necesită modificări ale sistemului de design.

Dacă lucrezi cu instrumente de procesare a imaginilor, procesarea pe partea clientului poate ajuta la păstrarea confidențialității în timp ce generezi asseturi vizuale accesibile — în special când testezi combinații de culori sau generezi stări de previzualizare.

Ce nu acoperă această listă

Această listă este intenționat incompletă. Nu acoperă semantica stărilor dezactivate, stările de încărcare, gestionarea erorilor sau tipare complexe de butoane precum butoanele împărțite sau declanșatoarele de dropdown. Aceste tipare au nevoie de propriile lor recomandări.

De asemenea, nu acoperă întrebarea mai largă despre când să folosești un buton față de alte elemente interactive. Pentru asta, trebuie să înțelegi HTML-ul semantic și arborele de accesibilitate — subiecte care merită articole separate.

Ce acoperă este partea ușor de remediat: greșelile care apar în aproape fiecare code review, care afectează cei mai mulți utilizatori și care sunt cel mai ușor de corectat în timpul dezvoltării.

Cum să integrezi asta în fluxul tău de lucru

Listele de verificare pentru accesibilitate funcționează doar dacă fac parte din procesul de dezvoltare, nu dacă sunt adăugate ulterior. Iată cum poți face asta:

În design: adaugă stări de focus și adnotări pentru zona de interacțiune în fișierele de design. Nu le lăsa pe seama dezvoltatorilor să le ghicească.

În code review: verifică existența elementelor <button>, aria-label pe butoanele cu pictogramă și CSS-ul pentru starea de focus. Acestea se observă rapid.

În testare: parcurge interfața cu tasta Tab. Dacă nu poți ajunge la un buton sau nu poți vedea unde este focusul, nici utilizatorii tăi nu pot.

În documentație: include cerințele de accesibilitate pentru butoane în biblioteca ta de componente. Fă lucrul corect mai ușor decât lucrul greșit.

Dacă depanezi probleme din producție, instrumentele pentru inspectarea antetelor HTTP și a redirecturilor te pot ajuta să înțelegi cum interpretează tehnologiile asistive marcajul tău — în special când investighezi gestionarea focusului după navigare.

Costul omiterii acestei munci

Butoanele inaccesibile nu eșuează doar la conformitatea WCAG — ele rup fluxuri de lucru. Un utilizator care nu poate apăsa un buton de trimitere nu poate finaliza un formular. Un utilizator care nu poate vedea stările de focus nu poate naviga cu tastatura. Un utilizator care nu poate distinge textul butonului de fundal nu poate citi eticheta.

Acestea nu sunt cazuri marginale. Aproximativ 15% din populația globală are o formă de dizabilitate, iar limitările temporare (mouse stricat, lumină puternică a soarelui, ținut un bebeluș în brațe) ajung să afecteze pe toată lumea la un moment dat.

Vestea bună este că accesibilitatea butoanelor este, în mare parte, o serie de probleme deja rezolvate. Nu trebuie să inventezi tipare noi sau să aștepți suport din partea browserelor. Trebuie doar să folosești platforma corect și să îți testezi munca.

Idei principale

• Folosește elemente <button> pentru butoane și elemente <a> pentru navigare — diferența semantică contează pentru tehnologia asistivă
• Asigură zone de interacțiune de cel puțin 44×44 pixeli CSS pentru a acomoda deficiențele motorii și utilizatorii mobili
• Oferă stări de focus vizibile, cu contrast ridicat, care funcționează în întregul tău sistem de design
• Scrie etichete de butoane care au sens când sunt citite izolat și folosește aria-label pentru butoanele doar cu pictogramă
• Verifică contrastul culorilor în timpul designului, nu după lansare, pentru a evita modificări costisitoare ulterior

FAQ

Q: Pot folosi role="button" pe un <div> dacă adaug gestionare pentru tastatură?

A: Poți, dar nu ar trebui. Va trebui să gestionezi manual Enter, Space, gestionarea focusului și stările dezactivate — și inevitabil vei rata ceva. Elementul <button> face toate acestea corect în mod implicit. Folosește-l.

Q: Dar butoanele care comută starea, precum un buton play/pause?

A: Folosește aria-pressed="true" sau aria-pressed="false" pentru a indica starea curentă. Eticheta butonului ar trebui să reflecte și acțiunea care se va întâmpla la clic („Pauză” când redă, „Redă” când este în pauză), nu starea curentă. Utilizatorii de cititoare de ecran trebuie să știe ce va face butonul, nu în ce stare se află sistemul.

Q: Butoanele dezactivate trebuie să respecte cerințele de contrast?

A: WCAG 2.1 scutește controalele dezactivate de cerințele de contrast (1.4.3), dar acest lucru este controversat. Butoanele dezactivate cu contrast slab sunt greu de perceput pentru toată lumea. Dacă vei afișa un buton dezactivat, fă-l lizibil. Și mai bine, ascunde-l sau explică de ce este dezactivat.

Q: Cum testez accesibilitatea butoanelor fără un cititor de ecran?

A: Folosește tastatura. Parcurge interfața cu Tab și verifică dacă poți ajunge la fiecare buton, dacă poți vedea unde este focusul și dacă poți activa butoanele cu Enter sau Space. Asta prinde majoritatea problemelor. Pentru testare mai profundă, folosește inspectorul de accesibilitate din Chrome sau Firefox DevTools pentru a verifica rolul și eticheta calculate.

Q: Care este diferența dintre aria-label și aria-labelledby?

A: aria-label oferă direct un șir de text. aria-labelledby referențiază ID-ul unui alt element al cărui conținut text devine eticheta. Folosește aria-labelledby când textul etichetei există deja în altă parte în DOM. Folosește aria-label când trebuie să oferi o etichetă care nu este vizibilă pe ecran.

Surse

• 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