Ai primit cerința ca un website sau o aplicație să respecte WCAG. Apoi, într-un alt document, apare EN 301 549. Echipa tehnică începe să încerce să afle care dintre cele două standarde trebuie folosit și ce trebuie testat efectiv.
Confuzia este de înțeles. Cele două sunt strâns legate, dar au roluri și arii de acoperire diferite.
Pentru echipele care creează sau gestionează produse digitale, această distincție contează — mai ales atunci când accesibilitatea trebuie integrată în procesele de design, dezvoltare, asigurare a calității (QA) și conformitate.
Ce este EN 301 549?
EN 301 549 este standardul european pentru cerințele de accesibilitate aplicabile produselor și serviciilor din domeniul Tehnologiei Informației și Comunicațiilor (TIC).
Domeniul său de aplicare este mai vast decât cel al site-urilor web. Standardul acoperă cerințe pentru tehnologii precum site-uri web și documente non-web, software și aplicații mobile, hardware și alte produse și servicii TIC.
Acest lucru schimbă perspectiva pentru o echipă de produs.
Dacă organizația ta gestionează un serviciu digital complex, accesibilitatea trebuie luată în considerare pentru toate componentele relevante ale acelui serviciu — nu doar pentru pagina principală a site-ului.
Pentru echipele tehnice, EN 301 549 oferă cerințe care pot fi integrate în specificații, procese de achiziție, dezvoltare și testare.
Comisia Europeană explică faptul că standardul depășește cerințele WCAG. Prin urmare, îndeplinirea tuturor criteriilor de succes WCAG relevante nu înseamnă automat că toate cerințele EN 301 549 au fost acoperite.
Unde se încadrează WCAG?
WCAG (Ghidul de accesibilitate a conținutului web) este standardul internațional dezvoltat de W3C pentru accesibilitatea conținutului web.
Criteriile de succes WCAG sunt organizate în jurul a patru principii:
- Perceptibil
- Operabil
- Înțelegibil
- Robust
Sub aceste principii se află criterii de succes testabile, organizate pe trei niveluri de conformitate: A, AA și AAA.
În practică, aceste criterii se traduc în cerințe foarte concrete.
O imagine informativă are nevoie de o alternativă textuală adecvată.
Conținutul trebuie să aibă un contrast suficient.
Funcționalitatea trebuie să poată fi operată prin metodele cerute de criteriile de succes aplicabile.
Formularele trebuie implementate astfel încât informațiile și relațiile de care au nevoie utilizatorii să poată fi determinate programatic, acolo unde criteriile relevante o impun.
Focalizarea tastaturii trebuie să fie vizibilă și ușor de urmărit.
Componentele interactive trebuie implementate astfel încât tehnologiile asistive să poată primi informațiile necesare despre acestea.
Dintr-odată, „accesibilitatea” devine un set de cerințe pe care un designer, un dezvoltator și un specialist QA le pot discuta și testa în mod concret.
EN 301 549 și WCAG nu sunt același lucru
Aceasta este una dintre cele mai importante distincții de înțeles.
WCAG se concentrează pe accesibilitatea conținutului web. EN 301 549 are o sferă de aplicare ICT mai largă și încorporează cerințele WCAG pentru conținutul web în structura sa, alături de cerințe suplimentare.
Versiunea EN 301 549 relevantă în prezent pentru cerințele europene armonizate de accesibilitate utilizează WCAG 2.1. Comisia Europeană precizează că WCAG 2.2 nu este încă utilizat într-un standard EN 301 549 armonizat prin publicarea referinței sale în Jurnalul Oficial al Uniunii Europene.
Această distincție este importantă în 2026.
Dar WCAG 2.2 există deja
WCAG 2.2 este cea mai recentă versiune finalizată a familiei WCAG, iar W3C recomandă utilizarea celei mai noi versiuni atunci când organizațiile își dezvoltă sau își actualizează politicile și practicile de accesibilitate.
WCAG 2.2 adaugă nouă criterii de succes noi față de WCAG 2.1. Acestea includ cerințe legate de aspectul focalizării, dimensiunea minimă a elementelor de interacțiune, alternative la interacțiunile de tip „drag and drop”, autentificarea accesibilă și evitarea introducerii redundante a informațiilor în anumite situații.
Din 2025, WCAG 2.2 a devenit și un standard internațional ISO: ISO/IEC 40500:2025.
Pentru o echipă tehnică, acest lucru creează o distincție între standardul european utilizat pentru cadrul de reglementare relevant și versiunea WCAG recomandată de W3C pentru dezvoltarea actuală a accesibilității.
W3C explică, de asemenea, că orice conținut care respectă WCAG 2.2 respectă implicit și WCAG 2.1 și WCAG 2.0, datorită modului în care au fost concepute versiunile succesive.
Ce înseamnă acest lucru pentru echipele de produs?
Accesibilitatea funcționează mai bine atunci când devine parte din cerințele produsului înainte de începerea dezvoltării.
Să luăm ca exemplu un formular simplu de creare a contului.
Echipa definește câmpurile și regulile de validare. UX definește interacțiunea. Designul pregătește componentele și stările acestora. Dezvoltarea le implementează. QA verifică rezultatul.
Dacă accesibilitatea este luată în calcul abia după lansare, problemele descoperite pot necesita modificări în mai multe dintre aceste etape.
Dacă cerințele sunt definite în etapa de planificare, echipa poate discuta despre etichete, focalizare, mesaje de eroare, contrast și navigarea prin tastatură încă de la început.
Acest lucru reduce, de asemenea, situațiile în care accesibilitatea devine o listă separată de erori care trebuie remediate după lansare.
Ce ar trebui să ia în considerare echipele de UX și Design?
Un sistem de design bine pus la punct poate preveni repetarea aceleiași probleme de accesibilitate pe zeci de pagini.
Butoanele, formularele, ferestrele modale, navigarea, componentele interactive și stările de focalizare trebuie să fie definite incluzând cerințele de accesibilitate în specificațiile lor.
Contrastul este un exemplu evident.
Însă accesibilitatea nu se rezumă doar la culoare.
Designerii trebuie să ia în considerare și modul în care utilizatorii înțeleg ierarhia informațiilor, stările componentelor, mesajele de eroare și interacțiunile care nu depind de o singură metodă de introducere a datelor.
O componentă poate arăta perfect într-un fișier de design și totuși să creeze probleme de accesibilitate după implementare.
De aceea, testarea accesibilității trebuie să continue și în produsul funcțional.
Ce ar trebui să ia în considerare echipele de dezvoltare?
HTML-ul semantic și implementarea corectă a componentelor joacă un rol direct în accesibilitate.
Dezvoltatorii trebuie să înțeleagă ce se întâmplă atunci când un utilizator renunță la mouse și încearcă să navigheze prin interfață folosind doar tastatura.
La fel de important este ceea ce primesc tehnologiile asistive.
Care este numele accesibil al componentei?
Ce rol are aceasta?
În ce stare se află?
Ce se întâmplă cu focalizarea atunci când o fereastră modală se deschide sau se închide?
Poate fi formularul completat efectiv?
Aceste întrebări sunt mult mai utile în timpul dezvoltării decât cerința vagă ca „pagina trebuie să fie accesibilă”.
Ce ar trebui să ia în considerare echipele de QA?
Testarea automată este utilă, dar nu poate verifica singură toate cerințele de accesibilitate.
W3C explică faptul că WCAG este conceput astfel încât conformitatea să poată fi evaluată printr-o combinație de evaluare automată și apreciere umană.
Aici testarea manuală rămâne importantă.
Echipa QA poate testa navigarea prin tastatură, ordinea focalizării și comportamentul componentelor. Testarea cu tehnologii asistive adaugă un nivel suplimentar de validare.
Între timp, testele automatizate pot identifica rapid anumite probleme repetabile pe mai multe pagini.
Combinarea acestor metode oferă o imagine mult mai utilă decât bazarea pe un singur scor.
Un scor de accesibilitate nu spune întreaga poveste
Tabloul de bord arată 92/100. Sună bine.
Dar ce se întâmplă dacă problema rămasă este la butonul care finalizează plata?
Impactul asupra utilizatorului nu este neapărat proporțional cu numărul total de erori.
De aceea, echipele ar trebui să ia în considerare și gravitatea unei probleme, componenta afectată și locul în care aceasta apare în cadrul unui parcurs critic al utilizatorului.
Finalizarea comenzii, autentificarea, crearea contului, plata și rezervările sunt exemple în care o singură barieră de accesibilitate poate împiedica un utilizator să finalizeze o acțiune.
Prioritățile de remediere ar trebui să țină cont de acest context.
Accesibilitatea continuă și după lansare
Un produs digital se schimbă.
Sunt adăugate pagini, componente și integrări noi. Echipa de marketing publică conținut nou. Un formular este modificat. Experiența de finalizare a comenzii primește o actualizare.
Un test efectuat în urmă cu șase luni descrie produsul așa cum exista el acum șase luni.
De aceea, procesul tău ar trebui să includă testarea după modificările relevante și monitorizarea problemelor care pot apărea pe măsură ce produsul evoluează.
Wawsome te poate ajuta să identifici problemele de accesibilitate detectabile automat și să monitorizezi accesibilitatea site-ului web în timp.
Cum ar trebui să arate un proces intern de accesibilitate?
Pentru o echipă care gestionează continuu un produs digital, accesibilitatea ar trebui să fie prezentă în mai multe etape ale procesului.
În cerințe, atunci când este definită funcționalitatea.
În sistemul de design, pentru componentele reutilizabile.
În dezvoltare și revizuirea codului, atunci când acele componente sunt implementate.
În QA, prin testare automată și manuală.
După lansare, prin monitorizarea și retestarea zonelor care au suferit modificări.
Acest lucru transformă standardele EN 301 549 și WCAG din norme abstracte în cerințe concrete, sarcini de dezvoltare și cazuri de testare cu care echipele pot lucra cu adevărat.
Întrebări frecvente
Ar trebui să folosesc WCAG 2.1 sau WCAG 2.2?
Standardul EN 301 549 utilizează în prezent WCAG 2.1 în versiunea armonizată relevantă la nivel european. W3C recomandă utilizarea celei mai recente versiuni WCAG și precizează că un conținut conform cu WCAG 2.2 este, de asemenea, conform cu WCAG 2.1.
Pentru obligațiile legale, trebuie să verificați standardul specific și cadrul de reglementare aplicabil produsului sau serviciului în cauză.
Dacă respect WCAG, înseamnă automat că respect și EN 301 549?
Nu. EN 301 549 are o sferă de aplicare mai largă. Comisia Europeană precizează în mod explicit că îndeplinirea tuturor criteriilor de succes WCAG 2.1 nu oferă, prin ea însăși, o prezumție de conformitate cu toate cerințele relevante bazate pe EN 301 549.
Pot testa automat toate criteriile de succes WCAG?
Nu. Evaluarea accesibilității necesită și verificări care implică judecata umană. Testarea automată este utilă pentru problemele care pot fi detectate tehnic și consecvent, dar nu poate înlocui evaluarea manuală.
Când ar trebui să testez accesibilitatea?
În timpul dezvoltării și înainte de lansare, precum și după efectuarea unor modificări care ar putea afecta experiența utilizatorului. Pentru produsele actualizate frecvent, monitorizarea continuă poate ajuta echipele să identifice problemele noi pe măsură ce apar.
Cu ce ar trebui să începeți?
Dacă echipa dumneavoastră gestionează un site web existent, începeți prin a înțelege ce probleme de accesibilitate pot fi identificate chiar acum. Rezultatele unei scanări inițiale pot oferi un punct de plecare pentru prioritizarea testării și a remedierilor ulterioare.
Pentru o evaluare completă, rezultatele automatizate ar trebui completate cu verificările manuale necesare pentru criteriile care nu pot fi evaluate automat.