Què és ARIA? Rols, landmarks i regions actives

Què és ARIA — i què no és

ARIA són les sigles d’Accessible Rich Internet Applications. És un conjunt d’atributs definits per la Web Accessibility Initiative (WAI) del W3C que permet als desenvolupadors comunicar el significat i l’estat dels elements de la interfície d’usuari a tecnologies assistives com els lectors de pantalla.

La regla més important sobre ARIA és també la que s’ignora amb més freqüència: no facis servir ARIA quan l’HTML natiu ja pot fer la feina. Un element <button> ja s’anuncia com a botó i respon als esdeveniments de teclat. Un element <nav> ja comunica als lectors de pantalla que és un landmark de navegació. Afegir role="button" a un <div> i després programar-ne el comportament és més difícil de mantenir, més fàcil de trencar i normalment pitjor per a l’accessibilitat que fer servir l’element correcte des del principi.

ARIA no fa el següent:

No fa que el contingut sigui visible ni interactiu — només canvia el que anuncia la tecnologia assistiva
No arregla un accés de teclat trencat — continues necessitant tabindex i escoltadors d’esdeveniments
No substitueix un HTML semàntic ben estructurat

On ARIA ajuda de debò és quan l’HTML natiu no té cap element per a allò que estàs construint: un selector de dates, un bàner de notificacions en directe, un combobox personalitzat, una vista d’arbre. En aquests casos, ARIA et permet comunicar la semàntica que l’HTML no pot expressar.

Rols ARIA

Un rol indica a la tecnologia assistiva amb quina mena d’element està tractant. Cada element interactiu té un rol implícit derivat de la seva etiqueta HTML. L’element <a> té el rol link. L’element <input type="checkbox"> té el rol checkbox. L’element <h2> té el rol heading.

Quan construeixes un element personalitzat que no té equivalent en HTML, li assignes un rol explícit:

<!-- Un commutador personalitzat construït a partir d'un div -->
<div
  role="switch"
  aria-checked="false"
  tabindex="0"
>
  Mode fosc
</div>

Ara el lector de pantalla anunciarà això com a control de tipus commutador i n’indicarà l’estat de selecció. Sense el rol, s’anunciaria com a text pla i l’usuari no tindria cap manera de saber que és interactiu.

Rols habituals i quan fer-los servir

Els rols de giny descriuen controls interactius:

Rol	Fes-lo servir quan
`button`	Un element clicable personalitzat sense cap etiqueta HTML millor
`checkbox`	Un commutador personalitzat de selecció múltiple
`combobox`	Un camp de text combinat amb un desplegable de tipus listbox
`dialog`	Una superposició modal (només quan no es fa servir l’element natiu `<dialog>`)
`listbox`	Una llista desplegable personalitzada
`slider`	Un control de rang personalitzat
`switch`	Un commutador d’activació/desactivació
`tab`, `tablist`, `tabpanel`	Una interfície de pestanyes
`tooltip`	Una descripció breu que es mostra en passar-hi per sobre o en rebre el focus

Els rols d’estructura del document descriuen contingut no interactiu:

article — una peça de contingut autònoma
figure — una imatge amb un peu
list, listitem — quan cal semàntica de llista en elements que no ho són
presentation / none — elimina el rol implícit d’un element (fes-ho poques vegades i amb cura)

Un error crític: afegir rols sense comportament

Cada rol comporta un contracte que els lectors de pantalla i els usuaris de teclat esperen que es respecti. Un role="button" ha de respondre tant a Enter com a Espai. Un role="checkbox" ha de commutar amb Espai. Un role="link" ha de navegar amb Enter.

Si afegeixes el rol però no el comportament corresponent, enganyes activament els usuaris de tecnologia assistiva. Senten que s’anuncia un control, intenten interactuar-hi amb la drecera de teclat esperada i no passa res. Això és pitjor que no fer servir ARIA en absolut.

Landmarks ARIA

Els landmarks — les regions de referència — són l’esquelet de navegació de la pàgina. Permeten als usuaris de lectors de pantalla saltar entre les regions principals sense haver de llegir tot el que hi ha entremig — l’equivalent de la mirada d’un usuari vident que escaneja la disposició de la pàgina d’un cop d’ull.

L’HTML5 va introduir elements semàntics que es corresponen directament amb els rols de landmark. Fes-los servir i obtindràs els landmarks de franc:

