Qué es un widget de accesibilidad y cómo funciona
Un widget de accesibilidad, también llamado overlay, es una capa de JavaScript que se instala sobre un sitio web existente. No modifica el código fuente del sitio. Actúa por encima de él, intentando corregir problemas de forma automática en el navegador del usuario.
Algunos ajustan el contraste visual. Otros aumentan el tamaño de la fuente. Algunos intentan generar descripciones automáticas para imágenes sin texto alternativo o mejorar la navegación por teclado. Todo en tiempo real, sin tocar el código base del sitio.
El argumento comercial es simple: en lugar de invertir en una auditoría de accesibilidad y en trabajo de implementación real, pagas una suscripción anual y el widget "se encarga de todo". Algunas empresas del rubro llegaron a garantizar cumplimiento legal absoluto con solo instalar su producto.
En enero de 2025, la Comisión Federal de Comercio de Estados Unidos, la FTC, multó a accessiBe, uno de los proveedores más grandes del mercado, con un millón de dólares por publicidad engañosa. La razón: prometían que su widget hacía sitios web "conformes con WCAG" cuando técnicamente no era posible.
Los números que la industria prefiere no mostrar
Hay una estadística que resume bien el problema. Según el reporte anual de UsableNet, el 25% de todas las demandas por accesibilidad web presentadas en 2024 en Estados Unidos apuntaron específicamente a sitios que tenían un widget o overlay instalado. No como solución. Como parte del problema.
En 2024, 1.023 demandas por accesibilidad web citaron explícitamente el uso de un widget como barrera para el acceso, no como garantía de cumplimiento. Fuente: UsableNet, 2024 Digital Accessibility Lawsuit Report.
Lo que ocurre en muchos de esos casos es que el widget interfiere con las tecnologías de asistencia que usan personas con discapacidad. Un lector de pantalla, por ejemplo, interactúa directamente con el código del sitio. Cuando un overlay intenta modificar ese código en tiempo real, puede generar conflictos, comportamientos inesperados o simplemente desactivar funciones que el usuario ya tenía configuradas en su propio dispositivo.
Dicho de otra forma: algunas personas con discapacidad desactivan los widgets cuando los encuentran, porque empeoran su experiencia.
Hay casos judiciales que lo documentan. En el fallo Murphy v. Eyebobs, el tribunal rechazó explícitamente el argumento de que un overlay constituía accesibilidad adecuada. En el acuerdo LightHouse v. ADP, el texto del acuerdo estableció que soluciones como las de AudioEye y accessiBe "no serían suficientes para lograr accesibilidad".
También hay un caso que involucra directamente a un cliente del proveedor. En junio de 2024, la clínica de dermatología Tribeca Skin Center demandó a accessiBe por incumplimiento de contrato. La clínica había pagado por el widget convencida de que estaría protegida legalmente. Meses después fue demandada por un usuario ciego que no podía navegar el sitio. El widget no había resuelto los problemas de fondo.
Por qué los widgets no pueden resolver el problema solos
La accesibilidad web no es una capa visual. Es estructura. Un sitio accesible está construido con código semántico correcto, jerarquía de encabezados lógica, etiquetas asociadas a los formularios, roles ARIA implementados según las especificaciones, y navegación funcional por teclado.
Nada de eso puede generarse automáticamente por encima del código existente de forma confiable. Un widget puede cambiar el color de fondo o aumentar el tamaño del texto. No puede saber si el texto alternativo de una imagen es descriptivo o vacío de significado. No puede determinar si el orden de navegación por teclado tiene sentido para alguien que no puede usar el mouse. No puede evaluar si un formulario de contacto es usable para alguien con movilidad reducida.
Las herramientas automatizadas, incluyendo los widgets más sofisticados, detectan entre el 30% y el 40% de los problemas de accesibilidad. El resto requiere revisión humana especializada y, en lo posible, testing con personas con discapacidad.
Eso no cambia por añadir una capa de JavaScript sobre el sitio.
Entonces, ¿para qué sirve un widget?
Aquí es donde conviene ser precisos, porque la respuesta honesta no es "para nada".
Un widget de accesibilidad bien implementado, como complemento de un sitio que ya tiene un trabajo real de accesibilidad detrás, puede mejorar la experiencia de algunos usuarios. Personas que prefieren navegar con el texto más grande. Personas con sensibilidad a ciertos colores que quieren activar un modo de alto contraste rápidamente. Personas que prefieren una fuente más legible para dislexia.
Estas son preferencias de usuario válidas. Y ofrecer esa personalización tiene sentido, siempre que no reemplace el trabajo de fondo.
La diferencia está en cómo se presenta el widget. Si se instala como solución de accesibilidad, estás tomando un atajo que no funciona. Si se instala como una capa de personalización adicional sobre un sitio ya trabajado, puede ser una herramienta útil.
Esa distinción no es menor. Es la diferencia entre un parche y un complemento.
Cómo lo entendemos en Árbol Digital
Ofrecemos un widget de accesibilidad con soporte local porque entendemos que puede mejorar la experiencia de algunos usuarios cuando está bien contextualizado. Pero nunca lo ofrecemos como punto de partida ni como sustituto de nada.
Nuestro proceso de trabajo comienza con una evaluación real del sitio, basada en las pautas WCAG 2.2, ahora también norma ISO, con revisión técnica y, cuando corresponde, con testing real con usuarios. El widget puede ser parte de la solución final. No es la solución.
Lo que diferencia un widget bien utilizado de uno mal utilizado no es el producto en sí. Es el contexto en que se instala y la honestidad con que se describe lo que puede y no puede hacer.
Qué hacer si tu sitio tiene un widget instalado hoy
Si instalaste un widget convencido de que te daba cumplimiento completo, no eres el único. Es un mensaje que varios proveedores comunicaron agresivamente durante años. Pero hay pasos concretos que puedes dar ahora:
1. Revisa qué problemas tiene realmente tu sitio. Herramientas gratuitas como WAVE te dan una primera señal de los errores más evidentes. Si los resultados muestran problemas de contraste, imágenes sin descripción o formularios sin etiquetas, el widget no los está resolviendo. Están ahí, solo que invisibles para quien los administra.
2. Entiende qué cubre y qué no cubre el widget que usas. Ningún widget cubre el 100% de los criterios WCAG. Pregunta directamente al proveedor qué criterios aborda y cuáles no. Si la respuesta es vaga, es una señal importante.
3. Considera una auditoría como punto de partida real. En Chile, el Decreto Supremo N°1 exige estándares de accesibilidad al sector público desde hace más de diez años. Para el sector privado, la presión normativa internacional aumenta. Saber exactamente dónde está tu sitio es el primer paso para mejorar. Nuestra Auditoría Digital Responsable te da ese diagnóstico completo.
El fondo del asunto
El problema con los widgets no es tecnológico. Es de expectativas. Una herramienta que se vende como solución completa cuando técnicamente no puede serlo le hace un daño doble al mercado: le da a las empresas una falsa sensación de seguridad y les quita recursos que podrían ir a trabajo real.
La accesibilidad web es una pregunta sobre si una persona con discapacidad puede usar tu sitio. Esa pregunta no tiene una respuesta automática. Tiene una respuesta que requiere entender cómo navega realmente esa persona, qué tecnologías usa, y qué barreras encuentra en el código.
En nuestra Radiografía de accesibilidad web en Chile encontramos que la mayoría de los sitios evaluados tienen problemas estructurales que ningún widget puede corregir. No porque los equipos sean descuidados, sino porque la accesibilidad nunca estuvo en el plano de diseño original.
El widget puede ser parte del camino. No puede ser el camino completo.