Ce este ARIA? Roluri, landmark-uri și regiuni live

Ce este ARIA — și ce nu este

ARIA vine de la Accessible Rich Internet Applications. Este un set de atribute definite de Web Accessibility Initiative (WAI) a W3C, care le permite dezvoltatorilor să comunice semnificația și starea elementelor de interfață către tehnologii de asistare precum cititoarele de ecran.

Cea mai importantă regulă despre ARIA este și cea mai des ignorată: nu folosi ARIA atunci când HTML-ul nativ poate face treaba. Un element <button> se anunță deja ca buton și răspunde la evenimentele de tastatură. Un element <nav> comunică deja cititoarelor de ecran un landmark de navigare. Adăugarea role="button" pe un <div> și apoi scrierea comportamentului în JavaScript este mai greu de întreținut, mai ușor de stricat și, de obicei, mai proastă pentru accesibilitate decât folosirea elementului potrivit de la bun început.

ARIA nu:

• Face conținutul vizibil sau interactiv — schimbă doar ce anunță tehnologia de asistare
• Repară accesul defectuos de la tastatură — tot ai nevoie de tabindex și de ascultători de evenimente
• Înlocuiește un HTML semantic bine structurat

ARIA ajută cu adevărat atunci când HTML-ul nativ nu are un element pentru ceea ce construiești: un selector de dată, un banner de notificări în timp real, un combobox personalizat, o vizualizare arborescentă. În aceste cazuri, ARIA îți permite să comunici semantica pe care HTML-ul nu o poate exprima.

Rolurile ARIA

Un rol îi spune tehnologiei de asistare cu ce fel de element are de-a face. Fiecare element interactiv are un rol implicit derivat din eticheta sa HTML. Elementul <a> are rolul link. Elementul <input type="checkbox"> are rolul checkbox. Elementul <h2> are rolul heading.

Când construiești un element personalizat care nu are echivalent în HTML, îi atribui un rol explicit:

<!-- Un comutator personalizat construit dintr-un div -->
<div
  role="switch"
  aria-checked="false"
  tabindex="0"
>
  Mod întunecat
</div>

Cititorul de ecran va anunța acum acest element ca pe un control de tip comutator și va rosti starea sa de bifare. Fără rol, ar fi anunțat ca text simplu, iar utilizatorul nu ar avea de unde să știe că este interactiv.

Roluri frecvente și când să le folosești

Rolurile de widget descriu controale interactive:

Rol	Se folosește când
button	Un element personalizat pe care se poate face clic, fără o etichetă HTML mai potrivită
checkbox	Un comutator personalizat cu selecție multiplă
combobox	O intrare de text combinată cu o listă derulantă de tip listbox
dialog	O suprapunere modală (doar când nu folosești elementul nativ <dialog>)
listbox	O listă derulantă personalizată
slider	Un control personalizat de tip interval
switch	Un comutator pornit/oprit
tab, tablist, tabpanel	O interfață cu file
tooltip	O descriere scurtă afișată la trecerea cu mouse-ul sau la focalizare

Rolurile de structură a documentului descriu conținut neinteractiv:

• article — o bucată de conținut de sine stătătoare
• figure — o imagine cu legendă
• list, listitem — când este nevoie de semantica de listă pe elemente care nu sunt liste
• presentation / none — elimină rolul implicit al unui element (de folosit rar și cu grijă)

O greșeală critică: adăugarea rolurilor fără comportament

Fiecare rol vine cu un contract pe care cititoarele de ecran și utilizatorii de tastatură se așteaptă să fie respectat. Un role="button" trebuie să răspundă atât la Enter, cât și la Space. Un role="checkbox" trebuie să comute la Space. Un role="link" trebuie să navigheze la Enter.

Dacă adaugi rolul, dar nu și comportamentul corespunzător, induci în eroare în mod activ utilizatorii de tehnologie de asistare. Ei aud un control anunțat, încearcă să interacționeze cu el folosind comanda de tastatură așteptată și nu se întâmplă nimic. Asta este mai rău decât lipsa totală a ARIA.

Landmark-urile ARIA

Landmark-urile sunt scheletul de navigare al paginii. Ele le permit utilizatorilor de cititoare de ecran să sară între regiunile majore fără să citească tot ce se află între ele — echivalentul privirii unui utilizator văzător care scanează dintr-o ochire aspectul paginii.

HTML5 a introdus elemente semantice care corespund direct rolurilor de landmark. Folosește-le și landmark-urile vin gratuit:

