Flujo del caso con lector de pantalla: pistas e hipótesis

Abres el caso del día con el lector de pantalla activado. El enunciado anuncia edad y motivo de consulta. Después el foco salta a un botón sin nombre, luego a un gráfico decorativo, y la "pista 1" solo existe como color en la esquina. Formulas una hipótesis, pero el campo de búsqueda dice solo "editar". La retroalimentación de proximidad parpadea en verde sin palabra. El cierre existe en pantalla y desaparece en el habla. Este texto recorre el flujo del caso jugable con lector de pantalla: pistas (hasta seis), hipótesis, envío, proximidad, cierre y lo que la interfaz necesita anunciar y ordenar en cada etapa. Se diferencia del catálogo de tecnología asistiva visual (productos y lectores) y del mapa WCAG en accesibilidad digital en softwares médicos. Aquí el objeto es el recorrido pedagógico por el caso, no la lista de softwares.

Nada en este artículo afirma eficacia de NEXO. Describimos principios de diseño, criterios públicos (W3C, orientaciones de juegos accesibles) y recursos verificados en la declaración de accesibilidad. Casos ficticios con presentación clínica real, con hasta seis pistas, solo enseñan si cada etapa del flujo es legible en la API de accesibilidad, no solo en el diseño visual.

Puntos principales

• El flujo del caso tiene etapas estables: apertura, pista, hipótesis, envío, proximidad, siguiente pista o cierre; el lector de pantalla necesita nombres, orden y landmarks en cada una.
• El orden de foco en el DOM debe seguir la secuencia pedagógica, no el azar del CSS; el criterio 2.4.3 de la WCAG trata exactamente de eso.
• Las pistas progresivas (hasta seis) piden rótulo con número y contenido en texto real; revelar solo por animación o color falla en el habla y en el braille.
• Los campos de hipótesis y los botones de envío necesitan un nombre accesible que describa la acción; "editar" y "OK" no bastan.
• Proximidad y cierre exigen palabra además de color; el detalle de la explicación larga después del cierre es otro momento del ciclo (ver retroalimentación útil y la declaración pública).
• En NEXO, la página /accessibility describe rótulos en pistas y retroalimentación, HTML semántico e independencia del color en la proximidad; sin afirmación de resultado de aprendizaje. Los límites de uso, cuando son relevantes, están en /economia.

Mapa del flujo: de la apertura al cierre

En un juego diario de diagnóstico, el caso no es una página estática. Es un recorrido: lees el contexto, recibes pistas a demanda, propones hipótesis, recibes proximidad y, al acertar o agotar intentos, llegas al cierre. El aprendizaje basado en casos organiza ese ciclo en torno a un problema clínico concreto (cómo funciona). Entrenar el diferencial con pistas progresivas refuerza el peso de cada hallazgo (entrenar con pistas). Con lector de pantalla, el mismo recorrido solo funciona si cada cambio de estado está nombrado y es enfocable.

Casi el 6% de los estudiantes de medicina en Estados Unidos declaró una discapacidad en 2021, más del doble que en 2015, y piden adaptaciones que incluyen acceso digital (Huth et al., 2025; prevalencia y adaptaciones: Meeks et al., 2020). En cursos en línea de ciencias, más de la mitad de los estudiantes con discapacidad reportó adaptaciones inadecuadas tras la migración digital; las recomendaciones de inclusión deben ser universales, no solo individuales (Gin et al., 2022). El contenido interactivo probado con lector de pantalla muestra que muchos tipos de actividad "funcionan" solo en parte y piden una alternativa explícita (Böhm y Lux, 2025). Los recursos digitales para discapacidad visual piden descripción por lector, navegación por teclado y adherencia a las directrices W3C (Almeida et al., 2020).

Imagina un caso ficticio con presentación clínica real: adulto joven con dolor torácico y disnea desde hace algunas horas, hasta seis pistas. La pista 1 habla de inicio súbito; la pista 2 de saturación; la pista 3 de hallazgo de examen. Subes y bajas hipótesis (embolia, síndrome coronario, neumotórax, ansiedad). Cada paso debe existir en el árbol de accesibilidad: no basta con que aparezca en el rectángulo de la pantalla.

