Liste de contrôle WCAG 2.2 pour créateurs de cours : chaque exigence expliquée

Créer un cours en ligne qui a l'air soigné et offre un excellent contenu n'est que la moitié du travail. Si les apprenants en situation de handicap ne peuvent pas percevoir vos vidéos, naviguer dans vos quiz ou comprendre vos instructions, votre cours est fondamentalement défaillant pour une partie significative de votre audience. Les Web Content Accessibility Guidelines (WCAG) 2.2, publiées par le W3C en octobre 2023, fournissent la norme technique définitive pour rendre le contenu numérique accessible. Cette liste de contrôle traduit chaque exigence pertinente du WCAG 2.2 Niveau AA en actions concrètes que les créateurs de cours en ligne et les concepteurs pédagogiques peuvent mettre en œuvre immédiatement.

WCAG 2.2 organise ses 56 critères de succès sous quatre principes, connus par l'acronyme POUR : Perceptible, Utilisable, Compréhensible et Robuste. Chaque principe aborde une dimension différente de l'accessibilité. Cet article passe en revue les critères les plus pertinents pour les cours en ligne, explique ce que chacun signifie en pratique, fournit des conseils de mise en œuvre et signale les erreurs que les créateurs de cours commettent le plus souvent.

Utilisez ceci comme référence de travail. Imprimez-le, mettez-le en favori ou partagez-le avec votre équipe. Si vous créez des cours sur Eduspera, de nombreux contrôles sont automatisés grâce à la note d'accessibilité intégrée de la plateforme — mais comprendre les exigences sous-jacentes fait de vous un meilleur créateur de cours, quels que soient les outils que vous utilisez.

Principe 1 : Perceptible

Le contenu doit être présenté de manière à ce que tous les utilisateurs puissent le percevoir — que ce soit par la vue, l'ouïe ou le toucher. Pour les créateurs de cours, ce principe régit la manière dont vous gérez les images, les vidéos, l'audio, la couleur et la mise en forme du texte.

1.1.1 Contenu non textuel (Niveau A)

Ce que cela signifie : Chaque élément non textuel — images, diagrammes, graphiques, icônes, infographies — doit avoir une alternative textuelle qui transmet la même information. Les lecteurs d’écran ne peuvent pas interpréter les pixels ; ils lisent le texte alternatif que vous fournissez.

Comment mettre en œuvre pour les cours en ligne :

• Rédigez des attributs alt descriptifs pour chaque image dans vos supports de cours. Un diagramme montrant "Trois étapes du processus de design thinking : Empathie, Définir, Idéer" nécessite un texte alternatif qui nomme ces étapes, pas seulement "diagramme".
• Pour les infographies complexes, fournissez une description longue dans le texte environnant ou un lien vers une version textuelle détaillée.
• Les images décoratives (séparateurs visuels, motifs de fond) doivent utiliser un alt="" vide pour que les lecteurs d’écran les ignorent complètement.
• Les icônes utilisées comme boutons ou liens doivent avoir des étiquettes accessibles — soit du texte visible, soit des attributs aria-label.

Erreurs courantes :

• Utiliser des noms de fichiers comme texte alternatif (par exemple, alt="IMG_2847.jpg").
• Écrire un texte alternatif qui dit "image de" — le lecteur d’écran annonce déjà qu'il s'agit d'une image.
• Laisser le texte alternatif vide sur les images informatives, les rendant invisibles pour les utilisateurs de lecteurs d’écran.

1.2.2 Sous-titres (Prérequis) (Niveau A)

Ce que cela signifie : Toutes les vidéos préenregistrées avec audio doivent inclure des sous-titres synchronisés. Ce n'est pas négociable — les sous-titres ne sont pas un simple ajout pour les cours en ligne ; ils sont une exigence de base.

Comment mettre en œuvre pour les cours en ligne :

• Utilisez des outils de transcription AI (comme OpenAI Whisper) pour générer des sous-titres initiaux, puis révisez-les et corrigez-les manuellement. Les sous-titres automatisés atteignent généralement une précision de 90-95 %, mais les 5 % restants concernent souvent la terminologie technique, les noms propres et le jargon spécifique au domaine — exactement les mots que vos apprenants doivent comprendre.
• Assurez-vous que les sous-titres sont synchronisés avec l'audio — le timing est important. Un sous-titre qui apparaît deux secondes en retard perturbe l'expérience d'apprentissage.
• Incluez l'identification des locuteurs lorsque plusieurs personnes parlent.
• Sous-titrez les effets sonores significatifs (par exemple, "[applaudissements]", "[téléphone qui sonne]") qui contribuent à la compréhension.

