Què és ARIA, les cinc regles i «cap ARIA és millor que un mal ARIA»

WAI-ARIA (s'obre en una finestra nova) (Accessible Rich Internet Applications) és una especificació del W3C que defineix un conjunt d'atributs HTML (role i els que comencen per aria-) per comunicar a les tecnologies de suport el significat, l'estat i les relacions dels elements d'una interfície. La versió vigent és WAI-ARIA 1.2 (recomanació de juny de 2023), acompanyada de l'ARIA Authoring Practices Guide (s'obre en una finestra nova) (APG), que descriu com implementar patrons concrets (pestanyes, menús, diàlegs…), i de l'especificació del càlcul del nom accessible. En aquesta lliçó fixem què fa ARIA, què no fa i les regles que eviten els desastres.

Què fa ARIA i què no

ARIA actua exclusivament sobre l'arbre d'accessibilitat. Quan afegeixes role="button" a un <div>, el lector de pantalla anunciarà «botó», però el <div> continua sense rebre el focus, sense respondre a Retorn ni Espai i sense participar en el formulari. ARIA és una promesa que fas a la persona usuària: «això es comporta com un botó». Si no compleixes la promesa amb JavaScript i tabindex, el resultat és pitjor que si no haguessis dit res, perquè la persona intentarà fer-lo servir i no funcionarà.

En resum, ARIA:

• Sí que canvia o afegeix el rol, el nom, la descripció, els estats i les propietats que perceben les tecnologies de suport.
• Sí que permet anunciar canvis dinàmics (regions actives) i expressar relacions (controla, etiquetat per, descrit per).
• No afegeix comportament: ni focus, ni teclat, ni validació, ni enviament.
• No canvia l'aspecte visual ni afecta els usuaris sense tecnologia de suport.
• No arregla un HTML mal estructurat; el maquilla.

Les cinc regles d'ús d'ARIA

El document Using ARIA del W3C resumeix l'ús correcte en cinc regles que convé saber de memòria.

Regla 1: si hi ha un element HTML natiu, fes-lo servir

Si pots fer servir <button>, <a href>, <input type="checkbox">, <nav>, <dialog> o <details>, no construeixis l'equivalent amb <div> i ARIA. L'element natiu porta el rol, el comportament i el suport de tots els navegadors. Les excepcions legítimes són molt poques: que la funcionalitat no existeixi en HTML (pestanyes, arbre, graella editable), que l'element natiu no es pugui estilitzar com exigeix el disseny i s'hagi comprovat que no hi ha alternativa, o que el suport d'accessibilitat de l'element natiu sigui deficient en els navegadors objectiu.

Regla 2: no canviïs la semàntica nativa llevat que sigui imprescindible

<h2 role="tab">Horaris</h2>
<a href="#" role="button">Envia</a>
<ul role="navigation">…</ul>

Regla 3: tot control ARIA interactiu ha de ser operable amb teclat

Si poses role="button", role="tab", role="menuitem" o qualsevol altre rol de giny, estàs obligat a implementar el teclat que l'APG descriu per a aquell patró: focus amb tabindex, activació amb Retorn i Espai, fletxes si el patró les fa servir. El rol sense el teclat és la pitjor combinació possible.

Regla 4: no facis servir role="presentation" ni aria-hidden="true" en elements enfocables

Un element que pot rebre el focus però que està amagat a l'arbre d'accessibilitat produeix una parada «fantasma»: la persona prem Tab, el focus arriba a alguna cosa i el lector no diu res. Abans d'amagar un element amb aria-hidden, assegura't que ni ell ni els seus descendents són enfocables; si ho són, treu-los de l'ordre amb tabindex="-1", amb inert o amb display:none.

Regla 5: tot element interactiu ha de tenir un nom accessible

Ho vam veure al curs d'HTML: sense nom, el lector anuncia «botó» o «enllaç» i prou. Amb ARIA això afecta sobretot les icones i els rols de giny: role="button" en un <div> amb una icona a dins necessita aria-label o aria-labelledby.

Quan sí que cal fer servir ARIA

ARIA és imprescindible en aquests casos:

• Patrons sense equivalent HTML: pestanyes (tablist, tab, tabpanel), arbres, graelles, menús d'aplicació, combobox personalitzats, controls lliscants de dos valors.
• Estats que l'HTML no pot expressar: aria-expanded en un botó que desplega un panell, aria-pressed en un botó commutador, aria-current="page" en l'enllaç de la pàgina actual, aria-selected en una pestanya, aria-sort en una columna ordenable.
• Relacions que l'HTML no cobreix: aria-describedby, aria-controls, aria-labelledby entre elements que no es poden associar d'una altra manera.
• Anuncis de canvis dinàmics sense moure el focus: aria-live, role="status", role="alert".
• Donar nom als landmarks repetits i a les regions genèriques.

<button type="button" aria-expanded="false" aria-controls="filtros">
  Filtra els resultats
</button>
<div id="filtros" hidden>…</div>

Suport real

Que un atribut existeixi a l'especificació no garanteix que totes les combinacions de navegador i lector de pantalla l'anunciïn igual. Abans de dependre d'un atribut poc comú (aria-roledescription, aria-details, aria-errormessage), comprova'l en les parelles més utilitzades a Espanya: NVDA i JAWS amb Chrome o Firefox, VoiceOver amb Safari, TalkBack amb Chrome. El web a11ysupport.io i les notes de la mateixa APG documenten el suport conegut. Quan el suport sigui dubtós, ofereix una alternativa (text visible, aria-describedby en lloc d'aria-errormessage).

Resum

• ARIA modifica només l'arbre d'accessibilitat: aporta rol, nom, estat i relacions, però cap comportament.
• Regla 1: fes servir HTML natiu sempre que existeixi; regla 2: no destrueixis la semàntica nativa; regla 3: tot giny ARIA necessita teclat; regla 4: res enfocable no pot estar amagat a l'arbre; regla 5: tot element interactiu necessita nom.
• ARIA és imprescindible per a patrons sense equivalent HTML, per a estats com aria-expanded i per anunciar canvis dinàmics.
• Més ARIA no vol dir més accessibilitat; comprova cada atribut amb lectors de pantalla reals.