Salt la conținut
Pandus
ro Schimbați limba
Meniu

Modele UI accesibile: WCAG, WAI-ARIA și APG

Actualizat 14 octombrie 2026 · Lectură de 7 min

Căutați „WCAG combobox” sau „WCAG tabs” și ajungeți în trei documente W3C diferite, care răspund la întrebări diferite. Această serie explică fiecare model de interfață obișnuit într-un magazin online — la ce folosește, ce criterii WCAG se aplică, un exemplu HTML scurt și corect, comportamentul așteptat la tastatură și ce poate și ce nu poate găsi o verificare automată. Pagina de față explică cum se leagă documentele între ele și enumeră toate modelele.

Este un ghid tehnic, nu consultanță juridică.

WCAG vs WAI-ARIA vs ARIA Authoring Practices

Document Ce este La ce răspunde
WCAG 2.2 Recomandare W3C, standardul din spatele EN 301 549 și al majorității legilor Care trebuie să fie rezultatul: acces cu tastatura, nume, contrast, mesaje de eroare
WAI-ARIA 1.2 Recomandare W3C (6 iunie 2023) de roluri, stări și proprietăți Cum spuneți tehnologiilor asistive ce este un element personalizat: role="tab", aria-expanded
ARIA Authoring Practices Guide (APG) Ghid W3C WAI cu modele și exemple Cum ar trebui să se comporte un widget: ce taste, ce mutări ale focusului, ce atribute

WCAG nu numește niciun widget. Spune, de exemplu, că fiecare element de control trebuie să își expună numele, rolul și starea (4.1.2), că totul trebuie să funcționeze cu tastatura (2.1.1), că focusul trebuie să fie vizibil (2.4.7) și că structura trebuie să existe în cod, nu doar în aspectul vizual (1.3.1). HTML-ul nativ vă oferă cea mai mare parte din acestea gratuit. Când construiți ceva ce HTML nu are — file, un combobox cu sugestii, un carusel — WAI-ARIA vă permite să îl descrieți, iar APG vă spune cum se așteaptă utilizatorii de tehnologii asistive să se comporte acesta.

W3C descrie WAI-ARIA ca o modalitate de a face accesibile „conținutul dinamic și controalele avansate de interfață”, iar APG ca un însoțitor care „recomandă abordări pentru a-i ajuta pe dezvoltatorii de aplicații web să facă widgeturile” accesibile. APG nu este o cerință de conformitate: puteți îndeplini WCAG și cu o altă soluție, bine testată. Chiar introducerea sa spune că testarea cu tehnologii asistive „este esențială înainte de a folosi în producție cod din acest ghid”.

Mai întâi HTML-ul nativ

Nota W3C Using ARIA a formulat-o ca primă regulă de utilizare a ARIA: dacă puteți folosi un element sau atribut HTML nativ care are deja încorporate semantica și comportamentul de care aveți nevoie, folosiți-l în loc să refolosiți alt element și să adăugați ARIA. Celelalte reguli: nu schimbați semantica nativă decât dacă este cu adevărat necesar; toate controalele interactive ARIA trebuie să poată fi folosite cu tastatura; nu puneți niciodată role="presentation" sau aria-hidden="true" pe un element care poate primi focus. (Nota este publicată acum ca draft întrerupt și trimite la APG pentru îndrumări suplimentare, dar regulile rămân baza comună.)

APG spune același lucru în cuvintele sale: „Mai bine fără ARIA decât cu ARIA prost” („No ARIA is better than bad ARIA”) și „un rol este o promisiune”. Adăugarea role="button" pe un div promite un buton, dar „rolurile ARIA nu fac browserele să ofere comportament de tastatură sau stiluri” — trebuie în continuare să îl faceți focalizabil și să reacționeze singur la Enter și Space.

<!-- Nativ: nume, rol, focus și tastatură gratuit -->
<button type="button">Adaugă în coș</button>

<!-- Reconstruit: fiecare parte se adaugă de mână și adesea este uitată -->
<div role="button" tabindex="0" onclick="add()" onkeydown="addOnEnterOrSpace(event)">Adaugă în coș</div>

