Cómo auditar el acceso por teclado y lector de pantalla en un widget de WebChat

Audita la página, el widget y la transición entre ambos

Un widget de chat no funciona de forma aislada. Su lanzador se encuentra dentro de una página anfitriona, mientras que la conversación abierta puede mostrarse en un panel, un cuadro de diálogo u otro tipo de interfaz. Prueba la experiencia integrada real: la página que rodea al lanzador, el propio widget y lo que ocurre cuando las personas entran o salen de él.

Antes de probar, registra la URL de la página, la configuración del widget, el navegador y el sistema operativo, la tecnología de asistencia y los estados de la interfaz incluidos. Incluye el lanzador, el chat abierto, cualquier formulario previo al chat, el intercambio de mensajes, los errores de validación, el estado minimizado y el estado cerrado cuando esas funciones estén disponibles. No des por sentado que todos los widgets usan un cuadro de diálogo modal; determina cómo se comporta este.

• Alcance: integración en la página anfitriona, controles del widget y estados relevantes de la conversación.
• Muestra: elige páginas y recorridos representativos, incluidos un formulario o un estado de error, si están disponibles.
• Entorno: registra el navegador, el sistema operativo, el lector de pantalla y el método de entrada.
• Responsabilidad: anota qué partes controla el equipo de tu sitio web, el proveedor del widget o el proveedor del canal.

Prepara un plan de pruebas breve y repetible

Combina las pruebas solo con teclado y las pruebas con lector de pantalla. Las comprobaciones automatizadas de accesibilidad pueden ayudar a detectar algunos problemas, pero no demuestran que un widget sea accesible. WAI señala que ninguna herramienta de evaluación por sí sola puede determinar si un sitio cumple los estándares de accesibilidad; se necesita la evaluación de personas con conocimientos.

Elige un conjunto pequeño de recorridos de usuario que tu equipo pueda repetir después de los cambios. Por ejemplo: abrir el widget, llegar a sus campos y completarlos, enviar un mensaje, recibir una respuesta, cerrar el widget y seguir usando la página. Incluye pasos solo con teclado y una prueba con lector de pantalla para el mismo recorrido.

• Usa Tab y Mayús+Tab para moverte entre los controles; usa Intro y la barra espaciadora para activar botones.
• Usa los comandos habituales de lectura y navegación por formularios del lector de pantalla para inspeccionar nombres, roles, instrucciones y actualizaciones.
• Ejecuta un análisis automatizado cuando corresponda y, después, verifica manualmente sus resultados y prueba los comportamientos que no puede evaluar.
• Utiliza datos de prueba que no sean sensibles; evita enviar información real de clientes durante una auditoría.

Prueba la apertura, el cierre y el retorno del foco

Navega hasta el lanzador sin usar el ratón. Comprueba que tenga un nombre accesible útil, que el foco sea visible y que se pueda activar con Intro o la barra espaciadora. Después de abrir el chat, determina adónde va el foco y si ese destino deja claro cuál es la siguiente acción.

Si el chat se comporta como un cuadro de diálogo modal, compara su comportamiento con el teclado con el patrón de cuadro de diálogo modal de WAI-ARIA Authoring Practices: el foco entra en el cuadro de diálogo, Tab y Mayús+Tab permanecen dentro, Escape lo cierra y, normalmente, el foco vuelve al control que lo abrió. Aplica este patrón solo si la interfaz es realmente modal. En un panel no modal, comprueba que las personas puedan moverse entre el panel y la página sin quedar atrapadas ni perder su lugar.

Cierra el chat con el teclado y confirma que el foco vuelva a un lugar lógico —normalmente, el lanzador— y siga siendo visible. Ábrelo de nuevo y comprueba si se entienden el estado anterior de la conversación y el comportamiento del foco.

• ¿Se puede llegar al lanzador y al control de cierre y activarlos con el teclado?
• ¿El foco es visible antes y después de abrir, cerrar y volver a abrir el widget?
• ¿El foco se mueve a un punto de partida útil cuando se abre el widget?
• ¿Se puede salir del widget sin usar un dispositivo apuntador y sin quedar atrapado inesperadamente en el foco?
• Después de cerrar el widget, ¿se puede continuar desde un lugar razonable de la página anfitriona?

Comprueba el orden, los controles y las instrucciones de los formularios

Recorre con Tab el widget abierto y los controles cercanos de la página. El foco debe avanzar en un orden que conserve el significado y permita utilizar la interfaz. Observa si el foco salta detrás de una superposición, omite un control, entra en contenido oculto o sale inesperadamente del widget. Comprueba que todos los controles que reciben el foco tengan un indicador de foco visible.

Inspecciona botones, enlaces, campos y otros componentes interactivos con un lector de pantalla. Sus nombres y roles deben explicar qué son y qué acción realizan; los cambios de estado —como expandido, seleccionado o deshabilitado— deben comunicarse cuando corresponda. Un icono visual por sí solo quizá no proporcione un nombre útil.

Para cada campo, comprueba que las personas puedan saber qué información se espera y que, cuando sea necesario, la etiqueta o instrucción esté asociada al campo de forma programática. Prueba también la ruta de error, no solo la entrada correcta: provoca un error de validación seguro y predecible y comprueba que el campo con error y el problema se identifiquen mediante texto. Si se conoce una corrección y resulta apropiado, comprueba si se explica.

