Con los tres principios anteriores hemos cubierto lo que la persona percibe, opera y comprende. Pero todo eso descansa sobre una condición técnica: que el contenido esté construido de forma que navegadores y tecnologías de asistencia lo interpreten de manera fiable, hoy y en el futuro. Ese es el cuarto y último principio POUR, Robusto. Es el más corto en criterios y el más "de fontanería", pero el más crítico: si el código no es robusto, un componente puede ser perfecto visualmente y aun así no existir para Marta y su NVDA. Aquí conectamos directamente con el árbol de accesibilidad que vimos en el Módulo 2.

1. Qué significa "robusto"
2. Pauta 4.1: Compatible
3. El vínculo con el árbol de accesibilidad
4. Tabla resumen de criterios
5. Errores comunes y consejos
6. Ejercicios
7. Conclusión y cierre del módulo

Robusto significa que el contenido debe poder ser interpretado de forma fiable por una amplia variedad de agentes de usuario, incluidas las tecnologías de asistencia presentes y futuras. No basta con que "se vea bien en mi navegador": el marcado debe exponer información que cualquier TA pueda leer, ahora y cuando aparezcan nuevas versiones de lectores, navegadores o dispositivos. La robustez es lo que hace que tu trabajo en accesibilidad sobreviva al tiempo.

Maximizar la compatibilidad con los agentes de usuario actuales y futuros.

Históricamente, 4.1.1 exigía marcado bien formado (sin id duplicados, etiquetas correctamente anidadas y cerradas). En WCAG 2.2 este criterio se marcó como obsoleto y se eliminó. ¿Por qué? Porque los navegadores modernos y las TA ya recuperan de forma robusta y consistente los errores de marcado que este criterio pretendía evitar: la especificación HTML define cómo parsear código imperfecto, así que esos fallos ya no rompen la accesibilidad por sí mismos. Los problemas que sí importan (por ejemplo un id duplicado que rompe una asociación aria-labelledby) quedan cubiertos por otros criterios como 4.1.2 o 1.3.1. Conclusión práctica: no persigas la validez del marcado como un fin en sí; persigue que nombre, función y valor lleguen correctos.

Es el criterio central de la robustez. Para todo componente de interfaz —especialmente los personalizados— la TA debe poder determinar:

• Nombre (name): cómo se llama ("Filtrar por categoría").
• Función (role): qué es (un botón, un desplegable, una casilla).
• Valor/estado (value/state): en qué situación está (abierto/cerrado, seleccionado, expandido).

Con HTML nativo esto viene gratis: un <button> o un <select> ya exponen su nombre, función y estado. El problema aparece con componentes hechos a mano con <div> y JavaScript: sin role, sin nombre accesible y sin estados ARIA, son cascarones vacíos para la TA.

Los mensajes de estado —confirmaciones, errores, resultados, progreso— deben poder anunciarse a la TA sin mover el foco. Cuando Cursalia muestra "Se han encontrado 12 cursos" tras filtrar, o "Matrícula guardada", Marta debe oírlo aunque su foco siga en el filtro. Técnicamente esto se logra con regiones "en vivo" (por ejemplo aria-live), pero aquí basta con retener el requisito.

En el Módulo 2 vimos que la TA no lee el DOM visual, sino el árbol de accesibilidad: una representación que el navegador construye exponiendo el nombre, la función y el estado de cada elemento. El principio Robusto es, literalmente, la exigencia de que ese árbol esté bien poblado.

Imagina el desplegable del filtro de Cursalia construido con <div> sin semántica. Visualmente funciona: se abre, se cierra, resalta la opción elegida. Pero en el árbol de accesibilidad no hay ningún "botón", ningún nombre, ningún estado "expandido". Marta tabula y NVDA anuncia... nada útil, o un simple "clic". El control es invisible para ella. La solución conceptual es dar name/role/value correctos: usar HTML nativo siempre que se pueda, y cuando no, aplicar ARIA para declarar función y estado.

