Accesibilidad motora en apps de enseñanza clínica

Abres la app de casos en la tablet. La pista siguiente exige un gesto de pinza para ampliar la imagen, luego un arrastre largo hasta el campo de hipótesis y un toque preciso en un icono de 24 píxeles junto a otro casi idéntico. Con temblor leve en las manos, o con fuerza limitada en uno de los miembros, el intento falla tres veces antes de que la hipótesis siquiera se envíe. El razonamiento clínico estaba listo. La interfaz pidió precisión motora fina. Ese es el terreno de la accesibilidad motora en apps de enseñanza clínica y en juegos de diagnóstico.

La accesibilidad motora trata de hacer la interacción usable para quien tiene temblor, limitación de miembros, fuerza reducida, menor precisión de toque, fatiga muscular o quien opera con switch, teclado, trackball, control o entrada por voz. Vale para estudiantes y médicos con discapacidad física permanente y también para quien lleva férula, está posprocedimiento, tiene dolor agudo o usa el aparato con una sola mano en el turno. El foco de este texto es el diseño de apps y plataformas de enseñanza: objetivos de toque, gestos, tiempo, arrastrar y soltar y alternativas de entrada. No es una lista numerada de normas técnicas de software médico, ni una guía de lectores de pantalla (tema de otro post de la serie).

Puntos principales

• Las barreras motoras en apps de enseñanza clínica incluyen objetivos pequeños, gestos de recorrido obligatorio, arrastrar y soltar sin alternativa, timeouts cortos y dependencia de ratón fino o de toque preciso.
• Principios útiles: objetivos grandes y espaciados, operación con un único puntero, tiempo flexible, teclado y switch completos, deshacer fácil y equivalencia entre toque, teclado y entrada asistiva.
• Estudiantes y médicos con discapacidad física existen en la formación; los estándares técnicos funcionales piden el resultado clínico, no un único modo de apuntar en la pantalla.
• El tamaño de objetivo y las alternativas a gestos complejos tienen base en investigación de interacción y en orientación internacional de accesibilidad web y móvil.
• En NEXO, casos ficticios con presentación clínica real y hasta seis pistas en flujo de pantalla piden interacción con pistas e hipótesis; el diseño inclusivo reduce la fricción motora sin afirmar eficacia.

Qué es la accesibilidad motora en apps de enseñanza

La accesibilidad motora es el conjunto de decisiones de interfaz que permiten operar una app sin depender de movimientos finos, rápidos o complejos. En enseñanza clínica digital, esto cubre tocar pistas, abrir hipótesis, confirmar el envío, navegar en el diferencial y cerrar el caso. Si la única forma de avanzar es un gesto de pinza seguido de un arrastre preciso bajo cronómetro, la app mide destreza digital, no solo razonamiento.

No confundir con accesibilidad cognitiva (lenguaje, carga, feedback) ni con accesibilidad visual (lectores, contraste, ampliación). Un caso puede ser cognitivamente claro y aun así inaccesible para quien no logra mantener el dedo estable sobre un objetivo minúsculo. Tampoco es el mismo eje del post sobre accesibilidad digital en softwares médicos, centrado en criterios generales de software clínico, ni el de tecnología asistiva para médicos con discapacidad visual. Aquí el problema es motor: temblor, fuerza, amplitud, uso de switch y equivalencia de entrada.

En la formación médica, existen estudiantes con discapacidad física y sensorial, aunque la divulgación y las adaptaciones siguen siendo inconsistentes. En un análisis nacional de estándares técnicos de escuelas de Medicina, pocos documentos respaldaban de forma explícita adaptaciones razonables; muchos eran ambiguos o silenciosos sobre la responsabilidad y sobre el uso de ayudas (Zazove et al., 2016). Un análisis ético sostiene que los estándares "orgánicos" (exigir el órgano o el gesto sin ayuda) excluyen a candidatos capaces bajo estándares funcionales, que piden el resultado de la tarea con adaptación (McKee et al., 2016). El paralelo para las apps de enseñanza es directo: exigir "toque preciso con el pulgar dominante" es un estándar orgánico de interfaz; exigir "enviar la hipótesis" con teclado, switch o toque ampliado es un estándar funcional.