Modelele din această serie

Controale de bază

Ferestre pop-up și suprapuneri

Navigare și structură

  • Meniu de navigare — de ce APG recomandă pentru site-uri navigarea de tip disclosure, nu menubar
  • Breadcrumbs — un nav etichetat și aria-current="page"
  • File (tabs) — tablist, tastele săgeți și activarea automată
  • Acordeon — titluri cu butoane sau details și summary
  • Tabel de date — marcaj table real, anteturi și legende
  • Carusel — control de pauză, slide-uri etichetate, fără rotație surpriză

Formulare

Ce găsește o verificare automată în modele

Verificările noastre rulează axe-core într-un browser real, pe pagina așa cum se încarcă. Pentru modele, asta înseamnă că găsesc în mod sigur problemele structurale: butoane și linkuri fără nume, câmpuri de formular fără etichetă, roluri necunoscute, atribute ARIA nepermise pentru un rol sau care trimit la un ID inexistent, un tab în afara unui tablist, elemente focalizabile ascunse cu aria-hidden. Fiecare constatare trimite la fișa sa din biblioteca de reguli.

Nu pot găsi problemele de comportament: dacă tastele săgeți trec de la o filă la alta, dacă focusul intră într-un dialog și se întoarce apoi, dacă aria-expanded se schimbă când meniul se deschide, dacă un carusel poate fi pus pe pauză. Conținutul ascuns la încărcarea paginii, cum ar fi un dialog închis, nu este testat deloc; extensia de browser verifică pagina în starea pe care o arată browserul dumneavoastră, așa că puteți deschide mai întâi dialogul. Planificați partea cu tastatura și cititorul de ecran așa cum este descris în cum se testează WCAG.

Începeți cu verificarea gratuită a unei pagini. Este o verificare automată, nu un audit complet.

Întrebări frecvente

Care este diferența dintre WCAG și WAI-ARIA?

WCAG spune care trebuie să fie rezultatul, de exemplu ca fiecare element de control să își expună numele, rolul și starea (4.1.2). WAI-ARIA este o specificație W3C de roluri, stări și proprietăți, una dintre căile prin care se ajunge la acest rezultat atunci când HTML-ul nativ nu este suficient.

Cere WCAG folosirea ARIA?

Nu. WCAG este neutru din punct de vedere tehnologic. Elementele HTML native precum button, a, input, select și table îndeplinesc de obicei criteriile fără niciun ARIA. ARIA este necesar pentru widgeturi personalizate pe care HTML nu le oferă, de exemplu filele.

Ce este ARIA Authoring Practices Guide (APG)?

O resursă W3C WAI care descrie cum ar trebui să se comporte widgeturile obișnuite: ce roluri și stări folosesc și ce taste acceptă. Este un ghid, nu o cerință WCAG, iar W3C cere ca exemplele să fie testate cu tehnologii asistive înainte de a fi folosite în producție.

Care este prima regulă a ARIA?

Dacă un element sau atribut HTML nativ are deja semantica și comportamentul de care aveți nevoie, folosiți-l în loc să adăugați ARIA pe alt element. Un buton adevărat este mai bun decât un div cu rolul button.

Poate o verificare automată să testeze modelele UI?

Parțial. Găsește nume lipsă, roluri și atribute ARIA invalide și relații greșite între rolurile părinte și copil. Nu poate spune dacă tastele săgeți funcționează, dacă focusul se mută corect sau dacă stările se actualizează în timp ce folosiți widgetul.

Surse

  • W3C WAI, WAI-ARIA overview: https://www.w3.org/WAI/standards-guidelines/aria/
  • W3C WAI, ARIA Authoring Practices Guide, Read Me First: https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/
  • W3C WAI, APG patterns: https://www.w3.org/WAI/ARIA/apg/patterns/
  • W3C, Using ARIA (draft întrerupt, regulile de utilizare a ARIA): https://www.w3.org/TR/using-aria/