En 04-01 fijamos la regla de oro: usa el elemento HTML nativo antes que recrearlo. En 04-02 ya asomamos atributos como aria-describedby, aria-invalid y role="alert". Ahora toca entender qué son esos atributos: WAI-ARIA (Accessible Rich Internet Applications), un conjunto de atributos que permiten describir semántica —rol, estado y propiedades— en el marcado cuando el HTML nativo no llega. ARIA no cambia lo que ve el usuario ni añade comportamiento: solo cambia lo que expone el árbol de accesibilidad que estudiamos en el Módulo 2. Es una capa de información, no de interacción.

Precisamente por eso, esta lección trata ARIA como semántica declarativa: cómo etiquetar roles y estados en el HTML. Construir el widget interactivo —capturar teclado, mover el foco y actualizar estos estados con JavaScript— es el Módulo 5 (05-01). Aquí verás, por ejemplo, cómo darle a Marta el name/role/value correcto del desplegable de filtros de Cursalia; hacer que funcione con el teclado será el siguiente módulo.

1. Qué es ARIA y qué no es
2. Las 5 reglas de ARIA
3. Roles: landmark, widget y document
4. Estados y propiedades
5. El nombre accesible: aria-label, aria-labelledby, aria-describedby
6. aria-hidden y el peligro de ocultar contenido focusable
7. Introducción a las live regions
8. Caso Cursalia: name/role/value del desplegable de filtros
9. Tabla de atributos ARIA frecuentes
10. Errores comunes y consejos
11. Ejercicios
12. Conclusión

ARIA aporta tres tipos de información al árbol de accesibilidad:

• Roles (role="..."): qué es un elemento (un botón, una pestaña, una alerta).
• Propiedades (aria-label, aria-describedby...): características relativamente estables.
• Estados (aria-expanded, aria-checked...): condiciones que cambian con la interacción.

Lo que ARIA NO hace, y conviene grabárselo:

• No añade comportamiento. role="button" en un <div> no lo hace pulsable con teclado ni focusable; solo dice que es un botón. El comportamiento lo pones tú con JS (Módulo 5).
• No cambia la apariencia. No aplica estilos.
• No mejora nada por sí solo. Un ARIA mal puesto es peor que no poner nada, porque miente al lector de pantalla.

"Ningún ARIA es mejor que un mal ARIA." Un aria-* incorrecto crea una experiencia rota y difícil de diagnosticar.

La especificación resume el buen uso de ARIA en cinco reglas. Son la brújula de esta lección.

1. Si puedes usar un elemento HTML nativo con la semántica y el comportamiento que necesitas, úsalo, y no uses ARIA. Un <button> antes que un <div role="button">. Es la regla de oro de 04-01.
2. No cambies la semántica nativa salvo que sea imprescindible. No hagas <h2 role="button">; envuelve el texto en un <button> dentro del <h2>. Cambiar el rol nativo borra el original (el "heading" desaparece).
3. Todo widget ARIA interactivo debe ser operable con el teclado. Si creas role="button", debe recibir foco y activarse con Enter/Espacio. (La implementación es del Módulo 5, pero la regla nace aquí.)
4. No pongas role="presentation" ni aria-hidden="true" en elementos focusables. Ocultarías del árbol algo que el teclado sí puede alcanzar: el usuario enfoca "la nada".
5. Todo elemento interactivo debe tener un nombre accesible. Un botón sin nombre ("botón, sin etiqueta") es inservible para Marta.

Los roles ARIA se agrupan en familias. Tres importan aquí:

• Roles de landmark: regiones de navegación. Ya los obtienes gratis con HTML5 (<nav>=navigation, <main>=main...). Solo usarías el ARIA equivalente (role="navigation") si no puedes emplear el elemento nativo.
• Roles de widget: componentes interactivos (button, checkbox, tab, menuitem, dialog, slider...). Describen controles ricos. Construir su comportamiento es el Módulo 5; aquí solo declaramos el rol.
• Roles de documento/estructura: organizan contenido (list, listitem, heading, article, alert, status...).