Las orientaciones de juegos accesibles piden estructura predecible, landmarks significativos, indicadores de progreso y soporte de lector de pantalla en menús y jugabilidad (Game Accessibility Guidelines). La WCAG trata el orden de foco, los nombres, las relaciones y los cambios de estado (W3C, Focus Order 2.4.3; Info and Relationships 1.3.1). El mapa mental del flujo, para quien escucha la interfaz, es:

• Dónde estoy (título del caso, número de pista, estado "en curso" o "cerrado").
• Qué puedo hacer ahora (revelar pista, editar hipótesis, enviar, informar de un problema).
• Qué acaba de cambiar (nueva pista, proximidad, acierto, error de red).
• Adónde ir después (explicación, siguiente caso, salir).

La carga cognitiva en la enseñanza en salud ya pide reducir el ruido y preservar la memoria de trabajo para lo que enseña (van Merriënboer y Sweller, 2010; Mayer, 2010). Buscar el botón sin nombre o escuchar "gráfico" en lugar de la pista es ruido puro. Dialoga con la metacognición: solo monitoreas tu propio razonamiento si la interfaz no consume toda la atención.

En la práctica, trata el flujo como un protocolo mental de cabecera del paciente: anamnesis (enunciado), examen (pistas), hipótesis, prueba (envío), resultado (proximidad) y plan (explicación). Quien como preceptor observa el razonamiento en voz alta hace algo parecido. El lector de pantalla es esa voz alta automática: si el protocolo no está nombrado en la interfaz, la presentación del caso para uno mismo se rompe a mitad de camino. Por eso los landmarks y los headings no son un detalle de ingeniería; son la columna vertebral del razonamiento clínico en el medio digital.

Antes de la primera pista: página, landmarks y foco

Antes de cualquier pista, el lector arma el mapa de la pantalla. Los landmarks (main, navigation, complementary) y un heading de nivel 1 con el título del caso permiten saltar el chrome de la app. Un skip link al contenido principal evita un Tab eterno por el menú. Si el título de la pestaña del navegador es genérico ("App"), la lista de ventanas no ayuda a quien cambia de tarea en el turno.

El orden de foco inicial importa. Al abrir el caso, el foco debe caer en el heading o en el primer bloque de enunciado, no en un banner promocional ni en un modal olvidado. Los elementos enfocables ocultos visualmente, pero que siguen en el Tab, crean "huecos" silenciosos. La WCAG exige que la secuencia preserve significado y operación (Focus Order). En juegos y simulaciones web, una estructura consistente y la descripción del contexto orientan a quien no ve la escena (Floe, Web Games and Simulations).

El teclado es el compañero del lector: Tab, Shift+Tab, Enter, Espacio y flechas. El foco visible debe existir para quien ve parcialmente y para quien enseña mirando la pantalla ajena. El post de accesibilidad digital sitúa el teclado y los nombres en el software clínico; aquí el foco es la secuencia del caso jugable.

Prueba rápida de cinco minutos en la apertura:

• Enumera los headings: ¿aparece el título del caso?
• Enumera los landmarks: ¿hay un main con el enunciado?
• Tabulá desde arriba hasta el botón "revelar pista" sin trampa.
• Confirma que las imágenes decorativas tienen alt vacío y que las imágenes clínicas tienen alt útil.

Las instituciones de educación médica todavía comunican la inclusión de forma desigual en las páginas públicas (Ikedionwu et al., 2025). En el material de estudio, la inclusión empieza más abajo: en el DOM del caso. La accountability para estudiantes con discapacidad apunta en la misma dirección (Meeks, Stergiopoulos y Petersen, 2022). Las barreras de revelación en residentes muestran que muchos dudan en pedir acomodación (Pereira-Lima et al., 2023); diseñar el flujo legible por defecto reduce la dependencia de la solicitud solo para "lograr escuchar la pista 1".

La consistencia entre sesiones también cuenta. Si ayer el foco se abría en el enunciado y hoy se abre en el ranking, el modelo mental se derrumba. Guardar preferencias de lectura (cuando el producto las tenga) y mantener la estructura del caso estable reducen la carga de reorientación. Las guías de juegos accesibles piden una estructura predecible y detalles de recursos de accesibilidad visibles en el producto y en el sitio (Game Accessibility Guidelines); la declaración en /accessibility cumple la parte pública de esa petición en NEXO, sin afirmar eficacia.

Pistas progresivas: lo que el lector necesita oír

Hasta seis pistas progresivas son el corazón del método: la información llega en porciones, y el peso de cada hallazgo cambia el diferencial. Para el lector de pantalla, "porción" debe ser un bloque nombrado. Rótulos del tipo "Pista 2 de 6" más el texto clínico completo superan a "contenido nuevo" sin contexto. Si la pista es solo una tarjeta de color con un icono, la voz se convierte en "botón" o "imagen".

Revelación bajo demanda: el control "mostrar siguiente pista" debe tener un nombre accesible estable y, al activarlo, el foco debe ir al heading o a la región de la pista nueva. Evite inyectar el texto solo en una región aria-live agresiva que lee el párrafo entero sin control. Prefiera el foco en el heading de la pista y la lectura bajo comando del usuario; una live corta puede anunciar "Pista 2 disponible". La documentación de regiones live recomienda polite en la mayoría de los casos (APG Alert; MDN Live regions).

Las imágenes clínicas en la pista (trazado, foto, informe) piden una alternativa textual del hallazgo que importa, no el nombre del archivo. Los principios de multimedia piden alinear palabras e imágenes (Mayer, 2010). La doble codificación ayuda al estudio cuando texto e imagen se refuerzan (doble codificación); si el hallazgo esencial está solo en la figura, la pista desaparece para quien escucha.

Las abreviaturas ("PA", "FC", "SpO2") confunden la síntesis de voz. Expandirlas en la primera mención de la pista reduce el deletreo extraño. Las listas cortas dentro de la pista ("a favor", "en contra") con headings o ul reales orientan mejor que un párrafo único de ocho líneas.

El progreso visible ("3 de 6") necesita un equivalente textual. Una barra solo visual falla. Las guías de juegos accesibles piden indicadores de progreso y refuerzo no solo textual cuando la instrucción es crítica (Game Accessibility Guidelines). En MOOCs diseñados con WCAG y consulta de preferencias, los usuarios de lector de pantalla mostraron una asociación positiva con un buen desempeño frente a quienes no declararon preferencia; quienes tenían baja visión sin un lector adecuado quedaron en desventaja relativa (Rodriguez-Ascaso et al., 2024). El diseño de la pista es parte de esa ecuación.

La pausa diagnóstica en el razonamiento (pausa diagnóstica) cabe entre pistas: un control "revisar pistas anteriores" con lista navegable evita que la memoria de trabajo cargue todo por sí sola. La ética del diseño educativo ya pide no perjudicar al aprendiz por el formato (ética en el diseño de juegos).

Hipótesis y envío: nombres accesibles y orden

Formular una hipótesis es la jugada clínica del juego: nombre del diagnóstico o código. El campo de búsqueda o combobox necesita un label visible y asociado ("Hipótesis diagnóstica" o "Código CIE"), no solo un placeholder que desaparece al escribir. Los resultados de la lista deben poder anunciarse ítem por ítem, con el nombre completo del término. Botón de enviar: "Enviar hipótesis", no "OK".

Orden en el formulario: label, campo, ayuda breve ("puede buscar por nombre o código"), después enviar. Mensajes de error ("ningún resultado", "campo vacío") en texto ligado al campo, con el foco movido al error cuando tenga sentido. Evite validar solo por el color del borde.

Si hay una lista de hipótesis recientes o favoritas, cada ítem necesita un nombre distinto. "Botón", "botón", "botón" en la lista de controles es un fallo clásico. Lo mismo vale para "eliminar hipótesis" frente a "enviar".

Los trabajadores que usan lector de pantalla en el empleo a menudo combinan más de un lector y reportan menos dificultad cuando tienen respaldo (McDonnall et al., 2025). Esto no autoriza a clasificar productos aquí: el catálogo y las páginas oficiales están en el post de tecnología asistiva visual. En este flujo, el punto es que la interfaz del caso sobreviva a cualquier lector razonable: HTML semántico, nombres y foco.

La calibración de la confianza (calibración de la confianza) y la brecha de conocimiento frente a la brecha de razonamiento (brecha de conocimiento o de razonamiento) dependen de que usted sepa lo que envió. Si el lector no confirma la hipótesis elegida antes del Enter, el error se vuelve ruido. Un resumen "Va a enviar: embolia pulmonar" inmediatamente antes del botón reduce el envío ciego.

En casos ficticios con presentación clínica real, la hipótesis equivocada sigue enseñando si el ciclo de proximidad y la pista siguiente permanecen audibles. Cuando el campo se traga el nombre elegido o el botón de envío desaparece del Tab después del primer error, el estudiante con lector abandona el caso no por falta de razonamiento, sino por una falla de operación. Esto se parece al timeout motor en apps de enseñanza: la barrera no es clínica. Diseñar el formulario estable (mismos nombres, mismo orden, mismos mensajes) en cada intento es parte del diseño pedagógico, no solo de la ingeniería.

Del intento al cierre: proximidad y explicación

Con cada hipótesis, muchos juegos de diagnóstico devuelven proximidad: mismo capítulo, próximo, distante. Ese retorno corto no es la explicación larga del cierre; es la señal de navegación en el espacio CIE. La independencia del color es obligatoria: la deficiencia congénita de visión de colores es lo bastante frecuente para justificar una etiqueta textual en material médico (PMID 10562750; práctica segura: PMID 28731005). La comunicación científica ya documenta el mal uso del color como único canal (PMID 33116149).

Para el lector de pantalla, la proximidad necesita un nombre accesible completo: "Proximidad: mismo capítulo" o "Proximidad: distante", no solo "estado" o un ícono. Si hay animación, no puede ser el único canal; respetar la preferencia de reducir movimiento evita mareos y distracción. Una live region corta y educada puede anunciar la proximidad; no la anuncie de nuevo en cada re-render silencioso.

La retroalimentación en educación clínica es información sobre el desempeño con la intención de mejorar el siguiente ciclo (van de Ridder et al., 2008). Los metaanálisis muestran que el efecto depende del tipo y del modo de entrega (Wisniewski, Zierer y Hattie, 2019). El post sobre explicación útil profundiza en el contenido y el timing del retorno pedagógico. La gamificación puede usar precisión y constancia sin depender de confeti sin etiqueta (evidencia en gamificación). La evaluación formativa vive de ese retorno que informa el siguiente ciclo (evaluación formativa).

Después de la proximidad, el foco debe volver a un punto predecible: campo de hipótesis (para un nuevo intento) o botón "siguiente pista". Dejar el foco en el limbo después del anuncio es una de las fallas más costosas en tiempo de estudio. Quien juega con lector de pantalla reconstruye el espacio del diferencial por la secuencia de anuncios; si la proximidad desaparece en el silencio, la siguiente hipótesis se vuelve una conjetura sin mapa.

Cerrar el caso (acierto o fin de los intentos) cambia el modo de la pantalla. El lector necesita un anuncio claro de estado ("Caso cerrado: diagnóstico objetivo disponible") y un heading que inaugure el área de resultado. Mover el foco a ese heading es más seguro que volcar la explicación entera en una live region. La transición del intento al debrief es el punto en que muchas apps "olvidan" la API de accesibilidad: lo visual cambia de tema, suben los confetis, y el árbol de accesibilidad queda sin heading o con el foco atrapado en el modal.

La explicación larga después del cierre (porqué, pistas que lo sustentaban, diferencial) es un problema de estructura del documento: headings, texto real, enlaces con nombre, tablas con encabezado. Ese eje pedagógico de utilidad del retorno está en explicación útil; el cuidado con tecnologías de asistencia en la prosa del poscaso dialoga con la declaración en /accessibility y con la guía de tecnología de asistencia visual, sin repetir un catálogo de productos. Aquí el punto del flujo es la transición: de la jugada al debrief sin perder al usuario en el silencio o en el spam de anuncios.

