¿Tu chatbot es realmente usable por todos?

Los chatbots tienen un problema de accesibilidad

Los chatbots de atención al cliente se han convertido en la opción de contacto principal —y a menudo la única— para muchos productos digitales. La expectativa está clara: si necesitas ayuda, abre el chat. Si el chat no funciona para ti, con frecuencia no hay nada más.

Para los usuarios con discapacidad, esta situación suele ser insostenible. La mayoría de los chatbots comerciales no cumplen requisitos básicos de accesibilidad. Los usuarios de lectores de pantalla no pueden oír los mensajes a medida que llegan. Los usuarios de teclado quedan atrapados dentro del widget de chat y no pueden salir. Los usuarios con discapacidades motoras se encuentran con objetivos táctiles demasiado pequeños para pulsarlos de forma fiable. Los usuarios con discapacidades cognitivas se enfrentan a muros de texto y a la falta de una forma clara de recuperarse de una consulta mal interpretada.

Esto importa tanto ética como legalmente. La Ley Europea de Accesibilidad, en vigor desde junio de 2025, abarca los canales digitales de atención al cliente de las empresas afectadas, lo que incluye las interfaces de chatbot. La ADA en Estados Unidos se ha aplicado a los chatbots en litigios sobre accesibilidad web. Si un chatbot es un canal de servicio principal, un chatbot inaccesible es una exclusión del servicio.

Los siete fallos de accesibilidad más comunes en los chatbots

1. Ausencia de regiones activas ARIA

Cuando llega un nuevo mensaje a una ventana de chat, un usuario de lector de pantalla necesita oírlo. Pero los lectores de pantalla solo anuncian el contenido que se les ha indicado que es importante y dinámico. Sin una región activa ARIA que envuelva el contenedor de mensajes del chat, los mensajes aparecen visualmente pero son completamente silenciosos para los usuarios de lectores de pantalla.

<!-- Sin región activa: los nuevos mensajes no se anuncian -->
<div class="chat-messages">
  <!-- Los mensajes se añaden aquí de forma dinámica -->
</div>

<!-- Con región activa: los nuevos mensajes se anuncian a medida que llegan -->
<div
  class="chat-messages"
  role="log"
  aria-live="polite"
  aria-label="Conversación de chat"
>
  <!-- Los mensajes se añaden aquí de forma dinámica -->
</div>

role="log" está definido específicamente en ARIA para conversaciones de chat y flujos de mensajes. aria-live="polite" anuncia el contenido nuevo después de que el usuario haga una pausa, menos perturbador que assertive para un contexto conversacional.

2. Trampas de teclado

Una trampa de teclado ocurre cuando un usuario tabula hacia un componente y ya no puede tabular fuera de él: se queda atascado. Los widgets de chatbot están entre los lugares más comunes donde aparecen trampas de teclado.

La solución requiere implementar una gestión del foco adecuada: Tab y Mayús+Tab deben permitir navegar por los elementos interactivos dentro del chat, y Escape debe cerrar el chat y devolver el foco al elemento que lo abrió. WCAG 2.1.2 Sin trampas para el foco del teclado (Nivel A) cubre este requisito.

Probarlo es sencillo: abre tu chatbot usando solo el teclado, tabula por todos los elementos interactivos dentro de él y confirma que puedes salir usando Escape o un botón de cierre claramente visible.

3. Contraste de color insuficiente

Los chatbots suelen mostrarse con los colores de la marca, y los colores de la marca a menudo no se prueban frente a los requisitos de contraste de las WCAG. Fallos comunes:

Texto de la burbuja de chat que no alcanza un contraste de 4,5:1 frente al fondo de la burbuja
Texto de marcador de posición del campo de entrada por debajo de los umbrales de contraste
Texto de marca de tiempo en un gris muy claro

El requisito de contraste se aplica a la interfaz del chatbot igual que al resto de tu sitio: no hay excepción para los widgets.

4. Campos de entrada y botones sin etiquetar

El campo de entrada del chat —“Escribe tu mensaje…”— debe tener una etiqueta asociada programáticamente, no solo un texto de marcador de posición. El texto de marcador de posición desaparece en cuanto el usuario empieza a escribir y no es un sustituto fiable de una etiqueta.

El botón de enviar, el botón de minimizar, el botón de cerrar y cualquier otro control interactivo deben tener nombres accesibles. Un botón de “enviar” solo con un icono, sin texto y sin aria-label, es anunciado por los lectores de pantalla como “botón” sin ninguna descripción de su propósito.

<!-- Sin etiqueta: falla -->
<input type="text" placeholder="Escribe un mensaje...">
<button><svg><!-- icono de enviar --></svg></button>

<!-- Con etiqueta y aria-label: pasa -->
<label for="chat-input" class="sr-only">Escribe tu mensaje</label>
<input type="text" id="chat-input" placeholder="Escribe un mensaje...">
<button aria-label="Enviar mensaje">
  <svg aria-hidden="true"><!-- icono de enviar --></svg>
