Una sola pantalla compartida para que un alumno sordo no se quede fuera de la clase: subtítulos en vivo en español sencillo, palabras clave y respuestas rápidas.
La versión original nació en el AI Hackathon por México × Clara, en octubre de 2026, como un traductor de Lengua de Señas Mexicana con animación 3D. Yo hice el diseño UX/UI y el front-end, y mi equipo, el backend de la animación. La animación sí cargó, pero solo de forma local, en la computadora donde corría el backend.
Rediseñé el producto alrededor de subtítulos en español sencillo, palabras clave y respuestas rápidas. Las señas pasaron a ser una función experimental de apoyo.
Se puede probar en el navegador. No tiene backend: dictado, simplificación y señas están simulados, y la página lo aclara. Falta probarla con alumnos sordos, maestros e intérpretes.
El maestro dicta o escribe y el alumno lo lee en grande, en frases cortas y sin palabras rebuscadas. Puede ver el texto original cuando quiera.
Las palabras difíciles del mensaje aparecen con una definición corta, para no perder el tema de la clase.
Con un toque: «No entendí», «Más despacio», «Tengo una pregunta». También puede escribir o probar responder con señas.
Todo funciona con texto. Si una animación llegara a estar disponible, aparecería debajo de los subtítulos con la etiqueta «experimental»; si no llega, el alumno no pierde nada.
Solo contempla las señas de las respuestas rápidas. El alumno revisa el texto antes de que se envíe y puede descartarlo. Nada se presenta como traducción validada.
Controles operables con teclado, foco visible, anuncios aria-live, opción de texto grande y soporte para prefers-reduced-motion. No es una certificación WCAG.
HTML, Sass con BEM y JavaScript con módulos ES. El flujo es evento → controller → store → ui, con selectores para derivar lo que se muestra.
No sustituye a un intérprete: la LSM tiene gramática propia, usa expresión facial y varía por región. Además, no todas las personas sordas la usan.
Qué le pedí a Claude: un diseño base en Claude Design, sobre el que hice el diseño final; revisión y depuración del código, y ayuda para integrar el backend y el front-end en la versión original.
Qué hice y decidí yo: el diseño final a partir de esa base y las decisiones de producto, diseño y accesibilidad.
Simplificar el mensaje del maestro podría fallar por una red caída o un servicio sin responder. Ese error no puede dejar al alumno sin el mensaje.
El mensaje se agrega primero a la conversación con estado simplifying. Si la simplificación falla, pasa a error y el alumno ve el texto original, con un anuncio para lectores de pantalla.
async function simplify(id, text) {
try {
// La demo y un servicio real comparten el mismo flujo
const res = CONFIG.DEMO_MODE
? await demo.simulateSimplify(text, SIMPLIFIED, { fail })
: await api.simplifyText(text);
const patch = api.toMessagePatch(res);
updateMessage(id, { ...patch, status: 'ready' });
} catch (err) {
// El mensaje ya existe: el alumno ve el texto original
updateMessage(id, { status: 'error' });
announce('No se pudo simplificar. El alumno ve el texto original.');
}
}