Accessibilité motrice dans les apps d'enseignement clinique

Vous ouvrez l'app de cas sur la tablette. L'indice suivant exige un geste de pincement pour agrandir l'image, puis un long glissement jusqu'au champ d'hypothèse et une touche précise sur une icône de 24 pixels à côté d'une autre presque identique. Avec un léger tremblement des mains, ou une force limitée dans un des membres, la tentative échoue trois fois avant même que l'hypothèse soit envoyée. Le raisonnement clinique était prêt. L'interface exigeait une précision motrice fine. C'est le terrain de l'accessibilité motrice dans les apps d'enseignement clinique et dans les jeux de diagnostic.

L'accessibilité motrice consiste à rendre l'interaction utilisable pour les personnes qui ont un tremblement, une limitation des membres, une force réduite, une moindre précision de toucher, une fatigue musculaire, ou qui opèrent avec un switch, un clavier, une trackball, une manette ou une entrée vocale. Cela vaut pour les étudiants et les médecins ayant un handicap physique permanent, et aussi pour ceux qui portent une attelle, sont en post-procédure, ont une douleur aiguë ou utilisent l'appareil d'une seule main en garde. Ce texte porte sur la conception d'apps et de plateformes d'enseignement : cibles de toucher, gestes, temps, glisser-déposer et alternatives d'entrée. Ce n'est pas une liste numérotée de normes techniques de logiciels médicaux, ni un guide sur les lecteurs d'écran (sujet d'un autre article de la série).

Points principaux

• Les barrières motrices dans les apps d'enseignement clinique incluent les petites cibles, les gestes à trajectoire obligatoire, le glisser-déposer sans alternative, les délais courts et la dépendance à une souris fine ou à un toucher précis.
• Principes utiles : cibles grandes et espacées, opération avec un seul pointeur, temps flexible, clavier et switch complets, annulation facile et équivalence entre toucher, clavier et entrée assistive.
• Les étudiants et les médecins ayant un handicap physique existent dans la formation ; les normes techniques fonctionnelles demandent le résultat clinique, pas un seul mode de pointage à l'écran.
• La taille des cibles et les alternatives aux gestes complexes reposent sur la recherche en interaction et sur les recommandations internationales d'accessibilité web et mobile.
• Dans NEXO, des cas fictifs avec une présentation clinique réelle et jusqu'à six indices en flux d'écran demandent une interaction avec les indices et les hypothèses ; une conception inclusive réduit la friction motrice sans affirmer d'efficacité.

Qu'est-ce que l'accessibilité motrice dans les apps d'enseignement

L'accessibilité motrice est l'ensemble des décisions d'interface qui permettent d'opérer une app sans dépendre de mouvements fins, rapides ou complexes. Dans l'enseignement clinique numérique, cela couvre le toucher des indices, l'ouverture des hypothèses, la confirmation de l'envoi, la navigation dans le diagnostic différentiel et la clôture du cas. Si la seule façon d'avancer est un geste de pincement suivi d'un glissement précis sous chronomètre, l'app mesure la dextérité numérique, pas seulement le raisonnement.

Ne pas confondre avec l'accessibilité cognitive (langage, charge, retour) ni avec l'accessibilité visuelle (lecteurs, contraste, agrandissement). Un cas peut être cognitivement clair et rester inaccessible à qui ne peut pas garder le doigt stable sur une cible minuscule. Ce n'est pas non plus le même axe que l'article sur l'accessibilité numérique dans les logiciels médicaux, centré sur les critères généraux de logiciels cliniques, ni celui sur les technologies assistives pour les médecins ayant une déficience visuelle. Ici, le problème est moteur : tremblement, force, amplitude, usage d'un switch et équivalence d'entrée.

Dans la formation médicale, les étudiants en situation de handicap physique et sensoriel existent, même si la communication et les aménagements restent incohérents. Dans une analyse nationale des normes techniques des écoles de médecine, peu de documents soutenaient explicitement des aménagements raisonnables ; beaucoup étaient ambigus ou muets sur la responsabilité et sur le recours à des aides (Zazove et al., 2016). Une analyse éthique soutient que les normes "organiques" (exiger l'organe ou le geste sans aide) excluent des candidats capables selon des normes fonctionnelles, qui demandent le résultat de la tâche avec aménagement (McKee et al., 2016). Le parallèle pour les apps d'enseignement est direct : exiger "un toucher précis avec le pouce dominant" est une norme organique d'interface ; exiger "envoyer l'hypothèse" avec un clavier, un switch ou un toucher agrandi est une norme fonctionnelle.

La prévalence et la trajectoire comptent aussi pour qui conçoit un produit éducatif. Les données de prévalence et d'aménagements cliniques en éducation médicale montrent que le handicap à l'école de médecine n'est pas anecdotique (Meeks et al., 2020). Des études de cohorte sur la performance des étudiants en situation de handicap confirment qu'avec un accès adéquat, la trajectoire académique peut s'aligner sur celle des pairs ; le goulot d'étranglement est souvent une barrière d'environnement, pas un "manque d'aptitude" générique (Meeks et al., 2022). Les appels à l'action de la littérature demandent de supprimer les barrières structurelles et d'adopter des normes techniques inclusives (Marzolf et al., 2022 ; Kezar et al., 2019 ; Stauffer et al., 2022).

Pour l'étudiant, la question pratique est : "cette app me demande-t-elle un raisonnement clinique ou de viser un pixel ?". Pour qui conçoit des cas et des jeux, la question est : "chaque contrôle critique a-t-il un chemin opérable au clavier, au toucher large et avec un temps humain ?". Le reste de ce texte traduit cela en barrières et en remèdes concrets, avec un lien vers les types de jeux pour étudiants en médecine et vers l'apprentissage par cas.

Barrières motrices courantes dans l'interface

Dans les apps de cas et les jeux de diagnostic, les barrières motrices se répètent. Cibles petites et collées : icônes d'action côte à côte sans marge. Gestes de chemin obligatoires : pincement, glissement en courbe, multi-toucher. Glisser-déposer sans alternative toucher-pour-sélectionner et toucher-pour-déposer. Délais courts : l'écran expire si le doigt hésite. Contrôles uniquement dans le coin supérieur, difficiles à atteindre d'une seule main. Dépendance au survol de souris dans la version web. Confirmations destructrices sans annulation. Champs de texte qui ouvrent un clavier virtuel couvrant le bouton d'envoi.

Les guides d'accessibilité dans les jeux (par exemple la liste complète des Game Accessibility Guidelines) demandent le remappage des contrôles, d'éviter les gestes complexes obligatoires, de permettre un temps flexible et d'offrir des modes d'entrée alternatifs. En éducation mobile, des analyses de jeux éducatifs sur Android montrent que les interfaces fondées uniquement sur canvas exposent souvent une seule cible de la taille de l'écran au switch access, ce qui empêche le balayage élément par élément. Le point pour la médecine est le même : si la barrière est motrice, l'étudiant "rate" le cas sans avoir raté le diagnostic différentiel.

Liste objective des barrières à inspecter dans tout cas jouable :

• Boutons critiques plus petits que la zone confortable du doigt, sans padding cliquable.
• Actions qui n'existent que comme geste de chemin (glisser libre, pincement, cercle).
• Chronomètre ou expiration de session qui punit l'hésitation ou la correction d'un toucher.
• Parcours impossible uniquement au clavier (Tab, Entrée, flèches) dans la version web.
• Éléments non focalisables pour le switch access (ordre de focus cassé ou absent).
• Cibles destructrices (effacer, passer un indice) collées à la cible de confirmation.

Ces barrières touchent de façon inégale. Qui a un tremblement peut activer le voisin du bon bouton. Qui a une force limitée peut ne pas terminer un long glissement. Qui utilise une seule main se fatigue dans les gestes bilatéraux. Qui opère avec un switch a besoin que chaque contrôle soit une étape discrète du balayage. Qui est en mouvement (ambulance, couloir) subit le même effet : la main tremble et la petite cible devient une loterie. La conception inclusive ne "favorise" pas un groupe ; elle élargit ceux qui peuvent s'entraîner sur ce que le cas prétend mesurer.

Un test rapide de barrière motrice : essayez de parcourir le flux uniquement au clavier, puis uniquement au toucher grossier (articulation ou stylet épais), puis avec un rythme volontairement lent. Si un des chemins se casse, l'interface mesure la dextérité, pas le raisonnement. Corrigez les cibles, les gestes et le rythme avant d'ajouter du contenu clinique nouveau.

Autre signal : l'étudiant formule l'hypothèse à voix haute et échoue à l'enregistrer dans l'app. Dans ce cas, examinez la cible, le geste et le délai d'attente avant de conclure à une lacune de connaissances. L'article sur la lacune de connaissances ou de raisonnement traite du diagnostic éducatif ; ici, l'hypothèse est celle de l'utilisabilité motrice.

Cibles tactiles, espacement et précision

La taille de la cible est le premier remède concret. Les recommandations internationales d'accessibilité web préconisent, dans le critère renforcé de taille de cible, au moins 44 par 44 pixels CSS pour les entrées de pointeur, avec des exceptions pour les liens en ligne et les contrôles équivalents (W3C, Target Size Enhanced). Il existe aussi un minimum de 24 par 24 pixels CSS dans le critère de niveau AA le plus récent (W3C, Target Size Minimum). Dans les apps natives, les guides de plateforme parlent souvent d'environ 44 points (iOS) ou 48 dp (Android). Le nombre exact importe moins que la règle pratique : les cibles d'action clinique (envoyer une hypothèse, ouvrir un indice, confirmer) doivent être assez grandes pour un doigt tremblant ou un toucher avec le côté de la main.

Une recherche classique sur l'interaction mobile au pouce d'une seule main suggérait des cibles de l'ordre de 9 mm pour des tâches discrètes et sériées sans dégrader l'erreur ni la préférence (Parhi, Karlson et Bederson, 2006). Les notes techniques de la W3C sur la taille du toucher sur appareils mobiles traduisent des recommandations physiques de l'ordre de 9 mm par 9 mm, alignées sur cette ligne de preuves (W3C Mobile A11y TF, M002). Chez les utilisateurs ayant un handicap moteur sévère, les études d'interfaces tactiles montrent que la précision et le taux de réussite varient selon la région de l'écran et la taille de la cible ; le toucher (tapping) est souvent préféré aux gestes directionnels lorsque la taille est adéquate (Guerreiro et al., 2010).

L'espacement compte autant que la taille. Deux boutons de 44 pixels collés sans marge produisent une erreur de voisin. Laissez un espace inactif entre confirmer et annuler ; séparez "envoyer l'hypothèse" de "passer l'indice". Dans les listes d'hypothèses ou de codes, augmentez la hauteur de la ligne cliquable, pas seulement le texte visible. Le remplissage invisible compte dans la zone active.

Pratiques de cible dans un cas jouable :

• Boutons principaux avec une zone minimale généreuse (cible renforcée de 44 px CSS comme référence de conception).
• Marge claire entre les actions irréversibles et les actions courantes.
• Éviter les icônes uniquement dans le coin extrême de l'écran sans version accessible dans le flux principal.
• Sur le web, veiller à ce que le focus clavier dessine un contour visible sur le même contrôle élargi.
• Tester au pouce, avec un stylet épais et avec un tremblement simulé (toucher volontairement imprécis).

Cela n'"infantilise" pas l'app clinique. Les grandes cibles sont la norme d'un produit mature en santé numérique et en jeux sérieux. L'entraînement au diagnostic différentiel avec indices demande déjà de peser les constats avec soin ; du point de vue moteur, le même soin vaut pour le bouton qui enregistre le poids de l'hypothèse.

Gestes, glisser-déposer et pointeur unique

Les gestes de tracé et le multi-toucher sont des barrières classiques. Le critère de gestes de pointeur de la WCAG exige que les fonctionnalités reposant sur des gestes multipoints ou de tracé puissent être opérées avec un seul pointeur sans geste de tracé, sauf lorsque le geste est essentiel (W3C, Pointer Gestures). Traduction pour le jeu de diagnostic : si agrandir l'image est nécessaire, proposez des boutons de zoom plus et moins ; si ordonner les hypothèses est nécessaire, proposez des flèches ou un menu, pas seulement le glisser de cartes.

Le glisser-déposer apparaît dans plusieurs apps éducatives comme une métaphore "intuitive". Pour qui a un tremblement ou utilise un switch, glisser coûte cher : il faut maintenir la pression, suivre une trajectoire et relâcher sur la bonne cible. L'alternative accessible consiste à sélectionner d'un toucher et à confirmer la destination d'un autre toucher (ou avec Entrée au clavier). Le résultat pédagogique est le même ; l'exigence motrice baisse.

Correspondance utile entre gestes et alternatives :

• Pincement pour zoom : boutons + et −, ou curseur au clavier.
• Faites glisser pour révéler l'indice : bouton "indice suivant" avec un libellé clair.
• Faire glisser l'hypothèse vers la zone d'envoi : sélectionner l'hypothèse et le bouton "envoyer".
• Appui long pour le menu : bouton de menu visible ou raccourci clavier.
• Deux doigts pour la rotation de l'image : boutons de rotation à 90°.

Les directives d'accessibilité mobile du W3C rappellent que les gestes complexes peuvent être impossibles pour une partie des utilisateurs et que la conception doit offrir des options équivalentes (W3C, Mobile Accessibility Mapping). Dans la ludification en éducation médicale, la pression du temps et les gestes "amusants" n'aident que lorsqu'ils ne deviennent pas une barrière à l'entrée. Un plaisir qui exclut ceux dont la main tremble n'est pas un plaisir inclusif.

Il existe une distinction utile entre difficulté souhaitable et barrière inutile. Récupérer une hypothèse en mémoire est une difficulté souhaitable (voir aussi l'article sur les difficultés souhaitables). Réussir un geste de pincement sous un tremblement est une barrière inutile. L'accessibilité motrice supprime la seconde sans effacer la première.

Temps d'interaction et délais d'expiration

Un temps rigide introduit une variance qui n'est pas une compétence clinique : vitesse de visée, tremblement sous anxiété, besoin de repositionner le contacteur. Dans les applications d'enseignement, les délais d'expiration de session, les messages qui disparaissent seuls et les chronomètres qui closent le cas pénalisent ceux qui ont besoin de plus de temps moteur, pas seulement ceux qui pensent plus lentement.

Principes alignés sur l'accessibilité temporelle : permettre de prolonger, d'ajuster ou de désactiver les limites de temps lorsque le contenu n'est pas une épreuve formelle synchronisée ; prévenir avant l'expiration ; conserver ce qui a déjà été saisi. Dans l'entraînement quotidien au raisonnement, la norme doit être le rythme propre. S'il existe un mode chronométré, proposez-le comme option avancée, annoncée avant de commencer.

Bonnes pratiques de temps dans un cas jouable :

• Mode par défaut sans compte à rebours agressif dans l'interaction.
• Pause qui gèle le cas sans perdre l'hypothèse en brouillon.
• Temps supplémentaire automatique ou configurable pour ceux qui utilisent une entrée assistée.
• Éviter les notifications trop rapides comme unique canal de retour d'erreur de toucher.
• Permettre de corriger un toucher accidentel sans redémarrer tout le cas.

Anxiété et hâte motrices se renforcent : le doigt se trompe davantage quand le chronomètre rouge clignote. Il y a un écho avec les discussions sur l'anxiété d'examen : une pression sans nécessité pédagogique mesure le stress, pas seulement les connaissances. Dans l'étude formative, la générosité de temps relève de la conception, pas de la "mollesse".

La métacognition intervient aussi après le cas : "ai-je raté le toucher ou raté l'hypothèse ?". Séparer les deux évite de blâmer le raisonnement pour une défaillance de l'interface. L'article sur la métacognition en Médecine approfondit cette habitude ; du point de vue moteur, la question d'après-cas doit inclure l'hypothèse d'une erreur de cible.

Clavier, contacteur et entrée alternative

Un clavier complet est le test de référence de l'opérabilité. Si la version web de l'application d'enseignement ne permet pas Tab entre les contrôles, Entrée pour activer, Échap pour fermer et les flèches dans les listes, ceux qui utilisent un clavier physique, un clavier à l'écran agrandi, un émulateur de souris par la tête ou un contacteur restent exclus. Le critère clavier des WCAG demande que toute fonctionnalité soit opérable au clavier sans exiger de temps spécifique par touche, sauf exceptions essentielles de parcours (W3C, Keyboard). Évitez le piège au clavier : le focus ne doit pas rester bloqué dans un composant.

L'accès par contacteur (balayage linéaire ou par point) dépend d'éléments focalisables dans un ordre logique. Les interfaces conçues uniquement en canvas avec un seul rectangle cliquable cassent le balayage : le contacteur "voit" tout l'écran comme un bouton. Dans les applications de cas, chaque indice, chaque hypothèse et chaque action d'envoi doit être un contrôle discret nommé. Testez avec les outils natifs de contacteur du système d'exploitation mobile avant de publier un nouveau mode.

Autres entrées alternatives courantes en pratique :

• Trackball et souris adaptée : ils nécessitent un clic simple, pas un glisser continu.
• Manette ou gamepad : utile lorsque les boutons physiques sont plus grands que les cibles tactiles.
• Entrée vocale pour le texte de l'hypothèse : complémentaire, pas unique voie si l'environnement est bruyant.
• Pédale ou bouton externe : mappable sur "indice suivant" et "envoyer" lorsque le système d'exploitation le permet.
• Mode d'acceptation du toucher avec délai (dwell) : l'application ne doit pas annuler le focus si le doigt a hésité une demi-seconde.

La perception de l'environnement d'apprentissage par les étudiants en situation de handicap s'améliore lorsque le programme d'accès est visible et fiable ; les barrières structurelles et la culture de la divulgation pèsent encore (Moreland et al., 2025). Dans le produit éducatif, l'équivalent consiste à documenter les chemins d'entrée (clavier, switch, toucher agrandi) de manière à être trouvés sans chasse au trésor. La page d'accessibilité du site est le lieu institutionnel pour orienter ; l'application elle-même doit respecter ce que la page décrit, sans transformer l'article en audit de déclaration.

Principes pratiques en tableau

Le tableau ci-dessous résume la correspondance entre barrière et réponse. Utilisez-le lors de la révision d'une application d'enseignement clinique, d'un cas jouable ou d'une activité sur tablette avant publication.

Barrière motrice	Ce que l'étudiant ressent	Réponse de conception
Cible petite ou collée	Active la voisine ; rate l'envoi	Cible large ; marge entre les actions
Geste de trajectoire obligatoire	Ne réalise pas le pincement ou la courbe	Bouton ou toucher équivalent
Glisser-déposer uniquement	Dépose au mauvais endroit	Sélectionner et confirmer en deux touchers
Délai court	Perd sa progression en hésitant	Rythme propre ; avertissement avant expiration
Pas de clavier complet	Switch et clavier s'arrêtent en cours de route	Tab, Entrée, Échap ; ordre de focus
Canvas sans contrôles discrets	Le balayage ne voit qu'un seul bloc	Contrôles nommés et focalisables
Action destructive à côté de la confirmation	Efface le cas par inadvertance	Séparer ; demander confirmation ; annuler

Ces principes s'alignent sur les recommandations W3C relatives aux cibles, aux gestes et au clavier, ainsi que sur les pratiques des jeux accessibles. Ils ne remplacent pas un test avec des utilisateurs qui emploient un switch, une trackball ou une seule main, mais évitent les erreurs les plus coûteuses avant le premier playtest. Les revues des normes techniques dans les nouvelles écoles de médecine montrent que le langage inclusif reste inégal (Stauffer et al., 2022) ; il en va de même pour les applications : l'intention inclusive doit apparaître dans le contrôle concret, pas seulement dans le texte institutionnel.

Le retour utile dans les cas cliniques a aussi un angle moteur : si le seul retour d'erreur est un flash de 200 ms sur une icône minuscule, celui qui a raté le toucher ne voit même pas le critère. Un retour stable en texte, avec le temps de lire et un grand bouton " compris ", boucle le cycle sans visée olympique.

Comment NEXO s'y inscrit

Dans NEXO, le déroulement du cas du jour présente des cas fictifs avec une présentation clinique réelle et jusqu'à six indices progressifs. Interagir avec les indices et avec le champ d'hypothèse est le cœur de l'exercice. Du point de vue moteur, la conception inclusive signifie : des cibles opérables, des chemins sans geste de pincement obligatoire, un temps qui ne punit pas l'hésitation, et une équivalence entre toucher et clavier sur le web. Aucune phrase ici n'affirme une efficacité ; elle décrit le type d'interaction qu'un jeu quotidien de diagnostic doit rendre accessible.

Ressources de l'écosystème liées à l'étude : NEXO Researcher pour approfondir des thèmes ; NEXO Closer lorsque l'objectif est de combler des lacunes ; limites d'usage dans Économie. La page d'accessibilité rassemble les orientations générales de la plateforme. Le texte qu'est-ce que NEXO situe le jeu sur la carte de l'enseignement clinique.

Comment utiliser le cas du jour avec un regard d'accessibilité motrice (sans promesse de résultat) :

• Préférez une tablette avec clavier ou un ordinateur de bureau si le toucher fin fatigue ; le flux web doit rester opérable au clavier.
• Augmentez le zoom du système d'exploitation si les cibles semblent petites ; vérifiez que la mise en page se réajuste sans masquer le bouton d'envoi.
• Si un toucher accidentel saute un indice ou ferme une fenêtre, mettez en pause et utilisez annuler ou rouvrez calmement ; ne transformez pas l'erreur motrice en " précipitation cognitive ".
• Rédigez l'hypothèse en texte court avant de viser l'envoi, pour séparer le raisonnement de la précision du toucher.
• Si la douleur, la fatigue ou l'exclusion par l'interface sont intenses, mettez en pause et cherchez l'aide nécessaire.

Comparaisons honnêtes : NEXO concentre les indices et l'envoi de l'hypothèse dans un flux unique ; les simulateurs avec de nombreux gestes de manipulation 3D et les banques avec des dizaines de micro-cibles demandent plus de précision motrice. Le choix du jour dépend de l'objectif. Pour s'entraîner au diagnostic différentiel avec peu d'indices, le format épuré convient. Pour s'entraîner à l'habileté manuelle en procédure, le laboratoire de simulation est un autre espace. Le principe partagé : mesurez le raisonnement, pas la tolérance aux cibles minuscules.

Ceux qui créent des cas pour des groupes (précepteurs, moniteurs, groupes d'étude) peuvent appliquer le tableau ci-dessus même en dehors de la plateforme : grands boutons dans des diapositives interactives, alternatives au glisser, temps flexible dans l'activité formative et retour avec critère. NEXO illustre une voie ; le standard d'accessibilité motrice vaut pour tout cas jouable sur tablette.

Pour les précepteurs qui utilisent le cas du jour en groupe : permettez à chaque étudiant d'enregistrer l'hypothèse à son propre rythme et sur son propre appareil adapté, et seulement ensuite discutez à voix haute. Évitez une station unique avec souris fine partagée comme seul moyen de participation. Le contenu clinique reste ; le protocole d'usage devient plus inclusif.

Avant de publier ou de jouer un cas avec un regard d'accessibilité motrice, passez par cette liste :

• Les boutons critiques ont-ils une cible large et une marge par rapport au voisin ?
• Toute action gestuelle a-t-elle un équivalent en toucher simple ou au clavier ?
• Le parcours web se complète-t-il avec Tab et Entrée, sans piège de focus ?
• Y a-t-il un mode sans timeout punitif ?
• Les contrôles sont-ils discrets et focalisables pour un switch ?
• Les actions destructrices sont-elles séparées et réversibles ?
• Le retour d'erreur reste-t-il à l'écran assez longtemps et sur une zone large ?
• Ai-je testé avec un toucher grossier et avec le clavier seul ?

Si un item échoue, corrigez la conception avant d'attribuer l'erreur à l'étudiant. Ensuite, entraînez-vous avec un cas complet dans le parcours réel.

Jouez le cas du jour.

Questions fréquentes

L'accessibilité motrice, est-ce la même chose que WCAG ?

Pas exactement. WCAG apporte des critères techniques (cible, geste, clavier) que cet article utilise comme principes. L'accent ici porte sur les applis et jeux d'enseignement clinique, pas sur un guide normatif complet de logiciel médical.

Des cibles larges ne rendent-elles pas l'interface "infantile" ?

Non. Des cibles généreuses sont la norme dans les produits de santé et les jeux accessibles. Vous changez la zone active et l'espacement, pas la rigueur clinique du cas.

Le glisser-déposer peut-il rester s'il existe une alternative ?

Oui. Gardez le glisser comme raccourci optionnel si vous voulez, à condition que sélectionner et confirmer par touchers ou au clavier fasse la même tâche.

Le switch access exige-t-il une appli native ?

Pas nécessairement. Il exige des contrôles focalisables et un ordre logique. Un canvas unique échoue souvent ; des boutons et champs réels fonctionnent souvent avec les outils du système.

Cela ne concerne-t-il que les personnes ayant un handicap permanent ?

Non. Attelle, douleur, fatigue, usage à une main pendant la garde et tremblement situationnel produisent des barrières similaires. Une conception inclusive bénéficie à la majorité.

Comment NEXO s'inscrit-il sans devenir une promesse de résultat ?

Comme environnement d'essai avec des indices et l'hypothèse à l'écran. Utilisez-le pour pratiquer l'habitude du raisonnement dans un format opérable ; pas comme preuve de dextérité ni comme traitement.

Références

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/