Testarea accesibilității: instrumente gratuite și verificări manuale

Iată o poveste pe care o auzim des. Cineva rulează Lighthouse, primește un 100 verde la accesibilitate și trece mai departe. O săptămână mai târziu, un client scrie că nu a putut plăti, pentru că formularul cardului nu poate fi accesat de la tastatură. Ambele lucruri sunt adevărate. Verificarea automată a trecut, iar site-ul tot l-a lăsat baltă pe un om real.

Acest ghid arată cum testați serios cu un buget mic: ce instrumente gratuite să rulați, o rutină manuală de 15 minute, o primă încercare cu un cititor de ecran și când merită să plătiți pentru un audit.

Îmi poate spune un verificator automat dacă site-ul meu este accesibil?

Nu. Verificatoarele automate găsesc repede unele probleme, dar multe întrebări de accesibilitate au nevoie de un om care să le răspundă. Când Government Digital Service (GDS) din Regatul Unit a testat 10 instrumente pe o pagină cu 143 de erori cunoscute, cel mai bun a găsit 41%. W3C o spune direct: instrumentele de evaluare „nu pot determina accesibilitatea, ele pot doar să ajute la aceasta.”

Testul GDS (se deschide într-o filă nouă) datează din februarie 2017, iar cei 41% (obținuți de Asqatasun) includeau și semnalările instrumentului pentru verificări manuale. Instrumentele s-au îmbunătățit de atunci, dar decalajul are aceeași cauză. Un program poate vedea că o imagine nu are text alternativ. Nu poate vedea că „rochie roșie” este o descriere greșită pentru fotografia unui costum albastru sau dacă ordinea de focalizare are sens.

Așadar, tratați un verificator ca pe un detector de fum, nu ca pe o expertiză tehnică a clădirii. Merită totuși rulat: WebAIM Million 2026 (se deschide într-o filă nouă) a găsit erori detectabile pe 95,9% din primele un milion de pagini principale, așa că majoritatea site-urilor au de câștigat rapid. După cum spune ghidul W3C pentru alegerea instrumentelor (se deschide într-o filă nouă), „Este necesară judecata umană.”

Ce instrumente gratuite de testare a accesibilității să folosesc?

Folosiți unul sau două verificatoare automate, un verificator de contrast și un cititor de ecran. Instrumentele aplică reguli diferite și raportează rezultatele diferit, așa că două verificatoare prind de obicei mai mult decât unul. Fiecare instrument de mai jos are o versiune gratuită. Verificați condițiile actuale ale fiecăruia înainte să vă bazați pe el, pentru că numele, funcțiile și prețurile se schimbă.

Ce pot verifica de mână în 15 minute?

Destul de multe. Verificările rapide (Easy Checks) (se deschide într-o filă nouă) ale W3C acoperă titlurile paginilor, textul alternativ, titlurile din conținut, contrastul, linkurile de salt, focalizarea vizibilă de la tastatură, limba paginii, zoomul, subtitrările și etichetele formularelor. Alegeți o pagină importantă, de exemplu o pagină de produs sau formularul de rezervare, și acordați fiecărei verificări un minut sau două. Veți găsi lucruri pe care niciun verificator nu le raportează.

W3C spune că aceste verificări „acoperă doar câteva probleme de accesibilitate”, deci nu sunt o evaluare completă. Sunt totuși cel mai bun sfert de oră pe care îl puteți investi:

1. Titlul paginii (1 minut). Fila browserului spune ce pagină este, de exemplu „Rezervă o masă | Bistro Rosa”, și nu „Acasă” peste tot?
2. Imagini (2 minute). Afișați textul alternativ cu WAVE sau un instrument similar. Este corect? Sunt sărite imaginile decorative?
3. Titluri (2 minute). Afișați lista titlurilor și citiți-le singure. Funcționează ca un cuprins?
4. Contrast (2 minute). Verificați textul de bază, textul mic gri, textul butoanelor și textul peste imagini.
5. Tastatură (4 minute). Lăsați mouse-ul deoparte și parcurgeți pagina cu Tab (vedeți secțiunea următoare).
6. Zoom (2 minute). La 200%, apoi la 400%, mai puteți citi totul și folosi meniul fără să derulați în lateral?
7. Formulare și limbă (2 minute). Faceți clic pe eticheta fiecărui câmp; într-un formular bine construit, cursorul ajunge în câmp. Verificați în raportul instrumentului dacă lipsește limba paginii.

Cum testez cu tastatura?

Puneți mouse-ul deoparte. Apăsați Tab ca să înaintați, Shift+Tab ca să vă întoarceți, Enter ca să deschideți linkuri, Space sau Enter ca să apăsați butoane și săgețile în meniuri și în grupurile de butoane radio. Fiecare element interactiv trebuie să poată fi accesat, trebuie să vedeți mereu unde vă aflați și nu trebuie să rămâneți niciodată blocat.

