WCAG 2.2 față de 2.1: cele nouă criterii noi și ce cere legea în România

WCAG 2.2 a fost publicat în octombrie 2023. Cu toate acestea, cerința pe care o întâlnim în caietele de sarcini și în rapoartele de audit din România este, în continuare, WCAG 2.1 nivel AA.

Nu este o scăpare. Sunt două lucruri diferite, ușor de confundat.

Un standard tehnic descrie ce înseamnă un site accesibil. O lege stabilește ce versiune a standardului poate fi cerută la un control sau într-o sesizare.

Standardul și legea nu se schimbă în același ritm.

În septembrie 2026 s-a schimbat însă ceva în partea de reglementare, iar răspunsul la întrebarea „ce versiune urmăresc?” este astăzi altul decât acum un an.

În acest articol explicăm ce aduce nou WCAG 2.2 față de 2.1, care dintre criteriile noi contează pentru nivelul AA și cum este reglementată situația în România.

Ce aduce nou WCAG 2.2 față de 2.1?

WCAG 2.2 a fost publicat ca Recomandare W3C pe 5 octombrie 2023, iar textul în vigoare astăzi este versiunea din 12 decembrie 2024.

Față de 2.1, standardul adaugă nouă criterii de succes și elimină unul singur.

Restul criteriilor din 2.0 și 2.1 rămân neschimbate. Prin urmare, un site care respectă WCAG 2.2 poate fi declarat conform și cu 2.1, și cu 2.0.

Consecința practică îi privește direct pe cei care au lucrat deja la accesibilitatea unui site. Nimic din ce a fost făcut pentru 2.1 nu trebuie refăcut, pentru că cele nouă criterii se adaugă peste cerințele existente. Lucrul poate continua de unde a rămas.

Criteriile noi nu contează însă în aceeași măsură. Trei dintre ele sunt de nivel AAA, adică peste nivelul cerut de legislația europeană.

Șase criterii noi sunt de nivel A sau AA.

și

Trei criterii sunt de nivel AAA și rămân opționale.

Aceasta este prima distincție pe care o facem atunci când o instituție sau o companie ne cere o evaluare după WCAG 2.2.

Cele șase criterii noi de nivel A și AA

Denumirile oficiale ale criteriilor sunt în limba engleză. WCAG nu are o traducere oficială în limba română, așa că traducerile de mai jos sunt de lucru și nu au valoare normativă.

3.2.6 Consistent Help — ajutorul în același loc (nivel A)

Atunci când un site oferă o modalitate de a cere ajutor, aceasta trebuie să apară în aceeași poziție față de restul conținutului, pe toate paginile unde există.

Ajutorul poate fi un număr de telefon, un formular de contact, o fereastră de conversație sau o secțiune de întrebări frecvente.

Criteriul privește consecvența, nu existența ajutorului. Un site care nu oferă nicio formă de ajutor nu încalcă această cerință. Un site care oferă ajutor trebuie însă să îl păstreze în același loc.

Motivul este ușor de înțeles. O persoană cu dificultăți de memorie sau de orientare care găsește o dată butonul de ajutor îl caută în același loc și pe pagina următoare.

Dacă poziția se schimbă de la o pagină la alta, căutarea începe de fiecare dată de la zero.

3.3.7 Redundant Entry — aceeași informație, cerută o singură dată (nivel A)

Într-un proces cu mai mulți pași, informația pe care utilizatorul a introdus-o deja nu ar trebui cerută din nou.

Ea poate fi completată automat sau poate fi oferită într-o listă din care utilizatorul alege.

Standardul prevede și excepții. Datele pot fi cerute din nou atunci când reintroducerea este esențială pentru pasul respectiv, când securitatea conținutului o cere sau când informația anterioară nu mai este valabilă.

Un exemplu întâlnit frecvent este formularul de programare online care cere aceeași adresă la trei dintre cei patru pași.

Pentru o persoană cu dificultăți de memorie, fiecare repetare înseamnă un efort în plus și un risc în plus de eroare. Datele introduse la pașii anteriori pot fi preluate automat.