Element HTML	Rol de landmark	Scop
<header>	banner	Antetul la nivel de site (doar când este antetul de prim nivel, nu în interiorul unui <article>)
<nav>	navigation	Un meniu de navigare
<main>	main	Conținutul principal al paginii
<aside>	complementary	Conținut secundar, legat de conținutul principal
<footer>	contentinfo	Subsolul la nivel de site
<form>	form	Un formular (doar când are un nume accesibil)
<section>	region	O secțiune denumită (doar când are un nume accesibil prin aria-label sau aria-labelledby)

Nu trebuie să adaugi role="main" pe un element <main> — este redundant. Rolurile de landmark ARIA sunt necesare doar când nu poți folosi elementul HTML semantic, de exemplu într-o bază de cod veche care generează <div class="sidebar">:

<div class="sidebar" role="complementary" aria-label="Articole conexe">
  <!-- conținutul barei laterale -->
</div>

Etichetarea landmark-urilor când ai mai multe

Când o pagină are mai multe instanțe ale aceluiași landmark — două elemente <nav>, două elemente <section> cu role="region" — fiecare trebuie să aibă un nume accesibil unic, ca utilizatorii să le poată distinge:

<nav aria-label="Navigare principală">...</nav>
<nav aria-label="Navigare din subsol">...</nav>

Fără etichete, un cititor de ecran le anunță pe amândouă pur și simplu drept „navigare”. Cu etichete, utilizatorii aud „Navigare principală, landmark de navigare” și „Navigare din subsol, landmark de navigare” și pot alege varianta potrivită dintr-o listă de landmark-uri.

Regiunile live ARIA

O regiune live este o zonă a paginii al cărei conținut se actualizează dinamic și ale cărei actualizări ar trebui anunțate automat utilizatorilor de cititoare de ecran, fără ca aceștia să fie nevoiți să mute focalizarea.

Atributul de bază este aria-live. Acceptă trei valori:

• off — actualizările nu sunt anunțate (valoarea implicită pentru toate elementele)
• polite — actualizările sunt anunțate după ce utilizatorul își încheie sarcina curentă
• assertive — actualizările întrerup imediat orice rostește cititorul de ecran

<!-- O zonă de mesaje de stare populată după trimiterea unui formular -->
<div aria-live="polite" id="status-message"></div>

<script>
  document.getElementById('status-message').textContent =
    'Mesajul tău a fost trimis.';
</script>

Când conținutul textual se schimbă, un cititor de ecran cu aria-live="polite" așteaptă o pauză în vorbire și apoi anunță noul conținut. Folosește polite pentru marea majoritate a actualizărilor dinamice. Rezervă assertive doar pentru eșecuri critice — o eroare de plată, un avertisment de expirare a sesiunii — unde informația este suficient de urgentă încât să justifice întreruperea utilizatorului.

Roluri-scurtătură pentru regiunile live

Două roluri împachetează semantica aria-live într-un singur atribut:

• role="status" — echivalent cu aria-live="polite". Se folosește pentru mesaje de succes, stări de încărcare și actualizări care nu sunt urgente.
• role="alert" — echivalent cu aria-live="assertive" și implică totodată aria-atomic="true". Se folosește pentru mesaje de eroare și eșecuri critice.

<!-- Eroare anunțată imediat, întrerupând vorbirea curentă -->
<div role="alert" id="payment-error"></div>

<!-- Actualizare de stare anunțată politicos, după vorbirea curentă -->
<div role="status" id="cart-count">3 produse în coș</div>

Greșeli frecvente cu regiunile live

Adăugarea conținutului înainte ca elementul să fie în DOM. Browserul înregistrează regiunea live atunci când elementul este parcurs prima dată. Dacă injectezi elementul și îi setezi conținutul textual simultan, unele cititoare de ecran ratează complet anunțul. Include întotdeauna containerul regiunii live în HTML-ul inițial și actualizează-i conținutul ulterior, prin JavaScript.

Folosirea lui assertive pentru orice. Regiunile live assertive întrerup tot ce face utilizatorul, inclusiv alte anunțuri. Un contor de rezultate ale căutării care se actualizează în timp ce utilizatorul tastează nu justifică role="alert". Abuzul de assertive produce o experiență ostilă pentru utilizatorii de cititoare de ecran.

Actualizarea prea frecventă a regiunii live. Dacă un indicator de progres își actualizează regiunea live la fiecare 100 de milisecunde, coada de vorbire se aglomerează și utilizatorii nu aud nimic util. Actualizează textul live doar la borne semnificative — 25%, 50%, 75%, finalizat — sau amână actualizările cu un temporizator.

