Accesibilidad ≠ Overlay: HTML semántico, la base que un overlay no puede sustituir
Una web puede verse perfectamente ordenada y resultar confusa para quien navega con lector de pantalla, teclado u otra tecnología de asistencia. La causa puede estar en algo invisible: el HTML. Elementos como <main>, <nav>, <button>, <label> y los encabezados aportan significado, no solo apariencia.
Semántica significa comunicar qué es cada cosa
Dos textos pueden parecer iguales y no significar lo mismo para el navegador. Un <h2> comunica que comienza una sección; un <p> agrandado con CSS sigue siendo un párrafo. W3C destaca que una estructura bien marcada facilita la navegación y la orientación.
Los encabezados y las regiones son navegación
Los encabezados comunican la organización del contenido. Elementos como <header>, <nav>, <main>, <aside> y <footer> identifican regiones que lectores de pantalla y otras herramientas pueden utilizar para desplazarse con más eficiencia.
Un botón debe ser un botón
Un <button> nativo ya incorpora semántica y comportamiento conocidos. Simularlo con un <div> obliga a reconstruir semántica, foco y comportamiento de teclado. La primera regla de uso de ARIA recomienda utilizar HTML nativo cuando existe un elemento adecuado.
Los formularios necesitan relaciones reales
En un formulario no basta con colocar visualmente «Correo» cerca de una caja. W3C recomienda asociar las etiquetas con sus controles, normalmente mediante <label>, para que las tecnologías de asistencia puedan identificar correctamente el propósito del campo.
ARIA complementa; no sustituye HTML correcto
ARIA es esencial cuando HTML nativo no ofrece la semántica necesaria, especialmente en interfaces complejas. Pero no está pensado para sustituir HTML correcto sin necesidad. Un uso incorrecto de ARIA también puede alterar la semántica que recibe la tecnología de asistencia.
Lo que un overlay encuentra cuando llega tarde
Cuando una capa actúa después de cargar la página trabaja sobre una estructura que ya existe. Si la base usa elementos incorrectos, relaciones ausentes o componentes personalizados mal construidos, el problema nació antes del overlay. La estrategia más robusta es construir correctamente en origen y probar con tecnologías de asistencia.
¿Y Blind Reader?
Blind Reader debe situarse en el plano de la ayuda a la persona usuaria. La tecnología de asistencia puede facilitar el acceso o la interacción, pero no elimina la necesidad de que la web exponga una estructura comprensible. Blind Reader ayuda al usuario; no sustituye el HTML semántico ni certifica la web.
Construir bien antes de añadir capas
La semántica no es un detalle técnico invisible: forma parte de la experiencia. Antes de pensar en una capa que interprete o transforme la página, conviene utilizar el elemento correcto para cada función. Una web accesible empieza mucho antes del botón de accesibilidad: empieza en su código.
Fuentes / Sources
W3C WAI — Page Structure Tutorial
Accesibilidad ≠ Overlay · 11