</button>

5. Objetivos táctiles demasiado pequeños para usuarios con discapacidad motora

Las WCAG 2.2 introdujeron el criterio 2.5.8 Tamaño del objetivo (mínimo) en el Nivel AA, que exige que los elementos interactivos tengan un tamaño de objetivo mínimo de 24×24 píxeles CSS. Muchas interfaces de chatbot colocan los botones de cerrar, minimizar y emoji a 16-20 píxeles, muy por debajo de este umbral.

Para los usuarios con discapacidades motoras, temblores o control motor fino reducido, los objetivos pequeños son genuinamente inutilizables. Los botones de acción del chatbot están entre los elementos de la interfaz afectados con más frecuencia.

6. Sin aviso de tiempo de espera ni extensión de sesión

Muchos chatbots finalizan una sesión inactiva tras un periodo determinado. Cuando esto ocurre sin previo aviso, los usuarios que tardan más en redactar o leer los mensajes —incluidos muchos usuarios con discapacidades cognitivas o motoras— pueden perder su conversación sin ninguna oportunidad de extender la sesión.

El criterio WCAG 2.2.1 Tiempo ajustable (Nivel A) exige que, cuando se establece un límite de tiempo, los usuarios puedan desactivarlo, extenderlo, o que el límite sea de al menos 20 horas. Un chatbot que termina las sesiones tras 5 minutos de inactividad sin aviso no es conforme.

7. Lenguaje complejo y sin recuperación de errores

Los chatbots solo son útiles si los usuarios pueden comunicarse con ellos de forma efectiva. Para los usuarios con discapacidades cognitivas, dificultades de aprendizaje o niveles de alfabetización más bajos, un chatbot que utiliza jerga, ofrece largos muros de texto sin estructura o falla en silencio cuando no entiende una consulta es funcionalmente inaccesible.

Contenido de chatbot accesible:

Usa un lenguaje sencillo (frases cortas, palabras comunes)
Divide las respuestas en unidades fáciles de explorar en lugar de presentar párrafos
Ofrece una recuperación de errores clara: cuando el bot no entiende, lo dice explícitamente y ofrece alternativas específicas
Ayuda a los usuarios a reformular las consultas en lugar de limitarse a decir “No lo he entendido”

Nuevos criterios de las WCAG 2.2 especialmente relevantes para los chatbots

Las WCAG 2.2 añadieron varios criterios de éxito que se aplican con especial fuerza a las interfaces de chat:

2.4.11 Foco no oculto (mínimo) — Nivel AA. Cuando un widget de chat está abierto, no debe ocultar por completo el elemento enfocado detrás de él. Muchos widgets de chat aparecen sobre el contenido de la página y ocultan el elemento enfocado cuando los usuarios tabulan por la página subyacente.

2.4.12 Foco no oculto (mejorado) — Nivel AAA. El elemento enfocado debe ser totalmente visible.

2.5.7 Movimientos de arrastre — Nivel AA. Si tu widget de chat se puede reposicionar arrastrándolo, debe existir una alternativa de un solo puntero.

2.5.8 Tamaño del objetivo (mínimo) — Nivel AA, como se ha explicado anteriormente.

Cómo probar tu chatbot

Solo con teclado: abre el chat sin usar el ratón. Tabula por todos los elementos. Verifica que puedes escribir, enviar mensajes y cerrar el widget usando solo el teclado. Confirma que puedes salir con Escape.
Lector de pantalla: abre NVDA (Windows, gratuito) o VoiceOver (Mac/iOS, integrado) e interactúa con el chat. Verifica que los mensajes se anuncian a medida que llegan. Verifica que los campos de entrada y los botones están etiquetados correctamente.
Zoom al 200%: verifica que la interfaz del chat no se desborda ni oculta el contenido de la página cuando se amplía el texto.
Comprobación de contraste: usa una extensión de navegador como axe DevTools o WAVE para comprobar el contraste en la interfaz del chat.
Móvil: prueba los tamaños de los objetivos táctiles y verifica que el chat funciona con las funciones de accesibilidad de iOS/Android (VoiceOver, TalkBack).

Si vas a integrar un chatbot de terceros, evalúa la accesibilidad del proveedor antes de elegir. Solicita su VPAT (Voluntary Product Accessibility Template) para conocer el nivel de conformidad que declara. Prueba el widget tú mismo: las declaraciones del proveedor no sustituyen a las pruebas directas.

Incorporar la accesibilidad del chatbot desde el principio es significativamente más barato que adaptarla después. Si estás evaluando plataformas de chatbot, pasa cada candidata por esta lista de comprobación antes de comprometerte.

Para una revisión completa de tu chatbot y del resto de tu experiencia digital de atención al cliente, habla con nuestro equipo o empieza con un escaneo gratuito de tus páginas públicas.