Introducción: retos operativos
Desplegar un avatar IA en una pantalla o terminal en un espacio público exige garantizar el acceso a personas con discapacidades visuales, auditivas, motoras o cognitivas, sin perder la calidad multilingüe ni la disponibilidad 24/7. Esta guía pretende transformar principios generales en elementos concretos para integrar en el pliego de requisitos, el piloto y el runbook operativo.
Responsables de proyecto, direcciones de TI y equipos de accesibilidad encontrarán aquí: el marco normativo útil, criterios técnicos a verificar, recomendaciones de UX para la conversación y la interfaz, un protocolo de pruebas con usuarios con discapacidad y una lista de comprobación de auditoría lista para usar.
Marco normativo y aplicación de las WCAG
Los marcos de accesibilidad web como las WCAG ofrecen un marco técnico pertinente para las interfaces de los kioscos interactivos. En la práctica, se trata de aplicar principios como alternativas a los medios, operabilidad por teclado, legibilidad visual y robustez.
Antes del despliegue, verifique qué obligaciones se aplican localmente a su proyecto (normativa nacional, contratos públicos, políticas internas). Los requisitos concretos pueden variar según el tipo de lugar y el estatus de la organización. Considere las WCAG como una guía técnica que su interfaz deberá traducir en reglas de diseño y criterios de aceptación.
Criterios técnicos esenciales para la interfaz del kiosco
La compatibilidad con tecnologías de asistencia depende tanto del software de interfaz como del hardware y la integración. Para garantizar la interoperabilidad con lectores de pantalla y tecnologías de asistencia, exija que la interfaz respete principios concretos: estructura semántica clara, etiquetas accesibles, orden de tabulación lógico e indicación visible del foco.
Otros puntos técnicos a incluir en el pliego: soporte completo de navegación por teclado, textos redimensionables sin pérdida de funcionalidad, contrastes visibles, alternativas textuales para elementos no textuales y modos de entrada múltiples (táctil, voz, entrada por teclado).
Compatibilidad con lectores de pantalla y estructura de las respuestas
Para que un lector de pantalla anuncie correctamente los contenidos producidos por el avatar, la capa de interfaz debe exponer elementos textuales y atributos ARIA pertinentes. Prevea salidas textuales equivalentes a los mensajes hablados para que un usuario ciego o con baja visión acceda a la misma información.
Durante la integración, pruebe la legibilidad de las respuestas breves y la claridad de las etiquetas. Evite presentaciones únicamente icónicas o animadas sin alternativa textual. La arquitectura de la pantalla debe permitir al visitante identificar rápidamente el estado de la sesión (espera, en curso, resultado).
Interacción vocal, personas con pérdida auditiva y alternativas visuales
La interacción vocal es fundamental para muchos usos, pero debe ir siempre acompañada de una alternativa visual. Prevea un campo de entrada de texto visible, un teclado virtual táctil y botones de control claros para iniciar, detener o repetir una interacción.
Los subtítulos y la transcripción en tiempo real mejoran la accesibilidad para personas con pérdida auditiva. Estas funciones suelen requerir una integración específica con un servicio de STT/transcripción y un componente de visualización de subtítulos. Por ello es útil anticipar estas necesidades en el pliego y prever las APIs o webhooks necesarios.
Ergonomía física e implantación del kiosco
La accesibilidad física depende de la elección de la ubicación y de la ergonomía del hardware: colocación que permita el acceso en silla de ruedas, superficie de apoyo suficiente, inclinación de la pantalla, legibilidad desde diferentes ángulos y protección contra el deslumbramiento. Estos aspectos dependen del hardware elegido y de las limitaciones del sitio.
Piense también en los usos sentado vs de pie, en la presencia de un reposabrazos o una superficie de apoyo para la entrada de datos, y en una señalización clara para orientar a los usuarios hacia el kiosco. La calidad del micrófono y del altavoz impacta la fluidez de la interacción vocal y debe considerarse en las pruebas en condiciones reales.
Accesibilidad cognitiva y diseño de la conversación
Adaptar el diseño conversacional a personas con trastornos cognitivos implica lenguaje claro, frases breves, opciones limitadas y ayuda paso a paso. Prevea confirmaciones simples y opciones de reanudar con facilidad cuando el avatar no ha comprendido.
La persona del avatar debe permanecer previsible y coherente. SANIA puede personalizarse según la actividad y las necesidades del cliente, lo que permite ajustar el tono, la velocidad de habla y la complejidad del vocabulario según el público objetivo.
Protocolo de pruebas con usuarios con discapacidad para un piloto operativo
Un piloto accesible integra pruebas de usuario con personas con discapacidades visuales, auditivas, motoras y cognitivas. Defina objetivos de prueba precisos: validación de la navegación por teclado, comprensión de las respuestas habladas y textuales, uso en condiciones de ruido real y evaluación de la señalización física.
Organice escenarios representativos (ejemplos: encontrar una información simple, pedir orientación, cambiar el idioma). Durante cada sesión, recoja observaciones cualitativas, anote puntos de interrupción y solicite comentarios sobre la facilidad de uso y la comprensión. Prevea pruebas en varios idiomas si el sitio recibe público multilingüe.
Lista de comprobación de auditoría operativa lista para usar
Esta lista puede integrarse en el pliego de requisitos y utilizarse durante el piloto y la explotación. Cubre la interfaz, la voz, el hardware y las pruebas.
Presencia de un modo de texto accesible equivalente a cada mensaje hablado.
Navegación completa por teclado y orden de tabulación lógico en la interfaz.
Etiquetado claro de los controles con atributos accesibles (ARIA) y etiquetas visibles.
Indicación visual del foco y retroalimentación de estado explícita (reproducción en curso, espera).
Tamaños de objetivo táctil suficientes y zonas de entrada fácilmente accesibles.
Contraste de color conforme a las recomendaciones WCAG para el texto principal y los elementos interactivos o, en su defecto, destacando alternativas visuales (iconos acompañados de texto). Tenga en cuenta que los ratios precisos están definidos por las WCAG y deben consultarse según el objetivo de conformidad elegido por la organización. Aquí un punto operativo: pruebe la interfaz en condiciones de iluminación variables para validar la legibilidad real.
Ejemplos de configuraciones SANIA y puntos a precisar en el pliego
Aquí hay tres configuraciones ilustrativas y los elementos a especificar en el pliego. Atención: algunas funciones requieren una integración específica y no se proporcionan automáticamente sin desarrollo.
Configuración 1 - interfaz táctil y texto accesible: SANIA se despliega en una pantalla/kiosco interactivo con interfaz táctil y salidas textuales completas. Características a definir: navegación por teclado, etiquetas ARIA, gestión del foco, tamaños de fuente adaptables. Observaciones sobre SANIA: el avatar puede utilizarse con una interfaz táctil y textual y explota una base de conocimiento propia de la organización.
Configuración 2 - adición de interacción vocal: SANIA proporciona la interfaz vocal y la síntesis de voz. Especifique en el pliego la gestión de interrupciones vocales, el cambio de idioma en sesión y la calidad requerida para micrófonos y altavoces. Observaciones sobre SANIA: SANIA puede comunicarse en más de 100 idiomas, puede funcionar 24 horas al día y puede gestionar la interrupción de una respuesta vocal cuando el usuario vuelve a hablar.
Configuración 3 - accesibilidad aumentada (subtítulos y transcripción): para ofrecer subtítulos o transcripción en tiempo real, prevea una integración específica con un servicio de STT y un componente de visualización de subtítulos. Especifique las APIs, la latencia aceptable y los modos de conmutación si el servicio de transcripción no está disponible. Esta capa es una integración y requiere definir las responsabilidades entre las partes interesadas.
Puntos de atención y errores frecuentes
No limite la accesibilidad a la sola interacción vocal: un kiosco siempre debe ofrecer alternativas textuales y táctiles. Evite considerar el reconocimiento de voz como una solución universal sin prever escenarios de respaldo.
No confunda accesibilidad de software con accesibilidad de hardware. Elecciones de hardware inadecuadas (pantalla no legible a pleno sol, micrófono mal posicionado) pueden inutilizar una interfaz de software bien diseñada.
Por último, no presuma la conformidad: incluya a las personas afectadas en el piloto y documente las decisiones tomadas para poder justificarlas en caso de auditoría.
En la práctica: preparar el piloto y el runbook operativo
Integre criterios de accesibilidad desde la redacción del pliego y prevea pruebas en condiciones reales antes de la generalización. Defina puntos de revisión operativos para verificar la disponibilidad de los servicios vocales y de transcripción cuando estén integrados.
Documente los procedimientos de mantenimiento del hardware y software, los contactos para servicios terceros (por ejemplo proveedor STT) y los escenarios degradados (modo solo texto si la función vocal no está disponible). Finalmente prevea una consigna clara para orientar a los visitantes hacia asistencia humana cuando el avatar no pueda responder.