Déroulé du cas au lecteur d'écran : indices et hypothèses

Vous ouvrez le cas du jour avec le lecteur d'écran activé. L'énoncé annonce l'âge et le motif. Ensuite, le focus saute vers un bouton sans nom, puis vers un graphique décoratif, et l'« indice 1 » n'existe que sous forme de couleur dans le coin. Vous formulez une hypothèse, mais le champ de recherche indique seulement « modifier ». Le retour de proximité clignote en vert sans mot. La clôture existe à l'écran et disparaît à la parole. Ce texte parcourt le déroulé du cas jouable avec lecteur d'écran : indices (jusqu'à six), hypothèses, soumission, proximité, clôture et ce que l'interface doit annoncer et ordonner à chaque étape. Il se distingue du catalogue de technologie d'assistance visuelle (produits et lecteurs) et de la carte WCAG en accessibilité numérique dans les logiciels médicaux. Ici, l'objet est le parcours pédagogique à travers le cas, pas la liste de logiciels.

Rien dans cet article n'affirme l'efficacité de NEXO. Nous décrivons des principes de conception, des critères publics (W3C, recommandations pour des jeux accessibles) et des ressources vérifiées dans la déclaration d'accessibilité. Des cas fictifs à présentation clinique réelle, avec jusqu'à six indices, n'enseignent que si chaque étape du déroulé est lisible dans l'API d'accessibilité, pas seulement dans la mise en page visuelle.

Points principaux

• Le déroulé du cas comporte des étapes stables : ouverture, indice, hypothèse, soumission, proximité, indice suivant ou clôture ; le lecteur d'écran a besoin de noms, d'ordre et de landmarks à chacune.
• L'ordre de focus dans le DOM doit suivre la séquence pédagogique, pas le hasard du CSS ; le critère 2.4.3 des WCAG traite exactement de cela.
• Les indices progressifs (jusqu'à six) demandent un libellé avec numéro et contenu en texte réel ; révéler uniquement par animation ou couleur échoue à la parole et au braille.
• Les champs d'hypothèse et les boutons d'envoi ont besoin d'un nom accessible qui décrive l'action ; « modifier » et « OK » ne suffisent pas.
• La proximité et la clôture exigent un mot en plus de la couleur ; le détail de l'explication longue après la clôture est un autre moment du cycle (voir retour utile et la déclaration publique).
• Dans NEXO, la page /accessibility décrit les libellés des indices et du retour, le HTML sémantique et l'indépendance à la couleur dans la proximité ; sans affirmation de résultat d'apprentissage. Les limites d'usage, lorsqu'elles sont pertinentes, figurent dans /economia.

Carte du déroulé : de l'ouverture à la clôture

Dans un jeu quotidien de diagnostic, le cas n'est pas une page statique. C'est un parcours : vous lisez le contexte, recevez des indices à la demande, proposez des hypothèses, recevez une proximité et, en trouvant la bonne réponse ou en épuisant les tentatives, arrivez à la clôture. L'apprentissage par cas organise ce cycle autour d'un problème clinique concret (comment ça marche). S'entraîner au diagnostic différentiel avec des indices progressifs renforce le poids de chaque constatation (s'entraîner avec des indices). Avec un lecteur d'écran, le même parcours ne fonctionne que si chaque changement d'état est nommé et peut recevoir le focus.

Près de 6 % des étudiants en médecine aux États-Unis ont déclaré un handicap en 2021, plus du double de 2015, et demandent des aménagements qui incluent l'accès numérique (Huth et al., 2025 ; prévalence et aménagements : Meeks et al., 2020). Dans les cours de sciences en ligne, plus de la moitié des étudiants en situation de handicap ont signalé un aménagement inadéquat après la migration numérique ; les recommandations d'inclusion doivent être universelles, pas seulement individuelles (Gin et al., 2022). Des contenus interactifs testés avec un lecteur d'écran montrent que de nombreux types d'activité ne « fonctionnent » qu'en partie et demandent une alternative explicite (Böhm et Lux, 2025). Les ressources numériques pour la déficience visuelle demandent une description par lecteur, une navigation au clavier et le respect des directives W3C (Almeida et al., 2020).