• Comprueba el orden de navegación por teclado entre el lanzador, la conversación, el campo de mensaje, el control de envío y cualquier formulario previo al chat.
• Verifica que el foco sea visible y que se comporte de forma lógica cuando aparece contenido o cambian los controles.
• Comprueba los nombres, roles y estados de los controles con un lector de pantalla, no solo por su apariencia.
• Confirma que cada campo tenga una etiqueta o instrucción clara y asociada.
• Envía datos de prueba no válidos y comprueba si el error se identifica y, cuando corresponda, si se ofrecen indicaciones útiles para corregirlo.

Comprueba los anuncios de mensajes y estados

Envía un mensaje de prueba y comprueba cómo lo presenta el lector de pantalla. Luego, haz que aparezca una respuesta u otra actualización mientras el foco permanece en otro lugar. Las personas deben poder saber que llegó información nueva relevante sin tener que buscar en la conversación ni hacer que el foco se mueva inesperadamente.

Comprueba también los cambios de estado que no mueven el foco, como los comentarios de validación o un mensaje sobre el estado de la conexión, si ese estado forma parte de la experiencia que se está probando. El criterio de éxito 4.1.3 de WCAG 2.2 se refiere a los mensajes de estado que pueden determinarse mediante programación para que las tecnologías de asistencia puedan presentarlos sin recibir el foco. Evita anunciar cada cambio visual menor: los anuncios deben ser útiles y no abrumar la conversación.

• ¿Puede una persona usuaria de lector de pantalla identificar los mensajes entrantes y quién los envió?
• ¿Se anuncian las actualizaciones relevantes mientras el foco permanece en su sitio?
• ¿Los mensajes de validación y otros mensajes de estado llegan a la tecnología de asistencia sin que haya que buscarlos visualmente?
• ¿Los anuncios son comprensibles y oportunos, y evitan repeticiones innecesarias?

Documenta los defectos y asigna la responsabilidad adecuada

Describe cada hallazgo de forma que otra persona pueda reproducirlo. Incluye la página y el estado del widget, el entorno de prueba, el punto de partida, los pasos exactos con teclado o lector de pantalla, el resultado observado y el resultado esperado. Explica el impacto en términos prácticos —por ejemplo, «una persona que usa el teclado no puede llegar al botón de envío»— en vez de registrar únicamente una referencia a un estándar.

Distingue los posibles problemas de integración de la página anfitriona de los problemas del widget, pero considera que la experiencia integrada es lo que importa a las personas usuarias. Si no está claro quién es responsable, pide al equipo del sitio web y al proveedor del widget que reproduzcan el problema juntos. Un hallazgo que cruza esa frontera, como cuando el foco pasa a contenido oculto de la página al abrir el panel, puede requerir que ambos equipos investiguen.

• Registra: ID del problema, URL, fecha, navegador y sistema operativo, tecnología de asistencia, pasos, resultado real y resultado esperado.
• Añade: impacto para las personas usuarias, una captura de pantalla o una grabación breve cuando corresponda y la persona responsable probable.
• Clasifica: página anfitriona, widget, integración o responsabilidad compartida/no determinada.
• Repite los mismos pasos después de una corrección y registra el resultado en la página integrada, no solo en una vista previa local del componente.

Usa las pautas de WCAG y WAI y vuelve a probar después de los cambios

Usa WCAG 2.2 como referencia de evaluación para la operación con teclado, el orden del foco, la visibilidad del foco, las etiquetas e instrucciones, la identificación de errores, los nombres y roles de los componentes y los mensajes de estado. WAI-ARIA Authoring Practices ofrece pautas útiles de interacción para cuadros de diálogo modales y botones; aplica los patrones según el comportamiento real de la interfaz, no solo su apariencia visual.

Las pautas de evaluación de WAI recomiendan evaluar desde las primeras etapas y durante todo el desarrollo. Repite las comprobaciones pertinentes cuando cambien la configuración del widget, los estilos del sitio web, el código de integración o el propio widget. Mantén una lista breve de regresión y conserva los hallazgos para que los equipos puedan comprobar si un defecto reapareció.

• WCAG 2.2: https://www.w3.org/TR/wcag/
• Descripción general de la evaluación de accesibilidad de WAI: https://www.w3.org/WAI/test-evaluate/
• Patrón de cuadro de diálogo modal de WAI-ARIA APG: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
• Patrón de botón de WAI-ARIA APG: https://www.w3.org/WAI/ARIA/apg/patterns/button/
• Metodología de evaluación WCAG-EM: https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/

Ofrece una alternativa humana cuando el widget impida el acceso

Si una persona no puede acceder al chat o utilizarlo, no conviertas el widget inaccesible en la única vía de contacto con el soporte. Ofrece una alternativa de contacto que también sea accesible y explica claramente cómo comunicarse con una persona. Los equipos que usan webchat.vip pueden organizar conversaciones y configurar flujos que transfieran la conversación a una persona; esa capacidad no demuestra por sí sola que un widget o flujo concreto supere una auditoría de accesibilidad.

Asigna un equipo o rol concreto para recibir los hallazgos de accesibilidad, coordinarse con las personas responsables del sitio y del widget, y confirmar las correcciones. Si no está clara la causa, mantén abierto el problema y reprodúcelo conjuntamente en lugar de pedir a la persona afectada que diagnostique los límites técnicos.

• Indica a las personas cómo comunicarse con el soporte mediante una alternativa accesible cuando no puedan usar el chat.
• Deriva los problemas de acceso sin resolver a un contacto humano de soporte y a una persona responsable del sitio web o de accesibilidad.
• Verifica la alternativa y la experiencia integrada corregida con pruebas de teclado y lector de pantalla.