Element HTML	Rol de landmark	Finalitat
`<header>`	`banner`	Capçalera de tot el lloc (només quan és la capçalera de primer nivell, no dins d’un `<article>`)
`<nav>`	`navigation`	Un menú de navegació
`<main>`	`main`	El contingut principal de la pàgina
`<aside>`	`complementary`	Contingut secundari relacionat amb el contingut principal
`<footer>`	`contentinfo`	Peu de pàgina de tot el lloc
`<form>`	`form`	Un formulari (només quan té un nom accessible)
`<section>`	`region`	Una secció amb nom (només quan té un nom accessible via `aria-label` o `aria-labelledby`)

No cal afegir role="main" a un element <main> — és redundant. Els rols de landmark ARIA només calen quan no pots fer servir l’element HTML semàntic, per exemple en una base de codi antiga que genera <div class="sidebar">:

<div class="sidebar" role="complementary" aria-label="Articles relacionats">
  <!-- contingut de la barra lateral -->
</div>

Etiquetar els landmarks quan n’hi ha més d’un

Quan una pàgina té diverses instàncies del mateix landmark — dos elements <nav>, dos elements <section> amb role="region" —, cadascuna ha de tenir un nom accessible únic perquè els usuaris les puguin distingir:

<nav aria-label="Navegació principal">...</nav>
<nav aria-label="Navegació del peu de pàgina">...</nav>

Sense etiquetes, un lector de pantalla anuncia totes dues simplement com a «navegació». Amb etiquetes, els usuaris senten «Navegació principal, landmark de navegació» i «Navegació del peu de pàgina, landmark de navegació» i poden triar la que els interessa des d’una llista de landmarks.

Regions actives ARIA

Una regió activa és una àrea de la pàgina el contingut de la qual s’actualitza dinàmicament i on aquestes actualitzacions s’han d’anunciar automàticament als usuaris de lectors de pantalla sense que hagin de moure el focus.

L’atribut central és aria-live. Accepta tres valors:

off — les actualitzacions no s’anuncien (el valor per defecte de tots els elements)
polite — les actualitzacions s’anuncien quan l’usuari acaba la tasca que està fent
assertive — les actualitzacions interrompen immediatament allò que el lector de pantalla està dient

<!-- Una àrea de missatges d'estat que s'omple després d'enviar un formulari -->
<div aria-live="polite" id="status-message"></div>

<script>
  document.getElementById('status-message').textContent =
    "El teu missatge s'ha enviat.";
</script>

Quan el contingut de text canvia, un lector de pantalla amb aria-live="polite" espera una pausa en la locució i tot seguit anuncia el contingut nou. Fes servir polite per a la immensa majoria d’actualitzacions dinàmiques. Reserva assertive només per a fallades crítiques — un error de pagament, un avís de caducitat de sessió — on la informació és prou urgent per justificar la interrupció de l’usuari.

Rols abreujats per a regions actives

Dos rols agrupen la semàntica d’aria-live en un sol atribut:

role="status" — equivalent a aria-live="polite". Fes-lo servir per a missatges d’èxit, estats de càrrega i actualitzacions no urgents.
role="alert" — equivalent a aria-live="assertive" i implica també aria-atomic="true". Fes-lo servir per a missatges d’error i fallades crítiques.

<!-- Error anunciat immediatament, interrompent la locució en curs -->
<div role="alert" id="payment-error"></div>

<!-- Actualització d'estat anunciada educadament després de la locució en curs -->
<div role="status" id="cart-count">3 articles al carretó</div>

Errors habituals amb les regions actives

Afegir contingut abans que l’element sigui al DOM. El navegador registra la regió activa quan l’element s’analitza per primera vegada. Si injectes l’element i n’estableixes el contingut de text simultàniament, alguns lectors de pantalla es perden l’anunci completament. Inclou sempre el contenidor de la regió activa a l’HTML inicial i actualitza’n el contingut més tard amb JavaScript.

Fer servir assertive per a tot. Les regions actives assertives interrompen tot allò que l’usuari està fent, incloent-hi altres anuncis. Un comptador de resultats de cerca que s’actualitza a mesura que l’usuari escriu no justifica un role="alert". Abusar d’assertive produeix una experiència hostil per als usuaris de lectors de pantalla.

