ARIA: Accessible Rich Internet Applications

¿Qué es ARIA?

ARIA (Accessible Rich Internet Applications, también escrito WAI-ARIA) es una especificación del W3C con atributos HTML que indican a las tecnologías de apoyo qué es un elemento, en qué estado está y cómo se relaciona con otros. Existe para los widgets personalizados que el HTML por sí solo no puede describir, como pestañas, cuadros combinados y regiones que se actualizan en vivo.

ARIA solo cambia lo que se comunica a la tecnología de apoyo. No añade comportamiento: no hace que un elemento sea enfocable, pulsable ni manejable con teclado. Para eso siguen haciendo falta HTML y JavaScript.

Roles, estados y propiedades

WAI-ARIA 1.2, la Recomendación vigente del W3C, define tres tipos de atributo:

• Rol (role): el indicador principal de qué es un elemento, por ejemplo role="tablist" o role="dialog".
• Propiedad (property): una característica del elemento que cambia poco, por ejemplo aria-label o aria-controls.
• Estado (state): una característica que cambia con la acción del usuario o con un script, por ejemplo aria-expanded o aria-checked.

Las reglas de uso de ARIA

La guía "Using ARIA" del W3C establece cuatro reglas. La primera es la que más se incumple:

1. Usa primero HTML nativo. Si un elemento o atributo ya ofrece la semántica y el comportamiento que necesitas, úsalo en lugar de añadir ARIA a otro elemento.
2. No cambies la semántica nativa salvo que no haya más remedio.
3. Todos los controles ARIA interactivos deben poder usarse con el teclado.
4. No pongas role="presentation" ni aria-hidden="true" en un elemento enfocable, o el usuario llegará a algo que parece no ser nada.

<!-- Native: no ARIA needed -->
<button type="button">Save</button>

<!-- Avoid: a div pretending to be a button -->
<div role="button" tabindex="0">Save</div>

El botón nativo es enfocable, responde a Intro y Espacio y se anuncia bien sin trabajo extra. El div exige reconstruir todo eso a mano. Un lector de pantalla solo anuncia lo que le dice el marcado.

Ejemplo: un botón desplegable

Un botón que muestra y oculta un panel es un caso donde ARIA aporta valor real, porque el HTML solo no puede decir si el panel está abierto:

<button type="button" aria-expanded="false" aria-controls="faq-1">
  Shipping details
</button>
<div id="faq-1" hidden>Orders ship within two days.</div>

Tu script debe cambiar aria-expanded a true al quitar hidden, y devolverlo a false al cerrar. En controles con solo un icono hace falta un nombre mediante aria-label:

<!-- Icon-only button: no visible text, so it needs a name -->
<button type="button" aria-label="Close dialog"><svg aria-hidden="true">...</svg></button>

Roles habituales y regiones en vivo

• dialog para diálogos modales, tablist, tab y tabpanel para pestañas, combobox para campos de autocompletado.
• Puntos de referencia como navigation y main, que <nav> y <main> ya incluyen de forma nativa.
• aria-labelledby y aria-describedby para apuntar a texto visible que nombra o explica un elemento.
• aria-current="page" para marcar el enlace actual en una navegación.

Las regiones en vivo anuncian cambios que el usuario no ha provocado moviendo el foco. role="status" es educado y espera a que termine la locución actual; role="alert" es asertivo e interrumpe, así que resérvalo para errores que exigen atención inmediata.

<div role="status">Draft saved</div>
<div role="alert">Connection lost</div>

Errores comunes

• ARIA en lugar del elemento correcto. El más frecuente: un div con rol donde bastaría un botón, un enlace o un select.
• Roles sin soporte de teclado. Un role="tab" sin manejo de las flechas se anuncia como pestaña y se comporta como nada.
• Estados obsoletos. Dejar aria-expanded="false" con el menú abierto dice lo contrario de lo que el usuario ve.
• Ocultar contenido enfocable. aria-hidden="true" en un botón o enlace lo deja accesible con teclado pero mudo.
• Etiquetas que contradicen el texto visible. Si el botón dice "Buscar" pero su aria-label dice "Ir", quien usa control por voz no puede decir lo que ve. Consulta también formularios accesibles.
• No probar nunca con tecnología de apoyo. Un marcado válido no garantiza un anuncio con sentido.

ARIA y pruebas de accesibilidad

ARIA es una pieza para cumplir las WCAG, porque varios criterios de éxito dependen de que los elementos expongan nombre, rol y valor. Las herramientas automáticas detectan el mal uso de ARIA que se puede comprobar solo con el marcado: valores de rol no válidos, atributos no permitidos en un rol o aria-hidden en elementos enfocables forman parte de la puntuación de accesibilidad de Lighthouse. No pueden juzgar si un widget funciona, así que combínalas con pruebas de teclado, una revisión con lector de pantalla y pruebas de accesibilidad automatizadas en CI. Nuestra comparativa de herramientas de pruebas de accesibilidad (en inglés) repasa las opciones. La monitorización de velocidad de página de LoadFocus registra la categoría Accessibility de Lighthouse en cada auditoría, para que sigas la puntuación en el tiempo.

Preguntas frecuentes: ARIA

¿Cuál es la primera regla de ARIA?

Usar un elemento o atributo HTML nativo que ya ofrezca la semántica y el comportamiento necesarios, en lugar de reutilizar otro elemento y añadirle ARIA. Los elementos nativos traen soporte de teclado y anuncios correctos de serie.

¿ARIA hace que un elemento sea accesible con teclado?

No. ARIA solo cambia cómo se describe un elemento a la tecnología de apoyo. El foco, la gestión de teclas y el comportamiento hay que construirlos con HTML y JavaScript.

¿Es mejor no usar ARIA que usarlo mal?

A menudo sí. Roles incorrectos y estados obsoletos pueden dejar al usuario peor que con HTML sencillo y correcto. Añade ARIA cuando el HTML nativo no pueda expresar el widget, y pruébalo.

¿Qué diferencia hay entre aria-label y aria-labelledby?

aria-label da el nombre accesible como cadena de texto. aria-labelledby apunta al id de otro elemento cuyo texto visible pasa a ser el nombre. Prefiere el texto visible siempre que puedas.

¿Dónde encuentro patrones ARIA probados?

La ARIA Authoring Practices Guide (APG) del W3C describe patrones de diseño para widgets habituales, cada uno con ejemplos funcionales. Sigue un patrón en lugar de inventar el comportamiento del teclado.