Chapitre 16.1 — Checklists

⏱️ TL;DR — Cinq listes à cocher prêtes à l’emploi : avant de pousser une PR, pour balayer les WCAG 2.2 AA par principe POUR, pour un test clavier express, pour un formulaire, et pour un composant interactif. Copie celle qu’il te faut dans ta description de PR ou ton ticket. Aucune n’est exhaustive — elles attrapent 80 % des problèmes en 5 minutes.

Ce que tu trouveras ici

Des checklists actionnables, pas des rappels de cours. Chaque item est formulé comme une question binaire (oui = OK). Quand un item mérite une explication, on renvoie à la partie qui l’approfondit. Garde en tête la règle d’or : une checklist ne remplace pas un test manuel au clavier et au lecteur d’écran — elle t’évite d’oublier l’évident.

1. Checklist a11y d’une PR / feature

À coller dans le modèle de PR. Si un item ne s’applique pas, raye-le en expliquant pourquoi.

• Je navigue toute la feature au clavier seul (Tab, Maj+Tab, Entrée, Espace, Échap, flèches) sans souris.
• Le focus reste visible en permanence (anneau non supprimé) et son ordre est logique.
• Chaque image a un alt pertinent (ou alt="" si décorative). Voir Partie 8.
• Les contrôles sont des éléments natifs (<button>, <a>, <input>) plutôt que des <div> cliquables.
• Chaque champ de formulaire a un <label> associé ; les erreurs sont liées et annoncées. Voir Partie 9.
• Le contraste texte/fond atteint 4,5:1 (3:1 pour grand texte et éléments non-textuels). Voir Partie 7.
• La structure de titres (<h1>…<h6>) est hiérarchique, sans saut de niveau.
• Les landmarks (<header>, <nav>, <main>, <footer>) sont en place ; un seul <main>.
• Aucune information portée par la couleur seule (erreur = rouge et texte/icône).
• Les changements dynamiques importants sont annoncés (live region) sans voler le focus.
• J’ai passé axe DevTools ou Lighthouse : zéro violation bloquante. (Rappel : l’auto ne couvre que ~30-40 %.)
• J’ai fait un passage au lecteur d’écran (NVDA ou VoiceOver) sur le parcours principal.

2. Référence rapide WCAG 2.2 AA par principe POUR

Le modèle mental POUR (Perceptible, Utilisable, Compréhensible, Robuste). Une question par principe pour t’orienter — le détail des critères est en Partie 2.

💡 Réflexe — Quand tu ne sais pas dans quelle « case » ranger un problème, POUR sert de grille de tri : un lien illisible → Perceptible (contraste) ; une modale qu’on ne peut pas fermer → Utilisable (piège au focus) ; une erreur sans message → Compréhensible.

3. Checklist test clavier

Débranche la souris. Cinq minutes, aucune installation. Détail en Partie 4.

• Tab atteint tous les éléments interactifs, dans un ordre logique ; Maj+Tab revient en arrière.
• Le focus est toujours visible (anneau, surbrillance) — jamais outline: none sans remplacement.
• Rien n’est accessible à la souris mais pas au clavier (menus, tooltips, drag & drop).
• Entrée active liens et boutons ; Espace active boutons et coche les cases.
• Échap ferme les modales, menus et popovers ouverts.
• Aucun piège au focus : on peut toujours ressortir d’un composant au clavier.
• Dans une modale ouverte, le focus est contenu dedans et revient au déclencheur à la fermeture.
• Un skip link « Aller au contenu » apparaît au premier Tab. Voir le snippet dédié.

4. Checklist formulaire

Le point le plus rentable de l’a11y au quotidien. Détail en Partie 9.

• Chaque champ a un <label> visible et associé (for/id), ou un nom accessible équivalent.
• Les champs liés sont groupés dans un <fieldset> avec <legend> (radios, adresse…).
• Les erreurs sont annoncées, reliées au champ (aria-describedby) et expliquent quoi corriger.
• Le champ en erreur porte aria-invalid="true" ; l’erreur n’est pas signalée par la seule couleur.
• L’autocomplete est renseigné sur les champs d’identité (nom, e-mail, adresse…).
• Les instructions (format de mot de passe, obligatoire) sont avant le champ, pas seulement en placeholder.
• Le bouton d’envoi est un vrai <button type="submit"> ; la soumission fonctionne à la touche Entrée.
• Après envoi, le statut (succès/échec) est annoncé et le focus est géré (message d’erreur ou de confirmation).

5. Checklist composant interactif

Avant de « fabriquer » un widget (menu, onglets, accordéon, combobox…). Détail en Partie 10.

• Un élément natif suffirait-il ? (1re règle d’ARIA). Si oui, pas de widget maison.
• Je suis un pattern APG existant (rôles + interactions clavier documentés).
• Le rôle est correct (role="dialog", role="tablist"…) et le nom accessible présent.
• Les états sont tenus à jour en JS (aria-expanded, aria-selected, aria-checked…).
• Le clavier attendu du pattern est implémenté (voir 16.2).
• La gestion du focus est explicite (ouverture, fermeture, retour au déclencheur, roving tabindex si besoin).
• Testé au lecteur d’écran : le composant s’annonce et s’utilise vraiment, pas juste « sur le papier ».

🧭 Sur A11yLearn — La checklist n°1 vit dans le fichier .github/pull_request_template.md du dépôt A11yLearn : chaque PR arrive avec les cases déjà présentes, l’auteur les coche (ou raye avec justification). Résultat concret : les régressions d’accessibilité se voient en revue, pas trois mois plus tard dans un audit. Une checklist dans le workflow vaut dix rappels en réunion.

Chapitre suivant : Cheat sheet ARIA & clavier — les rôles, états et touches à connaître par cœur.