Actualitzar la regió activa massa sovint. Si un indicador de progrés actualitza la seva regió activa cada 100 mil·lisegons, la cua de locució es desborda i els usuaris no senten res d’útil. Actualitza el text actiu només en fites significatives — 25 %, 50 %, 75 %, completat — o aplica un temporitzador d’atenuació a les actualitzacions.

Oblidar aria-atomic. Per defecte, només s’anuncia el node de text que ha canviat dins d’una regió activa. Si vols que es torni a llegir tota la regió (no només el fragment modificat), afegeix aria-atomic="true":

<div aria-live="polite" aria-atomic="true">
  Queden <span id="count">2</span> articles
</div>

Sense aria-atomic, un lector de pantalla pot anunciar només «2» quan el comptador passa de 3 a 2. Amb l’atribut, es llegeix la frase completa «Queden 2 articles», que és gairebé sempre el que vols.

Altres atributs ARIA essencials

aria-label — proporciona un nom accessible quan no hi ha cap text visible adequat:

<button aria-label="Tanca el diàleg">✕</button>

aria-labelledby — apunta a un altre element el text del qual fa de nom accessible. És preferible a aria-label quan el text de l’etiqueta ja és visible a la pàgina:

<h2 id="billing-heading">Adreça de facturació</h2>
<form aria-labelledby="billing-heading">...</form>

aria-describedby — apunta a text complementari que descriu un element més enllà del seu nom:

<input type="password" aria-describedby="pwd-hint">
<p id="pwd-hint">Ha de tenir com a mínim 12 caràcters i incloure un símbol.</p>

aria-expanded — indica si un element plegable (desplegable, acordió, menú) està obert o tancat. Actualitza’l amb JavaScript sempre que canviï l’estat:

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

aria-hidden="true" — elimina un element de l’arbre d’accessibilitat. Fes-lo servir per a icones decoratives, text duplicat o elements visuals que afegirien soroll per als usuaris de lectors de pantalla:

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

aria-disabled="true" — marca un control com a desactivat sense treure’l de l’ordre de focus. És útil quan vols que els usuaris descobreixin que el control existeix i entenguin per què no està disponible, en lloc que se’l saltin en silenci:

<button aria-disabled="true">Envia (omple abans tots els camps)</button>

Provar ARIA a la pràctica

Escriure atributs ARIA és senzill. Encertar-los requereix provar-los. Els escàners automatitzats detecten patrons clarament trencats — un role="button" sense nom accessible, un aria-labelledby que referencia un ID inexistent, una regió activa amb un valor d’aria-live no vàlid. El que no et poden dir és si el text anunciat té sentit en context, ni si un giny personalitzat complex es comporta correctament quan s’hi navega només amb el teclat.

Per a proves en condicions reals, combina com a mínim dues parelles de lector de pantalla i navegador:

NVDA + Chrome a Windows — gratuït, molt utilitzat i proper a la població real d’usuaris de lectors de pantalla
VoiceOver + Safari a macOS o iOS — integrat, imprescindible per a les proves d’accessibilitat mòbil
JAWS + Chrome o Edge a Windows — de pagament, però el lector de pantalla més utilitzat en entorns corporatius

Navega pels teus components interactius fent servir només el teclat. Escolta amb atenció què s’anuncia quan obres un menú, envies un formulari amb un error de validació o actives una actualització d’una regió activa. Si l’anunci és ambigu o enganyós, la implementació d’ARIA és incorrecta — independentment del que digui qualsevol eina automatitzada.

La regla que ho engloba tot

L’especificació d’ARIA inclou cinc regles de redacció. La primera és la més important:

Si pots fer servir un element o un atribut HTML natiu que ja incorpori la semàntica i el comportament que necessites, en lloc de reaprofitar un element i afegir-hi un rol, estat o propietat ARIA per fer-lo accessible, fes-ho.

Construeix amb HTML semàntic. Recorre a ARIA només quan l’HTML s’esgota. Prova-ho amb un lector de pantalla real. Això cobreix gairebé totes les situacions que et trobaràs.

Per a una comprovació pràctica de com s’implementen els atributs ARIA a tot el teu lloc, les nostres auditories manuals d’accessibilitat inclouen proves amb lectors de pantalla fetes per persones que utilitzen tecnologia assistiva cada dia i que saben detectar problemes subtils d’ARIA que les eines automatitzades passen per alt.