ACCESIBILIDAD ≠ OVERLAY · 29
La accesibilidad de una web no depende de un botón flotante
📅 28 de octubre de 2026 · ⏱ 9 min de lectura
Un botón flotante puede cambiar cómo se ve una página. Pero cuando alguien no consigue completar un formulario, utilizar un menú con el teclado o comprender un mensaje de error, la accesibilidad depende del sitio real y de cómo se ha construido.
01. La accesibilidad no se instala al final
Un overlay suele ofrecer cambios de contraste, tamaño de letra o espaciado. Estas preferencias pueden ser útiles, pero no reparan por sí mismas los componentes de una web. La accesibilidad debe estar presente desde la investigación y el diseño hasta el desarrollo, la redacción y el mantenimiento.
La pregunta adecuada no es si existe un botón de accesibilidad, sino si una persona puede alcanzar sus objetivos sin obstáculos.
02. Qué ocurre debajo de la apariencia
Un botón que solo muestra un icono necesita un nombre accesible. Un campo de correo necesita una etiqueta asociada y una instrucción comprensible. Los encabezados deben seguir una jerarquía coherente para facilitar la exploración del contenido.
Si la estructura HTML es incorrecta, cambiar colores o tipografías no proporciona automáticamente esa información a un lector de pantalla.
03. El ejemplo de una compra que no termina
Imaginemos una tienda con un widget de accesibilidad. Una persona añade un producto al carrito, pero al abrir la ventana de confirmación el foco permanece detrás del diálogo. No puede llegar al botón de continuar utilizando el teclado.
Aunque el widget permita ampliar el texto, la compra sigue bloqueada. La solución consiste en gestionar correctamente el foco, los controles y el cierre del diálogo.
04. Los contenidos también pueden excluir
Una imagen con información importante necesita un texto alternativo que comunique su función. Un enlace denominado «haz clic aquí» pierde sentido cuando se consulta fuera de contexto. Los mensajes de error deben explicar qué ha sucedido y cómo solucionarlo.
La claridad del lenguaje, la estructura de las instrucciones y la calidad de los textos forman parte de la accesibilidad, no son un complemento opcional.
05. Navegación por teclado y tecnologías de apoyo
Prueba a recorrer tu web con Tab y Shift+Tab. Comprueba que sabes dónde está el foco, que puedes activar controles con Enter o Espacio y que no quedas atrapado en un menú o ventana.
Después, comprueba los formularios y mensajes con un lector de pantalla. Una evaluación completa también debe contemplar ampliación, dispositivos móviles y diferentes formas de interacción.
06. Lo que un overlay no puede prometer
La presencia de un panel flotante no demuestra conformidad con las WCAG ni sustituye una auditoría. Las herramientas automáticas detectan algunos problemas, pero no pueden valorar por sí solas la comprensión de un proceso o la facilidad de uso real.
Tampoco basta con aprobar una prueba una sola vez: cada nueva plantilla, formulario o actualización puede introducir barreras.
07. Una comprobación práctica en cinco minutos
Elige una tarea habitual: localizar un servicio, contactar o completar una compra. Desconecta el ratón y trata de realizarla solo con el teclado. Comprueba la visibilidad del foco, el orden de navegación, las etiquetas y la recuperación de errores.
Anota cada bloqueo y repite la prueba con tecnologías de apoyo. Estos resultados ofrecen una lista de mejoras mucho más útil que limitarse a comprobar si aparece un icono flotante.
08. Cómo construir accesibilidad real
Empieza por HTML semántico, componentes accesibles y una arquitectura de información clara. Diseña estados de foco visibles, controles con nombres comprensibles, mensajes de error útiles y formularios que puedan completarse.
Utiliza las WCAG 2.2 como referencia, combina análisis automático con pruebas manuales e incorpora la accesibilidad al mantenimiento cotidiano. La accesibilidad no se añade con un botón: se construye en toda la experiencia.