Erreurs courantes :

• Se fier uniquement aux sous-titres générés automatiquement sans les réviser.
• Utiliser des sous-titres incrustés (ouverts) avec un faible contraste ou de petites tailles de police.
• Omettre les sous-titres sur les vidéos "courtes" — l'exigence s'applique à toutes les durées.

1.2.5 Audiodescription (Prérequis) (Niveau AA)

Ce que cela signifie : Lorsque votre vidéo montre des informations visuelles qui ne sont pas décrites dans la piste audio — comme du texte à l'écran, des démonstrations ou des transitions visuelles — vous devez fournir une audiodescription de ces éléments visuels.

Comment mettre en œuvre pour les cours en ligne :

• L'approche la plus simple : narrez tout ce que vous montrez. Si vous démontrez une interface logicielle, décrivez ce sur quoi vous cliquez et ce qui apparaît à l'écran au fur et à mesure. Cette technique, appelée "vidéo auto-descriptive", élimine le besoin d'une piste d'audiodescription séparée dans la plupart des contextes pédagogiques.
• Pour les vidéos où le contenu visuel est essentiel mais non narré (par exemple, une démonstration silencieuse ou un time-lapse), fournissez une piste d'audiodescription séparée ou une description textuelle étendue.

Erreurs courantes :

• Dire "comme vous pouvez le voir ici" sans décrire ce que "ici" montre.
• Se fier aux enregistrements d'écran sans narrer les actions effectuées.
• Afficher du code ou des formules à l'écran sans les lire à haute voix.

1.4.3 Contraste (Minimum) (Niveau AA)

Ce que cela signifie : Le texte doit avoir un ratio de contraste d'au moins 4.5:1 par rapport à son arrière-plan. Le texte de grande taille (18pt ou 14pt en gras) nécessite au moins 3:1. Cela garantit la lisibilité pour les utilisateurs ayant une basse vision ou des déficiences de la vision des couleurs.

Comment mettre en œuvre pour les cours en ligne :

• Vérifiez vos présentations, vignettes et overlays de texte à l'écran à l'aide d'un outil de vérification du contraste (par exemple, WebAIM Contrast Checker).
• Évitez de placer du texte sur des arrière-plans photographiques chargés — utilisez un overlay semi-transparente si nécessaire.
• Soyez particulièrement prudent avec le texte d'espace réservé dans les formulaires, souvent stylé en gris clair sur fond blanc et ne respectant pas les exigences de contraste.

Erreurs courantes :

• Utiliser des couleurs de marque qui semblent attrayantes mais ne respectent pas les ratios de contraste (courant avec les palettes pastel).
• Oublier de vérifier le contraste dans les états de survol, de focus et d'activité.
• Utiliser du gris clair pour le texte "secondaire" ou "moins important" — s'il s'agit de contenu lisible, il nécessite un contraste complet.

1.4.5 Images de texte (Niveau AA)

Ce que cela signifie : N'utilisez pas d'images pour afficher du texte lorsque la même présentation visuelle peut être obtenue avec du texte stylé réel. Les images de texte ne peuvent pas être redimensionnées, reformatées ou lues par les lecteurs d’écran sans texte alternatif.

Comment mettre en œuvre pour les cours en ligne :

• Utilisez du texte réel (HTML, stylé avec CSS) pour les titres, sous-titres, étiquettes et encarts plutôt que de les intégrer sous forme de graphiques.
• Lorsque des captures d'écran de texte sont nécessaires (par exemple, montrer un éditeur de code), fournissez le contenu textuel sous forme de bloc de code ou de transcription à proximité.

Erreurs courantes :

• Créer des diapositives de titre élaborées sous forme d'images plates au lieu d'utiliser du texte stylé.
• Utiliser des captures d'écran de code au lieu de blocs de code correctement formatés avec mise en évidence de la syntaxe.

1.4.11 Contraste non textuel (Niveau AA)

Ce que cela signifie : Les composants de l'interface utilisateur (boutons, champs de formulaire, indicateurs de focus) et les graphiques significatifs (icônes, éléments de graphique) doivent avoir un ratio de contraste d'au moins 3:1 par rapport aux couleurs adjacentes.

Comment mettre en œuvre pour les cours en ligne :

• Assurez-vous que les boutons de quiz, les barres de progression et les contrôles de navigation sont clairement visibles par rapport à leurs arrière-plans.
• Vérifiez que les couleurs des graphiques sont distinguables — ne vous fiez pas uniquement à la couleur pour différencier les séries de données. Ajoutez des motifs, des étiquettes ou des formes distinctes.

