Chatbots, asistentes y interfaces conversacionales accesibles

Los asistentes conversacionales se han convertido en el primer punto de contacto de muchos servicios: el chat de la sede electrónica, el asistente de la banca, el bot de atención al cliente de la tienda, los asistentes de voz. Para algunas personas son una ayuda enorme (escribir en lenguaje natural en vez de navegar menús); para otras, una barrera nueva (mensajes que aparecen sin aviso, ventanas que atrapan el foco, respuestas largas y vagas, sin forma de llegar a una persona). Esta lección da las claves para que un chatbot sea accesible en su interfaz, en su conversación y en su integración con el servicio.

La interfaz del chat: un componente web más

Un chatbot web es un conjunto de componentes (botón de apertura, panel, registro de mensajes, campo de entrada, botones de respuesta rápida) y debe cumplir las WCAG 2.2 como cualquier otro. Los fallos más frecuentes en auditoría y cómo evitarlos:

• Botón de apertura: suele ser un icono flotante sin nombre. Debe ser un <button> con nombre («Abrir asistente virtual»), estado (aria-expanded), tamaño suficiente (2.5.8) y no tapar contenido ni el pie de página (en móvil, con texto grande, tapa botones de la propia web).
• Apertura automática: el panel que se abre solo a los 5 segundos con sonido y mensaje «¿Te ayudo?» roba el foco (3.2.1, 3.2.5), interrumpe al lector de pantalla y distrae (objetivo 5 de COGA). El chat se abre cuando el usuario lo pide.
• Gestión del foco: al abrir, el foco va al panel (al título o al campo); el panel se comporta como diálogo no modal o modal según diseño (role="dialog", aria-labelledby); Esc lo cierra y el foco vuelve al botón; nunca una trampa (2.1.2).
• Registro de mensajes: una región role="log" (que implica aria-live="polite") para que cada mensaje nuevo del bot se anuncie sin mover el foco (4.1.3). Cada mensaje identifica al emisor («Asistente:», «Tú:») de forma textual, no solo por color o posición (1.4.1, 1.3.3). El indicador «escribiendo…» no debe anunciarse en bucle.
• Campo de entrada: <label> (visible o aria-label), autocomplete si procede, envío con Intro y con botón nombrado, sin límite de tiempo para escribir (2.2.1).
• Botones de respuesta rápida (chips): botones reales, enfocables, con nombre; si desaparecen tras elegir, la elección queda escrita en el registro.
• Contenido enriquecido: tarjetas, carruseles, imágenes y enlaces dentro del chat con la misma semántica y alt que fuera; los enlaces abren en la misma pestaña o avisan.
• Contraste, zoom y reflujo: el panel debe funcionar al 200 % y en 320 px sin cortar el campo ni el botón de enviar (1.4.4, 1.4.10); mensajes con contraste 4,5:1 sobre sus burbujas.
• Persistencia: al navegar a otra página, la conversación no se pierde o se avisa; si el chat es un <iframe>, lleva title.

<button type="button" id="abrir-chat" aria-expanded="false" aria-controls="panel-chat">
  Abrir asistente virtual
</button>

<section id="panel-chat" role="dialog" aria-labelledby="titulo-chat" hidden>
  <h2 id="titulo-chat">Asistente virtual del Ayuntamiento</h2>
  <button type="button" class="cerrar">Cerrar asistente</button>

  <div role="log" aria-label="Conversación" aria-relevant="additions">
    <p><strong>Asistente:</strong> Hola. Puedo ayudarte con citas, tasas y padrón.
       Escribe tu pregunta o elige una opción.</p>
    <p><strong>Tú:</strong> quiero pedir cita para el padrón</p>
    <p><strong>Asistente:</strong> Puedes pedir cita en
       <a href="/cita-previa/padron">Cita previa para el padrón</a>.
       ¿Quieres que te explique qué documentos necesitas?</p>
  </div>

  <div class="respuestas-rapidas">
    <button type="button">Sí, qué documentos necesito</button>
    <button type="button">Hablar con una persona</button>
  </div>

  <form>
    <label for="mensaje">Escribe tu mensaje</label>
    <textarea id="mensaje" rows="2"></textarea>
    <button type="submit">Enviar</button>
  </form>