Pe Mac, Safari sare peste linkuri când apăsați Tab până când activați, în setările avansate, opțiunea de evidențiere a fiecărui element de pe pagină la apăsarea tastei Tab („Press Tab to highlight each item on a webpage” în versiunea în engleză). Apoi verificați:

• Vedeți mereu unde vă aflați? Dacă dispare conturul de focalizare, cine folosește tastatura e pierdut.
• Ordinea este logică? Focalizarea ar trebui să urmeze ordinea de citire.
• Este ceva acoperit? Un antet fix sau un banner pentru cookie-uri care ascunde elementul focalizat pică criteriul Focalizare neacoperită din WCAG 2.2.
• Puteți ieși din nou? Deschideți fiecare meniu, pop-up și selector de dată, apoi încercați să ieșiți. Tasta Escape ar trebui să închidă ferestrele de dialog.
• Funcționează tot parcursul? Adăugați un produs, schimbați cantitatea, aplicați un cupon și ajungeți la plată fără mouse.

Notați exact fiecare eroare: „Selectorul de mărime de pe pagina produsului nu se deschide cu Enter sau Space” se rezolvă mult mai repede decât „tastatura nu merge”.

Cum testez pentru prima dată cu un cititor de ecran?

Începeți cu cititorul de ecran pe care dispozitivul îl are deja sau cu NVDA pe Windows și ascultați o singură pagină. Nu încercați să-l folosiți ca un expert. Verificați doar că titlurile, linkurile, butoanele, imaginile și câmpurile de formular sunt anunțate cu nume care au sens și că nimic important nu rămâne mut.

• Mac: Command+F5 pornește și oprește VoiceOver; Control+Option+U deschide rotorul, o listă cu titluri, linkuri și câmpuri de formular.
• Windows: în NVDA, apăsați H ca să săriți de la un titlu la altul și Insert+F7 ca să afișați lista de linkuri și titluri.
• Telefon: porniți VoiceOver (iPhone) sau TalkBack (Android) și glisați spre dreapta ca să treceți de la un element la altul. Învățați mai întâi cum îl opriți.

Ascultați ce contează cel mai mult. În sondajul WebAIM din 2024 printre utilizatorii de cititoare de ecran (se deschide într-o filă nouă), 71,6% dintre respondenți au spus că parcurg o pagină lungă mai întâi după titluri, așa că începeți de acolo. Apoi deschideți lista de linkuri: cinci linkuri numite „Citește mai mult” nu spun nimic nimănui. „Adaugă în coș, pulover bleumarin” este un buton util; „buton” nu este. La final, completați un formular și verificați că fiecare câmp și fiecare eroare sunt citite cu voce tare.

Fiți modești în concluzii. Dacă vi se pare că sună stricat, probabil chiar este; dacă vi se pare că sună bine, asta nu e o dovadă. Ca să vedeți cum lucrează utilizatorii experimentați, citiți cum folosesc persoanele cu dizabilități internetul.

Cum verific zoomul, rearanjarea conținutului și spațierea textului?

Măriți pagina în browser la 200% și verificați că textul crește fără să fie tăiat sau să se suprapună. Apoi testați rearanjarea: la un zoom de 400%, într-o fereastră lată de 1.280 de pixeli, conținutul ar trebui să încapă fără derulare în lateral. În final, măriți spațiul dintre litere, cuvinte, rânduri și paragrafe și verificați că nimic nu se strică sau nu dispare.

Acestea corespund criteriilor WCAG Redimensionarea textului (1.4.4), Rearanjarea conținutului (1.4.10) (se deschide într-o filă nouă) și Spațierea textului (1.4.12) (se deschide într-o filă nouă). Rearanjarea folosește o lățime de 320 de pixeli CSS, care, notează W3C, „echivalează cu o lățime inițială a ferestrei de vizualizare de 1.280 de pixeli CSS la un zoom de 400%.” Spațierea textului cere să nu se piardă nimic atunci când un cititor mărește înălțimea rândului la de 1,5 ori mărimea fontului, spațiul dintre paragrafe la dublul mărimii fontului, spațiul dintre litere la 0,12 din mărimea fontului și pe cel dintre cuvinte la 0,16.

Un bookmarklet pentru spațierea textului, adică un mic script salvat ca marcaj în browser, aplică toate cele patru valori dintr-un clic. Căutați text care iese din butoane și etichete tăiate la margine. La un zoom de 400%, un laptop arată cam ce arată un telefon mic, așa că un site responsive bine construit trece deja o mare parte din aceste teste.

Cum verific formularele, mesajele de eroare și finalizarea comenzii?

Completați fiecare formular important de trei ori: o dată corect, o dată cu toate câmpurile goale și o dată cu greșeli intenționate. Fiecare câmp trebuie să aibă o etichetă vizibilă, fiecare eroare trebuie explicată în cuvinte lângă câmpul ei și trebuie să puteți lipi text în câmpurile pentru parolă și pentru codul de verificare.