Erreurs courantes :

• Utiliser des bordures fines et peu contrastées sur les entrées de formulaire.
• Styliser les boutons désactivés de manière à les rendre indiscernables de l'arrière-plan.

Principe 2 : Utilisable

Les utilisateurs doivent pouvoir naviguer et interagir avec votre cours en utilisant n'importe quelle méthode d'entrée — clavier, dispositif de commutation, commande vocale ou souris. Pour les créateurs de cours, ce principe régit la navigation, le timing et les éléments interactifs.

2.1.1 Clavier (Niveau A)

Ce que cela signifie : Chaque élément interactif — boutons, liens, champs de formulaire, contrôles vidéo, réponses de quiz, menus de navigation — doit être utilisable uniquement avec un clavier. Aucune fonctionnalité ne peut nécessiter exclusivement une souris ou un pavé tactile.

Comment mettre en œuvre pour les cours en ligne :

• Testez l'ensemble du flux de votre cours en utilisant uniquement la touche Tab (pour déplacer le focus), Entrée ou Espace (pour activer) et les touches fléchées (au sein des groupes). Si vous ne pouvez pas effectuer une action, cela échoue à ce critère.
• Les éléments interactifs personnalisés (accordéons, onglets, boîtes de dialogue modales) nécessitent des gestionnaires d'événements clavier appropriés — pas seulement des gestionnaires de clic.
• Assurez-vous que les lecteurs vidéo répondent aux raccourcis clavier : Espace pour lecture/pause, touches fléchées pour avancer, M pour couper le son.

Erreurs courantes :

• Construire des interactions de quiz par glisser-déposer qui n'ont pas d'alternative clavier.
• Utiliser des éléments <div> stylés comme des boutons sans role="button" et tabindex="0" — ils semblent cliquables mais ne peuvent pas recevoir le focus clavier.
• Créer des pièges à clavier où le focus entre dans une modal ou un lecteur vidéo mais ne peut pas en sortir sans souris.

2.1.2 Pas de piège à clavier (Niveau A)

Ce que cela signifie : Si le focus clavier peut se déplacer dans un composant, il doit pouvoir en sortir en utilisant l'interaction clavier standard (généralement Tab ou Échap). Les utilisateurs ne doivent jamais rester bloqués.

Comment mettre en œuvre pour les cours en ligne :

• Testez tout contenu intégré (lecteurs vidéo, simulations interactives, widgets tiers) en y accédant par tabulation et en vérifiant que vous pouvez en sortir par tabulation.
• Les boîtes de dialogue modales doivent piéger le focus à l'intérieur de la boîte de dialogue lorsqu'elles sont ouvertes, mais renvoyer le focus à l'élément déclencheur lorsqu'elles sont fermées via Échap ou un bouton de fermeture.

Erreurs courantes :

• Intégrer des widgets tiers (sondages, tableaux blancs, terrains de jeu de code) qui capturent le focus clavier sans fournir de mécanisme d'évasion.
• Boucles de tabulation infinies au sein de composants interactifs complexes.

2.4.7 Focus visible (Niveau AA)

Ce que cela signifie : Lorsqu'un élément reçoit le focus clavier, il doit y avoir un indicateur visible — généralement un contour ou un surlignage — pour que les utilisateurs de clavier puissent voir où ils se trouvent sur la page.

Comment mettre en œuvre pour les cours en ligne :

• Ne supprimez jamais le contour de focus par défaut du navigateur (outline: none) sans le remplacer par un style de focus personnalisé tout aussi visible ou plus visible.
• Utilisez un style de focus qui contraste bien avec les arrière-plans clairs et foncés. Un motif courant est un contour solide de 2px avec une couleur contrastante décalée par un petit espace.
• Testez la visibilité du focus sur chaque élément interactif : liens de navigation, boutons de leçon, options de quiz, contrôles vidéo.

Erreurs courantes :

• Ajouter *:focus { outline: none; } dans le CSS pour "nettoyer" le design — cette seule ligne casse l'accessibilité clavier sur l'ensemble de votre cours.
• Utiliser une couleur de focus qui se fond avec l'arrière-plan de l'élément.

2.5.7 Mouvements de glissement (Niveau AA) — Nouveau dans WCAG 2.2

Ce que cela signifie : Toute fonctionnalité utilisant un mouvement de glissement (cliquer-et-maintenir puis déplacer) doit également être réalisable par une action de pointeur unique sans glissement, sauf si le glissement est essentiel.

