Web Accessibility Cookbook

1Tout élément a un nom, un rôle, un état

Le livre est un vrai livre de cuisine (treize chapitres de recettes autonomes), mais sous les recettes il y a un modèle mental unique, et c'est lui qu'il faut emporter. Une personne aveugle ne voit pas votre bouton ; son lecteur d'écran le lui annonce, en trois informations : un nom (le texte lu), un rôle (quel genre de chose c'est) et un état (coché, ouvert, désactivé…).

<button aria-pressed="true">Favori</button>
<!-- annoncé : "Favori, bouton, activé" -->
<!--            ^nom    ^rôle   ^état -->

Toute l'accessibilité tient dans cette boucle : à chaque composant, demandez-vous « son nom, son rôle et son état sont-ils corrects et annoncés ? ». Un <div> cliquable n'a ni rôle ni état : pour le lecteur d'écran, il n'existe pas. C'est pour ça que la première règle (idée 2) est d'utiliser le bon élément HTML, qui fournit ces trois informations gratuitement. Et comme le dit la préface, l'accessibilité « ne fait pas qu'effleurer les disciplines du web, elle les relie » : la recette de l'un est souvent celle de tous.

2La première règle d'ARIA : ne pas utiliser ARIA

La colonne vertébrale de tout le livre : prenez d'abord l'élément HTML natif, et n'ajoutez ARIA que si aucun élément ne fait le travail. Un vrai <button> arrive avec un rôle, le support clavier et le focus ; un <div role="button"> vous oblige à tout reconstruire à la main, et le WebAIM Million a trouvé que 27,5 % des sites le ratent.

Tout élément interactif a besoin de deux choses sur lesquelles le livre revient sans cesse : un rôle (quel genre d'élément c'est) et un nom accessible (le texte que le lecteur d'écran annonce). Réussissez ça en HTML simple, et l'essentiel de l'accessibilité est déjà fait.

3Ça t'emmène ailleurs ? Lien. Ça fait quelque chose ? Bouton.

La règle la plus utile du front-end, et Matuzović en fait un test : si ça navigue, <a> ; si ça déclenche une action, <button>. Les deux se ressemblent et ne se comportent en rien pareil : un lien se suit, un bouton se presse, et les lecteurs d'écran les annoncent différemment.

Et quel que soit votre choix, ne supprimez jamais l'outline de focus sans le remplacer, et nommez l'élément pour ce qu'il est : une image-lien décrit sa destination, un bouton-icône décrit son action, jamais l'image.

4Respecter les réglages de l'utilisateur, pas les écraser

Les navigateurs et les systèmes exposent déjà ce dont les gens ont besoin :

• le mode sombre (prefers-color-scheme) ;
• le mouvement réduit (prefers-reduced-motion) ;
• le contraste accru et les couleurs forcées ;
• une police de base plus grande.

Le chapitre CSS est un long plaidoyer : ignorer ces signaux n'est pas neutre, c'est un manque de respect.

Le détail qui reste : la media query s'appelle prefers-reduced-motion, « et pas prefers-no-motion, pour une raison » (ch. 5). Le but est de couper le mouvement gratuit, pas de tuer toute animation. Et le CSS peut casser le sens en silence : list-style: none peut retirer la sémantique de liste dans Safari, obligeant parfois à remettre role="list".

5Le focus, c'est le curseur de ceux qui n'ont pas de souris

Pour les utilisateurs au clavier et au lecteur d'écran, l'anneau de focus EST le pointeur. La formule de Matuzović est sans détour : « supprimer les indicateurs de focus pour les utilisateurs clavier, c'est comme cacher le curseur pour les utilisateurs souris » (ch. 6). On ne supprime donc jamais l'outline ; on le stylise, idéalement avec :focus-visible, et on le garde visible en mode Forced Colors grâce à l'astuce de l'outline transparent.

Deux règles ferment le chapitre. L'ordre de lecture suit le DOM : réordonner en CSS avec order ou flex-direction désynchronise le vu et le lu. Et pour les modales, préférez le <dialog> natif ou l'attribut inert à un piège à focus fait maison.

6Cacher du contenu : cinq méthodes, des effets opposés

« Caché » ne veut pas dire une seule chose. Cacher visuellement n'est pas cacher au lecteur d'écran, et on confond les deux avec des résultats douloureux. Le livre met les compromis côte à côte.

Pour le cas courant (une section qu'on déplie), le <details> natif fonctionne sans une ligne de JavaScript ; le chapitre le pèse honnêtement contre un disclosure widget maison quand on veut un comportement cohérent d'un navigateur à l'autre.

7La moitié des champs de formulaire du web n'ont pas d'étiquette

Le chiffre qui cadre le chapitre : selon le WebAIM Million 2023, « 45,9 % des sites testés contenaient des champs de formulaire sans étiquette » (ch. 9), comprenez sans <label>, l'élément HTML qui nomme un champ. Une étiquette visible, reliée à son champ par for/id, est le seul non-négociable ; tout le reste (indications, messages d'erreur, regroupement) ne fait que réduire l'effort par-dessus.

Les recettes sont celles qu'on réutilise à vie :

• <fieldset> + <legend> pour les groupes de boutons radio et de cases ;
• aria-describedby pour les indications et les messages d'erreur ;
• un résumé d'erreurs en haut qui prend le focus à la soumission.

Le placeholder en guise d'étiquette, rappelle le livre, est un anti-pattern : il disparaît dès qu'on tape.

8Les tests automatiques sont un filet, pas un certificat

Le dernier chapitre est une douche froide. Les outils comme axe, Lighthouse et WAVE attrapent les erreurs mécaniques, mais pas le sens. La différence est nette :

<img src="chart.png">              <!-- axe LE VOIT : alt manquant, erreur -->
<img src="chart.png" alt="image">  <!-- axe NE VOIT RIEN : alt présent…
                                          mais "image" ne dit rien d'utile -->

« Un score parfait ne veut pas dire que votre site est accessible » (ch. 13) : l'outil vérifie qu'un alt existe, jamais qu'il décrit vraiment l'image. C'est un filet de départ, pas une ligne d'arrivée. L'avertissement le plus moderne concerne les web components : l'encapsulation du Shadow DOM casse les références par ID, donc une étiquette dans le light DOM ne peut pas pointer vers un champ dans le shadow DOM. Pire, plusieurs auditeurs populaires ne voient rien du tout à l'intérieur d'un shadow root. Construisez des composants accessibles, puis testez-les avec un vrai lecteur d'écran.

L'avertissement le plus moderne concerne les web components : l'encapsulation du Shadow DOM casse les références par ID, donc une étiquette dans le light DOM ne peut pas pointer vers un champ dans le shadow DOM. Pire, plusieurs auditeurs populaires ne voient rien du tout à l'intérieur d'un shadow root. Construisez des composants accessibles, puis testez-les avec un vrai lecteur d'écran.