En 06-02 quedó claro el techo de lo automático: un 30-40% de los problemas, y solo los objetivos. Y en 06-01, cuando tú arrancaste NVDA 10 minutos, ya avisamos de algo incómodo: tú sabes dónde está todo. Cierras los ojos, pero tienes el mapa de la página en la cabeza. Ni la máquina ni el desarrollador probando ven lo que de verdad importa al final: si una persona que usa esa tecnología a diario, y que no conoce tu web, logra completar su tarea sin frustrarse. Eso es usabilidad, y es la validación definitiva. En esta lección aprenderás a planificar, moderar y aprovechar sesiones de prueba con usuarios reales de tecnologías de asistencia sobre Cursalia.

1. "Yo pruebo con una TA" no es "un usuario real de esa TA prueba"
2. Planificar una sesión
3. Reclutamiento, consentimiento y ética
4. Moderar sin estropear los resultados
5. Qué observar y medir
6. Escenarios en Cursalia: Marta, Lucía y Sofía
7. Combinar con revisión experta
8. La trampa de "probamos con una persona"

Es la distinción central de esta lección:

Un ejemplo: en 06-01 tú, con NVDA, "encontraste" el botón Matricularme porque sabías que existía. Marta, usuaria ciega real, navega por encabezados buscando dónde matricularse, no lo encuentra donde ella espera, y concluye que el curso "no se puede comprar todavía". Técnicamente el botón tenía nombre accesible y pasaba axe. En usabilidad, era invisible. Ese hallazgo no lo produce ninguna otra prueba.

Una buena sesión se prepara antes de sentar a nadie.

• Objetivos: define qué quieres aprender. No "probar la accesibilidad" (demasiado vago), sino "¿puede un usuario de lector de pantalla completar una matrícula sin ayuda?".
• Tareas realistas: da tareas, no instrucciones. Mal: "haz clic en el botón azul de arriba a la derecha". Bien: "Encuentra un curso de Python y matricúlate en él." La tarea describe una meta, no los pasos: así observas cómo la persona decide el camino.
• Guion de tareas para Cursalia (ejemplo):
  1. Encuentra un curso de Python para principiantes usando el catálogo.
  2. Averigua cuánto dura y quién lo imparte.
  3. Matricúlate (completa el formulario de matrícula).
  4. Entra en el reproductor y activa los subtítulos de la primera lección.
  5. Responde el cuestionario de la lección 1 desde el panel del alumno.
• Duración: 45-60 minutos por persona es cómodo; más, agota.
• Entorno: que la persona use su propio equipo y su propia configuración de TA siempre que se pueda. La velocidad de voz, el navegador y la versión son su mundo; recrearlos tú los falsea.

Estás invitando a personas, no recogiendo datos de un servidor. El respeto es parte del método.

• Reclutamiento: busca participantes a través de asociaciones de personas con discapacidad, paneles especializados o redes de la comunidad. Necesitas usuarios reales y habituales de la TA, no compañeros disfrazados.
• Incentivos: paga a los participantes. Su tiempo y experiencia son un trabajo experto; el incentivo justo es cuestión de dignidad, no un extra.
• Consentimiento informado: explica por escrito qué vas a hacer, qué grabarás (pantalla, voz, audio del lector), para qué se usará y cuánto tiempo lo guardas. Firma antes de empezar. La persona puede parar cuando quiera, sin dar explicaciones.
• Ética y respeto en la sala:
  • Se prueba el producto, no a la persona. Dilo en voz alta: "si algo no funciona, es culpa de nuestra web, no tuya".
  • Usa lenguaje respetuoso y centrado en la persona; pregunta cómo prefiere que te refieras a su discapacidad si surge.
  • Nunca conviertas la sesión en un espectáculo ni en "inspiración". Es investigación de producto.
  • Privacidad: anonimiza los hallazgos en el informe (Módulo 06-04). "Participante 3, usuaria de NVDA", no su nombre.

El moderador puede arruinar la sesión con una sola frase. Reglas de oro:

• Protocolo de pensar en voz alta (think-aloud): pide a la persona que narre lo que hace, busca y espera. "Ahora estoy buscando el botón de matrícula… no lo oigo… voy a probar por encabezados." Ese relato es oro puro.
• No ayudes de más: cuando se atasca, muérdete la lengua. El silencio incómodo es donde aparece el hallazgo. Si ayudas al primer titubeo, has borrado justo lo que venías a medir. Solo intervén si lleva mucho rato bloqueada y la frustración ya no aporta nada.
• No dirijas: nada de "prueba a pulsar Tab ahí" o "¿no ves el botón azul?". Preguntas neutras: "¿qué esperabas que pasara?", "¿qué estás intentando ahora?".
• Observa, no interrogues: durante la tarea, calla y anota. Las preguntas, al final de cada tarea.
• Cuidado con el sesgo de cortesía: la gente tiende a decir que "está bien" para no ofender. Insiste en lo negativo: "¿qué te ha resultado más molesto?".

Combina métricas cuantitativas con observaciones cualitativas (estas últimas suelen ser las que cambian el producto).

El tiempo y el éxito dan titulares; las citas y los bloqueos dan las tareas de remediación de 06-04.

Tres sesiones reales, tres hallazgos que ni lo automático (06-02) ni la prueba manual del desarrollador (06-01) habían detectado.

Tarea: matricularse en un curso de Python. Marta rellena el formulario de matrícula y pulsa "Confirmar". Aparece un mensaje de éxito visual, pero se inyecta en un contenedor sin aria-live, así que NVDA no lo anuncia. Marta se queda esperando en silencio, sin saber si se ha matriculado, y acaba recargando la página por miedo a haber pagado dos veces.

• Por qué se escapó: axe veía el mensaje presente en el DOM (pasa). Tú, en 06-01, viste el mensaje con los ojos y diste por buena la tarea. Solo alguien que depende del audio revela que el mensaje no existe para ella. (El cómo se arregla —regiones en vivo— es contenido dinámico del Módulo 7.)

Tarea: aplicar el filtro "nivel principiante" en el catálogo. Lucía llega con Tab a los checkboxes, pero el catálogo aplica el filtro con un onchange que además mueve el foco al inicio de la lista de resultados. Como usa exclusivamente teclado y cada acción la devuelve arriba, tarda el triple y se marea. Funcionalmente "funciona"; en la práctica es agotador.

• Por qué se escapó: no es una violación de ninguna regla automática ni un fallo técnico de foco (el foco se gestiona, solo que mal para su flujo). Es puro coste de esfuerzo, visible únicamente observando a quien navega así todo el día.

Tarea: leer el precio y pulsar Matricularme. A 300% de zoom, el botón "Matricularme" queda fijo (position: sticky) y tapa el precio justo cuando Sofía hace scroll para leerlo. El reflow de 06-01 pasaba (no había scroll horizontal), pero la superposición de dos elementos al ampliar solo se ve cuando alguien con su nivel de zoom real intenta usar la página.

• Por qué se escapó: el contraste y el reflow automáticos daban verde; el hallazgo es una interacción entre zoom, scroll y un elemento pegajoso que ninguna herramienta modela.

Tres personas, tres problemas de usabilidad graves, cero detectados por axe o por la prueba manual del desarrollador. Ese es el argumento de esta lección.

No siempre podrás reclutar usuarios para cada iteración. Un complemento valioso es la revisión experta (evaluación heurística): una persona con experiencia en accesibilidad recorre Cursalia aplicando WCAG y su conocimiento de cómo usan la web las personas con discapacidad. No sustituye a los usuarios reales —un experto sigue sin ser Marta— pero detecta mucho entre sesiones y ayuda a decidir qué llevar a la próxima sesión con usuarios. El orden ideal: automático (06-02) → manual + experto (06-01) → usuarios reales (06-03).

Un error grave: hacer una sesión con un usuario ciego y declarar "Cursalia es accesible para invidentes". Las discapacidades son diversas y también lo es dentro de cada tipo:

• Distintas discapacidades (visual, motriz, auditiva, cognitiva) → problemas completamente distintos. Marta, Lucía, Sofía, Diego y Hugo tropiezan cada uno con cosas diferentes.
• Distinta TA y configuración → NVDA, JAWS y VoiceOver no se comportan igual; dos usuarios de NVDA pueden usar atajos distintos.
• Distinta experiencia → un usuario veterano supera obstáculos que hunden a uno novel.

