Le WordPress d'aujourd'hui, décodé pour les développeurs

Accessibilité

Une plateforme e-learning WordPress accessible : LMS, quiz et lecteurs d’écran

Douze modules, un quiz par module, un chronomètre visuel : trois éléments qui peuvent exclure un apprenant non-voyant si personne n'y pense en amont.

Par Clément Hadrot • 4 octobre 2024 • 5 min de lecture • Aucun commentaire
Une plateforme e-learning WordPress accessible : LMS, quiz et lecteurs d'écran

620 apprenants inscrits sur douze mois, dont quatorze ayant signalé un handicap visuel lors de leur inscription : c’est ce chiffre, remonté par le service formation d’un organisme certifiant, qui a déclenché l’audit d’accessibilité de leur plateforme e-learning bâtie sur WordPress avec un LMS tiers. Le constat de départ était optimiste : « nos contenus sont accessibles, ils sont écrits en HTML propre ». L’audit a montré que la structure textuelle n’était que la partie visible du problème.

Une plateforme de formation en ligne combine plusieurs briques d’interactivité qui, prises séparément, semblent anodines : un lecteur de progression, un minuteur, un système de quiz à choix multiples, une navigation entre modules verrouillée par ordre. Chacune de ces briques peut bloquer un parcours de formation si elle n’est pas pensée pour un usage clavier et lecteur d’écran. Voici ce qui a été trouvé et corrigé, module par module.

Le chronomètre qui n’existait que visuellement

Le module de quiz affichait un décompte en secondes dans un coin de l’écran, avec un changement de couleur du rouge au vert selon le temps restant. Ce décompte n’était porté par aucun texte accessible : un lecteur d’écran ne savait ni qu’un chronomètre existait, ni combien de temps il restait. Un apprenant non-voyant pouvait ainsi être exclu du quiz sans le savoir, découvrant la fin du temps imparti seulement au moment où la page se verrouillait.

La correction a consisté à ajouter une région live discrète, annoncée à intervalles espacés plutôt qu’à chaque seconde, pour ne pas noyer l’apprenant sous des annonces continues :

<div aria-live="polite" class="chrono-texte">
  Il reste 5 minutes pour répondre à ce quiz.
</div>

Le script associé ne met à jour ce texte qu’à des paliers précis (cinq minutes, deux minutes, trente secondes), et jamais à chaque tick, pour laisser l’apprenant se concentrer sur les questions plutôt que sur le compte à rebours.

La navigation entre modules bloquée par des liens désactivés visuellement

L'essentiel à retenir : Le chronomètre visuel doit avoir un équivalent annoncé ; La navigation entre modules doit rester prévisible au clavier ; Un score doit être lisible sans dépendre de la couleur seule

Les modules non encore débloqués étaient affichés en gris clair, avec un lien HTML classique conservé dans le code mais neutralisé par une classe CSS et un gestionnaire JavaScript qui annulait le clic. Un lecteur d’écran, lui, continuait de lire ces liens comme parfaitement activables : rien dans le balisage n’indiquait qu’ils étaient verrouillés. Un apprenant naviguant au clavier tombait ainsi sur des liens qui semblaient fonctionner mais ne menaient nulle part, sans explication.

La correction technique a consisté à remplacer le lien par un élément non interactif portant un état explicite lorsque le module est verrouillé, et à réserver la balise <a> aux seuls modules réellement accessibles :

  • Module débloqué : lien classique, focusable, menant au contenu.
  • Module verrouillé : élément <span> avec aria-disabled="true" et un texte explicite (« Module verrouillé, terminez le module précédent »).
  • Annonce du changement d’état dès qu’un module se débloque, via une région live dédiée à la progression.

Le quiz à choix multiples et l’association question-réponses

Le composant de quiz, fourni par le LMS tiers, générait des cases à cocher personnalisées en CSS pur, sans lien for/id entre le libellé de chaque réponse et son champ. Un lecteur d’écran annonçait alors « case à cocher, non cochée » sans préciser à quelle réponse elle correspondait. La solution n’a pas nécessité de changer de LMS : un filtre PHP sur le rendu HTML du quiz a suffi pour injecter les attributs manquants avant l’affichage final.

add_filter( 'lms_quiz_render_question', function( $html, $question ) {
    foreach ( $question->reponses as $i => $reponse ) {
        $id = 'reponse-' . $question->id . '-' . $i;
        $html = str_replace(
            '<input type="checkbox"',
            '<input type="checkbox" id="' . esc_attr( $id ) . '"',
            $html
        );
    }
    return $html;
}, 10, 2 );

Le score final illisible sans percevoir la couleur

Le résultat du quiz s’affichait comme un simple rond coloré : vert pour réussi, rouge pour échoué, sans aucun texte. Pour un utilisateur malvoyant ou daltonien, comme pour un lecteur d’écran, cette information était tout simplement absente. Le correctif a ajouté un texte systématique à côté du rond coloré, qui reste purement décoratif désormais :

ÉlémentAvantAprès
Résultat réussiRond vert seulRond vert + texte « Quiz réussi : 8/10 »
Résultat échouéRond rouge seulRond rouge + texte « Quiz à repasser : 4/10 »

Ce que retient l’équipe pédagogique

Le service formation a intégré ces points à sa grille de recette avant toute mise en ligne d’un nouveau module : présence d’un équivalent textuel pour chaque minuteur, vérification des liens de navigation avec le clavier seul, contrôle des associations label-champ sur chaque question, et lecture de chaque résultat par NVDA avant publication. Ce billet ne traite pas la conception pédagogique des contenus eux-mêmes : ces choix relèvent des formateurs et sortent du périmètre technique traité ici.

Notre verdict

Une plateforme e-learning WordPress n’a rien d’intrinsèquement inaccessible, mais elle concentre en un seul parcours plusieurs briques interactives sensibles au même titre qu’un site e-commerce. Traiter chacune séparément, avec des tests clavier et lecteur d’écran réguliers plutôt qu’un audit unique en fin de projet, évite qu’un apprenant abandonne un module sans que personne ne le sache.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi