Widgets de accesibilidad: qué hacen de verdad (y qué no)

Si has buscado «accesibilidad web» últimamente, seguro que te ha aparecido un icono redondo, normalmente azul, en la esquina de alguna página. Es un widget de accesibilidad. Hay decenas en el mercado, como accessiBe, UserWay, y variantes integradas en plugins de WordPress como el que usamos nosotros mismos. La comunidad de accesibilidad los tiene muy mal vistos en general, y con argumentos sólidos. Nosotros tenemos uno instalado en nuestra propia web. Por eso queremos hablar de ello sin rodeos: qué hacen de verdad, qué no, y por qué lo usamos igualmente.

Qué es, exactamente, un widget de accesibilidad

Es un script que se añade a una página web y muestra un menú flotante con opciones: aumentar el tamaño del texto, cambiar el contraste, activar un lector de pantalla básico, ajustar el espaciado entre líneas, activar tipografías especiales, resaltar enlaces y títulos. El usuario lo abre, elige las opciones que necesita, y la página cambia al instante, sin recargar.

Algunos, más avanzados, prometen ir más allá: escanear el código de la página y añadir automáticamente etiquetas ARIA o texto alternativo donde falten, mediante inteligencia artificial. Es precisamente esta segunda categoría la que genera más controversia, y vale la pena entender por qué.

Por qué la comunidad de accesibilidad es tan crítica

No es una cuestión de estética ni de moda. Hay tres argumentos concretos, y los tres tienen datos detrás.

Primero: no tocan el código fuente. Un widget no corrige una estructura de encabezados mal hecha, no añade un alt correcto a una imagen que no lo tiene, no arregla un formulario sin etiquetas asociadas. Buena parte de los criterios WCAG que hacen que una web sea realmente accesible para alguien que usa lector de pantalla a diario dependen exactamente de esto: marcado limpio, semántica correcta, relaciones entre elementos bien hechas (criterios como 1.1.1 Contenido no textual, 1.3.1 Información y relaciones, o 4.1.2 Nombre, función, valor). Ningún botón de superficie lo arregla, porque el problema está en el código, no en la pantalla.

Los widgets «inteligentes» que prometen añadir etiquetas automáticamente con IA tienen un problema añadido: cuando la herramienta adivina mal qué representa una imagen o qué función tiene un botón, no deja el elemento sin etiqueta, le pone una etiqueta incorrecta. Para un usuario de lector de pantalla, una descripción equivocada puede ser peor que ninguna descripción, porque genera confusión activa en lugar de silencio.

Segundo: pueden empeorar la experiencia real. Los datos de los propios usuarios de lectores de pantalla lo confirman: en encuestas como la de WebAIM, una parte importante dice que estos widgets les complican la navegación en lugar de facilitarla. El motivo es sencillo: estas personas ya llevan su propio lector de pantalla configurado a su gusto, desde hace años. Un script externo que se inyecta por encima de la página puede interferir con esa configuración, generar anuncios duplicados, o bloquear atajos de teclado que el usuario usa habitualmente en todas las webs.

Tercero: no te protegen legalmente. Tener un widget instalado no equivale a cumplir la normativa. Hay casos documentados, especialmente en Estados Unidos, de empresas con un widget activo que han perdido demandas por incumplimiento de accesibilidad igualmente, y en algún caso, la existencia del widget se ha interpretado como un intento de solución rápida de cara al exterior, sin trabajo real detrás. La ley mira el resultado, si una persona con discapacidad puede usar la web, no si has instalado un parche.

Lo que sí hace y dónde los límites son evidentes

Dicho esto, sería deshonesto decir que no sirven para nada. Si repasas los «perfiles de accesibilidad» que suele ofrecer un widget de este tipo, hay algunos que aguantan bien el escrutinio, y hay uno que es el ejemplo clásico de por qué la comunidad los critica. Vale la pena ser igual de riguroso a favor que en contra.

Convulsiones y epilepsia. Este es, probablemente, el caso con la base más sólida de todos. Detener animaciones y contenido parpadeante responde a un criterio WCAG explícito (2.3.1, umbral de destellos), porque un destello mal calculado puede desencadenar una crisis en una persona con epilepsia fotosensible. Un botón que corta la animación al instante, incluso antes de que el código de la página esté revisado a fondo, es una medida de seguridad real e inmediata. Es especialmente útil cuando el contenido de riesgo viene de un tercero, por ejemplo un anuncio, un vídeo incrustado, que el propietario de la web no controla del todo. Aquí el widget no es cosmética, es protección.