2.4.11 Focus Not Obscured (Minimum) — elementul focalizat rămâne vizibil (nivel AA)

Atunci când un element primește focusul de la tastatură, el nu trebuie să fie acoperit complet de alte elemente puse în pagină de site.

Cazul cel mai frecvent este bara fixată în partea de jos a paginii sau antetul care rămâne vizibil sus, la derulare. Utilizatorul apasă tasta Tab, focusul trece la elementul următor, iar acesta poate ajunge exact sub bară.

O persoană care navighează numai cu tastatura nu poate ști pe ce element se află, dacă acesta rămâne ascuns sub bară.

Acesta este singurul criteriu nou pe care l-am tratat deja pe blog. În articolul despre navigarea din tastatură poți vedea cum se verifică, în câteva minute, pe orice pagină.

2.5.7 Dragging Movements — alternativă la tragerea cu mouse-ul (nivel AA)

Orice funcție care cere tragerea unui element trebuie să fie disponibilă și fără tragere, printr-o singură apăsare.

Standardul nu interzice tragerea, ci cere ca utilizatorul să aibă la dispoziție și o a doua modalitate.

De exemplu, o listă care se reordonează prin tragere poate primi săgeți sus și jos pentru fiecare element. Un cursor glisant poate primi un câmp numeric sau butoane de creștere și de scădere.

Cu ele, utilizatorul poate schimba ordinea sau valoarea fără să țină butonul apăsat în timp ce mișcă mouse-ul.

Motivul este practic. O persoană cu tremur al mâinii sau care folosește un mouse adaptat nu reușește să țină butonul apăsat și să miște cursorul cu precizie în același timp.

2.5.8 Target Size (Minimum) — ținte de cel puțin 24 pe 24 de pixeli (nivel AA)

Zona pe care utilizatorul apasă sau pe care o atinge trebuie să măsoare cel puțin 24 pe 24 de pixeli CSS.

Standardul prevede cinci excepții, iar cea mai folositoare în practică este excepția de spațiere. O țintă mai mică poate rămâne acceptabilă dacă în jurul ei rămâne suficient spațiu liber până la celelalte ținte.

Celelalte excepții privesc linkurile aflate în interiorul unei fraze, controalele a căror mărime este stabilită de browser și situațiile în care dimensiunea este impusă prin lege.

Două locuri ajung frecvent sub această limită: pictogramele de rețele sociale din subsol și butonul de închidere al ferestrelor modale.

3.3.8 Accessible Authentication (Minimum) — autentificare fără test de memorie (nivel AA)

Niciun pas al autentificării nu poate cere un test de funcție cognitivă, în afara cazului în care site-ul pune la dispoziție și o alternativă.

Prin „test de funcție cognitivă”, standardul înțelege memorarea unei parole, rezolvarea unui puzzle sau transcrierea unui cod primit prin SMS ori pe e-mail.

Alternativele acceptate sunt enumerate explicit: o altă metodă de autentificare, un ajutor care îl sprijină pe utilizator să treacă testul, recunoașterea unor obiecte sau a unui conținut încărcat chiar de el.

Standardul dă și două exemple de soluții pe care le poate accepta: sprijinul pentru managerele de parole și posibilitatea de a lipi textul copiat.

Un câmp care nu permite lipirea codului primit prin SMS elimină tocmai una dintre soluțiile pe care standardul le dă ca exemplu.

Dintre cele nouă criterii noi, acesta se aplică celor mai multe site-uri, pentru că orice site cu cont de utilizator are un proces de autentificare.

În România, este vorba despre aproape orice serviciu bancar, orice magazin online și orice platformă publică unde utilizatorul își face cont.

Cele trei criterii noi de nivel AAA

Nivelul AAA nu este cerut de legislația europeană și nu poate fi îndeplinit integral pentru orice tip de conținut. Criteriile de mai jos rămân, așadar, o direcție de lucru, nu o obligație:

• 2.4.12 Focus Not Obscured (Enhanced) — elementul care primește focusul nu este acoperit nici măcar parțial;
• 2.4.13 Focus Appearance — indicatorul de focus acoperă o suprafață cel puțin egală cu a unui contur gros de 2 pixeli CSS în jurul elementului, iar contrastul față de starea nefocalizată este de cel puțin 3:1;
• 3.3.9 Accessible Authentication (Enhanced) — autentificarea nu cere nici recunoașterea unor obiecte, nici recunoașterea unor imagini încărcate de utilizator.

Dintre cele trei, 2.4.13 este singurul care stabilește o măsură numerică. Criteriul 2.4.7 Focus Visible, existent din versiunea 2.0, cere ca focusul să fie vizibil, fără să precizeze cât de vizibil.

Criteriul 4.1.1 Parsing a fost eliminat din standard

WCAG 2.2 declară criteriul 4.1.1 Parsing depășit și îl scoate din standard.

Criteriul cerea cod fără erori de sintaxă: etichete închise corect, identificatori unici, atribute nedublate.

Motivul eliminării este că browserele și tehnologiile asistive de astăzi tratează singure aceste erori. Un criteriu care semnala probleme fără efect real asupra utilizatorului cerea muncă de remediere fără niciun câștig pentru cititor.

Lucrul acesta este util de știut pentru cine primește un raport de audit. Dacă raportul listează erori de parsare printre neconformități, evaluarea a fost făcută după WCAG 2.1. Versiunea folosită poate fi cerută furnizorului, în scris.

Ce versiune este obligatorie în România?

Obligația legală nu este stabilită de W3C. În Uniunea Europeană, un standard W3C produce efecte juridice numai prin standardul european armonizat EN 301 549, și numai după ce acesta este citat în Jurnalul Oficial.

Comisia Europeană spune lucrul acesta explicit. Versiunile WCAG de după 2.1 nu devin automat relevante pentru Directiva privind accesibilitatea web, iar cerințele noi produc efecte juridice doar dacă intră în Anexa A a unei versiuni armonizate a EN 301 549, citată în Jurnalul Oficial.

Situația este următoarea:

• versiunea citată în Jurnalul Oficial rămâne EN 301 549 v3.2.1 (2021), construită pe WCAG 2.1 nivel AA;
• în septembrie 2026, ETSI a publicat EN 301 549 v4.1.1, care trece la WCAG 2.2 și adaugă o anexă dedicată Actului European privind Accesibilitatea;
• v4.1.1 nu este încă referința legală, pentru că nu a fost citată în Jurnalul Oficial.

Până la citare, o instituție publică din România are obligațiile prevăzute de OUG 112/2018, iar o companie privată din sectoarele vizate, pe cele din Legea 232/2022.

În ambele cazuri, reperul tehnic rămâne deocamdată versiunea construită pe WCAG 2.1.

Comisia atrage atenția și asupra unui alt aspect. EN 301 549 cuprinde cerințe pe care WCAG nu le acoperă, cum sunt cele privind comunicarea în timp real sau documentele descărcabile de pe site.

Un site care respectă toate criteriile WCAG 2.1 nu poate invoca automat prezumția de conformitate.

De ce merită urmărită versiunea 2.2 de pe acum?

Primul motiv privește costul. Trecerea la 2.2 nu invalidează nimic din ce este deja conform cu 2.1, pentru că versiunile sunt compatibile. Lucrul făcut acum poate fi păstrat ca atare și după citarea în Jurnalul Oficial.

Al doilea motiv privește problemele pe care le rezolvă criteriile noi. Autentificarea care cere memorare și transcriere, butoanele prea mici și focusul ascuns sub o bară fixă apar în evaluările pe care le facem, indiferent de versiunea cerută în contract.

Al treilea motiv privește achizițiile publice și contractele cu furnizorii. O cerință formulată astăzi ca „WCAG 2.1 AA” va fi aplicată peste doi ani unui site care ar trebui să respecte deja versiunea 2.2.

O formulare de tipul „WCAG 2.1 AA, cu criteriile suplimentare din 2.2 acolo unde sunt aplicabile” poate acoperi și cerința de astăzi, și pe cea care va urma.

Ce poate verifica o echipă chiar acum

