Ce que WCAG 2.2 AA exige réellement d’une plateforme d’apprentissage

Si votre plateforme d’apprentissage s’adresse au public, à une administration, à une université ou à des salariés dans l’Union européenne, l’accessibilité n’est plus une option appréciable. C’est désormais une obligation légale assortie d’échéances, dont certaines sont suffisamment proches pour compter cette année.

Cet article explique ce que signifie concrètement « accessible » pour une plateforme d’apprentissage, qui doit se conformer à quelles règles et à quelle date, où ces plateformes échouent le plus souvent et la différence de coût réelle entre une accessibilité prévue dès le départ et une mise aux normes après l’arrivée d’une réclamation. Il s’adresse aux personnes qui doivent choisir entre développer et acheter, pas aux responsables conformité ; nous limiterons donc le jargon normatif. Une précision : il s’agit d’un guide pratique, pas d’un avis juridique. Lorsque des budgets et des échéances sont en jeu, faites confirmer vos obligations par un conseil compétent.

La version courte

La norme vers laquelle renvoient presque toutes les lois est WCAG, les Web Content Accessibility Guidelines, au niveau de conformité AA. WCAG comporte trois niveaux : A constitue le minimum, AA est celui qu’exigent réellement les autorités et AAA est un objectif ambitieux rarement imposé dans son intégralité.

La version actuelle est WCAG 2.2, publiée fin 2023. La plupart des textes citent encore la version 2.1, car ils ont été rédigés avant la sortie de la 2.2. Bonne nouvelle : WCAG 2.2 reprend presque entièrement la 2.1 et y ajoute quelques critères particulièrement pertinents pour les produits éducatifs. Concevoir pour WCAG 2.2 AA est donc la cible raisonnable. Vous respectez les règles actuelles tout en anticipant les suivantes.

L’accessibilité n’est pas une fonction que l’on ajoute. C’est une propriété de chaque écran, formulaire et interaction. Ce constat explique l’essentiel de ce qui suit, notamment pourquoi elle coûte peu au début et beaucoup après coup.

Qui doit se conformer, et quand ?

Il n’existe pas de règle mondiale unique. Plusieurs textes peuvent s’appliquer simultanément à la même plateforme. Voici ceux qui concernent le plus souvent l’apprentissage en ligne.

Quelques points méritent d’être soulignés.

L’échéance du secteur public américain est celle qui s’accompagne d’un compte à rebours. Le département de la Justice a fixé des dates fermes dans une règle prise au titre de l’ADA Title II. Les grandes entités publiques avaient jusqu’en avril 2026 et les plus petites jusqu’en avril 2027. Si vous vendez aux districts scolaires, community colleges ou universités d’État, vos acheteurs sont sur cette échéance et leurs services achats vous interrogent dès aujourd’hui.

Les entreprises privées ne sont pas exemptées. Aux États-Unis, aucune phrase de l’ADA ne dit explicitement qu’un site doit respecter WCAG. Les tribunaux ont toutefois considéré à plusieurs reprises que les sites et applications d’entreprises privées relevaient de l’ADA, et WCAG AA est devenu la référence pratique. La pression ne prend pas la forme d’une date, mais d’une mise en demeure adressée par un cabinet. L’edtech est particulièrement exposée, car son public comprend des apprenants en situation de handicap.

L’Union européenne a élargi le périmètre en juin 2025. Les universités publiques étaient déjà couvertes. L’Acte législatif européen sur l’accessibilité étend les obligations à une large part des services numériques privés destinés aux consommateurs. Si votre plateforme vend des cours en ligne à des personnes situées dans l’UE, ne supposez pas qu’elle échappe au texte.

Le même standard, WCAG AA, arrive donc par plusieurs voies. Construisez une fois pour le respecter et vous répondez à chacune.

WCAG en langage clair : quatre questions

WCAG s’organise autour de quatre principes, résumés par l’acronyme POUR : Perceptible, Utilisable, Compréhensible et Robuste. Sans le jargon, ils posent quatre questions simples à propos de votre plateforme.

