Accesibilidad ≠ Overlay: ARIA no arregla mágicamente un HTML mal construido
Después del HTML semántico llega una confusión muy habitual: pensar que añadir atributos ARIA convierte automáticamente un componente mal construido en accesible. ARIA es una herramienta esencial para comunicar semántica a las tecnologías de asistencia, especialmente en interfaces dinámicas y controles personalizados. Pero no sustituye el comportamiento, el teclado, el foco ni una base HTML correcta.
ARIA es importante, pero no es una capa de reparación
WAI-ARIA permite comunicar roles, estados y propiedades a las tecnologías de asistencia y es especialmente útil para contenido dinámico y controles avanzados. Pero su objetivo es complementar o extender las capacidades de HTML, no actuar como un parche universal sobre cualquier código.
Primera regla: utiliza HTML nativo cuando puedas
Las prácticas de W3C recomiendan maximizar el uso de HTML semántico nativo. Si existe un elemento HTML que ya ofrece la semántica y el comportamiento que necesitamos, suele ser una base más robusta que recrearlo desde cero con un elemento genérico y ARIA.
Un role es una promesa
W3C resume una idea esencial así: «un role es una promesa». Si escribimos <div role="button">, estamos prometiendo que ese elemento se comportará como un botón. El atributo no añade por sí mismo la interacción de teclado ni el comportamiento que un botón nativo proporciona.
ARIA comunica semántica; no crea comportamiento
ARIA puede decir a una tecnología de asistencia que algo es un botón, que un panel está expandido o que un elemento está seleccionado. Pero no implementa automáticamente Tab, Enter, Espacio, flechas, gestión del foco o la lógica JavaScript necesaria. La semántica y el comportamiento tienen que coincidir.
Nombre, función, estado y valor
WCAG 4.1.2 exige que en los componentes de interfaz puedan determinarse programáticamente el nombre y la función, y que estados, propiedades y valores relevantes estén disponibles. Los controles HTML estándar ya aportan gran parte de esa información cuando se utilizan correctamente.
ARIA incorrecto puede empeorar la experiencia
ARIA mal utilizado no es neutro. W3C advierte que «No ARIA is better than Bad ARIA»: una semántica incorrecta puede representar de forma equivocada la interfaz para quien depende de una experiencia no visual. Más ARIA no significa necesariamente más accesibilidad.
ARIA necesita pruebas reales
Los ejemplos de ARIA Authoring Practices advierten de posibles diferencias de soporte entre navegador y tecnología de asistencia y recomiendan probar las implementaciones antes de llevarlas a producción. Copiar un patrón sin comprobar su comportamiento real no es suficiente.
¿Qué tiene que ver esto con los overlays?
Esta es también una lección sobre los overlays. Una capa puede intentar añadir o modificar atributos después de cargar la página, pero la accesibilidad depende de que semántica, interacción, teclado, foco y estados funcionen juntos. Añadir ARIA desde fuera no convierte automáticamente una interfaz defectuosa en una interfaz robusta.
¿Y Blind Reader?
Blind Reader debe mantenerse en el lado de la asistencia al usuario. Puede ayudar a la persona a trabajar con el contenido, pero no debe presentarse como un sistema que corrige automáticamente el ARIA o el HTML de una web ni como una prueba de conformidad WCAG. La web sigue siendo responsable.
La idea que debemos recordar
ARIA es una herramienta potente cuando se utiliza donde hace falta y se implementa correctamente. No es una palabra mágica. Primero: HTML nativo y semántico siempre que sea posible. Después: ARIA cuando sea necesario. Y siempre: comportamiento correcto, teclado, foco y pruebas con tecnologías de asistencia.