</section>

La conversación: diseño accesible del diálogo

• Lenguaje claro: respuestas breves, una idea por mensaje, sin jerga; si la respuesta es larga, se divide en pasos o se enlaza a la página. Un bot que responde con un párrafo de 200 palabras es tan inaccesible como un formulario de 60 campos.
• Confirmación y corrección: el bot repite lo entendido antes de actuar («Quieres cita para el padrón en la oficina centro, ¿correcto?») y permite corregir (3.3.4, 3.3.6, objetivo 4 de COGA).
• Tolerancia: entiende errores ortográficos, sinónimos, frases incompletas y lenguaje coloquial; no exige comandos exactos.
• Sin memoria exigida: no pide recordar códigos ni repetir datos ya dados (3.3.7); ofrece opciones en botones además del texto libre.
• Tiempo: la sesión no caduca mientras la persona escribe despacio; si hay inactividad, avisa y permite continuar (2.2.1).
• Transparencia: se identifica como asistente automático al inicio (lo exige además el Reglamento de IA para los sistemas que interactúan con personas), indica qué puede y qué no, y nunca simula ser humano.
• Fallo elegante: cuando no entiende, lo dice y ofrece alternativas (opciones, persona, teléfono), sin bucles de «no te he entendido».
• Privacidad: no pide datos sensibles en el chat si no es necesario; avisa de qué se guarda.

Asistentes de voz e interfaces solo de voz

Los asistentes de voz (en altavoces, coches, apps de banca por voz, centralitas con reconocimiento) ayudan a personas con discapacidad visual o motriz y excluyen a personas sordas, con dificultades de habla (disartria, tartamudeo, afasia) o en entornos ruidosos. Reglas: siempre una alternativa no vocal equivalente (teclado, chat de texto, menú por tonos, persona); tiempo de respuesta ampliable; confirmaciones; vocabulario tolerante; opción de repetir y de hablar más despacio; y en centralitas, posibilidad de pasar a un operador en cualquier momento sin volver al inicio. En la EN 301 549 (PDF, se abre en una ventana nueva), la comunicación bidireccional de voz tiene requisitos propios en el capítulo 6 (incluida la provisión de texto en tiempo real, 6.2, como alternativa).

Evaluación de un chatbot

1. Interfaz: auditoría WCAG del componente (teclado, foco, nombres, live region, zoom, contraste), con lector de pantalla y en móvil.
2. Conversación: pruebas con un guion de tareas (pedir cita, consultar un plazo, reclamar) escritas con errores ortográficos, lenguaje coloquial y mensajes cortos; medición de intentos, longitud de respuesta y caminos a persona.
3. Integración: ¿existe la misma información fuera del chat? ¿La vía humana es accesible (teléfono con texto o LSE, correo)? ¿El chat es accesible desde todas las páginas en el mismo lugar?
4. Usuarios: pruebas con personas con discapacidad cognitiva, visual y auditiva; es donde aparecen los problemas reales de comprensión.

Resumen

• El chat es un componente web: botón nombrado con estado, apertura solo a petición, foco gestionado sin trampas, registro con role="log" y emisor textual, campo etiquetado, zoom y contraste correctos, title si es iframe.
• La conversación sigue el lenguaje claro y los patrones COGA: breve, confirmación antes de actuar, tolerante a errores, sin exigir memoria, sin caducar, transparente y con fallo elegante.
• Siempre una vía humana accesible (patrón COGA), con la ayuda en el mismo orden relativo en todas las páginas (3.2.6) y la misma información disponible fuera del chat.
• Las interfaces solo de voz necesitan alternativa textual equivalente y paso a operador en cualquier momento.
• Evaluar interfaz, conversación e integración, y probar con personas usuarias con distintas discapacidades.