• Perceptible. Une personne peut-elle accéder au contenu par plus d’un sens ? Une vidéo a besoin de sous-titres pour qui ne l’entend pas et d’une transcription pour qui utilise un lecteur d’écran. Une image porteuse de sens doit avoir une description textuelle.
• Utilisable. Peut-on tout faire sans souris ? Boutons, menus, quiz et commandes vidéo doivent fonctionner au clavier, car de nombreuses technologies d’assistance dialoguent avec la page de cette façon.
• Compréhensible. L’interface est-elle claire et prévisible ? Les libellés disent ce qu’ils font, les erreurs expliquent comment les corriger et l’écran ne se réorganise pas de façon inattendue.
• Robuste. Fonctionne-t-elle avec les technologies d’assistance ? La page doit permettre au lecteur d’écran d’annoncer correctement la nature, le nom et l’état de chaque commande.

Chaque critère précis ne fait que rendre l’une de ces questions concrète. Un rapport d’échec peut presque toujours être ramené à l’un des quatre principes.

Où les plateformes d’apprentissage échouent réellement

Les conseils généraux parlent de sites web. Une plateforme d’apprentissage pose des difficultés particulières : vidéo, quiz chronométrés, contenus tiers et longues sessions interactives. Les mêmes échecs reviennent audit après audit.

Leçons vidéo ou audio sans sous-titres ni transcription. C’est l’échec le plus fréquent en e-learning et un manquement clair au niveau A. Les sous-titres automatiques constituent un début, mais ne sont pas assez fiables seuls pour le vocabulaire technique, les noms propres ou les accents.

Minuteurs de quiz impossibles à adapter. Un compte à rebours qu’on ne peut ni prolonger ni désactiver enfreint un critère WCAG sur le temps. Il désavantage aussi les utilisateurs de lecteurs d’écran et toute personne qui a besoin de davantage de temps. L’évaluation est le point de rencontre entre accessibilité et équité ; voyez aussi comment concevoir des évaluations qui résistent à la triche.

Questions par glisser-déposer utilisables uniquement à la souris. Les activités d’association et de classement sont souvent conçues sans solution clavier. Un type de question entier devient alors inaccessible. WCAG 2.2 contient précisément un critère qui exige une alternative au glissement.

État indiqué uniquement par la couleur. Un point vert pour « terminé » et rouge pour « en retard » ne signifie rien pour qui ne les distingue pas. La couleur peut renforcer le message, jamais le porter seule.

Texte trop peu contrasté sur les couleurs de marque. Gris clair, ou blanc sur une teinte pastel, échoue régulièrement au ratio exigé. C’est l’un des résultats les plus fréquents des analyses automatiques et la conséquence d’une décision graphique prise sans contrôle du contraste.

Composants personnalisés sans nom ni rôle. Barres de progression, accordéons, onglets et fenêtres modales construits avec des éléments génériques ne donnent aucune information utile au lecteur d’écran. L’utilisateur entend « bouton » sans savoir à quoi il sert, ou n’entend rien. Voilà le principe Robuste en échec.

Pièges clavier et focus invisible. Si l’apprenant peut entrer au clavier dans un lecteur vidéo ou une fenêtre, mais ne peut plus en sortir, il est bloqué. Si l’indicateur visuel de focus a été supprimé, il ignore où il se trouve.

Le contenu dans le contenu. Votre plateforme peut être accessible tandis que le module SCORM, le cahier PDF ou les diapositives intégrées ne le sont pas. Un lecteur d’écran ne peut lire ni un PDF non balisé ni un module SCORM mal conçu. Votre conformité ne dépasse jamais celle du contenu le moins accessible servi par la plateforme, et une grande partie de ce problème relève des contenus, pas du code.

Défis de connexion et cibles tactiles minuscules. WCAG 2.2 ajoute deux règles particulièrement pertinentes : l’authentification ne doit pas imposer un test de mémoire ou un puzzle, et les cibles interactives doivent être assez grandes pour être activées de manière fiable, notamment sur téléphone.

Le vrai coût : intégrer ou réparer