La prevalencia y la trayectoria también importan para quien diseña un producto educativo. Los datos de prevalencia y de adaptaciones clínicas en educación médica muestran que la discapacidad en la escuela de Medicina no es una anécdota (Meeks et al., 2020). Los estudios de cohorte sobre el desempeño de estudiantes con discapacidad refuerzan que, con acceso adecuado, la trayectoria académica puede alinearse con la de sus pares; el cuello de botella suele ser una barrera del entorno, no una "falta de aptitud" genérica (Meeks et al., 2022). Las llamadas a la acción en la literatura piden eliminar barreras estructurales y adoptar estándares técnicos inclusivos (Marzolf et al., 2022; Kezar et al., 2019; Stauffer et al., 2022).

Para el estudiante, la pregunta práctica es: "¿esta app me exige razonamiento clínico o me exige acertar un píxel?". Para quien diseña casos y juegos, la pregunta es: "¿cada control crítico tiene un camino operable con teclado, con toque amplio y con tiempo humano?". El resto de este texto traduce eso en barreras y en remedios concretos, con enlace a tipos de juegos para estudiantes de Medicina y a aprendizaje basado en casos.

Barreras motoras comunes en la interfaz

En apps de casos y en juegos de diagnóstico, las barreras motoras se repiten. Objetivos pequeños y pegados: iconos de acción uno al lado del otro sin margen. Gestos de trayecto obligatorios: pellizco, deslizamiento en curva, multitoque. Arrastrar y soltar sin alternativa de toque para seleccionar y toque para soltar. Tiempos de espera cortos: la pantalla expira si el dedo duda. Controles solo en la esquina superior, difíciles de alcanzar con una mano. Dependencia del hover del ratón en la versión web. Confirmaciones destructivas sin deshacer. Campos de texto que abren el teclado virtual y tapan el botón de envío.

Las guías de accesibilidad en juegos (por ejemplo la lista completa de las Game Accessibility Guidelines) piden reasignación de controles, evitar gestos complejos obligatorios, permitir tiempo flexible y ofrecer modos de entrada alternativos. En educación móvil, los análisis de juegos educativos en Android muestran que las interfaces basadas solo en canvas a menudo exponen un único objetivo del tamaño de la pantalla al switch access, lo que impide la exploración elemento a elemento. El punto para Medicina es el mismo: si la barrera es motora, el estudiante "falla" el caso sin haber fallado el diagnóstico diferencial.

Lista objetiva de barreras que inspeccionar en cualquier caso jugable:

• Botones críticos más pequeños que el área cómoda del dedo, sin padding clicable.
• Acciones que solo existen como gesto de trayecto (arrastre libre, pellizco, círculo).
• Cronómetro o expiración de sesión que castiga dudar o corregir un toque.
• Flujo imposible solo con teclado (Tab, Enter, flechas) en la versión web.
• Elementos no enfocables para switch access (orden de foco roto o ausente).
• Objetivos destructivos (borrar, saltar pista) pegados al objetivo de confirmar.

Estas barreras afectan de forma desigual. Quien tiene temblor puede activar el vecino del botón correcto. Quien tiene fuerza limitada puede no completar un arrastre largo. Quien usa una sola mano se cansa en gestos bilaterales. Quien opera con switch necesita que cada control sea un paso discreto en la exploración. Quien está en movimiento (ambulancia, pasillo) sufre el mismo efecto: la mano tiembla y el objetivo pequeño se vuelve una lotería. El diseño inclusivo no "favorece" a un grupo; amplía quién consigue entrenar lo que el caso pretende medir.

Una prueba rápida de barrera motora: intenta completar el flujo solo con teclado; después solo con toque grueso (nudillo o bolígrafo grueso); después con un tiempo deliberadamente lento. Si algún camino se rompe, la interfaz está midiendo destreza, no razonamiento. Corrige objetivos, gestos y tiempo antes de añadir contenido clínico nuevo.

Otra señal: el estudiante formula la hipótesis en voz alta y falla al registrarla en la app. En ese patrón, investiga objetivo, gesto y timeout antes de concluir que hay una laguna de conocimiento. El post sobre laguna de conocimiento o de razonamiento trata el diagnóstico educativo; aquí la hipótesis es usabilidad motora.

Objetivos de toque, espaciado y precisión