• Erori. „Date invalide” scris cu roșu nu este suficient. „Introduceți data de expirare în formatul LL/AA”, lângă câmp, este. După trimitere, focalizarea ar trebui să ajungă la rezumatul erorilor sau la primul câmp cu probleme.
• Autentificare și coduri. Potrivit criteriului Autentificare accesibilă (se deschide într-o filă nouă) din WCAG 2.2, blocarea lipirii sau a managerelor de parole pică testul dacă nu există o altă cale de acces.
• CAPTCHA și limite de timp. În sondajul WebAIM, utilizatorii de cititoare de ecran au pus CAPTCHA pe primul loc între elementele problematice de pe web. Verificați dacă există o alternativă accesibilă și dacă limitele de timp pot fi prelungite.

Lista noastră de verificare a accesibilității site-ului conține o listă mai completă pentru magazinele online, inclusiv bannerele pentru cookie-uri și pop-up-urile.

Ce include un audit profesionist de accesibilitate și când am nevoie de unul?

Un audit de accesibilitate este o analiză structurată, făcută de un specialist, în raport cu un standard precizat, de obicei WCAG 2.1 sau 2.2, nivelul AA. Combină scanările automate cu testarea manuală și cu tehnologii asistive a șabloanelor și parcursurilor importante și se încheie cu un raport cu priorități. Aveți nevoie de unul când legea vi se aplică, înaintea unei lansări importante sau când clienții vă cer dovezi.

Înainte să cădeți de acord asupra prețului, întrebați:

• În raport cu ce standard, versiune și nivel veți testa?
• Ce șabloane și parcursuri intră în analiză? Pentru un magazin online: pagina principală, categoria, produsul, coșul, finalizarea comenzii, paginile contului și formularele.
• Testați de mână cu cititoare de ecran, tastatură și zoom și pe ce browsere și dispozitive?
• Raportul ordonează problemele după gravitate, le localizează și propune soluții?
• Este inclusă o retestare?

Prețurile variază mult în funcție de furnizor, țară și aria de acoperire, așa că comparați ce este inclus. Dacă Actul european privind accesibilitatea vi se aplică, un audit vă susține și informațiile publice despre accesibilitate; ghidul nostru despre acest act explică cui i se aplică.

De ce să testați cu utilizatori cu dizabilități?

Pentru că a respecta un standard și a fi ușor de folosit nu sunt același lucru. O pagină de finalizare a comenzii poate trece toate criteriile WCAG și totuși să-i ia unui utilizator de cititor de ecran douăzeci de minute. W3C spune că evaluarea cu utilizatori cu dizabilități „identifică probleme de utilizabilitate care nu sunt descoperite doar prin evaluarea conformității” și îi arată echipei cum folosesc oamenii cu adevărat site-ul.

Nu aveți nevoie de un laborator. Câteva sesiuni pe cea mai importantă sarcină, de exemplu găsirea unui produs și plata, vă vor învăța mai mult decât încă o rundă de scanări. Recrutați participanți prin organizațiile persoanelor cu dizabilități, agenții de cercetare sau dintre propriii clienți și plătiți-i pentru timpul lor. Lăsați-i să folosească propriile dispozitive și setări. Ghidul W3C despre implicarea utilizatorilor în evaluare (se deschide într-o filă nouă) acoperă partea practică.

Ce fac cu rezultatele?

Ordonați problemele după cât de grav îi blochează pe oameni și după locul în care apar, corectați-le în codul și conținutul site-ului, testați din nou și notați ce a rămas nerezolvat. Un câmp fără etichetă la finalizarea comenzii contează mai mult decât o scăpare de contrast în subsol, iar o corectură într-un șablon comun repară fiecare pagină care îl folosește.

1. Stabiliți prioritățile. Mai întâi blocajele de pe parcursurile importante (finalizarea comenzii, rezervarea, înscrierea), apoi șabloanele comune, apoi paginile individuale.
2. Reparați la sursă. Schimbați tema, componenta sau conținutul, nu doar simptomul.
3. Retestați. Repetați aceleași verificări, de mână și cu instrumente.
4. Documentați. Enumerați problemele cunoscute, cu date, în declarația de accesibilitate. Ghidul nostru despre WCAG 2.2 explică criteriile mai noi.
5. Repetați. Adăugați o verificare cu tastatura și o scanare la fiecare lansare.

Dacă folosiți un widget de accesibilitate, inclusiv al nostru, testați cu el închis. Un panou ca SiteAccessible le oferă vizitatorilor moduri suplimentare de a ajusta pagina, dar WCAG întreabă dacă pagina funcționează în starea ei implicită. Unele scheme de audit nu evaluează paginile care rulează un script de tip overlay, așa că întrebați-vă mai întâi auditorul.