Que sont les attributs ARIA ? WAI-ARIA expliqué simplement

ARIA signifie Accessible Rich Internet Applications. Il s'agit d'un ensemble d'attributs HTML, normalisés par le W3C sous le nom de WAI-ARIA (version actuelle 1.2, publiée en juin 2023), qui fournit aux technologies d'assistance telles que les lecteurs d'écran des informations supplémentaires sur les éléments d'interface. ARIA devient nécessaire là où la sémantique du HTML natif s'arrête : une interface à onglets, un accordéon, un menu déroulant sur mesure ou un message d'état qui apparaît dynamiquement. Le vocabulaire repose sur trois briques : les rôles décrivent ce qu'est un élément, les états décrivent sa condition du moment, et les propriétés décrivent ses caractéristiques et ses relations. ARIA est à la fois puissant et dangereux. Correctement utilisé, il rend des composants complexes utilisables par les personnes qui naviguent au lecteur d'écran ; mal utilisé, il casse activement l'accessibilité, et c'est pourquoi la règle la plus importante d'ARIA consiste à préférer les éléments HTML natifs chaque fois qu'ils peuvent faire le travail.

Que signifie ARIA et pourquoi cette technologie existe-t-elle ?

Le HTML possède une sémantique intégrée riche : un button est annoncé comme un bouton, un nav est une navigation, une case cochée signale son état d'elle-même. Les lecteurs d'écran lisent tout cela dans l'arbre d'accessibilité que le navigateur construit à partir de votre balisage. Le problème commence avec tout ce pour quoi le HTML n'a pas d'élément. Il n'existe pas de panneau d'onglets natif, pas d'accordéon, pas de notification éphémère. Les développeurs les construisent à partir de div et de span, et pour une personne au lecteur d'écran un accordéon en div n'est que du silence : ni nom, ni rôle, ni état.

WAI-ARIA comble exactement cette lacune. Il vous permet d'indiquer aux technologies d'assistance ce qu'est votre composant sur mesure et ce qu'il est en train de faire, sans rien changer à l'apparence ni au comportement de la page pour les autres.

Rôles, états et propriétés : les trois briques d'ARIA

• Les rôles définissent ce qu'est un élément. role="dialog", role="tablist", role="alert". Un rôle est une promesse faite à l'utilisateur : cette chose se comportera comme une boîte de dialogue.
• Les états décrivent la condition actuelle et changeante d'un élément. aria-expanded="true", aria-checked="false", aria-disabled="true". Les états évoluent pendant que l'utilisateur interagit, et votre JavaScript doit les maintenir à jour.
• Les propriétés décrivent des caractéristiques et des relations qui changent rarement. aria-labelledby renvoie à l'élément qui donne son nom à celui-ci, aria-controls renvoie à l'élément qu'il pilote, aria-required signale un champ obligatoire.

La distinction entre états et propriétés est académique au quotidien, les uns comme les autres ne sont que des attributs. Le modèle mental qui compte : le rôle dit ce que c'est, tout le reste dit comment cela s'appelle, ce que cela fait et à quoi cela appartient.

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

Le document du W3C intitulé Using ARIA s'ouvre sur une règle qui ressemble à une plaisanterie mais qui est parfaitement sérieuse : s'il existe déjà un élément HTML natif doté de la sémantique et du comportement dont vous avez besoin, utilisez-le plutôt que de détourner un autre élément et d'y ajouter ARIA. Comparez ces deux façons de construire un bouton :

<!-- Ressemble à un bouton pour les voyants, n'est qu'un div mort pour les autres -->
<div class="btn" onclick="save()">Enregistrer</div>

<!-- Tout est inclus : rôle, prise en charge du clavier, focus -->
<button type="button" onclick="save()">Enregistrer</button>

Pour rattraper la version en div, il vous faudrait role="button", tabindex="0" et du JavaScript supplémentaire pour les touches Entrée et Espace. L'élément natif fait tout cela gratuitement et continuera de le faire dans des navigateurs que vous n'avez jamais testés. La même logique vaut pour les liens, les cases à cocher, les champs de formulaire et les titres.

Une donnée dégrisante étaye cette règle. WebAIM analyse chaque année le million de pages d'accueil les plus visitées, et ses rapports constatent systématiquement que les pages utilisant ARIA présentent en moyenne davantage d'erreurs d'accessibilité détectées que les pages qui s'en passent. Ce n'est pas qu'ARIA soit mauvais, mais qu'il est très fréquemment mal appliqué. Pas d'ARIA vaut mieux qu'un ARIA cassé.

Les attributs ARIA les plus importants expliqués

• aria-label : donne directement son nom accessible à un élément. Le cas d'usage classique est le bouton composé d'une seule icône : aria-label="Fermer" sur la croix d'une fenêtre modale.
• aria-labelledby : renvoie à l'ID d'un autre élément dont le texte visible devient le nom. Préférable à aria-label lorsqu'une étiquette visible existe, car les deux ne peuvent alors pas diverger.
• aria-describedby : renvoie à un texte descriptif supplémentaire, typiquement une aide ou un message d'erreur sous un champ de formulaire.
• aria-hidden="true" : retire un élément et ses enfants de l'arbre d'accessibilité. Judicieux pour les icônes décoratives, dangereux sur tout ce qui peut recevoir le focus.
• aria-expanded : signale sur le déclencheur si la zone qu'il pilote est ouverte ou fermée. La colonne vertébrale des accordéons, des menus déroulants et de la navigation mobile.
• aria-controls : relie un déclencheur à l'élément qu'il pilote.
• aria-live : transforme un élément en région dynamique dont les changements de contenu sont annoncés automatiquement. polite attend une pause, assertive interrompt immédiatement et devrait être réservé aux messages réellement urgents.
• aria-current : marque l'élément courant dans un ensemble, par exemple aria-current="page" sur le lien de navigation actif.
• aria-required et aria-invalid : signalent les champs obligatoires et les échecs de validation dans les formulaires. Avec la validation HTML native, required couvre déjà le premier point à lui seul.