Imaginez un cas fictif avec une présentation clinique réelle : jeune adulte avec douleur thoracique et dyspnée depuis quelques heures, jusqu'à six indices. L'indice 1 parle d'un début soudain ; l'indice 2 de la saturation ; l'indice 3 d'un constat d'examen. Vous montez et descendez des hypothèses (embolie, syndrome coronarien, pneumothorax, anxiété). Chaque étape doit exister dans l'arbre d'accessibilité : il ne suffit pas qu'elle apparaisse dans le rectangle de l'écran.

Les recommandations pour des jeux accessibles demandent une structure prévisible, des landmarks significatifs, des indicateurs de progression et la prise en charge du lecteur d'écran dans les menus et le gameplay (Game Accessibility Guidelines). Les WCAG traitent l'ordre de focus, les noms, les relations et les changements de statut (W3C, Focus Order 2.4.3 ; Info and Relationships 1.3.1). La carte mentale du parcours, pour qui écoute l'interface, est :

• Où je suis (titre du cas, numéro de l'indice, état "en cours" ou "fermé").
• Ce que je peux faire maintenant (révéler un indice, modifier une hypothèse, envoyer, signaler un problème).
• Ce qui vient de changer (nouvel indice, proximité, bonne réponse, erreur réseau).
• Où aller ensuite (explication, cas suivant, quitter).

La charge cognitive dans l'enseignement en santé demande déjà de réduire le bruit et de préserver la mémoire de travail pour ce qui enseigne (van Merriënboer et Sweller, 2010 ; Mayer, 2010). Chercher le bouton sans nom ou entendre "graphique" à la place de l'indice, c'est du bruit pur. Cela dialogue avec la métacognition : on ne surveille son propre raisonnement que si l'interface ne consomme pas toute l'attention.

En pratique, traitez le parcours comme un protocole mental au chevet du patient : anamnèse (énoncé), examen (indices), hypothèses, test (soumission), résultat (proximité) et plan (explication). Le précepteur qui observe le raisonnement à voix haute fait quelque chose de semblable. Le lecteur d'écran est cette voix haute automatique : si le protocole n'est pas nommé dans l'interface, la présentation du cas pour soi-même se brise en cours de route. C'est pourquoi les landmarks et les headings ne sont pas un détail d'ingénierie ; ils sont la colonne vertébrale du raisonnement clinique dans l'environnement numérique.

Avant le premier indice : page, landmarks et focus

Avant tout indice, le lecteur construit la carte de l'écran. Les landmarks (main, navigation, complementary) et un heading de niveau 1 avec le titre du cas permettent de sauter le chrome de l'app. Un skip link vers le contenu principal évite un Tab éternel dans le menu. Si le titre de l'onglet du navigateur est générique ("App"), la liste des fenêtres n'aide pas celui qui change de tâche pendant la garde.

L'ordre de focus initial compte. À l'ouverture du cas, le focus doit tomber sur le heading ou sur le premier bloc de l'énoncé, pas sur une bannière promotionnelle ni sur un modal oublié. Des éléments focalisables masqués visuellement, mais toujours dans le Tab, créent des "trous" silencieux. Les WCAG exigent que la séquence préserve le sens et l'opération (Focus Order). Dans les jeux et simulations web, une structure cohérente et une description du contexte orientent celui qui ne voit pas la scène (Floe, Web Games and Simulations).

Le clavier est le compagnon du lecteur : Tab, Shift+Tab, Entrée, Espace et flèches. Un focus visible doit exister pour ceux qui voient partiellement et pour ceux qui enseignent en regardant l'écran d'autrui. L'article sur l'accessibilité numérique situe le clavier et les noms dans le logiciel clinique ; ici, l'accent est mis sur la séquence du cas jouable.

Test rapide de cinq minutes à l'ouverture :

• Listez les headings : le titre du cas apparaît-il ?
• Listez les landmarks : y a-t-il un main avec l'énoncé ?
• Tabulez du haut jusqu'au bouton "révéler l'indice" sans piège.
• Confirmez que les images décoratives ont un alt vide et que les images cliniques ont un alt utile.

Les institutions d'éducation médicale communiquent encore l'inclusion de façon inégale sur leurs pages publiques (Ikedionwu et al., 2025). Dans le matériel d'étude, l'inclusion commence plus bas : dans le DOM du cas. L'obligation de rendre des comptes envers les étudiants en situation de handicap va dans le même sens (Meeks, Stergiopoulos et Petersen, 2022). Les barrières à la révélation chez les résidents montrent que beaucoup hésitent à demander un aménagement (Pereira-Lima et al., 2023) ; concevoir le parcours lisible par défaut réduit la dépendance à la demande juste pour "arriver à entendre l'indice 1".

La cohérence entre les sessions compte aussi. Si hier le focus s'ouvrait sur l'énoncé et qu'aujourd'hui il s'ouvre sur le classement, le modèle mental s'effondre. Enregistrer les préférences de lecture (quand le produit les propose) et garder la structure du cas stable réduisent la charge de réorientation. Les recommandations pour des jeux accessibles demandent une structure prévisible et des détails sur les fonctionnalités d'accessibilité visibles dans le produit et sur le site (Game Accessibility Guidelines) ; la déclaration sur /accessibility remplit la partie publique de cette demande dans NEXO, sans affirmer son efficacité.

Indices progressifs : ce que le lecteur doit entendre

Jusqu'à six indices progressifs sont le cœur de la méthode : l'information arrive par tranches, et le poids de chaque constat modifie le diagnostic différentiel. Pour le lecteur d'écran, une "tranche" doit être un bloc nommé. Des libellés du type "Indice 2 sur 6" accompagnés du texte clinique complet valent mieux que "nouveau contenu" sans contexte. Si l'indice n'est qu'une carte colorée avec une icône, la parole devient "bouton" ou "image".

Révélation à la demande : le contrôle "afficher l'indice suivant" doit avoir un nom accessible stable et, à l'activation, le focus doit aller vers le titre ou la région du nouvel indice. Évitez d'injecter le texte uniquement dans une région aria-live agressive qui lit tout le paragraphe sans contrôle. Préférez le focus sur le titre de l'indice et la lecture à la demande de l'utilisateur ; une live courte peut annoncer "Indice 2 disponible". La documentation sur les régions live recommande polite dans la plupart des cas (APG Alert ; MDN Live regions).

Les images cliniques dans l'indice (tracé, photo, compte rendu) demandent une alternative textuelle du constat qui compte, pas le nom du fichier. Les principes du multimédia demandent d'aligner mots et images (Mayer, 2010). Le double codage aide à l'étude quand texte et image se renforcent (double codage) ; si le constat essentiel n'est que dans la figure, l'indice disparaît pour qui écoute.

Les abréviations ("PA", "FC", "SpO2") perturbent la synthèse vocale. Les développer à la première mention dans l'indice réduit les épellations étranges. Des listes courtes dans l'indice ("pour", "contre") avec des titres ou des ul réels orientent mieux qu'un paragraphe unique de huit lignes.

La progression visible ("3 sur 6") a besoin d'un équivalent textuel. Une barre seulement visuelle échoue. Les recommandations pour des jeux accessibles demandent des indicateurs de progression et un renfort pas seulement textuel quand la consigne est critique (Game Accessibility Guidelines). Dans des MOOC conçus avec WCAG et une consultation des préférences, les utilisateurs de lecteur d'écran ont montré une association positive avec de bons résultats par rapport à ceux qui n'avaient pas déclaré de préférence ; ceux qui avaient une basse vision sans lecteur adéquat se trouvaient en désavantage relatif (Rodriguez-Ascaso et al., 2024). La conception de l'indice fait partie de cette équation.

Une pause diagnostique dans le raisonnement (pause diagnostique) a sa place entre les indices : un contrôle "revoir les indices précédents" avec une liste navigable évite que la mémoire de travail porte tout seule. L'éthique de la conception pédagogique demande déjà de ne pas pénaliser l'apprenant par le format (éthique dans la conception de jeux).

Hypothèses et soumission : noms accessibles et ordre

Formuler une hypothèse est le coup clinique du jeu : nom du diagnostic ou code. Le champ de recherche ou la combobox a besoin d'un label visible et associé ("Hypothèse diagnostique" ou "Code CIM"), pas seulement d'un placeholder qui disparaît à la saisie. Les résultats de la liste doivent être annonçables item par item, avec le nom complet du terme. Bouton d'envoi : "Envoyer l'hypothèse", pas "OK".

Ordre dans le formulaire : label, champ, aide courte ("vous pouvez chercher par nom ou par code"), puis envoyer. Messages d'erreur ("aucun résultat", "champ vide") en texte lié au champ, avec le focus déplacé vers l'erreur quand cela a du sens. Évitez de valider uniquement par la couleur de la bordure.

S'il existe une liste d'hypothèses récentes ou favorites, chaque item a besoin d'un nom distinct. "Bouton", "bouton", "bouton" dans la liste des contrôles est une faute classique. Il en va de même pour "retirer l'hypothèse" versus "envoyer".

Les travailleurs qui utilisent un lecteur d'écran au travail combinent souvent plusieurs lecteurs et signalent moins de difficultés lorsqu'ils disposent d'une solution de secours (McDonnall et al., 2025). Cela n'autorise pas à classer des produits ici : le catalogue et les pages officielles se trouvent dans l'article sur les technologies d'assistance visuelle. Dans ce parcours, l'essentiel est que l'interface du cas résiste à tout lecteur raisonnable : HTML sémantique, noms et focus.

La calibration de la confiance (calibration de la confiance) et l'écart entre manque de connaissances et manque de raisonnement (manque de connaissances ou de raisonnement) supposent que vous sachiez ce que vous avez envoyé. Si le lecteur ne confirme pas l'hypothèse choisie avant la touche Entrée, l'erreur devient du bruit. Un résumé "Vous allez envoyer : embolie pulmonaire" juste avant le bouton réduit les envois à l'aveugle.

Dans des cas fictifs à présentation clinique réelle, une hypothèse erronée reste instructive si le cycle de proximité et l'indice suivant restent audibles. Quand le champ avale le nom choisi ou que le bouton d'envoi disparaît de la tabulation après la première erreur, l'étudiant qui utilise un lecteur d'écran abandonne le cas non par manque de raisonnement, mais par défaut d'opération. Cela ressemble à un timeout moteur dans les applis d'apprentissage : la barrière n'est pas clinique. Concevoir un formulaire stable (mêmes noms, même ordre, mêmes messages) à chaque tentative relève de la conception pédagogique, pas seulement de l'ingénierie.

De la tentative à la clôture : proximité et explication

À chaque hypothèse, beaucoup de jeux de diagnostic renvoient une proximité : même chapitre, proche, éloigné. Ce retour court n'est pas l'explication longue de la clôture ; c'est le signal de navigation dans l'espace CIM. L'indépendance à la couleur est obligatoire : la déficience congénitale de la vision des couleurs est assez fréquente pour justifier un libellé textuel dans un support médical (PMID 10562750 ; pratique sûre : PMID 28731005). La communication scientifique documente déjà le mauvais usage de la couleur comme seul canal (PMID 33116149).

Pour le lecteur d'écran, la proximité a besoin d'un nom accessible complet : "Proximité : même chapitre" ou "Proximité : éloigné", pas seulement "statut" ou une icône. S'il y a une animation, elle ne peut pas être le seul canal ; respecter la préférence de réduction des animations évite la nausée et la distraction. Une live region courte et polie peut annoncer la proximité ; ne l'annoncez pas de nouveau à chaque re-rendu silencieux.

Dans l'éducation clinique, le feedback est une information sur la performance destinée à améliorer le cycle suivant (van de Ridder et al., 2008). Des méta-analyses montrent que l'effet dépend du type et du mode de transmission (Wisniewski, Zierer et Hattie, 2019). L'article sur l'explication utile approfondit le contenu et le timing du retour pédagogique. La ludification peut s'appuyer sur la précision et la constance sans dépendre de confettis sans libellé (données sur la ludification). L'évaluation formative vit de ce retour qui informe le cycle suivant (évaluation formative).

Après la proximité, le focus doit revenir à un point prévisible : le champ d'hypothèse (pour une nouvelle tentative) ou le bouton "indice suivant". Laisser le focus dans les limbes après l'annonce est l'une des erreurs les plus coûteuses en temps d'étude. Celui qui joue avec un lecteur d'écran reconstruit l'espace du diagnostic différentiel par la séquence des annonces ; si la proximité disparaît dans le silence, l'hypothèse suivante devient une tentative sans carte.

Clore le cas (réussite ou fin des tentatives) change le mode de l'écran. Le lecteur a besoin d'une annonce claire de l'état ("Cas clos : diagnostic cible disponible") et d'un heading qui ouvre la zone de résultat. Déplacer le focus vers ce heading est plus sûr que de déverser toute l'explication dans une live region. La transition de la tentative vers le débrief est le moment où beaucoup d'applis "oublient" l'API d'accessibilité : le visuel change de thème, les confettis montent, et l'arbre d'accessibilité reste sans heading ou avec le focus bloqué dans le modal.

L'explication longue après la fermeture (le pourquoi, les indices qui la soutenaient, le différentiel) est un problème de structure de document : titres, texte réel, liens nommés, tableaux avec en-tête. Cet axe pédagogique d'utilité du retour se trouve dans explication utile ; le soin apporté aux technologies d'assistance dans la prose d'après-case dialogue avec la déclaration sur /accessibility et avec le guide de technologie d'assistance visuelle, sans répéter un catalogue de produits. Ici, le point du parcours est la transition : du coup joué au débrief sans perdre l'utilisateur dans le silence ou le spam de publicités.

Les contrôles d'après-fermeture (rouvrir les indices, copier le résumé, signaler un problème, passer au cas suivant) entrent dans l'ordre de tabulation après le titre de résultat. Des noms descriptifs. S'il y a une fenêtre modale de célébration, elle doit pouvoir être fermée au clavier, avec un focus piégé de façon délibérée et restauré à la fermeture ; sinon elle devient un piège. Un scénario minimal de QA avec lecteur activé : envoyer une hypothèse erronée, écouter la proximité, révéler un indice, trouver la bonne réponse, écouter "cas fermé", tabuler jusqu'à "explication" et lire le premier titre du pourquoi.

Outils de l'écosystème d'étude après le cas : Researcher, Closer, Curator et Creators, toujours avec le même soin de nommage lorsqu'ils sont liés sur l'écran de résultat. Le même modèle de nom et de focus qui vaut pour l'indice vaut pour le lien de sortie : « Ouvrir Researcher » dit plus que « en savoir plus ».

Tableau : étape, annonce et erreur fréquente

Utilisez le tableau pour revoir le cas jouable avec un lecteur d'écran activé. Les contrastes sont techniques.

Étape du parcours	Ce que le lecteur doit entendre	Erreur fréquente	Réponse de conception
Ouverture du cas	Titre du cas ; landmark main ; énoncé	Focus sur la bannière ; titre générique	h1 + main ; lien d'évitement ; focus sur l'énoncé
Révéler un indice	"Indice N sur 6" + texte clinique	Couleur/animation seule ; bouton "bouton"	Nom du contrôle ; focus sur le titre de l'indice
Image dans l'indice	Alt du constat pertinent	Alt vide ou nom de fichier	Alt rédigé après avoir vu l'image
Champ d'hypothèse	Label + valeur choisie	Placeholder seul ; liste muette	label associé ; confirmation avant envoi
Envoyer	"Envoyer l'hypothèse"	"OK" / icône sans nom	Nom de l'action
Proximité	Mot du niveau (chapitre, proche, éloigné)	Vert/jaune/rouge seuls	Texte + icône nommée ; live court
Fermeture	État "fermé" + titre de résultat	Explication entière en aria-live	Focus sur le titre ; prose stable
Après-case	Actions suivantes nommées	Modale sans Échap ; focus perdu	Ordre de tabulation ; fermer et restaurer le focus

Après le tableau, demandez : si je n'entends que les titres, les landmarks et les noms de boutons, puis-je jouer le cas de l'énoncé à la fermeture ? Si la réponse est non, le parcours n'est pas encore accessible.

Comment NEXO s'inscrit dans tout cela

NEXO est un jeu quotidien de diagnostic avec des cas fictifs à la présentation clinique réelle et jusqu'à six indices progressifs. La page /accessibility déclare, entre autres points, des libellés descriptifs pour les éléments interactifs, les indices cliniques et le retour du jeu ; du HTML sémantique avec une hiérarchie de titres sur le site ; du contraste ; des alt sur les images significatives ; l'absence de média en lecture automatique ; et l'indépendance à la couleur des niveaux de proximité (couleur avec libellé textuel). La même page consigne des limitations connues sans en faire du marketing. Aucune phrase ici n'affirme que ces ressources améliorent la rétention, la note ou la performance clinique. C'est une description vérifiable.

Qui découvre la plateforme peut lire ce qu'est NEXO. L'apprentissage par cas situe la méthode (comment ça marche). Les limites d'usage, quand elles sont pertinentes, se trouvent dans /economia. L'angle de ce post est le parcours pas à pas avec un lecteur d'écran. Dans le même dossier, voir accessibilité cognitive, retour multimodal sur le coup joué, explication après diagnostic et comment écrire des cas cliniques inclusifs.

Questions fréquentes

Ce post remplace-t-il le guide de technologie d'assistance visuelle ?

Non. Les produits, les lecteurs et les pratiques cliniques de TA visuelle se trouvent dans technologie d'assistance visuelle. Ici, l'objet est le parcours du cas (indices, hypothèses, fermeture) et ce que l'interface doit annoncer.

Dois-je annoncer chaque indice entier en aria-live ?

En général, non. Un live court pour "indice disponible" ou la proximité ; le focus sur le titre ; la lecture du corps sous le contrôle de la personne qui utilise le lecteur.

L'ordre visuel peut-il diverger de l'ordre de focus ?

Seulement si la séquence préserve encore le sens et le fonctionnement. Dans le cas jouable, le parcours pédagogique (énoncé, indice, hypothèse, proximité, clôture) doit être celui de la touche Tab et de la lecture linéaire (WCAG 2.4.3).

La proximité uniquement par la couleur suffit-elle si le contraste est élevé ?

Non. Le contraste aide ceux qui voient ; il ne remplace pas un mot pour le daltonisme ni pour un lecteur d'écran. Couleur avec libellé textuel et, le cas échéant, icône nommée.

Quel est le lien avec l'explication après le diagnostic ?

Ce sont des moments distincts : la proximité est un signal court pendant le coup ; l'explication est un débriefing structuré. Utilité du retour : explication utile. Accessibilité numérique au sens large : logiciels médicaux.

Vaut-il la peine de tester avec un seul lecteur d'écran ?

Mieux vaut tester le parcours avec plus d'une combinaison de lecteur et de navigateur quand c'est possible ; des études auprès de travailleurs aveugles suggèrent de la prudence avec les outils (McDonnall et al., 2025). Sans classer les marques dans ce texte.

Liste de vérification finale

• Ouverture : h1 du cas, landmark main, skip link, focus initial sur l'énoncé.
• Indices (jusqu'à six) : contrôle nommé ; « Indice N sur 6 » ; texte réel ; alt clinique ; focus sur le nouvel indice.
• Hypothèse : label associé ; confirmation du terme ; bouton « Envoyer l'hypothèse ».
• Proximité : mot du niveau ; live court ; focus prévisible ensuite.
• Clôture : annonce d'état ; heading de résultat ; explication hors d'un live agressif.
• Après le cas : actions nommées ; modal fermable ; sans piège au clavier.
• Rien d'information uniquement par la couleur, uniquement par l'animation ou uniquement par l'image.
• Vérifier la déclaration sur /accessibility ; les limites sur /economia.

Jouez le cas du jour.

Références

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. Déficience de la vision des couleurs et couleur comme seul 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.