Ce este nou în WCAG 2.2? Cele 9 criterii noi, pe înțelesul tuturor

Cineva care folosește tastatura parcurge cu Tab pagina de finalizare a comenzii. Focalizarea ajunge pe butonul „Plătește acum”, dar deasupra lui stă un banner fix pentru cookie-uri, așa că persoana nu vede unde se află. Potrivit WCAG 2.1, pagina putea fi totuși conformă. Potrivit WCAG 2.2, nu mai este.

Este genul de lacună pe care o închide actualizarea 2.2. Mai jos, fiecare criteriu de succes nou este tratat la fel: ce spune, pe cine ajută, un test rapid și corectura obișnuită. Denumirile criteriilor sunt traducerile noastre, pentru că W3C nu are o traducere autorizată a WCAG în limba română; în tabel găsiți și numele originale, în engleză. Pentru cele patru principii și nivelurile adunate pe o singură pagină, consultați referința noastră WCAG 2.2.

Ce este WCAG 2.2?

WCAG 2.2 este versiunea actuală a Ghidului pentru accesibilitatea conținutului web (Web Content Accessibility Guidelines), standardul W3C la care trimit majoritatea legilor și contractelor privind accesibilitatea. A devenit recomandare W3C la 5 octombrie 2023 (se deschide într-o filă nouă), a fost actualizat la 12 decembrie 2024 (se deschide într-o filă nouă) și a fost aprobat ca ISO/IEC 40500:2025 (se deschide într-o filă nouă) în octombrie 2025.

WCAG este alcătuit din afirmații testabile, numite criterii de succes, fiecare cu un nivel: A (minimul), AA (ce cer de obicei legile) sau AAA (cel mai strict). „Avem nevoie de WCAG 2.2 AA” înseamnă toate criteriile de nivel A și AA din versiunea 2.2. Specificația spune că 2.2 „pornește de la WCAG 2.1 și este compatibil cu acesta”, deci adaugă la 2.1, nu îl înlocuiește.

Ce s-a schimbat de la WCAG 2.1 la 2.2?

WCAG 2.2 adaugă nouă criterii de succes și elimină unul. Șase dintre cele noi sunt de nivel A sau AA, deci contează pentru ținta obișnuită AA: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 și 3.3.8. Celelalte trei sunt AAA. Criteriul eliminat este 4.1.1 Analiză sintactică (Parsing), pe care W3C îl descrie acum drept învechit.

Criteriul 4.1.1 Analiză sintactică verifica erorile de marcaj, cum ar fi ID-urile duplicate. Întrebările frecvente despre WCAG 2 (se deschide într-o filă nouă) explică faptul că aceste probleme intră acum sub alte criterii, de exemplu 4.1.2 Nume, rol, valoare. Un singur detaliu: dacă un contract cere încă WCAG 2.0 sau 2.1, „s-ar putea să trebuiască să continuați să testați și să raportați 4.1.1”.

Focalizare neacoperită și aspectul focalizării: văd utilizatorii de tastatură unde se află?

Aceste criterii păstrează vizibil elementul care are focalizarea de la tastatură. La nivelul AA (2.4.11), un link sau un buton focalizat nu trebuie să fie ascuns complet de conținut adăugat de dumneavoastră, cum ar fi un antet fix, un banner pentru cookie-uri sau o bulă de chat. La nivelul AAA, nimic nu are voie să acopere vreo parte din el (2.4.12), iar conturul de focalizare trebuie să fie mare și cu un contrast clar (2.4.13).

• Pe cine ajută: persoanele văzătoare care folosesc tastatura în locul mouse-ului, adesea din cauza unei dizabilități motorii. Dacă nu văd focalizarea, merg pe ghicite.
• Test rapid: încărcați o pagină lungă cu bannerul pentru cookie-uri, antetul fix și widgetul de chat afișate, apoi apăsați Tab de mai multe ori. Dacă focalizarea dispare complet în spatele unui element, criteriul 2.4.11 nu este îndeplinit.
• Corectura obișnuită: adăugați în CSS un scroll padding egal cu înălțimea antetului sau a subsolului fix, ca browserul să deruleze elementele focalizate până nu mai sunt acoperite. W3C enumeră această soluție drept tehnică suficientă (se deschide într-o filă nouă). Un banner poate trece și dacă este modal și trebuie închis mai întâi.

Aspectul focalizării (2.4.13) cere un indicator cel puțin la fel de mare ca un contur gros de 2 pixeli CSS în jurul componentei, cu o schimbare de contrast de cel puțin 3:1 între starea focalizată și cea nefocalizată. Este un criteriu AAA, dar un contur continuu de 2 pixeli într-o culoare puternică este de obicei suficient. Ghidul nostru despre contrastul culorilor explică cum se măsoară raportul de 3:1.

Mișcări de glisare și dimensiunea țintei: se poate folosi site-ul fără o țintire precisă?

