Accesibilitatea web înseamnă ca site-ul sau aplicația să poată fi folosite și de oameni cu dizabilități (vedere, auz, motor, cognitiv) — și, practic, de oricine e pe mobil în soare, cu o mână ocupată sau cu o conexiune proastă. WCAG (Web Content Accessibility Guidelines) e setul internațional de criterii tehnice al W3C care spune „ce înseamnă accesibil” pe web. În Europa și în România, însă, WCAG nu e doar „bună practică”: e referința tehnică din spatele unor obligații legale. La UNICORE, asta intră în UI/UX și în website-uri / aplicații web — cerință de la început, nu ornament de final.
Harta legală, pe scurt (UE → RO). Există două „trenuri” europene: (1) Directiva (UE) 2016/2102 — accesibilitatea site-urilor și aplicațiilor mobile ale organismelor din sectorul public (Web Accessibility Directive / WAD). (2) Directiva (UE) 2019/882 — Actul european privind accesibilitatea (European Accessibility Act / EAA), pentru anumite produse și servicii de pe piața internă (inclusiv multe servicii digitale pentru consumatori). România le-a transpus: OUG nr. 112/2018 (aprobată prin Legea nr. 90/2019) pentru sectorul public; Legea nr. 232/2022 pentru cerințele EAA aplicabile produselor și serviciilor (aplicare efectivă din 28 iunie 2025).
Standardul tehnic comun: EN 301 549 (și legătura cu WCAG). În achiziții și în evaluarea conformității, referința europeană armonizată pentru TIC accesibil este standardul EN 301 549 („Accessibility requirements for ICT products and services”). În practică, pentru conținut web, EN 301 549 încorporează cerințele WCAG 2.1 nivel AA. De aceea, când auzi „trebuie WCAG AA”, în limbaj juridic românesc/european înseamnă de obicei: aliniere la EN 301 549 pentru componentele web/mobile acoperite. Nu inventezi un standard propriu — urmezi criteriul european.
Sectorul public: OUG 112/2018 + Legea 90/2019. Ordonanța stabilește cerințele de accesibilitate pentru site-urile web și aplicațiile mobile ale organismelor din sectorul public — de la administrație centrală și locală la alte entități acoperite de definiția de „organism din sectorul public”. Obiectivul: cetățenii (inclusiv persoanele cu dizabilități) să poată percepe, naviga și folosi serviciile digitale publice. ADR (Autoritatea pentru Digitalizarea României) are rol de monitorizare / control al respectării acestor prevederi, în baza competențelor din HG nr. 89/2020 și a normelor de monitorizare (Decizia ADR nr. 815/2022).
Ce trebuie să facă o instituție publică (obligații tipice). (1) Face site-ul / aplicația accesibile conform cerințelor (în practică: EN 301 549 / WCAG 2.1 AA pe conținutul acoperit). (2) Publică o declarație privind accesibilitatea — starea de conformitate, ce nu e accesibil încă, de ce, și alternative. (3) Oferă un mecanism de feedback ca utilizatorii să semnaleze bariere. (4) Dacă invocă „sarcină disproporționată” pentru anumite conținuturi, evaluează motivat și publică evaluarea împreună cu declarația — nu e o scuză generică. Lipsa de cunoștințe, „nu a fost prioritate” sau CMS-ul inaccesibil nu sunt motive legitime tipice în spiritul OUG.
Sarcina disproporționată — ce înseamnă (și ce nu). OUG permite, în cazuri justificate, să nu faci anumite conținuturi pe deplin accesibile dacă măsurile ar impune o sarcină organizatorică / financiară excesivă sau ar pune în pericol capacitatea instituției de a-și îndeplini misiunea — ținând cont și de prejudiciul pentru cetățeni, în special persoanele cu dizabilități. Nu e „renunțăm la accesibilitate”. E o excepție documentată, temporară în logică, cu alternative unde e posibil. Pentru achiziții: cumpărarea de software/CMS inaccesibil nu „șterge” obligația — alegerea furnizorului contează din start.
Sectorul privat: Directiva 2019/882 (EAA) + Legea 232/2022. Din 28 iunie 2025, Legea 232/2022 aplică cerințe de accesibilitate pentru o gamă de produse și servicii plasate pe piață / oferite consumatorilor — inclusiv, în spiritul EAA, servicii precum comerț electronic, servicii bancare pentru consumatori, comunicații electronice, elemente de transport de pasageri, e-book-uri / software de lectură, și interfețe digitale aferente (site-uri, aplicații, terminale de autoservire, unde e cazul). Nu orice firmă din România e „automat” acoperită pentru tot ce face pe web — contează dacă produsul/serviciul intră în domeniul legii. Când intră, interfețele digitale trebuie să permită perceperea, operarea și înțelegerea pe bază de egalitate, compatibil cu tehnologii asistive.
Excepții și tranziții (EAA / Legea 232 — pe înțeles). Legislația prevede praguri și perioade de tranziție (ex.: anumite microîntreprinderi pot fi exceptate după criterii; contracte de servicii încheiate înainte de 28.06.2025 pot continua până la expirare, dar nu mai mult de un plafon de ani; unele terminale de autoservire au termene lungi de înlocuire; conținut media / documente publicate înainte de dată pot avea excepții). Nu trata asta ca pe un „nu ne privește”: verifică domeniul, tipul de serviciu și calendarul cu consilier juridic — apoi aliniază produsul digital. Sancțiunile administrative (amenzi, măsuri pe produs/serviciu) fac parte din arhitectura legii; autoritățile de supraveghere diferă pe domenii (ex. consum, comunicații, audiovisual).
WCAG pe scurt (ca să înțelegi auditul). Patru principii POUR: Perceivable (poți percepe — alt text, subtitrări, contrast), Operable (poți opera — tastatură, timp, fără capcane), Understandable (înțelegi — limbaj, erori clare), Robust (funcționează cu tehnologii asistive). Niveluri: A (minim), AA (ținta practică a legii/standardului pentru web), AAA (mai strict, rar obligatoriu peste tot). „Am rulat un checker automat” ≠ conformitate legală: tool-urile prind o parte; testul cu tastatura, cititor de ecran și, ideal, utilizatori reali prinde restul — inclusiv ce cere o declarație de accesibilitate onestă.
Exemple concrete care apar în audituri (și în reclamații). Formulare fără etichete (cititorul de ecran nu știe ce cere câmpul). Contrast insuficient pe butoane „estetice”. Navigare imposibilă doar cu tastatura. PDF-uri scanate fără text (inaccesibile pentru persoanele cu deficiențe de vedere). Captcha doar vizual. Video instituțional fără subtitrări când informația e esențială. Pentru primării și instituții: petiții, programări, plăți, registre online — exact fluxurile unde legea are sens.
Aspecte tehnice din perspectiva software-ului
Legea stabilește „ce trebuie”; software-ul decide „cum se livrează”. EN 301 549 / WCAG 2.1 AA se traduc în alegeri concrete de HTML, CSS, JavaScript, componente UI și pipeline de testare. Subcapitolul de mai jos e checklist-ul pe care îl folosim la UNICORE în dezvoltare web și UI/UX când ținta e conformitate, nu doar un audit de o zi.
1) HTML semantic și structură. Folosește elemente reale: `header`, `nav`, `main`, `footer`, `button` (nu `div` cu onClick), `a` pentru navigare, heading-uri `h1`–`h6` într-o ierarhie logică (fără să sari nivele ca să „arate frumos”). Liste (`ul`/`ol`) pentru enumerări; tabele doar pentru date tabulare, cu `<th>` și `scope`. Un DOM curat reduce drastic nevoia de ARIA. Skip link („Sari la conținut”) la începutul paginii ajută navigarea cu tastatura.
2) Formulare și validare. Fiecare input are `<label for="...">` (sau wrapping corect); erorile sunt legate de câmp (`aria-describedby` / `aria-invalid`), nu doar culoare roșie. Mesajele spun ce e greșit și cum repari. Folosește `autocomplete` unde e cazul (login, adresă). Nu bloca submit-ul doar pe validare vizuală. Pentru fluxuri lungi (petiții, cereri): salvare parțială, pași clari, rezumat înainte de trimitere — accesibil și pentru utilizatori cu dificultăți cognitive.
3) Tastatură, focus și ferestre modale. Tot ce e acționabil trebuie ajuns cu Tab/Shift+Tab; ordinea vizuală = ordinea în DOM (sau e gestionată corect). Focus vizibil (`:focus-visible`) — nu îl scoți cu `outline: none` fără înlocuitor. În modale/drawer: focus trap, Escape închide, focusul se întoarce pe trigger la închidere. Evită `tabindex` pozitiv (anti-pattern). Shortcut-urile custom nu trebuie să încalce tastele cititoarelor de ecran.
4) ARIA — când ajută și când strică. Regula: HTML semantic întâi; ARIA doar când native nu acoperă (tablist, combobox complex, live region pentru alerte async). `aria-label` / `aria-labelledby` pe icon-only buttons; `aria-expanded` / `aria-controls` pe meniuri. Nu dubla roluri (`<button role="button">`). Live regions (`aria-live="polite"`) pentru toast-uri și rezultate de căutare — fără spam. ARIA greșit e mai rău decât deloc.
5) Vizual, media și mișcare. Contrast text/UI conform WCAG AA (în general 4.5:1 text, 3:1 componente UI mari). Nu transmite informația doar prin culoare. Imagini informative: `alt` util; decorative: `alt=""`. Video/audio esențial: subtitrări / transcript. Respectă `prefers-reduced-motion` (reducere animații). Zoom 200% și reflow pe lățimi mici fără pierdere de conținut (nu `overflow: hidden` pe text critic). Dark mode / teme: recalculează contrastele, nu copia orbeste token-urile.
6) SPA, framework-uri și componente. În React/Next/Vue etc.: la schimbarea rutei, mută focusul pe `main` / heading (altfel cititorul de ecran „rămâne” pe vechiul context). Anunță update-urile async. Liste virtualizate și infinite scroll trebuie să rămână operabile din tastatură. Design system-ul e unitatea de conformitate: un `Button` / `Modal` / `Select` accesibil salvează zeci de ecrane; unul greșit le strică pe toate. Evită canvas/WebGL pentru UI critic fără alternativă HTML.
7) Documente, captcha, autentificare. PDF-urile generate din sistem (adeverințe, decizii, confirmări) trebuie să aibă text selectabil, tag-uri/structură unde e posibil — nu doar imagine scanată. Captcha: preferă metode accesibile (ex. verificare invizibilă / SMS / întrebare alternativă), nu puzzle doar vizual. Login: erori clare, compatibilitate cu parole manager, MFA care nu blochează tehnologiile asistive. Session timeout: avertizare și posibilitate de prelungire.
8) Testare și „Definition of Done”. Automat: axe-core / Lighthouse a11y în CI, `eslint-plugin-jsx-a11y` (sau echivalent), teste Playwright/Cypress pe fluxuri critice cu navigare tastatură. Manual: checklist WCAG pe template-uri, VoiceOver / NVDA / TalkBack pe 1–2 fluxuri cheie, zoom 200%. Nu marca „Done” un ticket UI fără criterii de accesibilitate. Regresia apare la redesign și la plugin-uri terțe — retestează după upgrade-uri de UI kit.
Achiziții publice și furnizori. Dacă instituția cumpără un portal, un CMS sau o aplicație, cerințele de accesibilitate trebuie să fie în caietul de sarcini / contract — cu referință la EN 301 549 și la acceptanță verificabilă (nu doar „site modern”). Furnizorul privat care livrează către sectorul public trebuie să țină cont că produsul digital al instituției rămâne sub OUG 112/2018. Pentru operatorii sub Legea 232/2022, accesibilitatea e cerință de piață, nu opțiune de marketing. Consultanța IT ajută să mapezi ce lege ți se aplică și ce pui în contract.
Cum începi un plan de conformitate (public sau privat). (1) Clarifică domeniul legal: OUG 112, Legea 232, ambele, sau doar bună practică voluntară. (2) Inventariază proprietățile digitale (site, app, PDF-uri esențiale, terminale). (3) Audit pe EN 301 549 / WCAG 2.1 AA — pagini și fluxuri critice întâi. (4) Remediere pe priorități + criterii de acceptanță în sprinturi. (5) Declarație de accesibilitate (obligatorie în public; utilă și în privat) + canal de feedback. (6) Re-test și actualizare când schimbi template-ul sau CMS-ul. Accesibilitatea e proces, nu un PDF de o zi.
Notă importantă. Acest articol explică cadrul pe înțelesul tuturor și nu înlocuiește consultanța juridică sau un audit formal de conformitate. Textele oficiale (OUG 112/2018, Legea 90/2019, Legea 232/2022, Directiva 2016/2102, Directiva 2019/882, EN 301 549, Decizia ADR 815/2022) și ghidurile ADR rămân sursa de autoritate. Dacă vrei un audit pe paginile critice, o declarație de accesibilitate sau un plan de remediere aliniat la EN 301 549, contactează-ne.