El tamaño del objetivo es el primer remedio concreto. La orientación internacional de accesibilidad web recomienda, en el criterio mejorado de tamaño de objetivo, al menos 44 por 44 píxeles CSS para entradas de puntero, con excepciones para enlaces en línea y controles equivalentes (W3C, Target Size Enhanced). También hay un mínimo de 24 por 24 píxeles CSS en el criterio de nivel AA más reciente (W3C, Target Size Minimum). En apps nativas, las guías de plataforma suelen hablar de unos 44 puntos (iOS) o 48 dp (Android). El número exacto importa menos que la regla práctica: los objetivos de acción clínica (enviar hipótesis, abrir pista, confirmar) deben ser lo bastante grandes para un dedo tembloroso o un toque con el lateral de la mano.

Una investigación clásica de interacción móvil con el pulgar de una mano sugirió objetivos en el rango de unos 9 mm para tareas discretas y seriadas sin degradar el error y la preferencia (Parhi, Karlson y Bederson, 2006). Las notas técnicas de la W3C sobre tamaño de toque en dispositivos móviles traducen recomendaciones físicas del orden de 9 mm por 9 mm, alineadas con esa línea de evidencia (W3C Mobile A11y TF, M002). En usuarios con discapacidad motora grave, los estudios de interfaces táctiles muestran que la precisión y la tasa de acierto varían según la región de la pantalla y el tamaño del objetivo; tocar (tapping) suele preferirse a los gestos direccionales cuando el tamaño es adecuado (Guerreiro et al., 2010).

El espaciado importa tanto como el tamaño. Dos botones de 44 píxeles pegados sin margen producen error de vecino. Deja un espacio inactivo entre confirmar y cancelar; separa "enviar hipótesis" de "saltar pista". En listas de hipótesis o de códigos, aumenta la altura de la fila clicable, no solo el texto visible. El padding invisible cuenta para el área activa.

Prácticas de objetivo en un caso jugable:

• Botones primarios con un área mínima generosa (objetivo mejorado de 44 CSS px como referencia de diseño).
• Margen clara entre acciones irreversibles y acciones rutinarias.
• Evitar iconos solo en el extremo de la pantalla sin versión accesible en el flujo principal.
• En web, garantizar que el foco del teclado dibuje un contorno visible en el mismo control amplio.
• Probar con el pulgar, con un bolígrafo grueso y con temblor simulado (toque deliberadamente impreciso).

Esto no "infantiliza" la app clínica. Los objetivos grandes son estándar de producto maduro en salud digital y en juegos serios. El entrenamiento de diagnóstico diferencial con pistas ya pide sopesar los hallazgos con cuidado; desde el ángulo motor, el mismo cuidado vale para el botón que registra el peso de la hipótesis.

Gestos, arrastrar y soltar y un único puntero

Los gestos de trazo y multitáctiles son barreras clásicas. El criterio de gestos de puntero de la WCAG pide que la funcionalidad basada en gestos multipunto o de trazo pueda operarse con un único puntero sin gesto de trazo, salvo cuando el gesto sea esencial (W3C, Pointer Gestures). Traducción para el juego de diagnóstico: si ampliar la imagen es necesario, ofrece botones de más y menos zoom; si ordenar hipótesis es necesario, ofrece flechas o menú, no solo arrastrar tarjetas.

Arrastrar y soltar aparece en varias apps educativas como metáfora "intuitiva". Para quien tiene temblor o usa switch, arrastrar es costoso: exige mantener la presión, seguir la trayectoria y soltar en el objetivo correcto. La alternativa accesible es seleccionar con un toque y confirmar el destino con otro toque (o con Enter en el teclado). El resultado pedagógico es el mismo; la exigencia motora baja.

Mapeo útil de gestos a alternativas:

• Pellizco para zoom: botones + y −, o slider con teclado.
• Desliza para revelar pista: botón "próxima pista" con etiqueta clara.
• Arrastrar hipótesis a la zona de envío: seleccionar hipótesis y botón "enviar".
• Pulsación larga para menú: botón de menú visible o tecla de atajo.
• Dos dedos para rotación de imagen: botones de giro de 90°.

La orientación de accesibilidad móvil de la W3C recuerda que los gestos complejos pueden ser imposibles para parte de los usuarios y que el diseño debe ofrecer opciones equivalentes (W3C, Mobile Accessibility Mapping). En gamificación en la educación médica, la presión de tiempo y los gestos "divertidos" solo ayudan cuando no se convierten en barrera de entrada. Una diversión que excluye a quien tiene temblor en la mano no es diversión inclusiva.

Hay una distinción útil entre dificultad deseable y barrera inútil. Recuperar una hipótesis de la memoria es dificultad deseable (ver también el post sobre dificultades deseables). Acertar un gesto de pinza con temblor es barrera inútil. La accesibilidad motora elimina la segunda sin borrar la primera.