Los controles posteriores al cierre (reabrir pistas, copiar resumen, reportar un problema, ir al siguiente caso) entran en el orden de Tab después del heading de resultado. Nombres descriptivos. Si hay un modal de celebración, debe poder cerrarse con el teclado, con el foco atrapado de forma deliberada y restaurado al cerrar; si no, se convierte en una trampa. Un guion mínimo de QA con el lector activado: enviar una hipótesis equivocada, escuchar la proximidad, revelar una pista, acertar, escuchar "caso cerrado", Tab hasta "explicación" y leer el primer heading del porqué.

Herramientas del ecosistema de estudio después del caso: Researcher, Closer, Curator y Creators, siempre con el mismo cuidado de nombrado cuando se enlazan en la pantalla de resultado. El mismo patrón de nombre y foco que vale en la pista vale en el enlace de salida: "Abrir Researcher" dice más que "saber más".

Tabla: etapa, anuncio y falla común

Use la tabla al revisar el caso jugable con el lector de pantalla activado. Los contrastes son técnicos.

Etapa del flujo	Lo que el lector necesita oír	Falla común	Respuesta de diseño
Apertura del caso	Título del caso; landmark main; enunciado	Foco en el banner; título genérico	h1 + main; skip link; foco en el enunciado
Revelar pista	"Pista N de 6" + texto clínico	Solo color/animación; botón "botón"	Nombre del control; foco en el heading de la pista
Imagen en la pista	Alt del hallazgo relevante	Alt vacío o nombre de archivo	Alt escrito después de ver la imagen
Campo de hipótesis	Label + valor elegido	Solo placeholder; lista que cambia	label asociado; confirmación antes de enviar
Enviar	"Enviar hipótesis"	"OK" / ícono sin nombre	Nombre de la acción
Proximidad	Palabra del nivel (capítulo, próximo, distante)	Solo verde/amarillo/rojo	Texto + ícono con nombre; live corta
Cierre	Estado "cerrado" + heading de resultado	Explicación entera en aria-live	Foco en el heading; prosa estable
Poscaso	Acciones siguientes con nombre	Modal sin Escape; foco perdido	Orden de Tab; cerrar y restaurar el foco

Después de la tabla, pregunte: si solo escucho headings, landmarks y nombres de botones, ¿puedo jugar el caso desde el enunciado hasta el cierre? Si la respuesta es no, el flujo todavía no es accesible.

Cómo entra NEXO

NEXO es un juego diario de diagnóstico con casos ficticios con presentación clínica real y hasta seis pistas progresivas. La página /accessibility declara, entre otros puntos, rótulos descriptivos para elementos interactivos, pistas clínicas y feedback del juego; HTML semántico con jerarquía de headings en el sitio; contraste; alt en imágenes significativas; ausencia de medios en autoplay; e independencia del color en los niveles de proximidad (color con rótulo de texto). La misma página registra limitaciones conocidas sin convertir eso en marketing. Ninguna frase aquí afirma que esos recursos mejoran la retención, la nota o el desempeño clínico. Es una descripción verificable.

Quien está conociendo la plataforma puede leer qué es NEXO. El aprendizaje basado en casos sitúa el método (cómo funciona). Los límites de uso, cuando son relevantes, están en /economia. El ángulo de este post es el walkthrough del flujo con lector de pantalla. En la misma línea, ver accesibilidad cognitiva, feedback multimodal en la jugada, explicación posdiagnóstico y cómo escribir casos clínicos inclusivos.

Preguntas frecuentes

¿Este post reemplaza la guía de tecnología de asistencia visual?

No. Los productos, lectores y prácticas clínicas de TA visual están en tecnología de asistencia visual. Aquí el objeto es el flujo del caso (pistas, hipótesis, cierre) y lo que la interfaz debe anunciar.

¿Necesito anunciar cada pista entera en aria-live?

En general, no. Live corta para "pista disponible" o proximidad; foco en el heading; lectura del cuerpo bajo el control de quien usa el lector.

