IA de lengua de signos en móviles: accesibilidad más allá de la voz
Guía sobre el hito de ASL a texto en Pixel, por qué no equivale a transcribir voz, cómo diseñar agentes móviles accesibles y qué puede hacer hoy FoneClaw.
- El hito actual lleva ASL a texto en Gboard y Live Transcribe primero en Pixel 11; es una ruta de entrada lingüística, no soporte universal para todas las lenguas de signos ni control general de Android.
- La lengua de signos no es transcripción de voz: cada lengua tiene gramática propia, señales simultáneas de manos, rostro y cuerpo, y construcciones espaciales que exigen traducción contextual.
- Un agente móvil accesible debe separar entrada, intención, selección de app, permisos, confirmación visual, resultado y recuperación; traducir una frase no autoriza ejecutar una acción.
- FoneClaw no afirma reconocimiento de lengua de signos ni integración con SL2T; hoy aporta interacción escrita, contexto elegido por el usuario, políticas de herramienta, estado visible, parada y recuperación.
Qué puede hacer hoy la IA de lengua de signos en móviles
La IA de lengua de signos en móviles ya tiene un hito concreto: Google DeepMind describe SL2T como una tecnología que lleva dictado de ASL a inglés en Gboard y Live Transcribe, primero en Pixel 11. Según el artículo de Google DeepMind sobre poner IA de lengua de signos en manos de los usuarios, más dispositivos y más lenguas forman parte del trabajo futuro, pero la disponibilidad actual empieza con ASL a inglés en ese entorno.
La respuesta a “¿puede la IA entender lengua de signos en un móvil?” es, por tanto, sí en un caso inicial y delimitado: ASL a texto inglés en funciones concretas de Pixel 11. No significa que todos los Android lo tengan, que todas las lenguas de signos funcionen, que el sistema entienda cualquier firmante o que una frase traducida controle apps. Significa que una entrada visual de lengua de signos empieza a convertirse en texto utilizable en el teléfono.
Ese cambio importa porque los asistentes móviles han estado demasiado ligados a voz. Para muchas personas sordas o con dificultades de habla, voz no es una entrada cómoda ni suficiente. Convertir lengua de signos en texto dentro de Gboard o Live Transcribe abre tareas reales: dictar un mensaje, escribir una nota, introducir texto en una app, responder en una conversación o participar en un intercambio donde la salida visible importa.
Pero el límite es igual de importante que el avance. Sign-to-text es una entrada lingüística. No demuestra por sí sola que Android pueda ejecutar una acción, elegir una app, pedir permiso o confirmar una consecuencia. Un agente móvil accesible necesita la capa siguiente: interpretar intención, resolver destinatario, mostrar vista previa, pedir confirmación en modo accesible y recuperar el flujo si la cámara, la red o la traducción fallan.
Por qué traducir lengua de signos no es transcribir voz
Traducir lengua de signos no es lo mismo que transcribir voz. La transcripción de voz convierte audio en texto de una lengua hablada. La lengua de signos es una lengua natural con gramática propia, no una versión gestual palabra por palabra de una lengua oral. Además, no existe una lengua de signos universal: se usan más de 200 lenguas de signos en el mundo, con comunidades, variación regional y reglas distintas.
ASL no es español signado, ni BSL, ni LSE, ni una notación internacional que pueda extrapolarse sin más. En lengua de signos, las manos importan, pero también el rostro, el torso, la mirada, la dirección del movimiento y el espacio. Una ceja, una inclinación, una localización en el espacio o una construcción clasificadora pueden transportar significado gramatical. Por eso reconocer solo formas de mano o vocabulario aislado no resuelve la traducción.
El diseño de producto cambia cuando respetas esa realidad. Una app que convierte signos en texto no debe tratar la salida como dictado perfecto. Debe permitir revisión, corrección y repetición. Debe mostrar dudas cuando el modelo no está seguro. Debe evitar enviar mensajes, crear eventos o ejecutar acciones sensibles sin una confirmación que la persona pueda revisar visualmente.
Para nosotros, como equipo que construye FoneClaw, esta distinción es central. La accesibilidad más allá de la voz no consiste en añadir otro micrófono imaginario. Consiste en aceptar múltiples formas de entrada, múltiples formas de salida y un flujo de acción que no dependa únicamente de audio. El reto no es solo entender una frase; es convertirla en una tarea segura y controlable en el teléfono.
Arquitectura SL2T, evidencia y privacidad
DeepMind describe SL2T con una arquitectura relevante para cualquier constructor de agentes móviles. MediaPipe Holistic extrae en el dispositivo puntos de referencia de pose. Según DeepMind, las coordenadas geométricas se envían al servidor y el video bruto se descarta. Esa frontera mejora el diseño frente a enviar video completo, pero no convierte el sistema en totalmente local ni elimina todas las preguntas de privacidad. Los landmarks siguen representando información corporal y deben tratarse con cuidado.
El modelo de traducción pasa de esos puntos a texto directamente. La escala de entrenamiento también es notable: DeepMind habla de más de 100.000 horas y más de 50 lenguas de signos en el entrenamiento, mientras que el producto inicial se centra en ASL a inglés. Esta diferencia entre datos de investigación y disponibilidad de producto debe quedar clara. Entrenar con muchas lenguas no significa ofrecer traducción fiable para todas ellas en el móvil del usuario.
La evidencia pública incluye resultados y errores. DeepMind muestra que el sistema todavía puede fallar en signos raros, deletreo rápido con dedos, clasificadores, construcciones pasivas y tiempo verbal. Esos ejemplos no disminuyen el avance; lo hacen más útil. Un producto accesible honesto muestra dónde se equivoca para que el diseño añada revisión y reparación.
El comercio de privacidad, latencia y calidad sigue abierto. La extracción en el dispositivo reduce una parte del dato enviado, pero la traducción en servidor puede depender de conexión, disponibilidad y políticas del proveedor. Un asistente móvil para personas sordas no debería esconder esos detalles. Debe indicar si necesita cámara, red, cuenta, dispositivo específico y qué ocurre cuando la traducción no está disponible.
La lección para agentes telefónicos es directa: la entrada es una etapa, no el producto completo. Si la cámara captura signos, si el servidor traduce, si el texto llega a una app y si una acción se ejecuta, cada transición necesita estado visible y control del usuario.
Elige entrada y salida accesibles por tarea
Un agente móvil accesible no debería imponer una modalidad única. Algunas personas preferirán lengua de signos a texto cuando esté disponible. Otras usarán texto escrito, subtítulos, transcripción de habla cercana, RTT, Switch Access, lectura de pantalla, vibración, braille, confirmación visual o combinaciones. Android ya ofrece una caja de herramientas amplia, aunque la disponibilidad varía por dispositivo.
Live Transcribe, según la ayuda de Android sobre Live Transcribe, convierte voz y sonidos cercanos en texto en pantalla, con respuestas escritas, etiquetas de sonido, controles de historial y algunos idiomas sin conexión en dispositivos compatibles. Eso sirve para conversaciones habladas alrededor del usuario, no para reconocer lengua de signos.
Live Caption tiene otro papel. La ayuda de Android sobre Live Caption documenta subtítulos para medios y llamadas compatibles, y Google indica procesamiento en el dispositivo para esa función. Esa afirmación no debe trasladarse automáticamente a Live Transcribe, SL2T o FoneClaw. Cada modalidad tiene su propia arquitectura.
La vista general de accesibilidad Android reúne entrada, salida, subtítulos, lector de pantalla, Switch Access, braille y RTT. En diseño práctico, elegimos por tarea:
| Tarea | Entrada útil | Salida o confirmación | Riesgo si falta fallback |
|---|---|---|---|
| Dictar mensaje | Lengua de signos a texto, teclado o dictado | Vista previa editable | Enviar texto mal traducido |
| Conversación presencial | Live Transcribe o texto escrito | Texto grande, historial controlado | Perder contexto o guardar de más |
| Ver video o llamada | Live Caption cuando esté soportado | Subtítulos y respuesta escrita | Depender solo de audio |
| Control del teléfono | Toque, teclado, Switch Access o agente | Confirmación visual, vibración, estado | Ejecutar sin revisión accesible |
| Llamada telefónica | RTT, texto o ruta de app compatible | Texto durante la llamada | Quedarse fuera de la conversación |
Para una perspectiva de voz y baja visión, mantenemos una guía separada: Teléfono Android activado por voz para personas ciegas o con baja visión. Aquí la lección es otra: más allá de la voz, el teléfono debe aceptar varias entradas y confirmar acciones sin depender de audio.
De entrada accesible a acción segura del teléfono
La traducción de una frase a texto no autoriza una acción. Si una persona firma una frase que se convierte en “envía a Marta que llegaré tarde”, el sistema todavía debe resolver intención, destinatario, app, permiso, contenido, confirmación y resultado. Esa cadena es donde muchos asistentes fallan: tratan la entrada como comando listo para ejecutar.
Un agente móvil accesible debe separar pasos. Primero, mostrar el texto interpretado para revisión. Segundo, identificar la intención: mensaje, nota, búsqueda, llamada, calendario o ajuste. Tercero, elegir capacidad o herramienta compatible. Cuarto, comprobar permisos. Quinto, presentar una vista previa accesible: destinatario, contenido, app, hora, coste o efecto. Sexto, permitir corrección antes de completar. Séptimo, mostrar resultado y ofrecer recuperación.
La confirmación accesible no puede depender solo de sonido. Debe estar en pantalla, con tamaño legible, foco correcto, compatibilidad con lector de pantalla, respuesta táctil o ruta alternativa según el usuario. Para acciones de alto impacto, como enviar datos, llamar, modificar calendario, cambiar ajustes o compartir ubicación, la confirmación debe ser más clara que una notificación pasajera.
En FoneClaw usamos el mismo marco para capacidades: encontrar una herramienta no la ejecuta. AutoAttach, Suggest y Fallback ayudan a enrutar contexto y opciones, pero no autorizan la acción. Si quieres profundizar en esa mecánica, la guía Enrutamiento de capacidades de agentes de IA: AutoAttach, Suggest y Fallback en Android explica cómo separar coincidencia, sugerencia, fallback y ejecución.
FoneClaw visto desde la accesibilidad más allá de la voz
Primero, la frontera explícita: FoneClaw no afirma reconocer lengua de signos, no integra SL2T y no está certificado como solución de accesibilidad para lengua de signos. Esa honestidad importa. La nueva capacidad de Google enseña una dirección, pero no convierte a todos los agentes móviles en intérpretes visuales.
Lo que FoneClaw sí aporta hoy a la conversación es la capa de acción gobernada. FoneClaw acepta interacción escrita y rutas de contexto elegidas por el usuario donde están soportadas. El asistente flotante y el contexto de pantalla actual pueden ayudar a describir lo que el usuario está viendo cuando decide adjuntarlo. Para ese flujo, la guía Asistente de IA flotante en Android: usar la pantalla actual con control detalla cómo el contexto visible entra en la tarea sin convertirse en vigilancia permanente.
La arquitectura importa para accesibilidad más allá de la voz. Un usuario puede escribir, pegar texto generado por una herramienta de lengua de signos a texto, adjuntar una pantalla o pedir una acción con lenguaje natural. FoneClaw puede razonar sobre la intención, enrutar hacia capacidades compatibles y mostrar estado de tarea. La ejecución queda bajo política de herramientas, permisos y aprobación. La coincidencia de capacidad no ejecuta por sí sola.
También hemos aprendido que detener y recuperar son funciones de accesibilidad, no solo de seguridad. Si la entrada se tradujo mal, el usuario necesita cancelar. Si falta permiso, necesita una explicación visible. Si una app no permite completar un paso, el flujo debe dejar una alternativa: preparar texto, abrir pantalla, pedir aclaración o esperar intervención. El usuario no debería quedar atrapado en una acción porque el agente interpretó demasiado.
Lo que todavía debemos mejorar como categoría es claro: mejor compatibilidad con múltiples modalidades, auditoría con comunidades afectadas, opciones de confirmación más ricas y pruebas de error más realistas. FoneClaw puede ser parte del control del teléfono, pero la entrada de lengua de signos pertenece a una capa que hoy no reclamamos.
Audita con personas sordas
DeepMind describe participación de personas sordas desde concepto, datos, evaluación e impacto. Esa es una señal importante para cualquier constructor de agente móvil. La accesibilidad no se valida solo con un benchmark ni con un equipo oyente imaginando necesidades. Debe probarse con personas afectadas por el diseño y con diversidad de estilos, edades, dispositivos y situaciones.
Un checklist serio empieza por cobertura lingüística. ¿Qué lengua de signos se admite? ¿Qué variedades regionales? ¿Qué ocurre con firmantes zurdos, personas que firman con una mano, movilidad limitada, diferentes velocidades, cámaras pequeñas o luz baja? DeepMind menciona como preocupaciones prácticas el firmado con la mano izquierda y con una sola mano; esos detalles cambian la vida real más que una demo perfecta.
Después viene privacidad. ¿Se procesa video, landmarks, texto o todo? ¿Qué se guarda? ¿Qué se descarta? ¿Qué necesita red? ¿Qué ocurre en una conversación médica, familiar o laboral? Una afirmación técnica sobre coordenadas no sustituye un consentimiento claro ni una política entendible.
La tercera parte es reparación de errores. El sistema debe permitir corregir un signo raro, un deletreo rápido, un clasificador mal interpretado, una construcción pasiva o un tiempo verbal incorrecto. Si el texto resultante va a una acción del teléfono, la corrección debe aparecer antes de ejecutar.
Por último, mide fallback. ¿Qué pasa si la cámara falla, la red se corta, el modelo duda o la persona no quiere usar cámara? ¿Existe teclado, texto guardado, Switch Access, RTT, contacto de ayuda o ruta manual? Una comunidad no queda bien servida por una única ruta brillante que falla sin alternativa. Para gobierno de permisos y auditoría de agentes, enlazamos Identidad de agentes de IA: permisos, aprobación por herramienta y auditoría en Android.
Prueba un flujo más allá de la voz antes de confiar
Antes de confiar en un flujo accesible para acciones importantes, prueba una tarea reversible. Elige algo de bajo riesgo: crear una nota, preparar un mensaje sin enviarlo, abrir una app o consultar un ajuste. No empieces con envío automático, llamadas urgentes, pagos, ubicación compartida o cambios de seguridad.
- Verifica la entrada: revisa el texto traducido, escrito o pegado antes de pedir acción.
- Verifica el objetivo: contacto, app, calendario, nota o pantalla deben estar visibles.
- Verifica permisos: cámara, red, contactos, notificaciones o herramienta de agente deben estar claros.
- Verifica confirmación: la revisión debe funcionar sin depender solo del sonido.
- Verifica resultado: comprueba que la nota, borrador o pantalla final coincide con la intención.
- Prueba parada y fallback: cancela a mitad de flujo y confirma que puedes continuar manualmente.
Una prueba no demuestra fiabilidad universal. Sí revela si el sistema respeta lo más importante: entrada corregible, acción visible, permisos claros y salida alternativa. Ese es el estándar que la IA de lengua de signos en móviles nos obliga a aplicar a todos los agentes telefónicos, no solo a los que escuchan voz.