Accessibilité web — Devenir expert (a11y)
⏱️ TL;DR — L’accessibilité numérique (a11y), c’est faire en sorte que tout le monde puisse utiliser ce que tu construis — y compris les personnes aveugles, malvoyantes, sourdes, à mobilité réduite ou avec un handicap cognitif. Ce n’est ni une option, ni de la charité : c’est une exigence de qualité, une obligation légale (RGAA en France, Acte européen sur l’accessibilité depuis juin 2025), et un avantage concurrentiel. Ce cours te mène du principe (WCAG 2.2, ARIA) à la pratique (HTML sémantique, clavier, lecteurs d’écran, formulaires, composants) puis à l’application concrète (React/Next.js, Moodle), aux tests et à la mise en conformité. Objectif : que tu deviennes la personne « a11y » de référence de ton équipe.
À qui s’adresse ce cours
À toi : un développeur web (Next.js / React / TypeScript, mais les principes valent partout — Moodle, WordPress, HTML pur) qui veut maîtriser l’accessibilité pour de vrai, pas juste « mettre des alt et espérer ». Aucune connaissance préalable en a11y n’est requise ; à la fin, tu sauras auditer, corriger, construire accessible par défaut, et défendre le sujet dans ton organisation.
💡 Le pari central de ce cours — L’accessibilité n’est pas une couche qu’on ajoute à la fin. C’est une conséquence de bonnes fondations : du HTML sémantique, une navigation clavier qui marche, des noms et rôles corrects. 80 % de l’a11y, c’est « bien faire du web ». Les 20 % restants (ARIA, composants complexes, tests) sont ce qui sépare le dev sensibilisé de l’expert. Ce cours couvre les deux.
Ce que tu sauras faire à la fin
- Expliquer pourquoi l’accessibilité compte : les utilisateurs, l’éthique, le business, la loi.
- Maîtriser le cadre normatif : WCAG 2.2 (A/AA/AAA), WAI-ARIA, et le cadre légal FR/EU (RGAA, EAA).
- Construire sur des fondations solides : HTML sémantique, structure, landmarks, titres.
- Rendre tout utilisable au clavier et gérer le focus proprement.
- Comprendre les lecteurs d’écran et l’arbre d’accessibilité (name / role / value).
- Utiliser ARIA correctement (et savoir quand ne pas l’utiliser).
- Traiter texte, couleur, contraste, images et média (alternatives, sous-titres, transcriptions).
- Rendre accessibles les formulaires et les composants interactifs (modales, menus, onglets, combobox…).
- Appliquer tout ça en React/Next.js et sur Moodle / plateformes de formation.
- Tester (axe, Lighthouse, lecteur d’écran, clavier) et industrialiser (CI, déclaration d’accessibilité, audit).
Le sommaire
| # | Partie | Ce que ça couvre |
|---|---|---|
| 1 | Comprendre l’accessibilité | Le pourquoi, les handicaps, les principes POUR. |
| 2 | Cadre légal & normatif | WCAG 2.2, ARIA, RGAA, EAA, obligations. |
| 3 | HTML sémantique | La fondation : éléments, landmarks, titres. |
| 4 | Clavier & focus | Navigation clavier, ordre, focus visible, pièges. |
| 5 | Lecteurs d’écran | NVDA/JAWS/VoiceOver, arbre d’accessibilité. |
| 6 | WAI-ARIA | Rôles, états, propriétés, live regions. |
| 7 | Texte, couleur & contraste | Alternatives, contraste, zoom, reflow, langue. |
| 8 | Images, icônes & média | alt décisionnel, SVG, sous-titres, transcription. |
| 9 | Formulaires accessibles | Labels, erreurs, validation, autocomplete. |
| 10 | Composants interactifs | Modales, menus, onglets, combobox (patterns APG). |
| 11 | React & Next.js | SPA, focus, annonces de route, Radix/React Aria. |
| 12 | Moodle & formation | LMS, contenu de cours, documents, l’angle EdTech. |
| 13 | Mobile, responsive & mouvement | Cibles tactiles, gestes, zoom, prefers-reduced-motion. |
| 14 | Tester l’accessibilité | axe, Lighthouse, manuel, lecteur d’écran, CI. |
| 15 | Design accessible & industrialiser | Design system, déclaration, audit, workflow. |
| 16 | Cookbook & Annexes | Checklists, cheat sheets, glossaire, quiz. |
Le fil rouge : A11yLearn
Tout au long du cours, on rend accessible A11yLearn — une petite plateforme de formation (Next.js côté app, avec un espace Moodle côté contenu). Pas pour l’app en elle-même : pour montrer, sur du concret, comment on applique chaque principe — un menu qu’on rend navigable au clavier, un formulaire d’inscription qu’on corrige, une vidéo de cours qu’on sous-titre, un tableau de bord qu’on annonce correctement. L’exemple est volontairement de type EdTech, un secteur où l’accessibilité est légalement incontournable. Chaque partie fait progresser A11yLearn, dans l’encadré 🧭 Sur A11yLearn.
Comment lire ce cours
- Dans l’ordre la première fois : chaque partie s’appuie sur la précédente (on ne fait pas d’ARIA avant d’avoir compris le HTML sémantique et l’arbre d’accessibilité).
- En référence ensuite : le Cookbook & Annexes rassemble checklists, cheat sheets ARIA/WCAG et scripts de test.
- Les mots ont un sens précis : rôle, nom accessible, landmark, live region, critère WCAG ne sont pas interchangeables. Le cours les distingue rigoureusement.
⚠️ Piège — Le plus grand piège de l’a11y, c’est de croire qu’un outil automatique suffit. Les tests automatiques (axe, Lighthouse) ne détectent qu’une fraction des problèmes (de l’ordre de 30-40 %). L’accessibilité réelle se vérifie aussi à la main : au clavier, avec un lecteur d’écran, avec du jugement. Ce cours t’apprend les deux (Partie 14).
💡 Standard de référence — On vise WCAG 2.2 niveau AA, la cible exigée par les lois actuelles (RGAA, EAA). WCAG 3.0 existe mais reste un brouillon de travail pour plusieurs années : on en parle, mais on ne construit pas dessus. La source de vérité reste la spec du W3C et le référentiel RGAA officiel .
Prêt ? On commence par le plus important : comprendre pourquoi et pour qui.