Cum alegi un training WCAG bun pentru echipa de dezvoltare
Atunci când o companie începe să acorde mai multă atenție accesibilității web, una dintre soluțiile la care ajunge rapid este un training WCAG pentru echipa de dezvoltare.
Este o idee bună. Dar simplul fapt că dezvoltatorii participă la un curs despre WCAG nu înseamnă că aplicația va deveni automat mai accesibilă.
Există o diferență importantă între a ști ce înseamnă un criteriu WCAG și a putea recunoaște și rezolva o problemă de accesibilitate în codul pe care îl scrii în fiecare zi.
De aceea, înainte să alegi un training, merită să te uiți nu doar la programă și la numărul de ore, ci mai ales la ce vor face efectiv participanții în timpul cursului și ce vor putea face singuri după aceea.
În acest articol explicăm ce ar trebui să conțină un training WCAG destinat dezvoltatorilor, ce întrebări merită să pui unui furnizor și cum îți dai seama dacă un curs este suficient de practic pentru echipa ta.
Ce ar trebui să învețe un dezvoltator dintr-un training WCAG?
Un dezvoltator nu are nevoie doar să memoreze principiile WCAG.
Are nevoie să poată răspunde la întrebări foarte concrete:
- De ce cititorul de ecran nu anunță corect acest buton?
- De ce nu pot ajunge cu tastatura la un anumit element?
- De ce formularul este greu de completat fără mouse?
- Când trebuie să folosesc un element HTML nativ și când am nevoie de ARIA?
- Cum verific dacă o modificare pe care am făcut-o a rezolvat într-adevăr problema?
- Ce pot verifica automat și ce trebuie testat manual?
Acestea sunt situațiile cu care dezvoltatorii se întâlnesc în proiectele reale.
De aceea, un training destinat lor ar trebui să treacă dincolo de prezentarea criteriilor WCAG și să le ofere ocazia să testeze, să identifice probleme și să modifice cod.
De ce nu este suficient un curs despre criteriile WCAG
WCAG este un standard, nu un manual de programare.
El descrie rezultatul pe care trebuie să îl obții pentru ca un site sau o aplicație să fie accesibilă, dar nu oferă pentru fiecare situație o rețetă de implementare.
De exemplu, un criteriu poate spune că o funcționalitate trebuie să fie operabilă cu tastatura. Dezvoltatorul trebuie însă să știe ce înseamnă acest lucru în aplicația la care lucrează.
Cum se comportă focusul?
În ce ordine sunt parcurse elementele?
Ce se întâmplă când se deschide o fereastră modală?
Unde ajunge focusul când aceasta se închide?
Sunt întrebări care nu se rezolvă prin memorarea unui paragraf din standard.
În plus, WCAG nu are o traducere oficială în limba română, iar formulările originale în limba engleză pot fi destul de tehnice. Un training bun ar trebui să facă legătura dintre formularea standardului și situațiile pe care dezvoltatorii le întâlnesc efectiv în proiecte.
Cinci lucruri care nu ar trebui să lipsească dintr-un training WCAG pentru dezvoltatori
1. Testarea cu un cititor de ecran
Un dezvoltator poate înțelege teoretic ce este un „nume accesibil” pentru un element.
Dar lucrurile devin mult mai clare atunci când deschide aplicația cu un cititor de ecran și constată că butonul pe care îl vede pe ecran este anunțat într-un mod neașteptat sau că un câmp de formular nu are o etichetă pe care cititorul de ecran să o poată identifica.
De aceea, participanții ar trebui să testeze ei înșiși interfața.
De exemplu, pot primi o pagină cu:
- butoane fără nume accesibil;
- imagini cu texte alternative nepotrivite;
- câmpuri fără etichete asociate;
- elemente interactive construite cu elemente HTML nepotrivite.
Apoi trebuie să identifice problemele și să le corecteze.
Nu este nevoie de echipamente speciale pentru a începe. De exemplu, NVDA este un cititor de ecran gratuit care poate fi folosit în cadrul unui astfel de exercițiu.
Pentru un dezvoltator, experiența directă este mult mai valoroasă decât o demonstrație de câteva minute făcută de trainer.
2. Navigarea doar cu tastatura
O altă verificare simplă este să renunți complet la mouse.
Participantul trebuie să poată:
- ajunge la toate elementele interactive;
- vedea unde se află focusul;
- deschide și închide componente;
- completa formulare;
- utiliza meniuri;
- parcurge conținutul într-o ordine logică.
Un exercițiu simplu poate porni de la o fereastră modală.
Ce se întâmplă când aceasta se deschide?
Focusul ajunge în locul potrivit?
Poate utilizatorul să iasă din modală?
După închiderea ei, focusul revine unde trebuie?
Acestea sunt probleme foarte concrete, pe care dezvoltatorii le pot identifica mult mai ușor atunci când testează direct.
3. Formulare, etichete și mesaje de eroare
Formularele sunt un alt loc în care accesibilitatea poate avea un impact major asupra experienței utilizatorului.
Un exemplu simplu:
<input type="text" placeholder="Nume">Pentru un utilizator care vede pagina, este destul de clar ce trebuie introdus.
Dar placeholder nu ar trebui să fie folosit ca înlocuitor pentru o etichetă a câmpului.
O variantă mai potrivită este:
<label for="name">Nume</label>
<input id="name" name="name" type="text">Exemplul este simplu, dar tocmai astfel de diferențe trebuie să poată fi recunoscute de dezvoltatori atunci când lucrează la aplicații reale.
Același lucru este valabil pentru mesajele de eroare.
Dacă un formular spune vizual „Completează câmpul”, dar mesajul nu este transmis utilizatorului care folosește un cititor de ecran, problema nu este rezolvată doar pentru că eroarea apare pe ecran.
Într-un training practic, participanții ar trebui să poată porni de la un formular cu probleme și să îl facă accesibil pas cu pas.
4. HTML semantic înainte de ARIA
ARIA este importantă pentru accesibilitatea interfețelor moderne, dar nu ar trebui să fie prima soluție la orice problemă.
Dacă ai nevoie de un buton, începi cu:
<button>Trimite</button>nu cu:
<div role="button">Trimite</div>Al doilea exemplu poate fi făcut să funcționeze, dar dezvoltatorul trebuie să implementeze și comportamente care vin deja cu elementul HTML nativ: tastatură, focus și alte aspecte ale interacțiunii.
Cu cât construiești mai mult manual, cu atât crește și numărul lucrurilor care pot fi greșite.
De aceea, un training bun ar trebui să îi ajute pe dezvoltatori să înțeleagă ce oferă HTML-ul nativ înainte de a apela la ARIA.
Nu înseamnă că ARIA trebuie evitată. Înseamnă că trebuie folosită acolo unde este necesară.
5. Limitele testării automate
Instrumentele automate sunt foarte utile și ar trebui să facă parte din procesul de dezvoltare.
Dar ele nu pot verifica singure dacă un site este accesibil.
Un instrument poate detecta, de exemplu, că o imagine nu are atribut alt.
Nu poate decide întotdeauna dacă textul introdus în alt este relevant.
Poate identifica anumite probleme de contrast, dar nu poate înțelege întotdeauna dacă informația transmisă prin interfață este clară pentru utilizator.
Poate găsi anumite probleme tehnice, dar nu poate înlocui experiența unei persoane care navighează cu un cititor de ecran.
De aceea, dezvoltatorii trebuie să știe unde se termină verificarea automată și unde începe testarea manuală.
Trainingul ar trebui să folosească și cod real
Unul dintre cele mai importante lucruri pe care merită să le verifici atunci când alegi un training este dacă se lucrează pe exemple generale sau și pe aplicația echipei.
Exemplele pregătite de trainer sunt utile pentru explicarea conceptelor.
Dar codul real este cel care ridică întrebările dificile.
O aplicație poate avea:
- componente dezvoltate cu ani în urmă;
- biblioteci externe;
- componente reutilizabile;
- cod moștenit;
- comportamente JavaScript complexe;
- framework-uri și biblioteci de UI;
- soluții care au fost construite înainte ca accesibilitatea să devină o prioritate.
Un training care permite analizarea unor astfel de situații are o valoare mult mai mare pentru echipă.
Nu trebuie ca întregul curs să fie construit pe codul companiei. Este suficient ca o parte a exercițiilor să pornească de la probleme reale.
Ce se întâmplă cu accesibilitatea după training?
Aici apare una dintre cele mai importante diferențe dintre un curs interesant și unul care produce o schimbare reală.
Dacă accesibilitatea rămâne o informație pe care echipa a primit-o într-o zi de training, este foarte ușor ca lucrurile să revină la vechile obiceiuri.
De aceea, merită să te gândești de la început cum va fi introdusă accesibilitatea în procesul de dezvoltare.
De exemplu:
- accesibilitatea poate fi inclusă în criteriile de acceptanță;
- componentele noi pot fi verificate cu tastatura;
- anumite teste de accesibilitate pot fi automatizate;
- echipa poate avea un checklist pentru verificările de bază;
- problemele identificate pot intra în backlog;
- dezvoltatorii pot avea acces la o persoană care îi poate ajuta atunci când apar întrebări.
Scopul trainingului nu este ca dezvoltatorii să știe definiția tuturor criteriilor WCAG.
Scopul este să poată lua decizii mai bune atunci când construiesc produsul.
Este mai bine să faci trainingul înainte sau după un audit?
Depinde de situația echipei.
Dacă dezvoltatorii nu au aproape deloc experiență în accesibilitate, un training poate fi un punct bun de pornire. Îi ajută să înțeleagă problemele și să recunoască greșelile frecvente.
Dacă există deja un audit de accesibilitate, rezultatele lui pot deveni un material foarte bun pentru training.
De exemplu, în loc să lucrezi cu un formular generic, poți analiza un formular din aplicația companiei care a fost identificat în audit ca problematic.
În acest fel, echipa învață pornind de la probleme pe care trebuie oricum să le rezolve.
Este important însă să nu confundăm cele două servicii.
Auditul arată ce probleme există.
Trainingul ajută echipa să înțeleagă cum să le identifice și să le evite în viitor.
Cele două se pot completa, dar unul nu îl înlocuiește pe celălalt.
Cum alegi un training WCAG pentru echipa ta
O ofertă de training poate arăta foarte bine pe hârtie. Câteva întrebări te ajută să vezi cât de practică este în realitate.
Se lucrează efectiv sau se ascultă prezentări?
Întreabă ce procent din timp este rezervat exercițiilor.
Dacă aproape întregul curs este format din prezentări, este posibil să fie mai degrabă un curs introductiv despre WCAG decât un training destinat dezvoltatorilor.
Participanții folosesc un cititor de ecran?
O demonstrație făcută de trainer este utilă, dar nu înlocuiește experiența directă.
Întreabă dacă participanții vor avea ocazia să testeze singuri.
Se lucrează cu tastatura?
Ar trebui.
Este una dintre cele mai simple metode de a descoperi probleme importante de accesibilitate.
Se discută HTML semantic înainte de ARIA?
Este un indicator bun pentru nivelul tehnic al cursului.
Un training destinat dezvoltatorilor ar trebui să explice mai întâi ce poate face HTML-ul nativ și apoi când este justificată utilizarea ARIA.
Se lucrează pe aplicația reală?
Nu este obligatoriu ca întregul training să fie construit în jurul aplicației companiei, dar câteva exemple reale pot face o diferență importantă.
Trainerul înțelege tehnologiile folosite de echipă?
Nu trebuie să fie specialist în absolut fiecare framework.
Dar ar trebui să poată discuta concret despre modul în care principiile de accesibilitate se aplică în mediul tehnic în care lucrează participanții.
Ce rămâne după curs?
Întreabă ce materiale primește echipa și ce se întâmplă după terminarea trainingului.
Un checklist, materiale de referință, criterii de acceptanță sau o sesiune de follow-up pot ajuta mult la aplicarea cunoștințelor.
Ce rezultate poți aștepta în urma unui training WCAG?
Este important să ai așteptări realiste.
Un training poate ajuta o echipă să scrie mai bine codul nou.
Nu repară însă automat problemele dintr-o aplicație existentă.
Dacă produsul este dezvoltat de ani de zile, formarea echipei și remedierea problemelor deja existente sunt două lucruri diferite. Uneori este nevoie de un proiect separat de audit și remediere.
La fel de important: un training nu poate garanta singur conformitatea cu WCAG.
Conformitatea depinde de ceea ce se implementează efectiv în produs și de verificările realizate pe parcurs.
Un rezultat realist și valoros este ca dezvoltatorii să poată:
- recunoaște problemele frecvente de accesibilitate;
- testa interfețele cu tastatura;
- folosi un cititor de ecran pentru verificări de bază;
- înțelege când HTML-ul nativ este suficient;
- folosi ARIA în mod justificat;
- verifice formularele și mesajele de eroare;
- înțeleagă limitele instrumentelor automate;
- introducă accesibilitatea în procesul obișnuit de dezvoltare.
Pentru companiile cărora li se aplică cerințele din Legea 232/2022 privind accesibilitatea produselor și serviciilor, o astfel de pregătire poate ajuta echipa să identifice și să corecteze mai devreme problemele de accesibilitate.
De ce contează experiența practică în accesibilitate
Accesibilitatea web nu se rezumă la respectarea unor reguli în cod.
În spatele fiecărui criteriu WCAG există o situație concretă în care un utilizator poate întâmpina o problemă.
Un buton care nu poate fi accesat cu tastatura.
Un formular pe care cititorul de ecran nu îl poate înțelege.
O fereastră modală din care utilizatorul nu mai poate ieși.
Un mesaj de eroare pe care îl vede utilizatorul, dar nu îl poate identifica prin tehnologia asistivă pe care o folosește.
De aceea, experiența practică este atât de importantă în formarea dezvoltatorilor.
La Fundația TIFLO, trainingurile de accesibilitate pornesc de la această perspectivă: nu doar de la ce spune standardul, ci și de la cum este folosită în realitate o interfață de către o persoană cu dizabilități.
În funcție de nevoile echipei, trainingul poate include exerciții practice, testare cu tehnologii asistive, analizarea unor componente reale și discuții despre modul în care accesibilitatea poate fi introdusă în procesul de dezvoltare.
Vrei un training WCAG adaptat echipei tale?
Un training este mai util atunci când nu pornește doar de la o programă standard, ci și de la nivelul echipei, tehnologiile folosite și problemele cu care dezvoltatorii se confruntă în proiectele lor.
Fundația TIFLO oferă traininguri și sesiuni de coaching în accesibilitate, cu accent pe aplicarea practică a principiilor WCAG.
Dacă vrei să afli ce tip de training s-ar potrivi echipei tale, ne poți contacta pentru o discuție inițială.
Solicită o discuție despre training
Întrebări frecvente despre trainingurile WCAG pentru dezvoltatori
Cât ar trebui să dureze un training WCAG pentru dezvoltatori?
Durata depinde de experiența echipei și de obiectivele trainingului. Dacă există o componentă practică serioasă, este util să existe suficient timp pentru exerciții, nu doar pentru prezentări.
În multe situații, o zi de training poate fi un punct de pornire, urmată de o sesiune de follow-up după ce participanții au avut ocazia să aplice ce au învățat.
Este suficient un curs online gratuit despre WCAG?
Pentru noțiunile de bază, un curs online poate fi foarte util. W3C oferă, de exemplu, cursuri introductive despre accesibilitate digitală.
Un curs online nu poate reproduce însă întotdeauna lucrul direct pe codul echipei, testarea practică și discuțiile despre problemele specifice proiectului.
Cine ar trebui să participe la un training WCAG?
Dezvoltatorii sunt esențiali, dar accesibilitatea nu este responsabilitatea exclusivă a lor.
În funcție de proiect, poate fi util să participe și designeri, QA, product owneri sau alte persoane implicate în definirea și verificarea produsului.
Ce versiune WCAG ar trebui să urmărească un training?
Pentru proiectele noi, WCAG 2.2 este în prezent reperul recomandat de W3C. Pentru majoritatea organizațiilor, nivelul AA este ținta practică relevantă.
Trainingul WCAG înlocuiește un audit de accesibilitate?
Nu.
Un audit identifică problemele existente într-un produs. Trainingul îi ajută pe membrii echipei să înțeleagă accesibilitatea și să evite sau să identifice probleme similare în procesul de dezvoltare.
Trainingul poate fi adaptat tehnologiilor folosite de echipă?
Da. Principiile WCAG rămân aceleași, dar exercițiile pot fi adaptate mediului tehnic în care lucrează participanții.
Este util mai ales atunci când echipa are un sistem de componente, un framework sau anumite tipuri de interacțiuni care apar frecvent în proiect.
Cum verifici dacă un training a avut efect?
Nu doar prin feedback-ul participanților.
Poți urmări dacă accesibilitatea apare în criteriile de acceptanță, dacă problemele sunt identificate mai devreme și dacă dezvoltatorii pot face verificări de bază cu tastatura și cu un cititor de ecran.
Despre autor
Aurel Pătru este profesor, specialist în accesibilitate și fondatorul Fundației TIFLO. De peste 20 de ani activează în domeniul educației, iar de mai bine de 15 ani dezvoltă și implementează soluții de accesibilitate pentru persoanele cu deficiențe de vedere, de la documente și platforme digitale până la spații fizice și materiale Braille și tactile.
