Saltar al contenido
Fundamentos

¿Un botón o widget de accesibilidad hace accesible mi sitio? Por qué los overlays no alcanzan

3 min de lectura · WCAG: Conformidad con las Pautas WCAG 2.2

Escrita por Mapa Bianchi

Por qué importa

Los overlays son capas de código que se suman encima de un sitio y ofrecen un menú para agrandar la letra, cambiar colores o «activar el modo lector de pantalla». Suenan bien para quien decide el presupuesto, pero no corrigen el código de fondo. Además, pueden hacerle creer al equipo que el problema está resuelto y frenar las correcciones de verdad.

Por qué no alcanzan

  1. No arreglan la base. Un campo sin etiqueta, un título mal ordenado o un botón hecho con un div siguen igual debajo del widget. La reparación automática no puede adivinar, por ejemplo, qué muestra una imagen ni para qué sirve un botón sin nombre.
  2. Duplican lo que la gente ya tiene. Quien necesita letra más grande, alto contraste o un lector de pantalla ya lo tiene configurado en su dispositivo. Un menú más no suma.
  3. Pueden empeorar la experiencia. Hay personas usuarias de lectores de pantalla que reportan que estos widgets interfieren con su navegación o agregan anuncios confusos.
  4. No garantizan el cumplimiento legal. En 2025, la Comisión Federal de Comercio de Estados Unidos multó con un millón de dólares a accessiBe, una de las empresas más conocidas del rubro, por afirmar sin pruebas que su herramienta hacía que cualquier sitio cumpliera las WCAG. Y hay sitios con overlays que igual recibieron demandas.

Cientos de especialistas en accesibilidad firmaron la Overlay Fact Sheet (en inglés), que explica estos problemas y pide no usarlos como solución. El Foro Europeo de la Discapacidad publicó una declaración conjunta en el mismo sentido.

Qué hacer en su lugar

  • Una auditoría con herramientas automáticas y revisión manual, con teclado y lector de pantalla.
  • Corregir en el origen: el diseño, el código y el contenido.
  • Sumar la accesibilidad al proceso: en el diseño de cada componente, en la redacción de cada publicación y en el criterio de entrega. La guía Para devs tiene un checklist.
  • Publicar una declaración de accesibilidad honesta, con lo que se cumple, lo que falta y cómo avisar de un problema.

Casos que confunden

  • «Lo uso además de corregir el sitio»: si el sitio ya es accesible, el widget no suma y puede interferir. Mejor invertir ese presupuesto en revisar y en probar con personas.
  • Herramientas de ayuda a la lectura que la persona elige instalar en su navegador (como extensiones de lectura en voz alta) son otra cosa: las decide quien las usa, no el sitio.
  • «Pero el widget tiene buenas reseñas»: parte de la multa de la FTC fue por presentar reseñas pagadas como opiniones independientes.

Fuentes y última revisión

Checklist antes de contratar una solución

Marcá lo que ya resolviste. Abajo ves qué falta y lo podés copiar.

Antes de publicar

0 de 5 puntos cumplidos

Ver lo que falta (5)
  • ¿La solución corrige el código y el contenido, o solo agrega una capa?
  • ¿Promete cumplimiento legal «con una línea de código»? Desconfiá.
  • ¿Está prevista una auditoría con revisión manual?
  • ¿El equipo sabe qué corregir en diseño, código y contenido?
  • ¿Hay una declaración de accesibilidad con un canal para reportar problemas?