Accesibilitate pentru dezvoltatori: Construiește cod incluziv
Dezvoltatorii sunt arhitecții accesibilității la nivel de implementare. În timp ce designerii stabilesc fundamentul vizual și de interacțiune, codul este cel care determină în cele din urmă dacă un site web funcționează cu navigarea prin tastatură, comunică corect cu cititoarele de ecran și menține accesibilitatea pe diverse browsere și dispozitive.
Vestea bună este că majoritatea bunelor practici de accesibilitate se aliniază cu bunele practici generale pentru cod curat, semantic și conform cu standardele. A scrie cod accesibil nu înseamnă a adăuga complexitate — înseamnă a scrie cod corect de la început.
HTML semantic mai întâi
Cel mai important lucru pe care îl poți face pentru accesibilitate este să folosești elementele HTML semantice corect. HTML5 oferă o gamă bogată de elemente care poartă semnificație inerentă și funcționalitate de accesibilitate. Un element <button> este automat focalizabil, poate fi activat cu tastatura și este anunțat ca buton de cititoarele de ecran. Un <div> cu un handler onclick nu are niciuna dintre aceste funcționalități fără muncă suplimentară considerabilă.
Folosește <nav> pentru zonele de navigare, <main> pentru conținutul principal, <header> și <footer> pentru secțiunile respective, <section> și <article> pentru zonele de conținut, <h1> până la <h6> pentru titluri în ordine ierarhică corectă, <ul> și <ol> pentru liste, <table> cu <th> pentru date tabulare, <label> cu atribute for pentru câmpurile de formular și elemente native <button> și <a> pentru controalele interactive.
Aceste elemente creează un arbore de accesibilitate pe care tehnologiile asistive îl folosesc pentru a prezenta conținutul utilizatorilor. Când le folosești corect, o mare parte din accesibilitate este gestionată automat.
Structura titlurilor
Titlurile creează structura de nivel a paginii tale. Utilizatorii de cititoare de ecran navighează adesea prin titluri pentru a înțelege organizarea conținutului și a găsi secțiuni specifice. Fiecare pagină ar trebui să aibă exact un singur <h1>, iar titlurile ar trebui să urmeze o ierarhie logică fără a sări niveluri — un <h3> nu ar trebui să urmeze un <h1> fără un <h2> între ele.
Nu folosi niciodată elemente de titlu pentru stilizare vizuală. Dacă ai nevoie de text mare și bold care nu este un titlu, folosește CSS pe alt element. Invers, dacă un conținut funcționează ca titlu, marchează-l ca atare indiferent de prezentarea sa vizuală.
Accesibilitatea tastaturii
Toată funcționalitatea trebuie să poată fi operată doar prin tastatură. Aceasta înseamnă că fiecare element interactiv — linkuri, butoane, câmpuri de formular, meniuri, modale, slidere, taburi — trebuie să fie accesibil prin tasta Tab (sau Shift+Tab pentru ordine inversă), activabil cu Enter sau spațiu și părăsibil acolo unde este relevant.
Nu crea niciodată capcane de tastatură, unde utilizatorii pot naviga cu Tab într-un element dar nu pot ieși din el. Dialogurile modale ar trebui să mențină focusul în interiorul dialogului cât timp acesta este deschis și să returneze focusul la elementul declanșator când se închide, dar apăsarea Escape ar trebui să închidă întotdeauna dialogul.
Asigură-te că ordinea focusului urmează o secvență logică care corespunde layout-ului vizual. Ordinea DOM ar trebui în general să corespundă prezentării vizuale. Evită utilizarea valorilor tabindex pozitive care suprascriu ordinea naturală a focusului și creează confuzie. Folosește tabindex="0" pentru a face elementele non-interactive focalizabile atunci când este necesar și tabindex="-1" pentru elementele care trebuie focalizate doar programatic.
Limba paginii
Specifică limba implicită pe fiecare pagină folosind atributul lang pe elementul <html>. Aceasta spune cititoarelor de ecran ce reguli de pronunție să folosească. Dacă limba se schimbă în cadrul conținutului — de exemplu, o propoziție în franceză pe o pagină în română — marchează schimbarea cu un atribut lang pe elementul care conține textul respectiv.
Accesibilitatea formularelor
Formularele sunt locul unde utilizatorii oferă input și sunt o sursă frecventă de erori de accesibilitate. Fiecare câmp de formular trebuie să aibă o etichetă asociată programatic, de obicei folosind elementul <label> cu un atribut for care corespunde id-ului câmpului. Grupează câmpurile conexe folosind <fieldset> și <legend>.
Când sunt detectate erori de introducere, identifică câmpul cu eroare și descrie eroarea în text. Oferă sugestii de corectare acolo unde este posibil. Pentru câmpurile care acceptă formate specifice, oferă instrucțiuni clare despre formatul așteptat. Folosește atributul autocomplete pentru a activa completarea automată a browserului pentru câmpurile comune precum nume, email, adresă și număr de telefon.
Mesajele de stare care nu primesc focus — precum „produs adăugat în coș" sau „3 rezultate găsite" — trebuie anunțate utilizatorilor de cititoare de ecran prin regiuni ARIA live sau roluri de stare.
Text alternativ
Fiecare imagine non-decorativă trebuie să aibă text alternativ semnificativ care descrie conținutul sau funcția sa. Pentru imaginile informative, descrie ce transmite imaginea. Pentru imaginile funcționale (precum un logo care face link la pagina de start), descrie funcția. Pentru imaginile decorative care nu adaugă informație, folosește un atribut alt gol (alt=""), astfel încât cititoarele de ecran să le sară complet.
Imaginile complexe, precum diagramele, graficele sau infograficele, pot necesita descrieri mai lungi prin intermediul unei legende, text adiacent sau o descriere detaliată cu link.
WAI-ARIA
Specificația pentru Accessible Rich Internet Applications oferă semantică suplimentară în situațiile în care HTML-ul nativ este insuficient. ARIA îți permite să comunici roluri, stări și proprietăți tehnologiilor asistive pentru widget-uri personalizate și conținut dinamic.
Cu toate acestea, ARIA ar trebui folosit cu prudență. Prima regulă a ARIA este: dacă poți folosi un element HTML nativ care are semantica și comportamentul de care ai nevoie, fă-o. ARIA nu adaugă funcționalitate — adaugă doar semantică. Un <div role="button"> necesită în continuare JavaScript pentru gestionarea tastaturii, în timp ce un <button> nativ gestionează aceasta automat.
Folosește rolurile de reper ARIA (sau echivalentele lor HTML5) pentru a defini regiunile paginii. Folosește aria-label și aria-labelledby pentru a furniza nume accesibile acolo unde textul vizibil este insuficient. Folosește aria-expanded, aria-selected, aria-checked și alte atribute de stare pentru a comunica starea curentă a widget-urilor interactive. Folosește regiunile aria-live pentru a anunța actualizări dinamice de conținut.
Design responsive și reflow
Conținutul trebuie să poată fi prezentat fără pierdere de informație la o lățime de 320 pixeli CSS fără a necesita derulare orizontală. Aceasta asigură că utilizatorii care fac zoom la 400% pe un ecran desktop standard pot accesa în continuare tot conținutul. Proiectează layout-urile să reorganizeze conținutul într-o singură coloană la lățimi înguste, în loc să necesite derulare în două dimensiuni.
Linkuri de salt
Oferă utilizatorilor de tastatură un mecanism pentru a sări peste blocurile de conținut repetitiv, cum ar fi meniurile de navigare, și a ajunge direct la conținutul principal. Cea mai comună implementare este un link „Salt la conținutul principal" care este primul element focalizabil pe pagină și devine vizibil când primește focus.
Lista de verificare a dezvoltatorului
Înainte de a lansa o funcționalitate, verifică: toată funcționalitatea funcționează doar cu tastatura; ordinea focusului este logică; focusul este vizibil pe toate elementele interactive; toate imaginile au text alternativ adecvat; toate câmpurile de formular au etichete; limba paginii este specificată; ierarhia titlurilor este corectă; ARIA este folosit corect și doar când este necesar; conținutul se reorganizează la 320px lățime; și actualizările dinamice de conținut sunt anunțate cititoarelor de ecran.
În această secțiune
Este site-ul tău accesibil?
Scanează-ți site-ul gratuit și obține scorul WCAG în câteva minute.
Scanează-ți site-ul gratuit