Comment mettre en œuvre pour les cours en ligne :

• Si vous avez des questions de quiz par glisser-déposer ("faites glisser l'étiquette vers la zone correcte du diagramme"), fournissez une alternative par menu déroulant ou clic pour sélectionner.
• Les listes de leçons réordonnables doivent prendre en charge des boutons "monter/descendre" en plus des poignées de glissement.

Erreurs courantes :

• Supposer que le glisser-déposer est la seule interaction intuitive — de nombreux utilisateurs ne peuvent pas effectuer de mouvements de glissement en raison de handicaps moteurs.
• Fournir une alternative clavier mais pas une alternative à un seul pointeur (clic/tap) — ce critère concerne spécifiquement l'entrée par pointeur, pas seulement le clavier.

2.4.4 Objectif du lien (dans le contexte) (Niveau A)

Ce que cela signifie : L'objectif de chaque lien doit pouvoir être déterminé à partir du texte du lien seul, ou du texte du lien avec son contexte environnant. Les utilisateurs de lecteurs d’écran naviguent souvent en tabulant à travers les liens — entendre "cliquez ici, cliquez ici, cliquez ici" est inutile.

Comment mettre en œuvre pour les cours en ligne :

• Rédigez un texte de lien descriptif : "Télécharger le projet (PDF, 2.3 MB)" au lieu de "Cliquez ici".
• Pour la navigation dans les leçons, utilisez le titre de la leçon comme texte de lien, pas des étiquettes génériques.

Erreurs courantes :

• Utiliser "En savoir plus" ou "Lire la suite" comme texte de lien sans contexte supplémentaire.
• Lier des URL brutes comme texte visible — elles sont illisibles par les lecteurs d’écran et difficiles pour tout le monde.

2.2.1 Durée ajustable (Niveau A)

Ce que cela signifie : Si votre cours inclut des activités chronométrées (quiz, évaluations), les utilisateurs doivent pouvoir désactiver, ajuster ou prolonger la limite de temps — avec au moins une de ces options disponibles.

Comment mettre en œuvre pour les cours en ligne :

• Pour les quiz chronométrés, offrez une option pour demander un temps prolongé ou désactiver complètement le chronomètre.
• Les diaporamas ou carrousels à avance automatique doivent avoir des contrôles de pause.
• Les expirations de session doivent avertir les utilisateurs avant l'expiration et permettre une extension.

Erreurs courantes :

• Coder en dur les minuteries de quiz sans aucune option d'ajustement — cela affecte de manière disproportionnée les apprenants ayant des handicaps cognitifs, des déficiences motrices ou utilisant des technologies d'assistance qui ralentissent la vitesse d'interaction.

Principe 3 : Compréhensible

Le contenu et le comportement de l'interface doivent être compréhensibles pour tous les utilisateurs. Pour les créateurs de cours, ce principe aborde la clarté du langage, la navigation cohérente et la manière dont votre cours gère les entrées des utilisateurs — en particulier dans les quiz et les formulaires.

3.1.1 Langue de la page (Niveau A)

Ce que cela signifie : La langue humaine par défaut de chaque page doit être déterminable de manière programmatique — généralement via l'attribut lang sur l'élément <html>. Les lecteurs d’écran utilisent cela pour sélectionner le moteur de prononciation correct.

Comment mettre en œuvre pour les cours en ligne :