Aceste două criterii de nivel AA îi ajută pe cei cărora le este greu să controleze fin cursorul. 2.5.7 spune că orice se poate face prin glisare trebuie să funcționeze și cu clicuri sau atingeri simple. 2.5.8 spune că țintele trebuie să aibă cel puțin 24 pe 24 de pixeli CSS sau să fie distanțate astfel încât un cerc de 24 de pixeli centrat pe fiecare să nu atingă altă țintă.

2.5.7 Mișcări de glisare

Gândiți-vă la glisorul pentru intervalul de preț din filtrele unui magazin sau la o listă de dorințe pe care o reordonați prin glisare. Pentru cineva cu tremor sau care folosește un dispozitiv de indicare montat pe cap, secvența apăsare, menținere, mutare, eliberare poate fi foarte grea.

Test rapid: duceți la capăt fiecare acțiune de glisare doar cu clicuri sau atingeri. Corectura obișnuită: permiteți clicul oriunde pe traseul glisorului, adăugați lângă el câmpuri „min” și „max” sau puneți butoane „Mută mai sus” și „Mută mai jos” în listele sortabile. Suportul pentru tastatură nu ajunge: documentul explicativ (se deschide într-o filă nouă) al W3C spune că echivalența prin tastatură „nu îndeplinește automat acest criteriu de succes”.

2.5.8 Dimensiunea țintei (minim)

Erorile obișnuite sunt butoanele mici „×” de pe ferestrele pop-up, numerele de pagină înghesuite, evaluările cu stele și rândurile de pictograme pentru rețele sociale. O atingere pe elementul greșit îl enervează pe oricine și este o barieră reală pentru persoanele cu dexteritate redusă.

• Excepții: linkurile din interiorul unei propoziții, țintele care au pe aceeași pagină un control echivalent de dimensiunea cerută, controalele dimensionate de browser pe care nu le-ați restilizat și situațiile în care o anumită dimensiune este esențială sau impusă prin lege.
• Test rapid: pe un telefon, încercați fiecare pictogramă și fiecare buton mic; ca să măsurați unul, inspectați-l în instrumentele pentru dezvoltatori ale browserului.
• Corectura obișnuită: adăugați padding. Zona pe care se poate da clic crește, chiar dacă pictograma arată la fel. Și tratați 24 de pixeli ca pe un minim: criteriul AAA mai vechi 2.5.5 cere 44 pe 44.

Ajutor consecvent și introducere redundantă: îi puneți pe oameni să caute sau să se repete?

Ambele sunt de nivel A. 3.2.6 Ajutor consecvent spune că, dacă un ajutor, cum ar fi datele de contact, un chat sau un link către întrebările frecvente, apare pe mai multe pagini, trebuie să stea de fiecare dată în aceeași ordine față de restul paginii. 3.3.7 Introducere redundantă spune că oamenii nu ar trebui să reintroducă informații pe care le-au dat deja în același proces.

Criteriul Ajutor consecvent nu vă obligă deloc să oferiți ajutor. Spune doar că, dacă numărul de telefon stă în antet pe paginile de produs, nu ar trebui să se mute în subsol la finalizarea comenzii, exact acolo unde oamenii au cea mai mare nevoie de el. Câștigă cel mai mult persoanele cu dificultăți de memorie sau de atenție. Corectura este de obicei un șablon comun, nu plasarea ajutorului pagină cu pagină.

Criteriul Introducere redundantă vizează formularele în mai mulți pași. Un formular de rezervare care vă cere e-mailul la pasul 1 și din nou la pasul 3 nu respectă criteriul, la fel ca o finalizare a comenzii care vă pune să tastați din nou o adresă de facturare identică. Completați câmpul automat sau lăsați oamenii să îl selecteze, de exemplu cu o casetă „Adresa de facturare este aceeași cu cea de livrare”. Excepțiile: reintroducerea este esențială, este necesară din motive de securitate sau informațiile anterioare nu mai sunt valabile.

Autentificare accesibilă: se pot autentifica oamenii fără un test de memorie?

Criteriul de succes 3.3.8 (nivelul AA) spune că niciun pas al autentificării nu se poate baza pe un test al funcțiilor cognitive, cum ar fi memorarea unei parole, tastarea unor caractere deformate sau rezolvarea unui puzzle, decât dacă oferiți o alternativă sau un mecanism de ajutor. În practică: lăsați managerele de parole să completeze câmpurile, permiteți lipirea și oferiți o metodă care nu depinde de memorie.

WCAG definește testul funcțiilor cognitive drept „o sarcină care îi cere utilizatorului să își amintească, să manipuleze sau să transcrie informații”. Introducerea numelui, a adresei de e-mail sau a numărului de telefon nu intră aici, pentru că sunt date personale, aceleași peste tot. Un pas de autentificare trece la nivelul AA dacă oferă cel puțin una dintre variantele de mai jos:

• O alternativă: o metodă fără test cognitiv, cum ar fi o cheie de acces (passkey) sau un link trimis pe e-mail.
• Un mecanism de ajutor, cum ar fi compatibilitatea cu managerele de parole sau copierea și lipirea, ca un cod unic să nu trebuiască tastat din nou.
• Recunoașterea obiectelor, de exemplu „selectați imaginile cu o bicicletă”.
• Conținut personal, cum ar fi identificarea unei imagini pe care ați încărcat-o chiar dumneavoastră.

Versiunea AAA, 3.3.9, renunță la ultimele două variante, așa că un CAPTCHA cu imagini poate trece la nivelul AA, dar nu și la AAA. Erori tipice: câmpuri de parolă care blochează lipirea sau managerele de parole, casete pentru coduri unice care nu mai funcționează când lipiți codul și un CAPTCHA text fără alternativă. Cel mai mult câștigă persoanele cu dislexie sau cu tulburări de memorie, dar oricine a rămas blocat în afara contului după o zi lungă va recunoaște problema.

Este WCAG 2.2 obligatoriu prin lege?

Depinde unde vă aflați și cine sunteți. Legile numesc rar direct o versiune WCAG, iar mai multe trimit încă la WCAG 2.1 AA. Pentru că WCAG 2.2 este compatibil cu versiunile anterioare, respectarea 2.2 AA înseamnă și respectarea 2.1 AA, cu excepția criteriului eliminat 4.1.1. Dacă țintiți 2.2, le acoperiți pe amândouă. Dacă un contract numește o versiune, urmați contractul.

• Uniunea Europeană: potrivit Actului european privind accesibilitatea, conformitatea este prezumată atunci când respectați standardul armonizat EN 301 549. Conform AccessibleEU (se deschide într-o filă nouă), versiunea 4.1.1, publicată în septembrie 2026, preia WCAG 2.2, dar nu este încă referința juridică; până la citarea ei în Jurnalul Oficial se aplică v3.2.1 (bazată pe WCAG 2.1 AA). Ghidul nostru despre Actul european privind accesibilitatea explică cui se aplică actul.
• Regatul Unit: ghidul guvernamental (se deschide într-o filă nouă) spune că site-urile și aplicațiile din sectorul public trebuie să respecte WCAG 2.2 AA. Ghidul se referă la organismele publice, nu la firmele private.
• Statele Unite: regula Departamentului de Justiție pentru administrațiile statale și locale folosește WCAG 2.1 AA, iar termenele de conformare au fost amânate în aprilie 2026 (se deschide într-o filă nouă) la 26 aprilie 2027 și 26 aprilie 2028. Pentru firmele private, ghidul din 2022 (se deschide într-o filă nouă) al Departamentului spune că ADA se aplică site-urilor lor, dar nu stabilește un standard tehnic anume.

Și WCAG 3?

WCAG 3 este un proiect, deci deocamdată niciun site nu poate fi conform cu el. W3C a publicat versiuni de lucru actualizate în septembrie 2026 și estimează că WCAG 3 va deveni un standard finalizat abia „peste încă câțiva ani”. WCAG 2 nu va fi retras decât la câțiva ani după aceea, așa că 2.2 este versiunea după care trebuie să lucrați acum.

Cum puteți verifica noile criterii în 15 minute?

Majoritatea erorilor legate de cele șase criterii A și AA le puteți depista în aproximativ 15 minute, cu o tastatură, un telefon și propria pagină de autentificare. Verificarea nu înlocuiește un audit complet sau testarea cu persoane cu dizabilități, dar vă arată de unde să începeți și îi dă unui dezvoltator o listă concretă de lucru.

1. Parcurgeți cu Tab pagina principală, o pagină de produs și finalizarea comenzii, cu toate bannerele afișate. Vedeți mereu focalizarea? (2.4.11)
2. Folosiți fiecare glisor și duceți la capăt fiecare acțiune de glisare și fixare doar cu clicuri sau atingeri. (2.5.7)
3. Pe un telefon, încercați fiecare buton de închidere, număr de pagină și pictogramă mică. (2.5.8)
4. Comparați unde apar ajutorul și datele de contact pe trei tipuri de pagini. (3.2.6)
5. Parcurgeți o cumpărare sau o rezervare și notați orice întrebare la care răspundeți de două ori. (3.3.7)
6. Autentificați-vă cu un manager de parole, apoi lipiți o parolă și un cod unic. Are vreun CAPTCHA o alternativă? (3.3.8)

Pentru restul WCAG, ghidul nostru despre cum vă testați accesibilitatea site-ului prezintă instrumente gratuite și verificări manuale, iar lista de verificare a accesibilității site-ului transformă erorile frecvente într-o listă de sarcini. Tot ce nu puteți corecta încă își are locul în declarația de accesibilitate.

O observație despre widgeturi, inclusiv al nostru: niciunul dintre aceste criterii nu poate fi îndeplinit dintr-un panou folosit de vizitator. Un cursor mare face țintele mici mai ușor de nimerit, dar nu le face late de 24 de pixeli, iar evidențierea focalizării nu mută din cale un banner fix. Fiecare criteriu nou ține de felul în care sunt construite paginile, deci corectura se face în șabloane și în cod.