Regla práctica: incluye varios participantes por perfil y cubre diversidad de discapacidades (no solo lectores de pantalla; también teclado, zoom, cognitivo y sordera). Con 3-5 usuarios por perfil ya afloran la mayoría de problemas graves de ese perfil. Una sola persona te da anécdotas, no evidencia.

• Dar los pasos en vez de la tarea: si dices "pulsa el segundo botón", ya no observas cómo la persona busca. Da metas, no rutas.
• Ayudar al primer titubeo: mata el hallazgo. Aguanta el silencio.
• Confundirte a ti mismo con un usuario: tú conoces la web; tu prueba con NVDA (06-01) es válida para lo técnico, no para la usabilidad.
• Una sola persona = "ya está probado": falso. Diversifica perfiles y TA.
• No pagar / tratarlo como favor: es trabajo experto; el incentivo es respeto, no opcional.
• Olvidar consentimiento y anonimato: grabar sin permiso o publicar nombres es una falta ética grave.
• Consejo: graba (con permiso) y revisa después; en directo se te escapan detalles del audio del lector.

Ejercicio 1. Marta completa el formulario de matrícula, pulsa "Confirmar" y se queda en silencio, recargando la página. axe no reportó nada y tú, en 06-01, diste la tarea por superada. ¿Qué tipo de problema es, por qué solo lo detectó ella, y en qué se diferencia de un fallo que sí vería una herramienta?

Ejercicio 2. Tu jefe dice: "Hicimos una sesión con un usuario de JAWS y todo fue bien, ya podemos poner el sello de accesible". Da dos razones por las que esa conclusión es inválida.

Ejercicio 3. Diseña una sesión de 45 minutos con Lucía (solo teclado) para validar el flujo de matrícula de Cursalia: escribe (a) 3 tareas realistas, (b) 2 métricas que recogerías y (c) una regla de moderación que te obligarías a respetar.

Solución 1. Es un problema de usabilidad, no una violación técnica: el mensaje de éxito existe en el DOM (por eso axe pasa y tú lo ves), pero no se anuncia a quien depende del audio. Solo Marta lo detecta porque solo ella depende del lector para saber que la acción tuvo efecto; para ti el problema es invisible porque tienes la información por otra vía (la vista). Se diferencia de un fallo de herramienta en que aquí no falta ningún atributo comprobable: falla la experiencia, que ninguna regla automática modela.

Solución 2. (1) Una sola persona no es evidencia: sus problemas y su destreza son particulares; hacen falta varios usuarios por perfil (3-5) para que afloren los problemas graves. (2) Falta diversidad: un usuario de JAWS no representa a usuarios de teclado, de zoom, con dislexia o con sordera; "accesible" exige cubrir distintas discapacidades y distintas TA, no un único perfil.

Solución 3. Ejemplo. (a) Tareas: "Encuentra un curso de Python para principiantes"; "Matricúlate en él"; "Activa los subtítulos del primer vídeo" — todas como metas, sin indicar teclas. (b) Métricas: éxito de tarea (completada/con ayuda/fallida) y número de veces que el foco la devuelve al inicio de la lista al filtrar (punto de fricción). (c) Regla de moderación: no sugerir teclas ni indicar dónde está un control; ante un atasco, esperar en silencio y, como mucho, preguntar "¿qué estás intentando ahora?".

Las pruebas con usuarios reales de tecnologías de asistencia son la validación definitiva: solo ellas revelan la usabilidad, esa capa que ni el 30-40% de lo automático (06-02) ni tu prueba manual de desarrollador (06-01) alcanzan. Marta, Lucía y Sofía nos enseñaron tres problemas invisibles para todo lo demás. Pero una sesión genera muchos hallazgos dispersos —citas, tiempos, bloqueos, violaciones—, y hay que convertirlos en decisiones: qué es grave, qué es un falso positivo, qué se arregla primero y cómo demuestras que quedó resuelto. De eso trata la última lección del módulo, 06-04 Interpretación de Informes de Accesibilidad: leer todo lo que has recogido en las tres lecciones anteriores y transformarlo en un plan de acción priorizado.