Testul rapid de accesibilitate înainte de lansare: ce verificați singur pe site-ul nou
Un ghid pas cu pas pentru verificarea accesibilității înainte de lansare: titluri, texte alternative, contrast, tastatură, formulare și zoom.
- Nº
- 27
- Publicat
- Lectură
- 12 min
- Categorie
- Notes
- Scris de
- Revylio
Testul rapid de accesibilitate: ce verificați și ce nu acoperă
Testul rapid de accesibilitate înainte de lansare este o verificare pe care o faceți singur, în browser, pe câteva pagini ale site-ului nou. Verificați titlurile paginilor, textele alternative ale imaginilor, structura titlurilor, contrastul, navigarea cu tastatura, formularele și zoomul. Testul prinde problemele evidente. Nu înlocuiește un audit complet.
Ghidul de față urmează metoda publicată de W3C Web Accessibility Initiative sub numele Easy Checks, prima evaluare a accesibilității unui site. Verificările din Easy Checks se bazează pe WCAG. WCAG (Web Content Accessibility Guidelines) este standardul internațional pentru accesibilitatea web. Punctele lui principale se numesc criterii de succes (Success Criteria).
W3C spune limpede unde se oprește metoda. Easy Checks nu este o evaluare completă a accesibilității. Pentru o evaluare definitivă și cuprinzătoare este nevoie de specialiști.
Testul contează pentru oameni reali. Un articol despre testarea interfețelor, publicat de Blog De IT, citează statistici OMS: circa 16% dintre oamenii de pe Pământ au o formă de dizabilitate. Mulți dintre ei folosesc tehnologii asistive. Tehnologiile asistive sunt programe sau dispozitive care îi ajută pe oamenii cu dizabilități să folosească webul.
Cititorul de ecran este una dintre aceste tehnologii asistive. El citește cu voce tare conținutul paginii și permite navigarea de la tastatură. Îl folosesc mai ales persoanele nevăzătoare.
Pregătirea testului: ce pagini alegeți și ce instrumente vă trebuie
Pentru testul rapid vă trebuie doar un browser obișnuit. W3C precizează că majoritatea verificărilor merg în orice browser, fără instrumente descărcate. Unele verificări devin mai ușoare cu o extensie de browser, dar nu sunt obligatorii.
Alegeți paginile după rolul lor, nu după ordinea din meniu. O listă scurtă și reprezentativă ar trebui să cuprindă:
- pagina principală;
- o pagină de serviciu sau de produs tipică;
- un articol de blog cu imagini;
- pagina de contact, cu formularul;
- orice pagină cu un traseu important, de exemplu căutarea sau coșul de cumpărături.
Paginile construite pe același șablon au de obicei aceleași probleme. Dacă meniul are o eroare pe pagina principală, o are probabil pe toate paginile. De aceea o pagină din fiecare tip de șablon vă spune mai mult decât zece pagini la rând din aceeași secțiune.
Pregătiți și un fișier simplu pentru notițe. Pentru fiecare problemă scrieți pagina, elementul și ce ați observat. Programatorul are nevoie de aceste trei lucruri ca să repare fără să ghicească. Fără ele, lista de probleme devine o discuție lungă în loc de o listă de sarcini.
Titlul paginii și structura titlurilor: ce aude primul un cititor de ecran
Titlul paginii este primul lucru pe care îl spune un cititor de ecran când utilizatorul ajunge pe o pagină nouă. W3C pornește lista Easy Checks tocmai de aici. Titlul paginii este textul afișat în fila browserului, nu titlul mare din pagină.
Verificarea este simplă. Deschideți fiecare pagină din listă și citiți textul din filă. Fiecare pagină ar trebui să aibă un titlu propriu, care spune despre ce este pagina. Trei pagini cu titlul „Acasă” sau cu numele firmei și nimic altceva sunt o problemă. Un vizitator cu mai multe file deschise nu le poate deosebi.
Structura titlurilor din pagină este a doua verificare. Titlurile au niveluri: un titlu principal, apoi subtitluri, apoi subtitluri ale subtitlurilor. Cititoarele de ecran le folosesc ca pe un cuprins, pentru a sări direct la secțiunea dorită. Un titlu ales doar pentru că „arată mai mare” strică acest cuprins.
Instrumentele automate de accesibilitate raportează titlurile ierarhizate incorect. Un instrument nu vă spune însă dacă textul titlului descrie bine secțiunea. Asta judecați dumneavoastră, citind doar titlurile, în ordine. Dacă din ele înțelegeți conținutul paginii, structura este bună.
Textele alternative ale imaginilor: lipsa se vede automat, calitatea doar de om
Textul alternativ este descrierea unei imagini, scrisă în codul paginii, pe care cititorul de ecran o citește în locul imaginii. Termenul corect este „atributul alt” sau „text alternativ”. W3C notează că „alt tag” este tehnic greșit, deși îl auziți des.
Testele automate vă spun dacă atributul alt lipsește. Nu vă spun dacă textul este potrivit. Pentru asta trebuie să vedeți imaginea și să o judecați în context, explică W3C. Fotografia unei echipe pe pagina de cariere are nevoie de altă descriere decât aceeași fotografie folosită ca fundal.
Imaginile pur decorative au o regulă proprie. Dacă oamenii nu trebuie să afle nimic din imagine, ea primește un atribut alt gol, adică alt="". Cititorul de ecran o sare. Un text alternativ de tipul „imagine1.jpg” sau „poză” este mai rău decât unul gol, pentru că adaugă zgomot.
Verificați separat textul scris în imagini. W3C precizează că textul din imagini nu se mărește când utilizatorul crește dimensiunea textului. Un banner cu oferta scrisă direct în fotografie devine ilizibil pentru cine are nevoie de litere mari. Pentru regulile de format și greutate, vedeți ghidul nostru despre imaginile site-ului și textul lor alternativ.
Contrastul textului: pragul de 4,5:1 și un exemplu real de eșec
Contrastul minim pentru textul de dimensiune normală este de 4,5:1, conform W3C. Raportul compară luminozitatea textului cu luminozitatea fundalului. W3C observă că cerința este numită adesea „contrast de culoare”, dar tehnic este vorba de contrast de luminanță.
W3C dă un exemplu concret în pagina demonstrativă inaccesibilă „BAD Tickets”. Pe unele rânduri, textul este gri închis pe fundal gri deschis. Raportul de contrast măsurat este de 3,76:1. Valoarea este sub pragul de 4,5:1, deci rândurile acelea nu trec testul.
Pentru un ochi obișnuit, pe un monitor bun, textul din exemplul W3C pare totuși lizibil. Exact de aceea contrastul se măsoară, nu se apreciază din ochi.
Pașii pentru propriul site sunt aceiași:
- Notați culoarea textului și culoarea fundalului pentru textul principal, butoane și link-uri.
- Introduceți cele două culori într-un calculator de contrast sau citiți valoarea din instrumentele de dezvoltator ale browserului.
- Comparați raportul cu 4,5:1 pentru textul de mărime normală.
- Notați fiecare combinație sub prag, cu pagina pe care apare.
Contrastul foarte mare nu este automat soluția. W3C atrage atenția că unele persoane cu dificultăți de citire, precum dislexia, nu pot citi culorile foarte luminoase și au nevoie de luminanță scăzută. Țintiți pragul minim fără a orbi cititorul.
Navigarea doar cu tastatura: focusul vizibil, ordinea și capcanele
Navigarea doar cu tastatura este verificarea pe care instrumentele automate nu o fac deloc. Un scan automat nu verifică navigarea exclusiv cu tastatura, ordinea corectă a focusului, interacțiunea cu cititoarele de ecran și comportamentul conținutului dinamic. Focusul este marcajul vizual care arată unde vă aflați în pagină când folosiți tastatura.
Lăsați mouse-ul deoparte și parcurgeți pagina cu tasta Tab. Mergeți înapoi cu Shift și Tab. Activați link-urile și butoanele cu Enter. Urmăriți trei lucruri:
- focusul se vede în orice moment, pe fiecare link și buton;
- ordinea urmează ordinea logică a paginii, de sus în jos;
- puteți ajunge la fiecare element pe care îl puteți folosi cu mouse-ul, inclusiv meniul pe mobil.
Capcana de tastatură este cea mai gravă problemă din această categorie. W3C o descrie ca pe o situație frecventă: focusul intră în controalele unui player video și nu mai poate ieși. Pentru cine folosește doar tastatura, pagina se blochează acolo. Testați fiecare video, hartă încorporată sau fereastră care se deschide peste pagină. Intrați cu Tab și verificați că ieșiți tot cu tastatura.
Nu vă grăbiți cu această verificare. Este partea din testul rapid care spune cel mai mult despre experiența reală a unui utilizator.
Formularele: etichete vizibile, ordinea câmpurilor și erori care nu depind de culoare
Formularul de contact este locul unde problemele de accesibilitate vă costă direct cereri. Fiecare câmp trebuie să aibă o etichetă vizibilă, care rămâne pe ecran și după ce începeți să scrieți. Un text gri în interiorul câmpului, care dispare la prima literă, nu ajunge.
Completați formularul doar cu tastatura, de la primul câmp până la trimitere. Verificați că Tab vă duce prin câmpuri în ordinea în care apar pe ecran. Apoi trimiteți formularul gol sau cu o adresă de e-mail greșită și citiți mesajele de eroare.
Mesajul de eroare trebuie să spună în cuvinte ce este greșit. Un chenar roșu în jurul câmpului nu este suficient. Blog De IT amintește că persoanele cu daltonism nu pot deosebi verdele de roșu. Pentru ele, „câmp corect” verde și „câmp greșit” roșu arată la fel. Scrieți textul erorii lângă câmp și spuneți cum se corectează.
La Svennis, verificăm formularul de contact doar cu tastatura înainte de fiecare lansare, pentru că acolo vedem cel mai des focusul care sare peste un câmp sau eroarea semnalată numai prin culoare. Ambele scapă unui scanner automat și ambele apar la prima trimitere făcută de un om.
Pentru partea de conținut și de conversie a formularului există un ghid separat pe blog. Aici rămâneți la întrebarea simplă: poate cineva să trimită formularul fără mouse și fără să vadă culorile?
Zoom la 200% și ecrane mici: textul trebuie să crească fără scroll orizontal
Verificarea de zoom din Easy Checks cere mărirea paginii la 200%. Folosiți comanda de zoom a browserului și parcurgeți pagina. Textul trebuie să crească, iar conținutul să se reașeze pe lățimea ecranului. Nimic nu trebuie tăiat, suprapus sau ascuns.
Scroll-ul orizontal este semnalul cel mai clar de eșec. W3C precizează că majoritatea oamenilor nu pot citi eficient un text care cere derulare pe orizontală. Pentru unele dizabilități, citirea devine imposibilă. Dacă la 200% trebuie să mutați pagina stânga-dreapta pentru fiecare rând, notați problema.
Ecranele mici pun aceeași întrebare. Website Planet notează că peste 50% din navigarea pe internet se face de pe telefon sau tabletă. Tot acolo se arată că site-urile se construiesc de obicei pe desktop. Pagina recomandă să vă faceți propriile teste chiar dacă tema sau constructorul de site promite că este optimizat pentru mobil.
Testul se face fără telefon. Blog De IT descrie metoda: deschideți Google Dev Tools cu tasta F12 sau cu clic dreapta și Inspect. Apoi alegeți vizualizarea pentru dispozitive mobile. Încercați o rezoluție mică de telefon, de exemplu 393x852 pixeli, pe care Website Planet o listează pentru iPhone 15. Rotiți apoi ecranul simulat și verificați și modul orizontal.
Lista de verificare a testului rapid, într-un singur tabel
Tabelul de mai jos adună toate verificările din acest ghid. Pentru fiecare arată cum o faceți, ce căutați și dacă un instrument automat o poate prinde singur. Coloana a patra explică de ce testul manual rămâne necesar.
| Verificare | Cum o faceți | Ce căutați | O prinde un scan automat? |
|---|---|---|---|
| Titlul paginii | Citiți textul din fila browserului | Titlu unic, care descrie pagina | Parțial: lipsa da, calitatea nu |
| Structura titlurilor | Citiți doar titlurile, în ordine | Niveluri logice, texte care descriu secțiunea | Ierarhia greșită da, sensul nu |
| Text alternativ | Comparați fiecare imagine cu descrierea ei | Descriere potrivită sau alt="" la decor | Lipsa da, potrivirea nu |
| Contrast | Măsurați culorile textului și ale fundalului | Cel puțin 4,5:1 la textul normal | Da, în mare parte |
| Tastatură | Tab, Shift și Tab, Enter, fără mouse | Focus vizibil, ordine logică, fără capcane | Nu |
| Formulare | Completați și trimiteți doar cu tastatura | Etichete vizibile, erori explicate în cuvinte | Nu, pentru ordine și erori |
| Zoom și mobil | Zoom la 200%, apoi vizualizare de telefon | Fără scroll orizontal, fără text tăiat | Nu |
Treceți rezultatul fiecărui rând în notițe, cu pagina și elementul. O listă cu „trece” sau „nu trece” pe fiecare rând este suficientă pentru discuția cu echipa care face site-ul.
Ce nu detectează instrumentele automate și de ce un scor nu înseamnă conformitate
Un scan automat de accesibilitate rulează validatori și raportează doar problemele detectabile tehnic, fără să evalueze experiența reală a utilizatorului. Un astfel de scan prinde, de exemplu, lipsa atributului alt, contrastul insuficient între text și fundal și titlurile ierarhizate greșit. Sunt erori utile de găsit și se găsesc repede.
Restul nu se vede din cod. Scanul nu verifică navigarea cu tastatura, ordinea focusului, felul în care cititorul de ecran anunță rolurile și mesajele sau comportamentul conținutului care se schimbă pe pagină. Tabelul din secțiunea anterioară arată aceeași limită: jumătate din verificări cer un om.
De aceea un scor de 100 dintr-un instrument nu înseamnă un site accesibil. Un scan automat nu poate demonstra conformitatea cu EAA, cu WCAG 2.2 nivel AA sau cu standardul european EN 301 549. Nici un „certificat” emis doar pe baza unui scan automat nu reflectă conformitatea cu WCAG sau EN 301 549.
Testul rapid din acest ghid are aceeași limită, din alt motiv. El acoperă manual verificările de bază, dar nu le acoperă pe toate. Tratați-l ca pe un filtru înainte de lansare, nu ca pe o dovadă de conformitate. Dacă cineva vă oferă un certificat după un scan de câteva minute, cereți să vedeți ce s-a testat manual.
Auditul complet WCAG 2.2 AA: când îl cereți, pentru o firmă din România
Un audit complet este recomandat atunci când site-ul intră sub obligațiile din Legea nr. 232/2022, pentru că vă ajută să demonstrați că serviciul respectă cerințele de accesibilitate. În România, European Accessibility Act (Directiva (UE) 2019/882) a fost transpus prin Legea nr. 232/2022. Cerințele ei se aplică serviciilor furnizate consumatorilor după 28 iunie 2025.
Printre serviciile vizate sunt comerțul electronic, serviciile bancare pentru consumatori, cărțile electronice și serviciile de comunicații electronice. Site-urile prin care se furnizează aceste servicii trebuie să fie accesibile. Microîntreprinderile care furnizează servicii sunt scutite de aceste cerințe. Cine intră sub obligație și ce trebuie verificat acum am explicat separat, în articolul despre accesibilitatea site-ului firmei după EAA.
Un audit complet de accesibilitate combină scanarea automată cu evaluarea manuală. Criteriile sunt cele din WCAG 2.2, nivelurile A și AA, plus standardul EN 301 549. Testarea se face pe un eșantion reprezentativ de pagini și trasee:
- autentificarea în cont;
- căutarea;
- coșul și finalizarea comenzii;
- formularele, ferestrele modale și mesajele de eroare.
Verificarea manuală merge mai departe decât testul rapid. Zoomul și reașezarea conținutului se testează între 200% și 400%, în modurile portret și orizontal. Decizia finală pentru fiecare criteriu WCAG o ia un om, chiar dacă se folosesc instrumente automate.
Pentru un site de prezentare fără vânzări online, testul rapid poate fi un punct de plecare rezonabil. Pentru un magazin online sau un serviciu digital, faceți testul rapid înainte, ca să reparați erorile evidente, apoi cereți auditul complet.
Pașii următori după testul rapid de accesibilitate
Testul rapid vă lasă cu o listă de probleme. Ce faceți cu ea depinde de câte sunt și de unde vin. Ordinea de mai jos funcționează pentru majoritatea site-urilor noi:
- Trimiteți echipei care construiește site-ul lista completă, cu pagina, elementul și ce ați observat.
- Cereți repararea problemelor de tastatură și de formular înainte de lansare. Acestea blochează oameni, nu doar îi încurcă.
- Refaceți exact aceleași verificări pe aceleași pagini după reparații. Nu vă bazați pe impresia vizuală.
- Decideți dacă site-ul are nevoie de un audit complet, după criteriile din secțiunea despre EAA.
Accesibilitatea nu se termină la lansare. Fiecare imagine nouă are nevoie de text alternativ și fiecare pagină nouă de titluri corecte. Stabiliți cine răspunde de asta, după modelul din ghidul despre cine editează site-ul după lansare. Includeți apoi testul rapid în verificările periodice de mentenanță ale site-ului.
Dacă site-ul nu a fost încă construit, scrieți cerințele de accesibilitate direct în brieful pentru refacerea site-ului. Dacă testul arată probleme în aproape fiecare șablon, o reparație punctuală poate costa mai mult decât o refacere. În acest caz, citiți ce include un redesign de site web gândit pentru accesibilitate și discutați varianta cu echipa noastră.