Accesibilitatea nu este un ultim punct de pe lista de teste QA

În proiectele web, accesibilitatea e încă adesea tratată ca un test final de calitate:

Site-ul e gata, designul e stabilit, componentele funcționează – și abia apoi se uită cineva dacă contrastele sunt bune, dacă există texte alternative și dacă totul se poate folosi de la tastatură. Tehnic, merge cumva. Dar nu prea are sens.

W3C Web Accessibility Initiative recomandă explicit ca accesibilitatea să fie integrată în proiecte de la început. Nu e doar mai eficient, ci previne și situația în care structuri deja terminate trebuie refăcute mai târziu.

Accesibilitatea începe la arhitectură și componente

Multe probleme nu apar din cauza unui singur aria-label lipsă. Apar mult mai devreme. De exemplu, la întrebări precum:

• Este un element cu adevărat un buton sau doar un div pe care se poate da click?
• Poate fi folosită o componentă complet de la tastatură?
• Are ordinea conținutului sens și fără layoutul vizual?
• Pot formularele comunica stări de eroare pe înțeles?
• Funcționează navigarea și fără mouse?
• Ce responsabilitate are CMS-ul și ce responsabilitate are frontendul?

Acestea sunt decizii de arhitectură și de componente. Dacă o componentă de bază e construită greșit și e folosită de 40 de ori pe un site, nu ai 40 de mici probleme de accesibilitate. Ai o problemă structurală.

HTML-ul semantic rezolvă surprinzător de mult

De aceea încerc mai întâi să mă gândesc ce element HTML se potrivește de fapt sarcinii.

Un buton este un <button>.

O navigare este un <nav>.

Titlurile formează o ierarhie logică.

Câmpurile de formular au labeluri.

Sună banal, dar previne multe probleme înainte să fie nevoie de atribute ARIA suplimentare sau de JavaScript.

Pentru mine, accesibilitatea ține deci mai puțin de întrebarea:

„Ce mai trebuie să adăugăm?”

și mai mult de:

„Am construit corect baza?”

Folosirea tastaturii e un bun test de realitate

Unul dintre cele mai simple teste ale mele: las mouse-ul deoparte. Pot folosi pagina complet?

W3C dă accesul de la tastatură ca exemplu de bază: un site accesibil nu are voie să depindă de faptul că utilizatorul poate folosi un mouse. Așa descoperi destul de repede probleme:

• focusul nu e vizibil
• elementele nu pot fi accesate
• modalele nu țin focusul unde trebuie
• meniurile funcționează doar la hover
• ordinea focusului nu are sens

Și multe dintre aceste probleme nu îi afectează doar pe oamenii cu dizabilități permanente.

Accesibilitatea ajută și utilizatorii cu limitări temporare sau de context – de exemplu o mână ruptă, soare puternic sau un loc în care sunetul nu poate fi folosit.

Testele automate ajută – dar nu sunt de ajuns

Unelte precum Lighthouse, axe sau verificările automate din CI sunt foarte utile. Le-aș folosi mereu. Dar pot detecta doar o parte din probleme.

Și W3C subliniază explicit că niciun instrument automat nu poate stabili singur dacă un site îndeplinește cu adevărat toate cerințele de accesibilitate. Pentru asta e în continuare nevoie de o evaluare umană competentă.

Un instrument poate constata, de exemplu, că o imagine are un atribut alt. Dar poate judeca mult mai greu dacă textul din el are sens în contextul concret.

De aceea văd testarea accesibilității mai degrabă ca o combinație de:

Automatizare + teste manuale + înțelegere tehnică.

Pentru mine, accesibilitatea face parte din calitatea software

De aceea nu prea are sens pentru mine să tratez accesibilitatea ca pe un subiect special, separat, care apare cândva la finalul unui proiect. E legată direct de lucrurile care fac oricum un software bun:

• componente curate
• structuri ușor de înțeles
• interacțiuni robuste
• stări clare
• ușurință în utilizare
• mentenabilitate
• teste

W3C definește accesibilitatea web ca premisă pentru ca oamenii să poată percepe, înțelege, naviga și folosi site-uri și aplicații web.

Pentru mine, în dezvoltare asta înseamnă: accesibilitatea nu ar trebui să fie întrebarea pe care o punem chiar înainte de release. Ar trebui să fie una dintre întrebările pe care le punem înainte să construim o componentă.