Chapitre 16.5 — Quiz final
⏱️ TL;DR — Quinze questions pour valider tes acquis sur l’ensemble du cours, de la compréhension aux tests en passant par ARIA, les formulaires et le cadre légal. Réponds de tête avant de déplier chaque solution. Si un point résiste, retourne à la partie concernée — le but n’est pas le score, c’est la maîtrise.
Le quiz
1. Que signifie « a11y » et quelle en est l’idée centrale ?
Numéronyme d’accessibility (a + 11 lettres + y). Idée centrale : concevoir des interfaces utilisables par tout le monde, quels que soient les capacités, le matériel ou le contexte — un critère de qualité, pas une faveur. Voir Partie 1.
2. Quels sont les quatre principes POUR ?
Perceptible, Utilisable, Compréhensible, Robuste. C’est la grille qui organise tous les critères WCAG. Voir 1.4.
3. Quel niveau WCAG les lois (RGAA, EAA) exigent-elles ?
Le niveau AA (qui englobe A). Le AAA n’est pas exigé globalement. La version courante est WCAG 2.2. Voir Partie 2.
4. Depuis quand l’EAA s’applique-t-il, et le RGAA impose quoi de spécifique ?
5. Pourquoi préférer un <button> natif à une <div> cliquable ?
<button> natif à une <div> cliquable ?Le <button> apporte gratuitement le rôle annoncé, le focus clavier et l’activation (Entrée/Espace). Une <div> est muette pour le lecteur d’écran et non focusable. C’est la fondation sémantique. Voir Partie 3.
6. Quel est le test d’accessibilité le plus rentable, et comment le faire ?
Le test clavier : lâcher la souris et faire Tab. On vérifie que tout est atteignable, le focus visible, l’ordre logique, rien piégé, tout activable. Gratuit, immédiat, très révélateur. Voir 14.3.
7. Quelle est la première règle d’ARIA ?
Ne pas utiliser ARIA quand un élément HTML natif fait le travail. ARIA modifie la sémantique exposée mais n’ajoute ni comportement, ni focus, ni style. « No ARIA better than bad ARIA ». Voir Partie 6.
8. Comment annoncer un message dynamique (« Enregistré ») sans voler le focus ?
Avec une live region : role="status" / aria-live="polite" pour l’informatif, role="alert" / assertive pour l’urgent. Le message est annoncé sans déplacer le focus. Voir 6.4.
9. Quel contraste minimum pour du texte normal en AA, et quelle erreur liée à la couleur éviter ?
4,5:1 pour le texte normal (3:1 pour le grand texte et les éléments non textuels). Ne jamais transmettre une information par la seule couleur (ajouter texte, icône ou motif). Voir Partie 7.
10. Quand un alt doit-il être vide (alt="") ?
alt doit-il être vide (alt="") ?Quand l’image est purement décorative (elle n’ajoute aucune information) : un alt="" la retire de l’arbre d’accessibilité. Un alt absent, lui, est un bug. Pour une image fonctionnelle, le alt décrit l’action. Voir 8.1.
11. Le placeholder peut-il servir de label de champ ?
placeholder peut-il servir de label de champ ?Non. Le placeholder disparaît à la saisie, a un contraste souvent faible et n’est pas fiablement traité comme un label. Chaque champ a besoin d’un vrai <label> associé. Voir 9.1.
12. Quel est le problème d’accessibilité propre aux SPA (React/Next), et comment le régler ?
Au changement de route côté client, la page ne se recharge pas : le lecteur d’écran n’annonce rien et le focus reste en place. Il faut annoncer le changement (live region / route announcer) et déplacer le focus. Next.js App Router intègre un annonceur de route ; le focus et le title par page restent à gérer. Voir 11.2.
13. Un score Lighthouse de 100 prouve-t-il l’accessibilité ?
Non. Les outils automatiques ne couvrent que ~30-40 % des critères. Un score de 100 signifie « aucune erreur automatiquement détectable », pas « accessible ». Les tests manuels (clavier, lecteur d’écran) restent indispensables. Voir Partie 14.
14. Comment respecter les personnes sensibles au mouvement ?
Respecter prefers-reduced-motion (couper les grandes animations), ne pas dépasser 3 flashs par seconde (risque d’épilepsie), et rendre tout contenu animé automatique contrôlable (pause/arrêt). Voir 13.5.
15. Sur une plateforme de formation, où se joue souvent l’accessibilité réelle ?
Dans le contenu et les documents/médias : une plateforme accessible peut héberger un cours inaccessible (PDF scanné, vidéo sans sous-titres, faux titres). L’a11y d’un LMS est en trois couches (plateforme, contenu, documents). Voir Partie 12.
Le mot de la fin
Si tu retiens trois choses de tout ce cours :
- 80 % de l’accessibilité, c’est du bon HTML. Élément natif, structure sémantique, focus géré, nom/rôle/valeur corrects. Les 20 % restants (ARIA, composants complexes, tests) font l’expert — mais la fondation fait le gros du travail.
- La première règle d’ARIA : ne pas utiliser ARIA. Le plus accessible, c’est le plus simple et le plus natif.
- L’automatique ne suffit pas. Vise WCAG 2.2 AA, mais teste au clavier et au lecteur d’écran — c’est là que se cache l’expérience réelle.
Tu as désormais de quoi auditer, corriger et construire accessible par défaut — et devenir le référent a11y de ton équipe. Vu le contexte légal (RGAA, EAA), c’est une compétence rare et recherchée.
🧭 Sur A11yLearn — A11yLearn est passée, au fil du cours, d’une plateforme truffée de pièges à un service testable, déclaré et maintenu. Le même chemin t’attend sur tes projets : une partie à la fois, en construisant bien plutôt qu’en réparant tard.
Fin du cours. Retour à l’accueil Accessibilité. Pour transformer cette expertise en revenu (audits, mises en conformité, formation), va voir Monétiser (Dev + IA) ; pour la mettre en œuvre plus vite avec l’IA, Claude Code. Maintenant, va rendre le web utilisable par tout le monde.