Uitarea lui aria-atomic. În mod implicit, se anunță doar nodul de text modificat din interiorul unei regiuni live. Dacă vrei ca întreaga regiune să fie recitită (nu doar fragmentul modificat), adaugă aria-atomic="true":

<div aria-live="polite" aria-atomic="true">
  <span id="count">2</span> produse rămase
</div>

Fără aria-atomic, un cititor de ecran poate anunța doar „2” când contorul se schimbă de la 3 la 2. Cu el, se rostește expresia completă „2 produse rămase”, ceea ce este aproape întotdeauna ceea ce îți dorești.

Alte atribute ARIA esențiale

aria-label — oferă un nume accesibil atunci când niciun text vizibil nu este potrivit:

<button aria-label="Închide fereastra de dialog">✕</button>

aria-labelledby — indică un alt element al cărui text servește drept nume accesibil. Preferat față de aria-label atunci când textul etichetei este deja vizibil pe pagină:

<h2 id="billing-heading">Adresa de facturare</h2>
<form aria-labelledby="billing-heading">...</form>

aria-describedby — indică un text suplimentar care descrie un element dincolo de numele său:

<input type="password" aria-describedby="pwd-hint">
<p id="pwd-hint">Trebuie să aibă cel puțin 12 caractere și să includă un simbol.</p>

aria-expanded — arată dacă un element pliabil (listă derulantă, acordeon, meniu) este deschis sau închis. Actualizează-l în JavaScript ori de câte ori se schimbă starea:

<button aria-expanded="false" aria-controls="nav-menu">Meniu</button>
<ul id="nav-menu" hidden>...</ul>

aria-hidden="true" — elimină un element din arborele de accesibilitate. Se folosește pentru pictograme decorative, text duplicat sau elemente vizuale care ar adăuga zgomot pentru utilizatorii de cititoare de ecran:

<span aria-hidden="true">★★★★☆</span>
<span class="sr-only">4 stele din 5</span>

aria-disabled="true" — marchează un control ca dezactivat fără a-l elimina din ordinea de focalizare. Util când vrei ca utilizatorii să descopere că acel control există și să înțeleagă de ce nu este disponibil, în loc să fie sărit în tăcere:

<button aria-disabled="true">Trimite (completează mai întâi toate câmpurile)</button>

Testarea ARIA în practică

Scrierea atributelor ARIA este simplă. Corectitudinea lor cere testare. Scanerele automate depistează tiparele evident greșite — un role="button" fără nume accesibil, un aria-labelledby care trimite la un ID inexistent, o regiune live cu o valoare aria-live invalidă. Ele nu îți pot spune dacă textul anunțat are sens în context sau dacă un widget personalizat complex se comportă corect când este navigat exclusiv de la tastatură.

Pentru testarea în condiții reale, combină cel puțin două perechi de cititor de ecran și browser:

• NVDA + Chrome pe Windows — gratuit, folosit pe scară largă, apropiat de populația reală de utilizatori de cititoare de ecran
• VoiceOver + Safari pe macOS sau iOS — integrat, esențial pentru testarea accesibilității pe mobil
• JAWS + Chrome sau Edge pe Windows — cu plată, dar cel mai utilizat cititor de ecran în mediile enterprise

Navighează prin componentele tale interactive folosind doar tastatura. Ascultă cu atenție ce se anunță când deschizi un meniu, când trimiți un formular cu o eroare de validare sau când declanșezi actualizarea unei regiuni live. Dacă anunțul este ambiguu sau înșelător, implementarea ARIA este greșită — indiferent ce raportează vreun instrument automat.

Regula care le acoperă pe toate

Specificația ARIA include cinci reguli de scriere. Prima este cea mai importantă:

Dacă poți folosi un element sau un atribut HTML nativ care are deja încorporate semantica și comportamentul de care ai nevoie, în loc să reutilizezi un element și să adaugi un rol, o stare sau o proprietate ARIA ca să îl faci accesibil, atunci fă asta.

Construiește cu HTML semantic. Recurge la ARIA doar când HTML-ul nu mai are ce oferi. Testează cu un cititor de ecran real. Asta acoperă aproape orice situație pe care o vei întâlni.

Pentru o verificare practică a modului în care sunt implementate atributele ARIA pe tot site-ul tău, auditurile noastre manuale de accesibilitate includ testare cu cititoare de ecran realizată de persoane care folosesc tehnologii de asistare în fiecare zi și care pot depista problemele ARIA subtile pe care instrumentele automate le ratează.