Que sont les rôles de repère ARIA ?

Les repères découpent une page en régions nommées entre lesquelles les personnes au lecteur d'écran peuvent sauter directement, comme les voyants balaient visuellement une mise en page. Bonne nouvelle : les éléments HTML modernes créent implicitement la plupart des repères, si bien que dans un document bien structuré vous écrivez rarement ces rôles à la main.

• header correspond au repère banner
• nav correspond à navigation
• main correspond à main, et il ne devrait y en avoir qu'un seul par page
• aside correspond à complementary
• footer correspond à contentinfo
• form et section deviennent les repères form et region lorsqu'ils portent un nom accessible

Une habitude à prendre : si une page comporte deux navigations, distinguez-les avec aria-label="Menu principal" et aria-label="Menu du pied de page". Entendre deux fois « navigation » sans distinction n'aide personne.

Exemples ARIA concrets : accordéon et région dynamique

Un en-tête d'accordéon accessible minimal montre comment les pièces s'assemblent. Le bouton porte l'état, le panneau est référencé par son ID, et le JavaScript bascule les deux au clic :

<h3>
  <button aria-expanded="false" aria-controls="panel-shipping">
    Livraison et retours
  </button>
</h3>
<div id="panel-shipping" hidden>
  <p>Nous expédions sous 2 à 4 jours ouvrés...</p>
</div>

Et une région dynamique pour un retour qui apparaît sans rechargement de la page, par exemple après un ajout au panier ou une recherche filtrée :

<div aria-live="polite" class="visually-hidden" id="status"></div>

<script>
  document.getElementById('status').textContent = '12 produits trouvés'
</script>

Sans la région dynamique, une personne au lecteur d'écran filtre une liste de produits et n'entend absolument rien. Avec elle, le nombre de résultats est annoncé dès qu'il change. Petit attribut, grande différence.

Les erreurs ARIA courantes à éviter

• aria-hidden="true" sur des éléments focalisables : l'élément disparaît de l'arbre d'accessibilité mais reste dans l'ordre de tabulation. Les personnes qui naviguent au clavier atterrissent sur un fantôme. C'est l'une des erreurs ARIA les plus fréquentes en production.
• Les rôles redondants : role="button" sur un button ou role="navigation" sur un nav ajoute du bruit et montre que le balisage n'a pas été compris.
• Les rôles sans comportement : role="tab" promet une navigation aux touches fléchées. Si votre JavaScript ne la fournit pas, le rôle aggrave la situation par rapport à l'absence de rôle, car il crée une attente que le composant ne peut pas satisfaire.
• Les états périmés : un aria-expanded qui reste false pour toujours parce que personne ne le met à jour dans le gestionnaire de clic. Les personnes au lecteur d'écran entendent « replié » alors qu'elles font face à un panneau ouvert.
• aria-label sur des éléments de texte brut : sur un div ou un span dépourvu de rôle, aria-label est ignoré par la plupart des technologies d'assistance. Ce n'est pas une infobulle universelle.
• L'abus des régions dynamiques assertives : si chaque mise à jour du panier, chaque avis sur les cookies et chaque encart d'inscription à la newsletter interrompt l'utilisateur, les annonces réellement importantes se noient.

ARIA dans les thèmes et extensions WordPress

Le cœur de WordPress s'en sort correctement : le bloc de navigation gère aria-expanded sur les bascules de sous-menus, la classe CSS screen-reader-text pour les étiquettes masquées visuellement est une convention de longue date, et les composants de formulaire du cœur sont livrés avec des attributs sensés. Les ennuis arrivent en général avec ce qui vient s'installer par-dessus. Les constructeurs de pages, les extensions de carrousel, les méga-menus et les outils de fenêtres surgissantes sont les endroits où s'accumule la soupe de div avec des attributs ARIA absents ou cassés. Lorsque vous évaluez un thème, le tag accessibility-ready du répertoire des thèmes WordPress est un signal réel, car ces thèmes passent par une revue selon des critères définis. Pour tout le reste, le guide des pratiques de rédaction ARIA documente des modèles éprouvés pour à peu près tous les composants que vous aurez à construire, comportement clavier fonctionnel inclus.

Comment InspectWP contrôle-t-il l'usage d'ARIA ?

InspectWP examine vos pages rendues dans le cadre de son analyse d'accessibilité et signale les problèmes liés à ARIA que l'outillage automatisé détecte de façon fiable : noms de rôles invalides, attributs ARIA interdits sur l'élément qui les porte, références à des ID inexistants, éléments focalisables masqués par aria-hidden et éléments interactifs sans nom accessible. Les constats sont regroupés par gravité, si bien qu'un nom cassé sur votre navigation principale passe avant un rôle redondant dans le pied de page. Puisque c'est en définitive le comportement des lecteurs d'écran qui décide de ce qui fonctionne, considérez le rapport comme votre première passe rapide et reproductible, et vérifiez ensuite les parcours critiques avec un vrai lecteur d'écran.