Criteriile noi nu cer instrumente speciale. Patru dintre ele pot fi verificate manual, pe orice pagină. Un coleg din echipă poate să:

• parcurgă pagina cu tasta Tab, până jos, urmărind elementele care dispar sub antet sau sub bara fixă (2.4.11);
• caute funcțiile care cer tragere: liste reordonabile, cursoare glisante, hărți cu obiecte mutabile (2.5.7);
• măsoare butoanele mici din subsol, din meniuri și din ferestrele modale (2.5.8);
• parcurgă tot fluxul de autentificare, cu un manager de parole activ și cu lipirea codului primit prin SMS (3.3.8).

Celelalte două criterii nu pot fi verificate pe o singură pagină. Ele privesc poziția ajutorului pe tot site-ul (3.2.6) și informația cerută a doua oară în același proces (3.3.7).

Un audit de accesibilitate poate acoperi toate aceste criterii, împreună cu restul cerințelor din 2.1.

Pentru cine pornește de la zero cu standardul, ghidul nostru despre ce este WCAG explică principiile și nivelurile A, AA și AAA.

Vrei o evaluare a site-ului după criteriile din WCAG 2.2?

Fundația TIFLO evaluează site-uri și documente pentru instituții publice și pentru companii, combinând instrumentele automate cu testarea manuală, inclusiv cu cititoare de ecran.

Raportul arată ce lipsește față de versiunea cerută astăzi prin lege și ce ar mai fi de făcut pentru WCAG 2.2, astfel încât aceeași muncă să nu fie plătită a doua oară peste doi ani.

Rezultatul poate fi folosit direct într-un caiet de sarcini sau într-o discuție cu furnizorul site-ului.

Cere o evaluare de accesibilitate

Întrebări frecvente despre WCAG 2.2

Câte criterii de succes adaugă WCAG 2.2?

Nouă criterii de succes noi, dintre care două de nivel A, patru de nivel AA și trei de nivel AAA. Tot în versiunea 2.2, criteriul 4.1.1 Parsing a fost declarat depășit și scos din standard.

Când devine WCAG 2.2 obligatoriu în România?

În momentul în care Comisia Europeană citează EN 301 549 v4.1.1 în Jurnalul Oficial al Uniunii Europene. Până atunci, reperul tehnic al obligațiilor din OUG 112/2018 și din Legea 232/2022 rămâne versiunea construită pe WCAG 2.1 nivel AA. O dată exactă nu poate fi indicată, pentru că nu a fost anunțată.

Trebuie refăcut un site care respectă deja WCAG 2.1?

Nu. Versiunile sunt compatibile, iar 2.2 adaugă criterii peste cele existente. Pentru nivelul AA, mai sunt de verificat șase criterii, iar erorile de parsare nu mai trebuie urmărite.

Ce înseamnă că 4.1.1 Parsing a fost scos?

Că erorile de sintaxă din cod nu mai sunt tratate ca neconformitate în WCAG 2.2, pentru că browserele și tehnologiile asistive moderne le gestionează singure. Codul valid rămâne o bună practică, fără să mai fie un criteriu de succes.

Criteriile de nivel AAA din 2.2 sunt obligatorii?

Nu. Nivelul cerut de legislația europeană este AA. Cele trei criterii AAA din 2.2 privesc vizibilitatea completă a focusului, aspectul indicatorului de focus și o formă mai strictă de autentificare accesibilă. Le poți urmări ca direcție de lucru, fără ca absența lor să afecteze conformarea la nivelul AA.

Ce legătură are EN 301 549 cu WCAG?

EN 301 549 este standardul european pentru accesibilitatea produselor și serviciilor digitale. El preia criteriile WCAG și adaugă cerințe proprii, pe care WCAG nu le acoperă. Prezumția de conformitate în Uniunea Europeană decurge din EN 301 549, nu direct din WCAG.

Ce parte din criteriile noi poate fi verificată automat?

Mărimea țintelor poate fi măsurată automat, iar poziția ajutorului poate fi comparată de la o pagină la alta. Alternativa la tragere, autentificarea și informația cerută a doua oară cer parcurgerea manuală a fluxului, cu tastatura.

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.