Regions actives: aria-live, role="status" i role="alert" (4.1.3)

Les interfícies modernes canvien sense recarregar: apareix «Producte afegit al carretó», el comptador de resultats passa de 120 a 8 en aplicar un filtre, una barra de progrés avança, un xat rep un missatge. Qui veu la pantalla ho percep immediatament. Qui fa servir un lector de pantalla està escoltant una altra part de la pàgina i no se n'assabenta, llevat que el codi ho anunciï. Per a això hi ha les regions actives (live regions), i el criteri 4.1.3 Missatges d'estat (AA, introduït a WCAG 2.1) n'exigeix l'ús: els missatges d'estat s'han de poder determinar per programa mitjançant rol o propietats, de manera que les tecnologies de suport els presentin sense que rebin el focus.

Què és un missatge d'estat

WCAG defineix missatge d'estat com un canvi de contingut que informa la persona de l'èxit o el resultat d'una acció, de l'estat d'espera de l'aplicació, del progrés d'un procés o de l'existència d'errors, i que no suposa un canvi de context. Si el focus es mou al missatge (per exemple, a un diàleg o a un resum d'errors que rep el focus), ja no és un missatge d'estat en el sentit de 4.1.3: la persona el llegirà perquè hi és. El criteri cobreix precisament el que apareix sense moure el focus.

Les eines

• aria-live="polite": el lector anuncia el canvi quan acabi el que estigui dient. És l'opció per defecte per a gairebé tot.
• aria-live="assertive": interromp immediatament. Només per a errors o avisos que requereixen atenció urgent.
• role="status": equival a aria-live="polite" amb aria-atomic="true". Per a confirmacions, comptadors, estats de càrrega.
• role="alert": equival a aria-live="assertive" amb aria-atomic="true". Per a errors i avisos importants.
• role="log": per a fluxos on s'afegeix contingut al final (xat, registre d'activitat); polite i no atòmic.
• aria-atomic="true": anuncia tota la regió, no només el fragment que ha canviat. Imprescindible quan el missatge només té sentit complet («3 de 10 fitxers pujats»).
• aria-relevant: quins canvis s'anuncien (additions, removals, text); el valor per defecte, additions text, és gairebé sempre l'adequat i rarament cal tocar-lo.
• aria-busy="true": suspèn els anuncis mentre una regió s'actualitza per parts; quan passa a false, s'anuncia el resultat.

<p id="contador" role="status"></p>
<ul id="resultados">…</ul>

function actualizarResultados(lista) {
  pintarLista(lista);
  document.getElementById('contador').textContent =
    `${lista.length} resultats trobats`;
}

Les regles que fan que funcioni

Les regions actives són fràgils: petits detalls d'implementació fan que no s'anunciï res o que s'anunciï massa. Aquestes regles eviten la majoria de fallades:

1. La regió ha d'existir al DOM abans del canvi. Els lectors de pantalla registren les regions actives quan construeixen l'arbre; si crees el <div role="status"> i hi poses el text en la mateixa operació, molts no l'anuncien. Crea el contenidor buit en carregar la pàgina i insereix-hi el text després.
2. Canvia el contingut, no la visibilitat. Treure display:none a una regió que ja tenia text no compta com a canvi en diversos lectors. Insereix o modifica el text.
3. Una regió, un missatge cada vegada. Diverses regions parlant alhora es trepitgen. El més habitual és tenir una regió status i una alert globals, buides, a la plantilla, i escriure-hi des de qualsevol component.
4. Buida la regió al cap d'uns segons si l'has de reutilitzar, perquè el mateix missatge repetit s'anunciï de nou (alguns lectors no anuncien un text idèntic a l'anterior) i perquè no es llegeixi en navegar per la pàgina.
5. Sigues breu. Una regió activa no és un lloc per a paràgrafs; una frase curta i concreta.
6. No posis aria-live en contenidors grans (tot el <main>, una taula sencera): cada canvi provocarà lectures interminables.
7. assertive és l'excepció, no la norma. Reserva role="alert" per als errors que impedeixen continuar i els avisos de temps (sessió a punt de caducar).

// Incorrecte: la regió es crea amb el missatge a dins
const aviso = document.createElement('div');
aviso.setAttribute('role', 'alert');
aviso.textContent = 'Error en desar';
document.body.appendChild(aviso);

// Correcte: el contenidor ja existeix a l'HTML, buit
// <div id="aviso-error" role="alert"></div>
document.getElementById('aviso-error').textContent = 'Error en desar';

Casos típics i l'eina adequada

Quan no s'ha de fer servir una regió activa

Si la persona ha d'actuar sobre el que apareix (confirmar, corregir, triar), mou-hi el focus en lloc d'anunciar-ho: un diàleg modal, un resum d'errors enfocable. I si el canvi és la conseqüència directa i evident de l'acció sobre l'element amb focus (marcar una casella, canviar una pestanya), el mateix canvi d'estat de l'element ja s'anuncia; una regió activa duplicaria el missatge.

Com comprovar-ho

• Amb NVDA o VoiceOver actiu, provoca cada missatge d'estat sense moure el focus i comprova que s'anuncia una sola vegada i complet.
• Inspecciona l'HTML inicial: les regions han d'existir buides abans de la interacció.
• Busca aria-live en contenidors grans i assertive injustificats.
• Prova el mateix missatge dues vegades seguides: s'ha d'anunciar les dues.

Resum

• 4.1.3 exigeix que els missatges que apareixen sense moure el focus siguin anunciats per les tecnologies de suport mitjançant rol o propietats ARIA.
• role="status" (polite, atòmic) per a gairebé tot; role="alert" (assertive) només per a errors i urgències; role="log" per a fluxos.
• La regió ha d'existir buida al DOM abans d'inserir-hi el text; canvia el contingut, no la visibilitat.
• Poques regions, missatges curts, sense aria-live en contenidors grans.
• Si la persona ha d'actuar, mou el focus en lloc d'anunciar.