Accessibilité numérique (RGAA/WCAG) dans l EdTech : obligations et implémentation

L'accessibilité numérique n'est pas un nice-to-have pour les plateformes de formation. C'est une obligation légale pour une partie significative du marché EdTech français, et un avantage concurrentiel pour le reste. Pourtant, la majorité des LMS et des plateformes de microlearning ne respectent pas les critères de base du RGAA.

Cet article couvre le cadre réglementaire, les critères techniques qui impactent les plateformes de formation, et les patterns d'implémentation à intégrer dès la conception.

---

Qui est concerné

L'obligation légale

En France, le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) s'impose à :

• Toutes les administrations publiques (État, collectivités, établissements publics)
• Les entreprises de plus de 250 millions d'euros de chiffre d'affaires
• Les organismes délégataires de mission de service public
• Les plateformes financées par des fonds publics (OPCO, CPF, France Travail)

Si votre plateforme de formation est déployée dans un de ces contextes, la conformité RGAA est obligatoire. Le niveau exigé est AA des WCAG 2.1 (Web Content Accessibility Guidelines), publiées par le W3C.

Au-delà de l'obligation

Même hors du périmètre légal, l'accessibilité est un critère de sélection croissant dans les appels d'offres EdTech. Les grands comptes l'exigent dans leurs cahiers des charges. Les organismes de formation certifiés Qualiopi doivent démontrer leur capacité à accueillir des personnes en situation de handicap, ce qui inclut l'accessibilité de leurs outils numériques.

Le marché de la formation professionnelle en France représente 25 milliards d'euros par an. Les entreprises et organismes soumis à l'obligation d'accessibilité représentent une part importante de ce marché. Développer une plateforme inaccessible, c'est se couper d'une partie de la demande.

---

Les critères RGAA qui impactent les plateformes de formation

Le RGAA compte 106 critères répartis en 13 thématiques. Tous ne sont pas pertinents pour une plateforme EdTech. Les critères suivants sont ceux que vous rencontrerez systématiquement.

Navigation au clavier

Chaque fonctionnalité de la plateforme doit être utilisable au clavier seul, sans souris. C'est le critère le plus fondamental et le plus fréquemment enfreint.

Ce que ça implique pour un LMS :

• Les menus de navigation, les boutons, les liens doivent être atteignables par tabulation
• L'ordre de tabulation doit suivre l'ordre visuel de la page
• Un indicateur de focus visible doit montrer à l'utilisateur où il se trouve
• Les modales, les menus déroulants et les tooltips doivent piéger le focus (focus trap) pour empêcher l'utilisateur de naviguer dans le contenu derrière la modale
• La touche Escape doit fermer les éléments superposés (modales, dropdowns)

Les pièges courants :

Les lecteurs vidéo custom. Si vous développez votre propre player vidéo, chaque contrôle (play, pause, volume, sous-titres, plein écran) doit être accessible au clavier. Utilisez un player avec accessibilité intégrée (video.js, Plyr) plutôt que de reconstruire les contrôles.

Les quiz interactifs. Les drag-and-drop, les sliders, les zones de clic sur image ne sont pas accessibles au clavier par défaut. Chaque interaction drag-and-drop doit avoir une alternative clavier (liste déroulante, boutons de déplacement).

Les éditeurs de contenu du back-office. Si votre éditeur WYSIWYG n'est pas accessible, les formateurs en situation de handicap ne peuvent pas créer de contenu. Testez l'éditeur au clavier seul.

Alternatives textuelles

Tout contenu non textuel (images, icônes, graphiques, vidéos) doit avoir une alternative textuelle qui transmet la même information.

Ce que ça implique pour un LMS :