¿El orden visual puede diferir del orden de foco?

Solo si la secuencia aún conserva significado y operación. En el caso jugable, el camino pedagógico (enunciado, pista, hipótesis, proximidad, cierre) debe ser el camino del Tab y de la lectura lineal (WCAG 2.4.3).

¿Basta la proximidad solo con color si el contraste es alto?

No. El contraste ayuda a quien ve; no sustituye la palabra para el daltonismo ni para el lector de pantalla. Color con rótulo textual y, si lo hay, icono nombrado.

¿Cómo se relaciona esto con la explicación después del diagnóstico?

Son momentos distintos: la proximidad es una señal corta en la jugada; la explicación es un debrief estructurado. Utilidad del retorno: explicación útil. Accesibilidad digital amplia: softwares médicos.

¿Vale la pena probar solo con un lector de pantalla?

Mejor probar el flujo con más de una combinación de lector y navegador cuando sea posible; los estudios con trabajadores ciegos sugieren reserva de herramientas (McDonnall et al., 2025). Sin clasificar marcas en este texto.

Lista de verificación final

• Apertura: h1 del caso, landmark main, skip link, foco inicial en el enunciado.
• Pistas (hasta seis): control nombrado; "Pista N de 6"; texto real; alt clínico; foco en la pista nueva.
• Hipótesis: label asociado; confirmación del término; botón "Enviar hipótesis".
• Proximidad: palabra del nivel; live corta; foco predecible después.
• Cierre: anuncio de estado; heading de resultado; explicación fuera de live agresiva.
• Pos-caso: acciones nombradas; modal cerrable; sin trampa de teclado.
• Nada de información solo en color, solo en animación o solo en imagen.
• Revisar la declaración en /accessibility; límites en /economia.

Juega el caso del día.

Referencias

1. Almeida AMP, et al. Development of an online digital resource accessible for students with visual impairment or blindness. Work. 2020. PMID 32007977.
2. Böhm A, Lux T. Analyses of the Accessibility of Interactive Learning Content in H5P. Stud Health Technol Inform. 2025. PMID 40380646.
3. Gin LE, et al. New Online Accommodations Are Not Enough. CBE Life Sci Educ. 2022. PMID 35496702.
4. Huth K, et al. Accessible by design: a guide for health professions educators. 2025. PMID 39773717.
5. Ikedionwu I, et al. Evaluating Disability-Inclusive Content on U.S. Medical Schools Websites. Acad Med. 2025. PMID 40550114.
6. Mayer RE. Applying the science of learning to medical education. Med Educ. 2010. PMID 20604850.
7. McDonnall MC, et al. Screen reader use among legally blind workers. 2025. PMID 40614067.
8. Meeks LM, et al. National prevalence of disability and clinical accommodations in medical education. 2020. PMID 33178890.
9. Meeks LM, Stergiopoulos E, Petersen KH. Institutional accountability for students with disabilities. Acad Med. 2022. PMID 34670236.
10. Pereira-Lima K, et al. Barriers to disability disclosure in residency. 2023. PMID 37166801.
11. Rodriguez-Ascaso A, et al. Performance of students with different accessibility needs in Design for All MOOCs. 2024. PMID 38451899.
12. van de Ridder JM, et al. What is feedback in clinical education? Med Educ. 2008. PMID 18230092.
13. van Merriënboer JJ, Sweller J. Cognitive load theory in health professional education. Med Educ. 2010. PMID 20078759.
14. Wisniewski B, Zierer K, Hattie J. The Power of Feedback Revisited. Front Psychol. 2019. PMID 32038429.
15. Deficiencia de la visión de los colores y color como único canal: PMID 10562750; PMID 28731005; PMID 33116149.
16. W3C. WCAG 2.2 Understanding: Focus Order; Info and Relationships. Focus Order; 1.3.1.
17. W3C APG / MDN. Live regions and alert pattern. APG Alert; MDN.
18. Game Accessibility Guidelines. Full list. gameaccessibilityguidelines.com.
19. Floe Inclusive Learning Design Handbook. Web Games and Simulations. handbook.floeproject.org.