Voici ce que peu de fournisseurs disent clairement : l’accessibilité coûte peu lorsqu’elle fait partie de la construction, et cher lorsqu’elle devient un chantier de réparation.

La raison est structurelle. Elle vit dans les composants : balisage sémantique, libellés corrects, gestion du focus et sous-titrage dans le flux de contenu. Lorsqu’une équipe adopte ces habitudes dès le premier composant, le surcoût reste faible et relève surtout de la discipline et des tests. Le travail se fond dans le coût normal d’un produit bien construit.

La mise aux normes tardive est un autre projet. Un même bouton peut déjà être utilisé sur quarante écrans. Le corriger une fois les améliore tous, mais il faut ensuite retester les quarante, chaque type de quiz, chaque fenêtre et chaque page dont l’ordre de focus n’a jamais été pensé. Vous ne rajoutez pas une fonction : vous rouvrez les fondations d’un système en production, dans la pire position possible pour négocier avec une échéance juridique.

C’est la même leçon que pour la sécurité des données étudiantes : les propriétés architecturales coûtent peu avant le lancement et cher après. Sécurité et accessibilité échouent discrètement pour la même raison. Invisibles lorsqu’elles fonctionnent, elles perdent les arbitrages face aux fonctions visibles, jusqu’au jour où leur absence devient très publique. Si vous envisagez un développement, l’accessibilité appartient au périmètre dès le départ et fait partie de ce qui détermine réellement le prix d’une plateforme e-learning.

Comment évaluer votre situation aujourd’hui

Un audit formel n’est pas nécessaire pour obtenir un premier diagnostic honnête. Quatre passages feront ressortir l’essentiel.

1. Lancez une analyse automatique. axe, WAVE ou le contrôle d’accessibilité de Lighthouse repèrent en quelques minutes les contrastes, libellés manquants et problèmes de structure. Le résultat est un plancher, pas un verdict : ces outils ne détectent qu’environ un tiers à la moitié des vrais problèmes.
2. Rangez la souris. Terminez une leçon et un quiz uniquement au clavier : Tab pour avancer, Entrée et Espace pour agir, flèches dans les menus. Si vous êtes bloqué ou perdu, un utilisateur au clavier le sera aussi.
3. Activez un lecteur d’écran. VoiceOver est fourni avec chaque Mac et NVDA est gratuit sous Windows. Fermez les yeux et parcourez une leçon. La première fois est inconfortable et plus instructive que n’importe quel rapport.
4. Contrôlez séparément la couche de contenu. Ouvrez un module SCORM, un PDF et une vidéo représentatifs. Vérifiez sous-titrage, balisage et navigation propres à chacun. Cette couche peut échouer même si la plateforme réussit.

Si vous achetez, ajoutez une cinquième étape : demandez le VPAT du fournisseur, parfois appelé Accessibility Conformance Report. Il décrit, critère par critère, le niveau de conformité du produit. Un éditeur incapable d’en fournir un — ou qui prétend être parfait sans la moindre réserve — vous apprend quelque chose dans les deux cas.

Ce que la « conformité » apporte — et n’apporte pas

Respecter WCAG 2.2 AA réduit l’exposition juridique et, surtout, ouvre la plateforme à environ une personne sur six dans le monde, qui vit avec un handicap important. C’est une part considérable de tout public apprenant.

La conformité ne garantit toutefois pas une bonne expérience. Une plateforme peut cocher chaque critère et rester pénible avec une technologie d’assistance. La liste est un plancher, pas un plafond. Elle n’est pas non plus un certificat acquis une fois pour toutes. Chaque fonction, contenu et intégration tierce peut introduire un nouvel échec. Les équipes sérieuses traitent donc l’accessibilité comme une pratique permanente de conception et de contrôle, pas comme un nettoyage ponctuel.

La conclusion est la même que pour la sécurité et les données. Les propriétés qui protègent vos utilisateurs et votre entreprise sont des choix d’architecture pris tôt, tant qu’ils restent peu coûteux. Soit vous placez l’accessibilité dans les fondations maintenant, soit vous paierez pour reconstruire ces fondations plus tard, selon l’échéance de quelqu’un d’autre.