• Assurez-vous que votre plateforme définit le bon attribut lang (par exemple, lang="fr" pour le français, lang="es" pour l'espagnol).
• Si votre cours contient des passages dans une langue différente, encadrez-les dans un span ou div avec l'attribut lang approprié pour que les lecteurs d’écran changent de prononciation.

Erreurs courantes :

• Utiliser lang="en" sur une page entièrement en espagnol — le lecteur d’écran tentera une prononciation anglaise sur des mots espagnols.
• Omettre complètement l'attribut lang, forçant le lecteur d’écran à deviner.

3.3.1 Identification des erreurs (Niveau A)

Ce que cela signifie : Lorsqu'un utilisateur commet une erreur de saisie (soumission d'un quiz, remplissage d'un formulaire), l'erreur doit être automatiquement détectée et décrite à l'utilisateur en texte. Le message d'erreur doit identifier le champ spécifique et décrire le problème.

Comment mettre en œuvre pour les cours en ligne :

• Lorsqu'une question de quiz est mal répondue, indiquez clairement quelle question contient une erreur et quel type de réponse est attendu.
• Pour les formulaires d'inscription ou de profil, affichez des messages d'erreur spécifiques à côté du champ concerné : "L'adresse e-mail doit inclure un symbole @" plutôt qu'une bannière générique "Entrée invalide" en haut de la page.
• Utilisez aria-describedby pour associer de manière programmatique les messages d'erreur à leurs champs de formulaire, afin que les lecteurs d’écran annoncent l'erreur lorsque le focus se déplace vers le champ.

Erreurs courantes :

• Indiquer les erreurs uniquement par la couleur (bordure rouge) sans texte — les utilisateurs qui ne peuvent pas percevoir la couleur manquent complètement l'erreur.
• Afficher un seul message "Il y a des erreurs dans votre soumission" sans spécifier quels champs nécessitent une correction.

3.3.2 Étiquettes ou instructions (Niveau A)

Ce que cela signifie : Les champs de formulaire et les composants interactifs doivent avoir des étiquettes ou des instructions qui décrivent l'entrée attendue. Chaque entrée de texte, menu déroulant, case à cocher et bouton radio a besoin d'une étiquette visible et associée de manière programmatique.

Comment mettre en œuvre pour les cours en ligne :

• Utilisez l'élément <label> avec un attribut for correspondant à l'id de l'entrée, ou encadrez l'entrée dans l'élément label.
• Pour les questions de quiz, assurez-vous que le texte de la question est associé de manière programmatique aux options de réponse en utilisant fieldset/legend ou aria-labelledby.
• Fournissez des indices de format là où c'est nécessaire : "Date de naissance (JJ/MM/AAAA)" ou "Le mot de passe doit comporter au moins 8 caractères."

Erreurs courantes :

• Utiliser le texte d'espace réservé comme seule étiquette — les espaces réservés disparaissent lorsque l'utilisateur commence à taper, les laissant sans contexte.
• Se fier à la proximité visuelle (l'étiquette apparaît près du champ) sans association programmatique.

3.2.3 Navigation cohérente (Niveau AA)

Ce que cela signifie : Les mécanismes de navigation qui apparaissent sur plusieurs pages (barre latérale du cours, navigation dans les leçons, barre de progression) doivent apparaître dans le même ordre relatif à chaque fois. Les utilisateurs construisent une mémoire spatiale de votre interface ; changer la disposition entre les pages les désoriente.

Comment mettre en œuvre pour les cours en ligne :

• Gardez votre navigation de cours (barre latérale, fil d'Ariane, boutons suivant/précédent) dans une position cohérente sur toutes les leçons.
• Si vous avez un indicateur de progression, assurez-vous qu'il apparaît au même endroit sur chaque page de leçon.

Erreurs courantes :

• Déplacer le bouton "Leçon suivante" du bas du contenu sur certaines pages vers le haut sur d'autres.
• Afficher différents éléments de navigation sur les pages de quiz par rapport aux pages de leçon sans raison claire.

3.3.8 Authentification accessible (Minimum) (Niveau AA) — Nouveau dans WCAG 2.2

Ce que cela signifie : Les processus d'authentification ne doivent pas nécessiter de tests de fonction cognitive (mémorisation d'un mot de passe, résolution d'un CAPTCHA, reconnaissance d'objets dans des images) à moins qu'une alternative accessible ne soit disponible. Les utilisateurs doivent pouvoir s'authentifier via des gestionnaires de mots de passe, des clés d'accès, copier-coller ou une authentification unique.

Comment mettre en œuvre pour les cours en ligne :

• Ne bloquez pas le collage dans les champs de mot de passe — cela empêche l'utilisation de gestionnaires de mots de passe.
• Prise en charge de la connexion OAuth/SSO (Google, Microsoft) comme alternative à l'authentification par mot de passe.
• Si vous utilisez des CAPTCHAs, fournissez une alternative audio ou utilisez des techniques de CAPTCHA invisibles qui ne nécessitent pas d'interaction utilisateur.

Erreurs courantes :

• Désactiver le collage sur les champs de mot de passe pour "sécurité" — cela réduit en fait la sécurité en décourageant l'utilisation de mots de passe forts et uniques.
• Utiliser des CAPTCHAs basés sur des images sans aucune alternative.

3.2.6 Aide cohérente (Niveau A) — Nouveau dans WCAG 2.2

Ce que cela signifie : Si votre plateforme fournit des mécanismes d'aide (informations de contact, liens FAQ, support par chat), ils doivent apparaître au même endroit relatif sur les pages.

Comment mettre en œuvre pour les cours en ligne :

• Placez votre lien d'aide/support à un endroit cohérent — généralement dans le pied de page ou un élément de navigation persistant.
• Assurez-vous que le mécanisme d'aide est disponible depuis le lecteur de cours, pas seulement le site principal.

Erreurs courantes :

• Fournir un widget de chat d'aide sur le site marketing mais le retirer de l'interface du lecteur de cours.

Principe 4 : Robuste

Le contenu doit être suffisamment robuste pour fonctionner de manière fiable avec les technologies d'assistance actuelles et futures. Pour les créateurs de cours, ce principe régit la structure HTML de votre cours et si les technologies d'assistance peuvent l'interpréter correctement.

4.1.2 Nom, rôle, valeur (Niveau A)

Ce que cela signifie : Chaque composant de l'interface utilisateur doit exposer son nom (étiquette), son rôle (quel type d'élément il est) et sa valeur ou état actuel aux technologies d'assistance. C'est ainsi que les lecteurs d’écran savent qu'un élément est un bouton, si une case à cocher est cochée ou quelle est la valeur actuelle d'un curseur.

Comment mettre en œuvre pour les cours en ligne :

• Utilisez des éléments HTML sémantiques : <button> pour les actions, <a> pour la navigation, <input type="checkbox"> pour les cases à cocher. Ceux-ci exposent automatiquement le rôle et l'état.
• Lors de l'utilisation de composants personnalisés, appliquez les rôles et propriétés ARIA appropriés : role="tabpanel", aria-selected="true", aria-expanded="false".
• Pour les indicateurs de progression de quiz, utilisez role="progressbar" avec aria-valuenow, aria-valuemin et aria-valuemax.

Erreurs courantes :

• Construire un lecteur vidéo personnalisé avec des boutons <div> sans rôles ARIA — les lecteurs d’écran ne peuvent pas les identifier comme interactifs.
• Utiliser aria-label qui contredit le texte visible — les utilisateurs de lecteurs d’écran entendent une chose tandis que les utilisateurs voyants en voient une autre.

4.1.3 Messages d'état (Niveau AA)

Ce que cela signifie : Les messages d'état — confirmations de succès, décomptes d'erreurs, mises à jour de progression — doivent être annoncés aux technologies d'assistance sans recevoir le focus. Les utilisateurs ne devraient pas avoir à chercher les changements sur la page.

Comment mettre en œuvre pour les cours en ligne :

• Utilisez des régions ARIA live (role="status" ou role="alert") pour les messages comme "Quiz soumis avec succès" ou "3 sur 10 questions répondues".
• Pour les mises à jour de progression en temps réel (progression de téléchargement, achèvement de leçon), utilisez aria-live="polite" pour que l'annonce n'interrompe pas l'activité actuelle de l'utilisateur.
• Pour les erreurs critiques, utilisez role="alert" qui déclenche une annonce immédiate.

Erreurs courantes :

• Afficher une notification de succès visible à l'écran mais non annoncée aux lecteurs d’écran.
• Utiliser aria-live="assertive" pour des mises à jour non critiques, provoquant des interruptions perturbatrices.

Structure HTML sémantique

Ce que cela signifie : Votre contenu de cours doit utiliser une sémantique HTML appropriée — titres (<h1> à <h6>) dans un ordre logique, listes pour les éléments listés, tableaux pour les données tabulaires et repères (<nav>, <main>, <aside>) pour les régions de page. Cela est fondamental pour le support des technologies d'assistance.

Comment mettre en œuvre pour les cours en ligne :

• Structurez votre contenu de leçon avec une hiérarchie de titres claire : un <h1> pour le titre de la leçon, <h2> pour les sections principales, <h3> pour les sous-sections. Ne sautez jamais de niveaux de titre.
• Utilisez <ul> ou <ol> pour les listes — les utilisateurs de lecteurs d’écran se fient à la sémantique des listes pour comprendre la structure et le nombre d'éléments.
• Encadrez votre navigation de cours dans un repère <nav> pour que les utilisateurs de lecteurs d’écran puissent y accéder directement.

Erreurs courantes :

• Utiliser du texte en gras pour simuler des titres — cela ressemble visuellement à un titre mais est invisible pour la fonction de navigation par titre des lecteurs d’écran.
• Emboîter le contenu dans des éléments <div> génériques sans signification sémantique.

Utilisation correcte de l'ARIA

Ce que cela signifie : Les attributs ARIA (Accessible Rich Internet Applications) complètent la sémantique HTML pour les widgets complexes. Cependant, une ARIA incorrecte est pire que pas d'ARIA — elle induit activement en erreur les technologies d'assistance.

Comment mettre en œuvre pour les cours en ligne :

• Suivez la première règle de l'ARIA : si vous pouvez utiliser un élément HTML natif qui a déjà la sémantique dont vous avez besoin, utilisez-le au lieu d'ajouter de l'ARIA à un élément générique.
• Si vous devez utiliser l'ARIA, suivez le Guide des pratiques d'auteur WAI-ARIA pour le modèle spécifique (onglets, accordéons, dialogues, etc.).
• Testez avec un lecteur d’écran — NVDA (gratuit, Windows), VoiceOver (intégré, macOS/iOS) ou TalkBack (intégré, Android).

Erreurs courantes :

• Ajouter role="button" à un <div> mais oublier d'ajouter des gestionnaires d'événements clavier — l'élément se déclare comme un bouton mais ne répond pas à Entrée ou Espace.
• Utiliser aria-hidden="true" sur du contenu visible et interactif — cela le cache des lecteurs d’écran alors qu'il reste visible à l'écran, créant une déconnexion confuse.

Liste de contrôle imprimable WCAG 2.2 pour les créateurs de cours

Utilisez cette liste de contrôle pour auditer le contenu de votre cours avant de le publier. Chaque élément correspond à un critère de succès spécifique du WCAG 2.2.

Perceptible

• ☐ Toutes les images ont un texte alternatif descriptif (1.1.1)
• ☐ Les images décoratives utilisent des attributs alt vides (1.1.1)
• ☐ Toutes les vidéos ont des sous-titres précis et synchronisés (1.2.2)
• ☐ Les vidéos avec des informations uniquement visuelles ont des audiodescriptions (1.2.5)
• ☐ Le ratio de contraste du texte est d'au moins 4.5:1 (1.4.3)
• ☐ Le ratio de contraste du texte de grande taille est d'au moins 3:1 (1.4.3)
• ☐ Le ratio de contraste des composants UI est d'au moins 3:1 (1.4.11)
• ☐ Du texte réel est utilisé au lieu d'images de texte (1.4.5)
• ☐ Le contenu est lisible lorsqu'il est zoomé à 200% (1.4.4)
• ☐ L'information n'est pas transmise uniquement par la couleur (1.4.1)

Utilisable

• ☐ Tous les éléments interactifs sont accessibles au clavier (2.1.1)
• ☐ Aucun piège à clavier n'existe nulle part dans le cours (2.1.2)
• ☐ L'ordre du focus suit une séquence logique (2.4.3)
• ☐ L'indicateur de focus est clairement visible sur tous les éléments (2.4.7)
• ☐ Le texte des liens décrit la destination ou l'objectif (2.4.4)
• ☐ Les titres des pages sont descriptifs et uniques (2.4.2)
• ☐ Le glisser-déposer a une alternative clic/tap (2.5.7)
• ☐ Les activités chronométrées peuvent être prolongées ou désactivées (2.2.1)
• ☐ Aucun contenu ne clignote plus de 3 fois par seconde (2.3.1)
• ☐ Un lien de navigation de saut est disponible (2.4.1)

Compréhensible

• ☐ La langue de la page est définie via l'attribut lang (3.1.1)
• ☐ Les erreurs de formulaire sont identifiées en texte avec des descriptions spécifiques (3.3.1)
• ☐ Tous les champs de formulaire ont des étiquettes visibles et associées (3.3.2)
• ☐ La navigation est cohérente sur toutes les pages (3.2.3)
• ☐ Les mécanismes d'aide apparaissent à un endroit cohérent (3.2.6)
• ☐ L'authentification ne nécessite pas de tests de fonction cognitive (3.3.8)
• ☐ Des suggestions d'erreur sont fournies lorsque possible (3.3.3)
• ☐ Le contenu utilise un langage clair et simple adapté au public

Robuste

• ☐ Les éléments HTML sémantiques sont utilisés correctement (4.1.2)
• ☐ Les composants personnalisés ont des rôles et états ARIA appropriés (4.1.2)
• ☐ Les messages d'état utilisent des régions ARIA live (4.1.3)
• ☐ Le contenu fonctionne avec les principaux lecteurs d’écran (NVDA, VoiceOver, JAWS)
• ☐ La hiérarchie des titres est logique et séquentielle
• ☐ Le HTML se valide sans erreurs critiques

Comment Eduspera automatise la conformité WCAG

Construire un cours accessible à partir de zéro est un effort considérable — mais cela ne doit pas être manuel. Eduspera intègre des vérifications d'accessibilité directement dans le flux de création de cours, détectant les problèmes avant qu'ils n'atteignent vos apprenants.

• Note d'accessibilité : Chaque cours reçoit une note d'accessibilité en temps réel basée sur des vérifications automatisées WCAG 2.2 AA. La note se met à jour à mesure que vous ajoutez du contenu, signalant immédiatement les textes alternatifs manquants, les problèmes de contraste et les problèmes structurels.
• Sous-titres alimentés par l'IA : Les vidéos téléchargées sur Eduspera sont automatiquement transcrites à l'aide de l'IA, générant des sous-titres que vous pouvez revoir et éditer directement dans la plateforme — répondant à SC 1.2.2 sans nécessiter d'outils ou de flux de travail séparés.
• Conception axée sur le clavier : L'ensemble du lecteur de cours — navigation, contrôles vidéo, quiz et suivi de progression — est construit avec une accessibilité complète au clavier dès le départ, non pas rétrofitée.
• Sortie HTML sémantique : Le contenu de cours rédigé dans l'éditeur de texte enrichi d'Eduspera produit automatiquement un HTML propre et sémantique avec une hiérarchie de titres appropriée, des structures de listes et des attributs ARIA.
• Moteur de quiz accessible : Les composants de quiz incluent des étiquettes appropriées, des messages d'erreur et une gestion du focus dès le départ, répondant à plusieurs critères WCAG (3.3.1, 3.3.2, 2.1.1, 4.1.2) sans nécessiter de connaissances techniques de la part des créateurs de cours.

L'objectif n'est pas de remplacer votre compréhension de l'accessibilité — cette liste de contrôle existe parce que comprendre les principes est important. L'objectif est d'automatiser les vérifications répétitives pour que vous puissiez vous concentrer sur la création d'un excellent contenu éducatif qui sert chaque apprenant. Lisez-en plus sur comment rendre les cours en ligne accessibles pour une perspective plus large sur la conception pédagogique accessible.

Questions fréquemment posées

Dois-je respecter le niveau A, AA ou AAA du WCAG pour mon cours en ligne ?

Le niveau AA du WCAG est la norme internationale reconnue pour la conformité à l'accessibilité web et est le niveau référencé par la plupart des législations, y compris l'Acte européen sur l'accessibilité, l'Americans with Disabilities Act (en pratique) et la Section 508. Le niveau A est le minimum absolu et est insuffisant pour la conformité. Le niveau AAA inclut des critères améliorés qui sont précieux mais pas typiquement requis — de nombreux critères AAA sont impraticables à appliquer universellement (par exemple, exiger une interprétation en langue des signes pour tout le contenu vidéo). Visez le niveau AA comme votre base, et adoptez des critères AAA individuels là où ils bénéficient à votre population d'apprenants spécifique.

Quels outils puis-je utiliser pour tester mon cours pour la conformité WCAG ?

Les outils automatisés détectent environ 30-40 % des problèmes WCAG. Utilisez axe DevTools (extension de navigateur), WAVE ou Lighthouse pour des analyses automatisées. Pour les 60-70 % restants, les tests manuels sont essentiels : naviguez dans votre cours en utilisant uniquement un clavier, testez avec un lecteur d’écran (NVDA sur Windows, VoiceOver sur macOS), vérifiez le contraste des couleurs avec le Contrast Checker de WebAIM, et demandez à des utilisateurs en situation de handicap de tester votre cours. Les plateformes comme Eduspera intègrent des analyses d'accessibilité automatisées directement dans le flux de création, détectant les problèmes courants avant la publication.

Puis-je adapter un cours existant pour la conformité WCAG, ou dois-je le reconstruire à partir de zéro ?

L'adaptation est presque toujours possible et généralement plus pratique que la reconstruction. Commencez par effectuer une analyse automatisée pour identifier les problèmes les plus courants — texte alternatif manquant, contraste insuffisant, champs de formulaire non étiquetés — car ceux-ci peuvent souvent être corrigés rapidement. Ensuite, abordez les problèmes structurels : hiérarchie des titres, navigation au clavier et gestion du focus. La correction la plus chronophage pour la plupart des créateurs de cours est l'ajout de sous-titres aux vidéos existantes, mais les outils de transcription AI ont considérablement réduit l'effort requis. Priorisez les corrections par impact : les barrières qui bloquent complètement l'accès (pièges à clavier, sous-titres manquants) doivent être corrigées en premier, suivies des problèmes qui dégradent l'expérience (contraste médiocre, texte alternatif manquant).