• Chaque image a un attribut alt descriptif. Pour les images décoratives, alt="" (vide) les masque aux lecteurs d'écran.
• Les icônes fonctionnelles (bouton lecture, icône de progression, indicateur de statut) ont un aria-label qui décrit leur fonction.
• Les graphiques d'analytics (courbes de progression, diagrammes de complétion) ont une description textuelle accessible. Un graphique montrant "Taux de complétion : 78 %" doit transmettre cette information par un texte alternatif ou un tableau de données accessible.

Erreur fréquente : les badges et les indicateurs visuels de progression. Un cercle vert qui signifie "module terminé" n'a aucun sens pour un lecteur d'écran. Ajoutez un aria-label="Module terminé" ou un texte masqué visuellement mais lisible par les technologies d'assistance.

Sous-titrage et transcription vidéo

Les vidéos de formation doivent avoir des sous-titres synchronisés. Les sous-titres automatiques (YouTube, Whisper) sont un point de départ, mais le RGAA exige des sous-titres vérifiés pour les contenus essentiels à l'apprentissage.

Niveaux de conformité :

• Sous-titres synchronisés (A) : le texte apparaît en temps réel avec la vidéo. Utilisez le format WebVTT pour sa compatibilité navigateur.
• Audio-description (AA) : une piste audio supplémentaire décrit les éléments visuels importants (démonstrations, schémas affichés). C'est le critère le plus coûteux à implémenter pour les contenus de formation.
• Transcription textuelle (A) : le contenu intégral de la vidéo est disponible sous forme de texte consultable. Plus simple à produire que l'audio-description et utile pour la recherche full-text dans les contenus.

Sur une plateforme de formation, le sous-titrage a un bénéfice au-delà de l'accessibilité : les apprenants en open space ou en déplacement consultent les vidéos sans le son. Le sous-titrage augmente le taux de visionnage de 15 à 25 %.

Contrastes et lisibilité

Le ratio de contraste entre le texte et l'arrière-plan doit être d'au moins 4.5:1 pour le texte courant et 3:1 pour le texte de grande taille (18px ou 14px bold).

Ce que ça implique pour un LMS :

