Chapitre 12.2 — L’accessibilité native de Moodle

⏱️ TL;DR — Moodle a été conçu avec l’accessibilité comme objectif affiché et vise la conformité WCAG 2.1 AA. Concrètement, il fournit des aides précieuses côté couche 1 : un vérificateur d’accessibilité intégré à l’éditeur de texte, des thèmes accessibles, et des outils de rapport/audit sur les cours. Mais retiens la limite fondamentale : tous ces outils ne corrigent pas le contenu à ta place. Le vérificateur signale un alt manquant, il ne l’écrit pas. La responsabilité du contenu reste celle des auteurs.

🎯 Objectifs

• Savoir ce que Moodle apporte nativement en accessibilité.
• Connaître le vérificateur d’accessibilité de l’éditeur et ce qu’il détecte.
• Comprendre le rôle des thèmes accessibles et des rapports d’accessibilité.
• Distinguer clairement ce que la plateforme règle de ce qu’elle ne règle pas.
• Savoir quoi configurer et vérifier côté admin.

Une plateforme pensée pour l’accessibilité

Moodle affiche depuis longtemps l’accessibilité comme un objectif de conception et se donne pour cible la conformité WCAG 2.1 niveau AA (le standard légal ; voir Partie 2). Ça se traduit par des fondations correctes : structure HTML sémantique des pages, navigation au clavier, points de repère (landmarks), gestion du focus, et un souci du contraste dans les thèmes par défaut.

C’est la couche 1 de notre modèle : le logiciel. Choisir une plateforme qui prend l’a11y au sérieux, c’est partir avec une base saine — mais ce n’est que le début.

♿ Côté utilisateur — Sur une plateforme bien conçue, un utilisateur de lecteur d’écran peut sauter directement au contenu principal, lister les titres pour se repérer dans un cours, et manipuler les formulaires (connexion, dépôt de devoir) en entendant clairement chaque champ. Ces automatismes, invisibles pour un voyant, sont ce que Moodle vise à fournir de série.

Le vérificateur d’accessibilité de l’éditeur

L’aide la plus concrète au quotidien : l’éditeur de texte de Moodle (l’espace où un formateur rédige une page, une consigne, une description) intègre un vérificateur d’accessibilité. C’est un bouton dans la barre d’outils qui analyse le contenu qu’on vient de saisir et signale les problèmes courants, typiquement :

• des images sans texte alternatif ;
• un contraste de texte insuffisant ;
• des titres mal hiérarchisés (sauts de niveau) ;
• des tableaux sans en-têtes ;
• des liens peu explicites.

L’intérêt est énorme : il met l’accessibilité au moment de la création, là où c’est le moins coûteux à corriger, et il rend le formateur autonome. Mais garde en tête sa nature : c’est un assistant, pas un correcteur automatique.

⚠️ Piège — Croire que « le vérificateur est vert, donc mon cours est accessible ». Un vérificateur automatique ne détecte qu’une partie des problèmes (on estime généralement qu’un outil automatique couvre autour de 30 à 40 % des critères). Il voit un alt manquant, mais pas un alt inutile ou mensonger (« image1.png »). Il voit un contraste, pas si l’ordre de lecture a du sens. Le vert de l’outil ne remplace pas le jugement humain.

Thèmes accessibles

Le thème détermine l’apparence et une bonne part de l’accessibilité de couche 1 : contrastes, taille de texte, focus visible, responsive. Les thèmes modernes fournis avec Moodle sont conçus pour respecter les contrastes et la navigation clavier. Deux conseils :

• Pars d’un thème accessible plutôt que de le reconstruire. Si tu développes un thème sur mesure, tu hérites de la responsabilité a11y : contraste (voir Partie 7), focus visible, sémantique.
• Ne casse pas l’accessibilité par personnalisation. Une couleur de marque mal choisie, un focus supprimé « pour faire propre », une police trop fine : c’est le dev qui réintroduit les problèmes que le thème de base évitait.

Rapports et audit d’accessibilité

Au-delà de la page en cours d’édition, l’écosystème Moodle propose des outils qui auditent des cours entiers et produisent des rapports d’accessibilité : listes d’images sans alternative, de contrastes faibles, de titres mal structurés à l’échelle d’un espace de cours. Ces outils permettent à un admin ou à un référent a11y de prioriser les corrections sur un catalogue existant, plutôt que d’inspecter page par page.

Le principe qui compte, indépendamment de l’outil précis : passer d’une accessibilité « au coup par coup » à une démarche mesurable et pilotée, avec des indicateurs et un suivi dans le temps.

Ce que Moodle NE règle PAS

Le point le plus important du chapitre. Aucune fonctionnalité de plateforme ne peut :

• écrire un bon texte alternatif à la place du formateur (elle sait dire qu’il manque, pas ce que l’image raconte) ;
• rendre accessible un PDF déjà inaccessible que tu déposes (couche 3, voir 12.4) ;
• sous-titrer une vidéo correctement (l’auto-génération ne suffit pas, voir 12.5) ;
• remplacer un faux titre en gras par un vrai niveau de titre (voir 12.3).

Autrement dit : la plateforme fournit les outils, les auteurs fournissent l’accessibilité. Le contenu reste sous la responsabilité de ceux qui le créent.

Côté admin : configurer et vérifier

Quelques réflexes de gouvernance, sans dépendre d’une version précise :

• Choisir et maintenir un thème accessible, et vérifier ses personnalisations (contraste, focus).
• S’assurer que le vérificateur d’accessibilité est disponible dans l’éditeur pour tous les créateurs de contenu.
• Renseigner la déclaration d’accessibilité attendue par le RGAA (voir Partie 2).
• Mettre en place un audit régulier (rapports d’accessibilité) et un suivi des corrections.
• Former les formateurs — c’est l’objet des chapitres suivants.

💡 Réflexe — Sépare mentalement deux questions à chaque décision : « est-ce que la plateforme le permet ? » et « est-ce que le contenu le fait ? ». Moodle répond très bien à la première. La seconde, c’est ton chantier de dev-formateur, et c’est là que se gagne l’accessibilité réelle.

🧭 Sur A11yLearn — Pour A11yLearn, on a activé le vérificateur d’accessibilité dans l’éditeur pour tous les comptes formateur, choisi un thème accessible non modifié dans ses contrastes, et programmé un audit trimestriel des cours via les rapports d’accessibilité. Résultat : la couche 1 tient, et on a une liste priorisée des cours à reprendre — au lieu de découvrir les problèmes quand un apprenant se plaint.

✏️ Exercices

Exercice 1 — Vrai ou faux. « Le vérificateur d’accessibilité de Moodle est au vert sur ma page, donc elle est conforme WCAG AA. » Vrai ou faux, et pourquoi ?

Exercice 2 — Répartis les tâches. Sur une plateforme Moodle, classe ces actions en « la plateforme s’en charge » vs « c’est à l’auteur/au dev » : (a) fournir un focus visible sur les liens du thème, (b) écrire l’alternative d’un schéma dans un cours, (c) signaler qu’une image n’a pas d’alt, (d) baliser un PDF déposé.

🧠 Quiz de révision

Chapitre suivant : Créer du contenu accessible — outiller et former les formateurs.