Daltonismo. También sólido. Los filtros de color para daltonismo (daltonización) son una técnica con base técnica real, no inventada por el marketing del widget: existen extensiones de navegador dedicadas solo a esto, y se usan en entornos profesionales de diseño. Tiene sentido como ayuda complementaria, sobre todo en webs que aún no han corregido los lugares donde solo el color distingue información (criterio WCAG 1.4.1). No sustituye corregir el código, pero mientras el código no está corregido, cumple una función real.

Una persona mayor con problemas de vista. Técnicamente, su navegador ya le permite ampliar el texto (Ctrl y +, o el zoom del móvil) en cualquier web, no solo en la tuya. El problema es que muchas personas mayores no lo saben, y nunca lo descubrirán por sí solas, no porque no puedan, sino porque nadie se lo ha enseñado y no es evidente que exista. Si ven un icono visible, en su idioma, con un botón grande que dice «Texto más grande», lo usan sin pensárselo dos veces. No es una solución técnicamente superior a la herramienta del navegador: es una solución que la persona encuentra y usa, y eso tiene un valor práctico real para este colectivo concreto, aunque sea un valor de descubribilidad y no de tecnología punta.

El contrapunto: ceguera. Y aquí está el ejemplo que la propia comunidad de accesibilidad usa para explicar por qué los overlays fallan. Una persona totalmente ciega ya lleva su propio lector de pantalla, como JAWS, NVDA, VoiceOver, configurado e integrado en el sistema desde hace años. Para llegar a abrir el «perfil de ceguera» del widget, tendría que poder localizar y activar ese botón sin ayuda… cosa que, si realmente no ve, solo puede hacer si ya tiene su propio lector activado. En este caso, el botón casi nunca lo llegará a pulsar la persona a quien dice estar dirigido. Es el espejo exacto del caso de las personas mayores: allí el botón se encuentra y se usa; aquí, estructuralmente, no.

La diferencia entre los cuatro casos no es casualidad: funciona cuando soluciona algo que el usuario no sabe hacer por sí solo y que no entra en conflicto con ninguna herramienta que ya use (personas mayores, daltonismo) o cuando actúa como medida de protección inmediata ante un riesgo real (epilepsia). Falla cuando supone que el usuario llegará al botón sin tener ya la solución montada (ceguera).

Cómo saber si te están vendiendo humo

Si alguien te propone un widget de accesibilidad para tu web, ya sea un proveedor externo o tu propio equipo interno, estas cuatro preguntas te dirán enseguida si hablan con rigor o con marketing:

1. «¿El widget sustituye la auditoría, o la complementa?» Si la respuesta es que el widget por sí solo te hace cumplir la normativa, desconfía. Ninguna herramienta de superficie sustituye revisar y corregir el código.
2. «¿Qué pasa con los criterios que no se pueden arreglar desde fuera del código?» Si no saben responder, es que nunca han revisado el código real, solo han instalado un script.
3. «¿Tiene declaración de accesibilidad propia, conforme al RD 1112/2018 o la Ley 11/2023?» Una declaración seria explica qué se ha corregido en el código y qué hace el widget por separado. Si todo se mezcla en una frase genérica, es señal de alarma.
4. «¿Qué pasa si el usuario ya tiene su propio lector de pantalla configurado?» Si no tienen respuesta, nunca han hablado con una persona con discapacidad visual que use uno de verdad.

Entonces, ¿vale la pena tener uno?

Nuestra respuesta: sí, como complemento, no como solución.

Si una web ya tiene el código bien hecho, es decir contraste correcto, estructura semántica limpia, formularios bien etiquetados, navegación de teclado funcional, imágenes con texto alternativo real, un widget puede añadir una capa extra de comodidad para algunos visitantes, especialmente los que no saben que ya tienen estas opciones en su navegador o sistema operativo. Es una red de seguridad para quien no es experto digital, no un sustituto del trabajo de base.

El problema nunca ha sido el widget en sí. Es cuando se vende como si fuera la solución completa. Por eso, cuando hacemos una auditoría, separamos siempre las dos cosas: por un lado, las correcciones técnicas en el código que hacen que tu web cumpla de verdad la normativa; por otro, herramientas de comodidad adicional como esta, que pueden sumar, pero nunca sustituir.

¿Quieres saber si tu web tiene problemas de accesibilidad reales, más allá de cualquier widget? Prueba nuestro escáner gratuito y obtendrás un informe basado en axe-core, el estándar técnico que usan los auditores profesionales.