Accesibilidad ≠ Overlay: un menú de accesibilidad no hace accesible una web
Una web no se vuelve accesible porque aparezca un icono en una esquina. Aumentar letra, cambiar colores o activar texto a voz pueden ser funciones útiles, pero no sustituyen una implementación accesible.
El botón visible no es la accesibilidad
WCAG se ocupa del contenido y de cómo funciona. Un menú es solo una posible interfaz; no demuestra por sí mismo que estructura, teclado, foco, formularios o alternativas sean accesibles.
Aumentar texto no sustituye el zoom
W3C indica que el texto debe poder ampliarse hasta el 200 % sin pérdida de contenido o funcionalidad y que el escalado es principalmente responsabilidad del agente de usuario. Un botón «A+» puede complementar, pero no sustituir, el zoom correcto del navegador.
Cambiar colores no sustituye un contraste correcto
WCAG exige contraste suficiente en la presentación predeterminada. Un modo de alto contraste puede ayudar a algunas personas, pero no convierte en correcto un texto que parte de un contraste insuficiente.
Texto a voz no es un lector de pantalla
W3C distingue el software de texto a voz de los lectores de pantalla. Un lector de pantalla utiliza semántica para comunicar estructura, roles, estados y controles, y permite navegar e interactuar con ellos.
Lo que un menú no corrige
Encabezados incorrectos, campos sin etiqueta, controles sin nombre accesible, problemas de foco o una mala estructura no se reparan simplemente añadiendo una barra flotante. Parte de la accesibilidad está en la semántica y en la compatibilidad con tecnologías de asistencia.
¿Y Blind Reader?
Blind Reader debe explicarse como tecnología de asistencia que ayuda directamente a la persona, no como un overlay que certifica WCAG o repara automáticamente la web. Puede aportar formas adicionales de percibir o interactuar con el contenido, mientras la web sigue siendo responsable de su propia accesibilidad.