Les lecteurs d'écran et la première règle d'ARIA

La première règle d'ARIA est de l'éviter : si un élément HTML natif fait déjà le travail, comme button, utilise-le au lieu d'ajouter un rôle à un div.

Ce qu'utilise un lecteur d'écran

Un lecteur d'écran ne lit pas des pixels. Le navigateur construit à partir du HTML un arbre d'accessibilité, une copie simplifiée de la page dans laquelle chaque élément intéressant a un rôle (bouton, lien, titre, case à cocher), un nom (le texte qui l'identifie) et parfois un état (coché, déplié, désactivé). Le lecteur d'écran lit cet arbre à voix haute ou l'envoie à une plage braille. Le critère de succès 4.1.2 Nom, rôle et valeur des WCAG 2.2, de niveau A, demande que chaque composant de la page expose ces trois informations.

Les utilisateurs écoutent rarement une page de haut en bas. Les lecteurs d'écran intégrés aux principaux systèmes d'exploitation, et ceux, gratuits, qu'on peut installer, permettent d'afficher une liste de titres, de liens ou de points de repère, de sauter au champ de formulaire suivant, ou de lire une ligne à la fois. C'est pourquoi les unités précédentes comptent tant : de vrais titres, des champs étiquetés, des boutons qui sont des boutons et des textes alternatifs alimentent tous directement cet arbre. L'attribut lang de l'élément html compte aussi. Le critère 3.1.1 Langue de la page l'exige, et les lecteurs d'écran s'en servent pour choisir la bonne voix et la bonne prononciation.

Ce qu'ajoute ARIA

WAI-ARIA (Accessible Rich Internet Applications) est un ensemble d'attributs qui modifient ce qui entre dans l'arbre d'accessibilité : role fixe le rôle, des attributs comme aria-label fixent le nom, et d'autres comme aria-checked ou aria-expanded fixent l'état. ARIA ne change que ce qui est annoncé. Il ne permet pas à un élément de recevoir le focus, n'ajoute pas de comportement au clavier et ne change pas son apparence. Le guide des pratiques de création ARIA du W3C (ARIA Authoring Practices Guide) en fait un titre : « No ARIA is better than bad ARIA » (pas d'ARIA vaut mieux qu'un mauvais ARIA). Un ARIA erroné dit quelque chose de faux sur la page à l'utilisateur d'un lecteur d'écran.

Les règles d'utilisation d'ARIA

Le document du W3C Using ARIA énonce de courtes règles citées partout (il a été marqué comme brouillon abandonné en février 2026, mais les règles elles-mêmes n'ont pas changé). Règle 1 : si tu peux utiliser un élément ou un attribut HTML natif qui a déjà le sens et le comportement voulus, fais-le, au lieu de détourner un autre élément avec ARIA. Règle 2 : ne modifie pas la sémantique native sauf si c'est vraiment nécessaire. Règle 3 : chaque composant interactif ARIA doit être utilisable au clavier. Règle 4 : ne mets pas role="presentation" ni aria-hidden="true" sur un élément qui peut recevoir le focus, sinon certains utilisateurs tomberont sur « rien ».

Là où ARIA aide vraiment, c'est pour combler des manques que HTML ne peut pas combler. Un bouton qui ne contient qu'une icône n'a pas de texte, donc pas de nom ; aria-label="Close" lui en donne un. Une icône SVG à côté d'un texte visible est décorative, et aria-hidden="true" sur le svg la tient hors de l'arbre. Ce sont les deux attributs dont la plupart des débutants ont besoin. Pour des composants entiers comme des onglets ou des menus, suis le motif correspondant du guide des pratiques de création au lieu d'en inventer un.