Tiempo de interacción y timeouts

Un tiempo rígido introduce una varianza que no es competencia clínica: velocidad de puntería, temblor bajo ansiedad, necesidad de reposicionar el switch. En apps de enseñanza, los timeouts de sesión, los mensajes que desaparecen solos y los cronómetros que cierran el caso penalizan a quien necesita más tiempo motor, no solo a quien piensa más despacio.

Principios alineados con la accesibilidad de tiempo: permitir extender, ajustar o desactivar los límites de tiempo cuando el contenido no sea una prueba formal sincronizada; avisar antes de que expire; conservar lo que ya se escribió. En el entrenamiento diario de razonamiento, el estándar debe ser el ritmo propio. Si hay un modo cronometrado, ofrécelo como opción avanzada, anunciada antes de empezar.

Buenas prácticas de tiempo en el caso jugable:

• Modo estándar sin cuenta regresiva agresiva en la interacción.
• Pausa que congela el caso sin perder la hipótesis en borrador.
• Tiempo extra automático o configurable para quien usa entrada asistiva.
• Evitar los toasts demasiado rápidos como único canal de feedback de error de toque.
• Permitir corregir un toque accidental sin reiniciar el caso entero.

La ansiedad y la prisa motora se refuerzan: el dedo falla más cuando el reloj rojo parpadea. Hay eco con las discusiones sobre ansiedad de examen: la presión sin necesidad pedagógica mide estrés, no solo conocimiento. En el estudio formativo, la generosidad de tiempo es diseño, no "debilidad".

La metacognición también entra después del caso: "¿fallé el toque o fallé la hipótesis?". Separar ambos evita culpar al razonamiento por un fallo de interfaz. El post sobre metacognición en Medicina profundiza el hábito; desde el ángulo motor, la pregunta posterior al caso debe incluir la hipótesis de error de objetivo.

Teclado, switch y entrada alternativa

Un teclado completo es la prueba de oro de la operabilidad. Si la versión web de la app de enseñanza no permite Tab entre controles, Enter para activar, Escape para cerrar y flechas en listas, quien usa teclado físico, teclado en pantalla ampliado, emulador de ratón por cabeza o switch queda fuera. El criterio de teclado de la WCAG pide que toda funcionalidad sea operable por teclado sin exigir un tiempo específico por tecla, salvo excepciones esenciales de ruta (W3C, Keyboard). Evita la trampa de teclado: el foco no puede quedar atrapado en un widget.

Switch access (barrido lineal o por punto) depende de elementos enfocables en orden lógico. Las interfaces diseñadas solo en canvas con un único rectángulo clicable rompen el barrido: el switch "ve" la pantalla entera como un botón. En apps de casos, cada pista, cada hipótesis y cada acción de envío debe ser un control discreto con nombre. Prueba con las herramientas nativas de switch del sistema operativo móvil antes de publicar un modo nuevo.

Otras entradas alternativas habituales en la práctica:

• Trackball y ratón adaptado: necesitan clic simple, no arrastre continuo.
• Control o gamepad: útil cuando los botones físicos son más grandes que los objetivos de toque.
• Entrada por voz para el texto de la hipótesis: complementaria, no camino único si el entorno es ruidoso.
• Pedal o botón externo: mapeable a "próxima pista" y "enviar" cuando el SO lo permita.
• Modo de aceptación de toque con retardo (dwell): la app no debe cancelar el foco si el dedo dudó medio segundo.

La percepción del entorno de aprendizaje por estudiantes con discapacidad mejora cuando el programa de acceso es visible y confiable; las barreras estructurales y la cultura de divulgación todavía pesan (Moreland et al., 2025). En el producto educativo, el equivalente es documentar caminos de entrada (teclado, switch, toque ampliado) de forma que se encuentren sin buscar como un tesoro. La página de accesibilidad del sitio es el lugar institucional para orientar; la app en sí debe cumplir lo que la página describe, sin convertir la publicación en una auditoría de declaración.

Principios prácticos en tabla

La tabla siguiente resume el mapeo de barrera y respuesta. Úsela al revisar una app de enseñanza clínica, un caso jugable o una actividad en tablet antes de publicar.