El HTML semántico y ARIA que implementan name/role/value son el Módulo 4: HTML Semántico y ARIA. El comportamiento robusto en contenido dinámico y SPAs (anunciar cambios, gestionar foco al navegar entre vistas) se profundiza en el Módulo 7.

• Reinventar controles con <div> y <span>. Un <div onclick> no es un botón para la TA. Empieza siempre por el elemento nativo (<button>, <select>, <input>), que trae name/role/value de fábrica.
• Creer que 4.1.1 aún exige "HTML válido". En WCAG 2.2 está obsoleto; lo que importa es que name/role/value lleguen bien. Aun así, evita id duplicados porque rompen asociaciones ARIA (eso lo penalizan 4.1.2 y 1.3.1).
• Poner ARIA sin gestionar el estado. Declarar role="button" pero no actualizar aria-expanded deja el valor mintiendo. La regla de oro: ningún ARIA es mejor que ARIA incorrecto.
• Mostrar mensajes que solo se ven. Un "Guardado" que aparece visualmente pero no se anuncia incumple 4.1.3; Marta no se entera de que su acción funcionó.
• Consejo: ante cualquier componente, hazte tres preguntas —¿tiene nombre?, ¿se sabe qué es?, ¿se sabe su estado?—. Si alguna falla, no es robusto.

Ejercicio 1. El desplegable del filtro de Cursalia está hecho con <div> y JavaScript; visualmente abre y cierra un panel de opciones. Con NVDA, Marta no percibe que es un control ni si está abierto. ¿Qué criterio se incumple y qué tres informaciones debe exponer el componente?

Ejercicio 2. Tras aplicar el filtro, aparece el texto "12 cursos encontrados", pero Marta, cuyo foco sigue en el control, no oye nada. ¿Qué criterio aplica, de qué nivel es y qué exige?

Ejercicio 3. Un compañero propone auditar el sitio validando el HTML con el validador del W3C para "cumplir 4.1.1". ¿Qué le explicarías sobre el estado de ese criterio en WCAG 2.2 y hacia dónde reorientar el esfuerzo?

Solución 1. Se incumple 4.1.2 Nombre, función, valor (A). El componente debe exponer: nombre (p. ej. "Filtrar por categoría"), función/rol (que es un control desplegable/botón que abre una lista) y valor/estado (si está expandido o contraído, y qué opción está seleccionada). La implementación con HTML nativo o ARIA se ve en el Módulo 4.

Solución 2. Aplica 4.1.3 Mensajes de estado (AA). Exige que el mensaje de estado se anuncie a la TA sin mover el foco, típicamente mediante una región en vivo, para que Marta lo escuche mientras sigue trabajando en el filtro.

Solución 3. Le explicaría que 4.1.1 (parsing) está obsoleto y se eliminó en WCAG 2.2: los navegadores ya recuperan de forma fiable el marcado imperfecto, así que validar HTML no es lo que garantiza accesibilidad. El esfuerzo debe reorientarse a 4.1.2 (que name/role/value sean correctos en cada componente) y a 4.1.3 (mensajes de estado). La validez sigue siendo buena higiene —sobre todo evitar id duplicados—, pero no es un criterio en sí.

El principio Robusto es la garantía técnica de todo lo anterior: sin name/role/value correctos y sin mensajes de estado anunciables, los otros tres principios se quedan en la superficie visual y no llegan al árbol de accesibilidad que usa Marta. Con esto cerramos el Módulo 3: hemos recorrido los cuatro principios POUR entendiendo qué exige cada uno y sus criterios clave de WCAG 2.2, con sus niveles A/AA.

Hasta aquí hemos hablado de requisitos. A partir del Módulo 4 cambiamos de plano: pasamos de "qué exige WCAG" a "cómo se implementa en HTML y CSS". Empezaremos por el HTML semántico —la forma más directa y robusta de dar name/role/value gratis— y seguiremos con formularios accesibles, ARIA y contraste. Todo lo que en este módulo hemos remitido con un "se implementa en el módulo 4/5" empieza a construirse ahora, con código real.