WAI-ARIA : rendre les interfaces riches accessibles
Ah, ARIA. C'est probablement le sujet qui génère le plus de confusion en accessibilité web. WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) est une spécification du W3C qui permet d'ajouter des informations sémantiques aux éléments HTML pour que les lecteurs d'écran les comprennent.
Le truc fondamental à retenir : ARIA ne change ni l'apparence ni le comportement de quoi que ce soit. Il ajoute uniquement des métadonnées — des étiquettes invisibles que seules les technologies d'assistance lisent. Votre composant a l'air pareil, se comporte pareil, mais le lecteur d'écran sait enfin ce que c'est.
Les 3 composantes d'ARIA
1. Les rôles : "cet élément, c'est quoi ?"
Les rôles disent au lecteur d'écran la nature de l'élément. Il y en a quatre familles :
- Rôles de landmark : banner, navigation, main, complementary, contentinfo — les grandes zones de la page
- Rôles de widget : button, checkbox, dialog, menu, tab, tabpanel, slider — les composants interactifs
- Rôles de structure : list, listitem, table, row, cell, heading — l'organisation du contenu
- Rôles de live region : alert, log, status, timer — les zones qui changent dynamiquement
<div role="dialog" aria-labelledby="dialog-title">
<h2 id="dialog-title">Confirmer la suppression</h2>
</div>
2. Les propriétés : "cet élément, il a quoi ?"
Les propriétés décrivent les caractéristiques permanentes d'un élément :
aria-label: un label invisible, très pratique pour les boutons-icônes sans textearia-labelledby: pointe vers un autre élément qui sert de label — préférez celui-ci quand le label est déjà visible dans la pagearia-describedby: ajoute une description complémentaire (aide, format attendu...)aria-controls: dit "ce bouton contrôle cet élément là-bas"aria-owns: crée un lien parent-enfant qui n'existe pas dans le DOMaria-required: "ce champ est obligatoire" — mais préférez l'attribut HTMLrequiredquand c'est possible
3. Les états : "cet élément, il en est où ?"
Les états changent au fil des interactions de l'utilisateur :
aria-expanded="true|false": le menu est ouvert ou ferméaria-selected="true|false": l'onglet est sélectionné ou nonaria-checked="true|false|mixed": la case est cochée (mixed, c'est pour les checkboxes partielles)aria-hidden="true|false": caché aux lecteurs d'écran — celui-là crée beaucoup de bugs quand on l'utilise malaria-disabled="true": élément désactivéaria-invalid="true": ce champ est en erreur
Les 5 règles d'or d'ARIA
Celui-là est souvent mal compris : ARIA a des règles strictes. Les voici, et elles sont non négociables :
- N'utilisez pas ARIA si l'HTML natif suffit : un
<button>est TOUJOURS mieux qu'un<div role="button">. Toujours. - Ne changez pas la sémantique native : mettre
role="button"sur un<h2>, c'est un crime contre l'accessibilité - Tout composant ARIA doit marcher au clavier : si vous mettez role="button", gérez Entrée et Espace
- Pas de aria-hidden="true" sur un élément focusable : sinon le focus "disparaît" et l'utilisateur est perdu
- Tout élément interactif doit avoir un nom accessible : via label, aria-label ou aria-labelledby
Les erreurs qu'on voit partout
Après des années à auditer des sites, voici les erreurs ARIA les plus fréquentes :
- ARIA redondant :
<nav role="navigation">— inutile, <nav> a déjà ce rôle implicitement. Ça ne casse rien, mais ça montre qu'on n'a pas compris. - aria-label sur des non-interactifs : un aria-label sur un <div> sans rôle ? Le lecteur d'écran l'ignore totalement. C'est du code mort.
- aria-hidden sur du contenu visible : "je veux que le lecteur d'écran ignore ce bloc"... mais le bloc est visible à l'écran. Résultat : une partie des utilisateurs ne sait pas qu'il existe.
- Rôle sans comportement clavier : role="button" sans gérer Entrée et Espace. Le lecteur d'écran dit "bouton" mais appuyer sur Entrée ne fait rien. Pire qu'un faux ami.
Quand utiliser ARIA, alors ?
ARIA n'est pas l'ennemi — c'est un outil de dernier recours, pour les cas que l'HTML natif ne couvre pas :
- Les composants complexes sans équivalent natif : onglets, menus déroulants, modales, arbres
- Les mises à jour dynamiques que le lecteur d'écran doit annoncer (aria-live, aria-busy)
- L'association entre éléments éloignés dans le DOM (aria-describedby, aria-controls)
- Le masquage de contenu décoratif (aria-hidden="true" sur une icône purement visuelle)
- L'enrichissement sémantique quand vraiment, le HTML ne peut pas faire le job
ARIA est un outil puissant mais dangereux. Mal utilisé, il peut rendre un site MOINS accessible qu'un HTML tout simple. La règle d'or que je répète à tous mes étudiants : « No ARIA is better than bad ARIA » — pas d'ARIA, c'est mieux que du mauvais ARIA.