La lección: si el elemento nativo ya tiene el rol, no lo repitas con role. <nav role="navigation"> es redundante.

Cuando el HTML nativo no puede expresar un estado (porque el control no existe de forma nativa), ARIA lo comunica. Los más frecuentes en marcado declarativo:

Un ejemplo declarativo: en la barra de navegación de Cursalia, marcar la página actual con aria-current="page" para que Marta sepa dónde está.

Advertencia clave: estos estados son declaraciones. aria-expanded="false" en el botón de filtros solo dice "cerrado"; actualizarlo a true al abrir es trabajo de JavaScript (Módulo 5). Un estado que nunca se actualiza vuelve a mentir al lector.

El nombre accesible es el texto que el lector anuncia para identificar un elemento (el name de name/role/value). El navegador lo calcula siguiendo una prioridad. Simplificada, de mayor a menor:

1. aria-labelledby (apunta a los id de otros elementos que sirven de nombre). Gana sobre todo lo demás.
2. aria-label (texto literal en el propio atributo).
3. El contenido/label nativo (el texto del <button>, el <label for> asociado).
4. Otros mecanismos (title...), como último recurso.

• aria-label: da un nombre cuando no hay texto visible. Ideal para el botón de cerrar (una "X") o el buscador con solo una lupa.

• aria-labelledby: construye el nombre a partir de texto ya visible en la página (evita duplicar y traducir dos veces). Puede referenciar varios id, que se concatenan.

• aria-describedby: no aporta el nombre sino una descripción adicional (se lee después). Es lo que usamos en 04-02 para ayudas y errores de formulario.

Diferencia esencial: labelledby = cómo se llama; describedby = información extra. Y aria-labelledby sobrescribe al texto interno, así que úsalo con cuidado.

aria-hidden="true" elimina un elemento (y sus descendientes) del árbol de accesibilidad, sin ocultarlo visualmente. Sirve para esconder del lector cosas puramente decorativas o duplicadas: un icono junto a un texto que ya lo dice.

El error grave (Regla 4) es poner aria-hidden="true" en algo focusable o que contenga elementos focusables (un enlace, un botón, un input). El resultado: Lucía tabula hasta un control que el lector considera inexistente. Enfoca "la nada".

Si de verdad quieres retirar algo del todo (visual y del árbol), usa hidden, display:none o quítalo del DOM; aria-hidden solo afecta al árbol, no al foco.

Una live region es una zona cuyo contenido, al cambiar dinámicamente, el lector anuncia solo, sin que el usuario tenga que ir hasta ella. Es la base del criterio 4.1.3 (Mensajes de estado) que vimos como requisito en el Módulo 3. A nivel de marcado hay tres piezas:

• aria-live="polite": anuncia cuando el lector termine lo que estaba diciendo. Para mensajes no urgentes: "Filtro aplicado: 12 cursos".
• aria-live="assertive": interrumpe y anuncia de inmediato. Para lo urgente: un error de envío.
• Roles atajo: role="status" equivale a polite; role="alert" equivale a assertive.

Punto importante: el contenedor debe existir vacío en el DOM desde el principio; el lector vigila los cambios dentro de él. Nos quedamos en el marcado. El detalle del comportamiento dinámico, cuándo usar polite vs assertive en formularios validados en vivo y el testing corresponden a los Módulos 5, 6 y 7.

Cursalia tiene un botón "Filtros" que muestra u oculta un panel. Supongamos —siguiendo la regla 1— que no podemos usar <details>/<summary> nativos y hay que construirlo. Nuestra tarea en este módulo es solo el marcado semántico correcto para que Marta perciba qué es y en qué estado está:

Analicemos qué recibe Marta:

• Role: button (nativo, no hace falta ARIA para el rol).
• Name: "Filtros" (texto del botón).
• Value/State: aria-expanded="false" → el lector anuncia "contraído".
• aria-controls="panel-filtros": declara qué elemento gobierna el botón.

Con esto, Marta oye: "Filtros, botón contraído". Sabe qué es, cómo se llama y su estado.

Lo que falta y NO es de este módulo: que al pulsar se muestre el panel, que aria-expanded pase a true, que se retire el hidden, y que el teclado (Enter/Espacio/Escape) funcione. Todo ese comportamiento es 05-01/05-02. Aquí hemos dejado el andamiaje semántico perfecto para que ese JavaScript solo tenga que actualizar el estado.

• Reinventar con ARIA lo que ya existe. <div role="button"> en vez de <button>. Regla 1 siempre primero.
• Sobrescribir la semántica nativa. <a role="button"> o <h2 role="tab"> borran el rol original. Casi nunca es lo que quieres.
• Estados que no se actualizan. Un aria-expanded="false" que nunca cambia miente. Si pones el estado, algo (JS, Módulo 5) debe mantenerlo al día.
• aria-hidden sobre elementos focusables. Crea "trampas" donde el foco existe pero el lector no ve nada.
• Elementos interactivos sin nombre. Un botón-icono sin aria-label es "botón sin etiqueta". Regla 5.
• Confundir labelledby con describedby. El primero es el nombre; el segundo, información extra que se lee después.
• Live region creada en el momento del cambio. Debe existir vacía desde el inicio para que el lector la vigile.
• Consejo: valida tu ARIA con la vista de árbol de accesibilidad del navegador (DevTools) y con un lector real. Si dudas si añadir un aria-*, probablemente la respuesta sea usar HTML nativo.

Un compañero ha maquetado el botón de reproducir de la vídeo-lección así. Reescríbelo cumpliendo las reglas de ARIA.

El botón de cerrar el panel de filtros solo muestra un icono "✕" y no tiene texto. Dótalo de un nombre accesible sin añadir texto visible, y explica qué mecanismo usas.

Cursalia tiene una pregunta frecuente plegable. Escribe solo el marcado semántico (rol, nombre y estado) del encabezado que abre/cierra la respuesta, indicando qué parte queda para el Módulo 5.

Solución 1. La regla 1 dice: usa el elemento nativo. Un <button> da rol, foco y teclado gratis, sin tabindex ni manejadores manuales de teclado; el icono se marca decorativo y se añade un nombre:

Así cumplimos las reglas 1 (nativo), 3 (operable con teclado, gratis) y 5 (tiene nombre).

Solución 2. Como no hay texto visible, se usa aria-label (propiedad que da un nombre por texto literal). El icono se oculta del lector porque es decorativo:

Si el nombre estuviera ya escrito visiblemente en otro elemento, la opción preferente sería aria-labelledby apuntando a él.

Solución 3. El patrón accesible envuelve el texto de la pregunta en un <button> dentro del encabezado (no se cambia el rol del <h3>; regla 2):

• Role: button (nativo) dentro de un heading que se conserva.
• Name: el texto de la pregunta.
• State: aria-expanded="false".

Lo que queda para 05-01: mostrar/ocultar #resp-1, alternar aria-expanded y gestionar el teclado. Aquí solo dejamos la semántica lista.

ARIA es la forma de añadir semántica —rol, estado y nombre— en el marcado cuando el HTML nativo no basta, pero su primera regla es no usarlo si hay una alternativa nativa, y un ARIA mal puesto es peor que ninguno. Has visto las cinco reglas, los tipos de rol, los estados declarativos como aria-expanded, cómo se calcula el nombre accesible (con la prioridad labelledby > label > texto nativo), el peligro de aria-hidden sobre focusables y una introducción a las live regions. Y has dejado el desplegable de filtros de Cursalia con un name/role/value impecable, listo para que el Módulo 5 le dé comportamiento.

Nos queda una pieza del principio "Perceptible" que aún no hemos implementado y que es puro CSS: que el contenido se vea y se lea bien. En 04-04 · Contraste de Color y Redimensionamiento de Texto cerraremos el módulo con ratios de contraste, no depender del color, unidades relativas, reflow y foco visible, aplicados a la paleta de marca de Cursalia y a Sofía con su zoom al 300%.