• Le texte gris clair sur fond blanc (#999 sur #fff → ratio 2.8:1) est non conforme. C'est pourtant la couleur par défaut de nombreux placeholders et textes secondaires.
• Les boutons avec du texte blanc sur fond coloré doivent respecter le ratio. Un bouton orange (#FF9900) avec du texte blanc (#fff) a un ratio de 2.5:1 : non conforme.
• Les indicateurs de progression par couleur seule (vert = terminé, rouge = échoué) ne sont pas accessibles aux daltoniens (8 % des hommes). Ajoutez un texte ou une icône en complément de la couleur.

Utilisez un outil de vérification des contrastes (axe DevTools, Lighthouse) dans votre pipeline de tests. Intégrez-le au CI pour éviter les régressions.

Formulaires et quiz accessibles

Les formulaires sont au cœur d'une plateforme de formation : inscription, quiz, questionnaires de satisfaction, formulaires de positionnement.

Règles de base :

• Chaque champ a un <label> visible associé via l'attribut for/id. Les placeholders ne remplacent pas les labels.
• Les messages d'erreur identifient le champ en erreur et décrivent le problème. "Erreur" n'est pas un message d'erreur accessible. "La réponse à la question 3 est obligatoire" en est un.
• Les champs obligatoires sont signalés autrement que par la couleur (astérisque + aria-required="true").
• Les quiz à choix multiples utilisent des <fieldset> et <legend> pour grouper les options de réponse.

Les quiz interactifs :

Les QCM standard (radio buttons, checkboxes) sont naturellement accessibles si les labels sont corrects. Les formats interactifs posent des problèmes spécifiques :

• Drag-and-drop : proposer une alternative avec des boutons "monter/descendre" ou des menus déroulants. Le rôle ARIA listbox avec aria-grabbed et aria-dropeffect existe, mais son support est inégal.
• Clic sur image (hot spots) : proposer une liste textuelle des zones cliquables avec leur description.
• Chronomètre : les quiz chronométrés posent un problème d'accessibilité. Proposez une option pour désactiver ou prolonger le chronomètre pour les apprenants qui utilisent des technologies d'assistance.

Documents téléchargeables

Les supports de formation téléchargeables (PDF, PPTX, DOCX) doivent être accessibles. Un PDF non balisé (issu d'un scan ou d'un export sans structure) est illisible par un lecteur d'écran.

Bonnes pratiques :

• Générez des PDF balisés (tagged PDF) avec une structure de titres, des alternatives textuelles pour les images, et un ordre de lecture logique.
• Si vous générez des attestations ou des feuilles de présence en PDF depuis votre plateforme, utilisez une bibliothèque qui produit des PDF accessibles (pdf-lib avec balisage, ou des templates HTML convertis en PDF via Puppeteer avec la bonne structure).
• Proposez une version HTML consultable en ligne en complément du PDF téléchargeable.

---

Intégrer l'accessibilité dans le développement

Dès la conception

L'accessibilité intégrée dès le design coûte 10 à 20 % du budget de développement. La remédiation d'une plateforme existante coûte 30 à 50 % du budget initial. La différence est suffisante pour justifier l'intégration dès le départ.

En pratique :

• Maquettes : vérifier les contrastes et la navigation au clavier dès la phase de design. Les outils de design (Figma) intègrent des plugins de vérification de contraste.
• Composants UI : utiliser une bibliothèque de composants avec accessibilité intégrée (Radix UI, Headless UI, React Aria). Ces bibliothèques gèrent les rôles ARIA, le focus management et la navigation clavier par défaut.
• Tests : intégrer axe-core dans les tests automatisés (jest-axe pour les tests unitaires, @axe-core/playwright pour les tests E2E). Chaque composant est testé pour la conformité WCAG.

Outillage recommandé

Outil	Usage	Intégration
axe DevTools	Audit dans le navigateur	Extension Chrome/Firefox
jest-axe	Tests unitaires a11y	CI (Jest)
@axe-core/playwright	Tests E2E a11y	CI (Playwright)
Lighthouse	Score accessibilité page	CI (lighthouse-ci)
WAVE	Audit visuel détaillé	Extension navigateur
Pa11y	Audit en ligne de commande	CI

L'intégration dans le CI empêche les régressions. Un test qui vérifie la conformité WCAG de chaque page critique (login, dashboard apprenant, quiz, vidéo) bloque le déploiement si un critère est enfreint.

Audit RGAA

Un audit RGAA complet (106 critères sur un échantillon de pages représentatives) est réalisé par un auditeur certifié. Il produit une déclaration d'accessibilité (obligatoire) et un plan d'action pour les non-conformités restantes.

Prévoyez l'audit 2 à 3 mois avant la mise en production. Les corrections prennent du temps, et certaines non-conformités nécessitent des choix de conception (alternative au drag-and-drop, format des quiz, gestion du chronomètre).

---

L'essentiel

L'accessibilité RGAA/WCAG dans l'EdTech n'est pas un projet séparé. C'est une contrainte de conception qui s'intègre dans chaque décision technique : choix des composants UI, format des quiz, player vidéo, génération de PDF, pipeline de tests.

Les priorités pour une plateforme de formation :

1. Navigation clavier complète — c'est le critère le plus impactant et le plus souvent enfreint
2. Sous-titrage vidéo — obligation légale et bénéfice UX pour tous les apprenants
3. Contrastes et indicateurs non-couleur — les plus simples à corriger en amont, les plus coûteux à corriger après
4. Quiz accessibles — alternatives clavier pour chaque interaction, labels corrects pour chaque champ
5. PDF balisés — attestations, feuilles de présence, supports de cours

Si vous développez une plateforme de formation et souhaitez intégrer l'accessibilité dès la conception, consultez notre page EdTech. Nous intégrons les contraintes RGAA dans l'architecture technique de nos projets dès la phase de cadrage.