Barrera motora	Lo que siente el estudiante	Respuesta de diseño
Objetivo pequeño o pegado	Activa el vecino; falla el envío	Objetivo amplio; margen entre acciones
Gesto de trayecto obligatorio	No completa pinza o curva	Botón o toque equivalente
Solo arrastrar y soltar	Suelta en el lugar equivocado	Seleccionar y confirmar en dos toques
Tiempo de espera corto	Pierde el progreso al dudar	Ritmo propio; aviso antes de expirar
Sin teclado completo	Switch y teclado se detienen a mitad	Tab, Enter, Escape; orden de foco
Canvas sin controles discretos	El barrido ve un único bloque	Controles nombrados y enfocables
Acción destructiva junto a la confirmación	Borra el caso sin querer	Separar; pedir confirmación; deshacer

Estos principios se alinean con la orientación W3C de objetivo, gesto y teclado, y con prácticas de juegos accesibles. No sustituyen la prueba con usuarios que usan switch, trackball o una sola mano, pero evitan los errores más costosos antes del primer playtest. Las revisiones de estándares técnicos en escuelas médicas nuevas muestran que el lenguaje inclusivo todavía es desigual (Stauffer et al., 2022); lo mismo vale para las apps: la intención inclusiva debe aparecer en el control concreto, no solo en el texto institucional.

El feedback útil en casos clínicos también tiene un ángulo motor: si el único retorno de error es un destello de 200 ms sobre un ícono diminuto, quien falló el toque ni siquiera ve el criterio. Un feedback estable en texto, con tiempo para leer y con un botón amplio de "entendido", cierra el ciclo sin puntería olímpica.

Cómo entra NEXO

En NEXO, el flujo del caso del día presenta casos ficticios con presentación clínica real y hasta seis pistas progresivas. Interactuar con las pistas y con el campo de hipótesis es el corazón del ensayo. Desde el ángulo motor, el diseño inclusivo significa: objetivos operables, caminos sin gesto obligatorio de pinza, tiempo que no castiga dudar, y equivalencia entre toque y teclado en la web. Ninguna frase aquí afirma eficacia; describe el tipo de interacción que un juego diario de diagnóstico debe hacer accesible.

Recursos del ecosistema vinculados al estudio: NEXO Researcher para profundizar temas; NEXO Closer cuando el foco es cerrar brechas; límites de uso en economía. La página de accesibilidad reúne orientaciones generales de la plataforma. El texto qué es NEXO sitúa el juego en el mapa de la enseñanza clínica.

Cómo usar el caso del día con mirada de accesibilidad motora (sin promesa de resultado):

• Prefiera tablet con teclado o computadora de escritorio si el toque fino cansa; el flujo web debe seguir siendo operable por teclado.
• Aumente el zoom del sistema operativo si los objetivos parecen pequeños; pruebe si el diseño se reajusta sin ocultar el botón de envío.
• Si un toque accidental salta una pista o cierra un diálogo, haga una pausa y use deshacer o reabra con calma; no convierta el error motor en "prisa cognitiva".
• Ensayé la hipótesis en texto corto antes de apuntar al envío, para separar el razonamiento de la precisión del toque.
• Si el dolor, la fatiga o la exclusión por la interfaz son intensos, haga una pausa y busque la ayuda necesaria.

Comparaciones honestas: NEXO concentra pistas y envío de hipótesis en un flujo único; los simuladores con muchos gestos de manipulación 3D y los bancos con decenas de microobjetivos exigen más precisión motora. La elección del día depende del objetivo. Para entrenar el diferencial con pocas pistas, el formato compacto encaja. Para entrenar la habilidad manual en un procedimiento, el laboratorio de simulación es otro espacio. El principio compartido: mida el razonamiento, no la tolerancia a objetivos diminutos.

Quien crea casos para grupos (preceptores, monitores, grupos de estudio) puede aplicar la tabla anterior incluso fuera de la plataforma: botones grandes en diapositivas interactivas, alternativas a arrastrar, tiempo flexible en la actividad formativa y retroalimentación con criterio. NEXO ilustra un camino; el estándar de accesibilidad motora vale para cualquier caso jugable en tablet.

Para preceptores que usan el caso del día en grupo: permita que cada estudiante registre la hipótesis a su propio ritmo y en su propio dispositivo adaptado, y solo entonces discuta en voz alta. Evite una única estación con mouse fino compartido como único medio de participación. El contenido clínico permanece; el protocolo de uso se vuelve más inclusivo.

Antes de publicar o de jugar un caso con mirada de accesibilidad motora, revise esta lista:

• ¿Los botones críticos tienen un área amplia y margen respecto al vecino?
• ¿Toda acción de gesto tiene un equivalente de toque simple o teclado?
• ¿El flujo web se completa con Tab y Enter, sin trampa de foco?
• ¿Hay un modo sin tiempo límite punitivo?
• ¿Los controles son discretos y enfocables para switch?
• ¿Las acciones destructivas están separadas y son reversibles?
• ¿La retroalimentación de error permanece en pantalla el tiempo suficiente y en un área amplia?
• ¿Lo probé con toque impreciso y solo con teclado?

Si algún punto falla, corrija el diseño antes de atribuir el error al estudiante. Después, practique con un caso completo en el flujo real.

Juega el caso del día.

Preguntas frecuentes

¿Accesibilidad motora es lo mismo que WCAG?

No exactamente. WCAG aporta criterios técnicos (área, gesto, teclado) que este artículo usa como principios. El foco aquí son apps y juegos de enseñanza clínica, no una guía normativa completa de software médico.

¿Las áreas grandes hacen que la interfaz parezca "infantil"?

No. Las áreas generosas son estándar en productos de salud y en juegos accesibles. Usted cambia el área activa y el espaciado, no el rigor clínico del caso.

¿Arrastrar y soltar puede quedarse si hay alternativa?

Sí. Mantenga el arrastre como atajo opcional si quiere, siempre que seleccionar y confirmar con toques o teclado haga la misma tarea.

¿Switch access exige una app nativa?

No necesariamente. Exige controles enfocables y orden lógico. Un canvas único suele fallar; los botones y campos reales suelen funcionar con las herramientas del sistema.

¿Esto solo importa a quienes tienen una discapacidad permanente?

No. Una férula, el dolor, la fatiga, el uso con una mano en el turno y el temblor situacional producen barreras parecidas. El diseño inclusivo beneficia a la mayoría.

¿Cómo encaja NEXO sin convertirse en promesa de resultado?

Como entorno de ensayo con pistas e hipótesis en pantalla. Úselo para practicar el hábito de razonamiento en un formato operable; no como prueba de destreza ni como tratamiento.

Referencias

1. W3C. Understanding SC 2.5.5 Target Size (Enhanced). https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced
2. W3C. Understanding SC 2.5.8 Target Size (Minimum). https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum
3. W3C. Understanding SC 2.5.1 Pointer Gestures. https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures
4. W3C. Understanding SC 2.1.1 Keyboard. https://www.w3.org/WAI/WCAG22/Understanding/keyboard
5. W3C. Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile. https://www.w3.org/TR/mobile-accessibility-mapping/
6. W3C Mobile Accessibility Task Force. M002 Providing adequate touch target size. https://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M002
7. Parhi P, Karlson AK, Bederson BB. Target size study for one-handed thumb use on small touchscreen devices. MobileHCI. 2006. DOI 10.1145/1152215.1152260.
8. Guerreiro T, et al. Towards accessible touch interfaces. ASSETS. 2010. DOI 10.1145/1878803.1878809.
9. Zazove P, et al. U.S. Medical Schools' Compliance With the Americans With Disabilities Act: Findings From a National Study. Acad Med. 2016. PMID 26796093.
10. McKee M, et al. Medical Schools' Willingness to Accommodate Medical Students with Sensory and Physical Disabilities. AMA J Ethics. 2016. PMID 27780023.
11. Meeks LM, et al. National Prevalence of Disability and Clinical Accommodations in Medical Education. J Med Educ Curric Dev. 2020. PMID 33178890.
12. Meeks LM, et al. The Performance and Trajectory of Medical Students With Disabilities. Acad Med. 2022. PMID 34817411.
13. Marzolf BA, et al. Call to Action: Eliminate Barriers Faced by Medical Students With Disabilities. Ann Fam Med. 2022. PMID 35879081.
14. Kezar LB, et al. Leading Practices and Future Directions for Technical Standards in Medical Education. Acad Med. 2019. PMID 30398992.
15. Stauffer C, et al. Technical Standards from Newly Established Medical Schools: A Review of Disability Inclusive Practices. J Med Educ Curric Dev. 2022. PMID 35036566.
16. Moreland CJ, et al. Perceptions of the Learning Environment Among Medical Students With Disabilities and the Impact of Program Access. Acad Med. 2025. PMID 40344596.
17. Game Accessibility Guidelines. Full list. https://gameaccessibilityguidelines.com/full-list/