Un module inaccessible exclut des apprenants sans que personne ne le remarque. Une personne malvoyante qui ne peut pas lire un texte gris clair, une autre qui utilise un lecteur d'écran et entend « image 47 point png » : aucune des deux ne remontera forcément le problème. Elles abandonneront le module, ou le valideront sans l'avoir compris.
Un audit d'accessibilité complet est un travail de spécialiste. Les sept contrôles de cet article n'en sont pas un. Ils couvrent les défauts les plus courants, se vérifient sans compétence technique et se corrigent, pour la plupart, sans rouvrir l'outil auteur.
Le cadre, en deux phrases
La référence internationale est WCAG, les règles pour l'accessibilité des contenus web publiées par le W3C. En France, le RGAA en est la déclinaison pour les services publics et certaines grandes entreprises. Un module e-learning est un contenu web : ces règles s'y appliquent.
Contrôle 1 : la langue est déclarée
Un lecteur d'écran choisit sa voix d'après la langue déclarée dans la page. Sans déclaration, un texte français peut être lu avec une prononciation anglaise, ce qui le rend incompréhensible.
À vérifier. La langue du module est indiquée dans le code de la page. Un outil de contrôle vous le dit sans que vous ayez à ouvrir le fichier.
Contrôle 2 : les images ont un texte alternatif
Le texte alternatif est la phrase qu'un lecteur d'écran lit à la place de l'image. Sans lui, le lecteur annonce le nom du fichier, ou rien.
Trois règles d'écriture :
- Décrivez ce que l'image apporte au propos, pas ce qu'elle montre. « Schéma des trois étapes de la consignation » vaut mieux que « schéma ».
- Une image décorative reçoit un texte alternatif vide. Le lecteur d'écran l'ignore, et c'est le comportement voulu.
- Ne commencez pas par « image de ». Le lecteur d'écran l'annonce déjà.
C'est le défaut le plus répandu, et le plus long à corriger à la main sur un catalogue. Une IA peut proposer un premier texte pour chaque image, que vous validez.
Contrôle 3 : le contraste du texte est suffisant
WCAG demande un rapport de contraste d'au moins 4,5:1 entre un texte courant et son fond. Les défauts viennent presque toujours de la charte graphique : un gris clair sur blanc, un texte blanc sur une couleur de marque trop pâle, des intertitres colorés.
À vérifier. Mesurez vos couleurs de texte contre leur fond. Si la couleur de marque ne passe pas, utilisez-la pour les aplats et les boutons, et gardez une couleur sombre pour le texte.
Contrôle 4 : les boutons et les liens ont un nom
Un bouton qui ne contient qu'une icône (une flèche, une croix) n'a pas de nom pour un lecteur d'écran. Il faut lui en donner un : « Suivant », « Fermer », « Lire la vidéo ».
Même logique pour les liens. « Cliquez ici » ou « En savoir plus » ne disent pas où ils mènent quand on parcourt la liste des liens au clavier. Préférez un libellé qui se comprend seul : « Télécharger la procédure de consignation ».
Contrôle 5 : la quantité de texte par écran reste raisonnable
Un écran chargé gêne tout le monde, et davantage les personnes qui utilisent un zoom ou une synthèse vocale. Au-delà de 150 mots environ sur un même écran, la lecture devient pénible avec ces aides.
À vérifier. Repérez les écrans les plus longs. Découpez-les : un écran, une idée.
Contrôle 6 : les quiz ne dépendent pas de la position des réponses
« Toutes les réponses ci-dessus » perd son sens quand les réponses sont mélangées, et se comprend mal quand elles sont lues une à une par un lecteur d'écran. Même problème pour « la réponse de gauche » ou « l'image du haut ».
À vérifier. Relisez chaque question en imaginant qu'on vous la lit à voix haute, dans un ordre quelconque.
Contrôle 7 : chaque page a un titre
Le titre de la page est la première chose qu'un lecteur d'écran annonce, et c'est le nom de l'onglet du navigateur. Un module dont toutes les pages s'appellent « index » ou « Sans titre » désoriente dès l'ouverture.
Ce que ces contrôles ne couvrent pas
Soyons précis sur les limites. Ces sept points ne vérifient pas :
- la navigation complète au clavier, sans souris ;
- les sous-titres et la transcription des vidéos ;
- les interactions complexes (glisser-déposer, zones cliquables) ;
- le comportement réel avec un lecteur d'écran.
Pour ces points, faites tester le module par une personne qui utilise ces aides, ou par un spécialiste. Les sept contrôles réduisent le nombre de défauts ; ils ne constituent pas une déclaration de conformité.
Corriger sans tout republier
| Défaut | Correction possible dans le package publié |
|---|---|
| Langue non déclarée | Oui |
| Texte alternatif manquant | Oui pour beaucoup de packages |
| Texte trop long | Oui, en corrigeant le texte ; le découpage en écrans dépend de l'outil auteur |
| Contraste de la charte | Selon le package |
| Bouton sans nom, interaction non accessible | Le plus souvent dans l'outil auteur |
La frontière entre ce qui se corrige dans le package et ce qui demande l'outil auteur est détaillée dans Modifier un SCORM sans le fichier source.
Intégrer l'accessibilité à la recette
Le plus efficace est de ne pas en faire un chantier à part. Ajoutez ces sept points à votre recette de mise en ligne, décrite dans Tester un SCORM avant de le livrer, et inscrivez-les dans le cahier des charges de vos prestataires. Un défaut repéré avant la livraison ne coûte rien ; le même défaut, repéré sur tout un catalogue en ligne, devient un projet.
Questions fréquentes
Mon organisme est-il obligé de rendre ses modules accessibles ?
Cela dépend de votre statut et de votre taille. Vérifiez vos obligations auprès de votre service juridique. Indépendamment de l'obligation, un module accessible est plus lisible pour tous vos apprenants.
L'outil auteur ne s'occupe-t-il pas de l'accessibilité ?
Il fournit les moyens (champ de texte alternatif, ordre de lecture). Il ne les remplit pas à votre place.
Par où commencer sur un catalogue existant ?
Par les modules obligatoires et les plus suivis, et par les textes alternatifs et le contraste.
Pour situer ces contrôles dans la vie d'un module, voir le guide SCORM du responsable formation.
Contrôler un module en une minute
Scorm Editor contient un contrôle d'accessibilité qui relève ces défauts à l'ouverture d'un package : langue non déclarée, images sans texte alternatif, contraste insuffisant, boutons sans nom, liens vagues, écrans trop chargés. Le contrôle est gratuit, et vous saisissez les textes alternatifs à leur place, sans régénérer le module. Ouvrir Scorm Editor.