Chapitre 6.1 — À quoi sert (vraiment) ARIA

⏱️ TL;DR — WAI-ARIA sert à enrichir la sémantique exposée aux technologies d’assistance : elle modifie le nom, le rôle et la valeur/état qu’un élément déclare dans l’arbre d’accessibilité. Elle ne fait rien d’autre : aucun comportement, aucun focus, aucun style, aucune touche clavier. Si tu poses role="button" sur une <div>, tu obtiens un élément annoncé « bouton » mais toujours muet au clavier — c’est à toi de coder le reste. D’où la première règle d’ARIA : ne l’utilise pas quand un élément HTML natif fait déjà le travail.

🎯 Objectifs

Décrire précisément ce qu’ARIA change et ce qu’elle ne change pas.
Connaître les cinq règles d’ARIA du W3C et savoir pourquoi la première prime.
Comprendre la maxime « No ARIA better than bad ARIA ».
Reconnaître les cas où ARIA est légitime (widgets complexes sans équivalent natif).

Ce qu’ARIA fait

ARIA (Accessible Rich Internet Applications) est un ensemble d’attributs HTML qui décrivent un élément aux technologies d’assistance. Rappelle-toi le triptyque de la Partie 5 : chaque nœud de l’arbre d’accessibilité porte un nom, un rôle et une valeur/état. ARIA agit exactement sur ces trois axes :

Le rôle : role="tab", role="dialog", role="alert"… annonce ce qu’est l’élément.
Le nom : aria-label, aria-labelledby fournissent le libellé lu à voix haute.
L’état / valeur : aria-expanded, aria-checked, aria-valuenow… décrivent où en est l’élément.

Autrement dit, ARIA parle au lecteur d’écran, pas au navigateur. Elle change ce qui est dit, pas ce qui se passe.

Ce qu’ARIA ne fait PAS

C’est le point que 90 % des dévs comprennent de travers. ARIA n’ajoute :

aucun comportement — un role="button" ne devient pas cliquable ni activable ;
aucun focus — l’élément n’entre pas dans l’ordre de tabulation (il te faut tabindex) ;
aucune touche clavier — Entrée, Espace, les flèches : tout est à coder en JS ;
aucun style — rien ne change visuellement.

ARIA est une couche de description, pas une couche de fonctionnement. Quand tu détournes une balise neutre en widget, tu signes un contrat : je promets de fournir moi-même le clavier, le focus et la logique.


<!-- ❌ Annoncé « Menu, bouton » MAIS : pas focusable, pas activable au clavier -->
<div role="button" onclick="ouvrirMenu()">Menu</div>
 
<!-- ✅ Le contrat ARIA tenu à la main : focus + rôle + clavier -->
<div role="button" tabindex="0"
     onclick="ouvrirMenu()"
     onkeydown="if(event.key==='Enter'||event.key===' ')ouvrirMenu()">Menu</div>
 
<!-- ✅✅ … ou, plus simplement, l'élément natif qui fait tout ça gratuitement -->
<button type="button" onclick="ouvrirMenu()">Menu</button>

⚠️ Piège — Croire qu’un role rend un élément utilisable. Le rôle décrit, il n’active pas. Un role="checkbox" sur une <span> sans tabindex, sans gestion de l’Espace et sans mise à jour d’aria-checked est une case à cocher morte : annoncée, mais impossible à cocher. Le lecteur d’écran promet à l’utilisateur quelque chose que ton code ne tient pas.

Les cinq règles d’ARIA

Le W3C résume le bon usage d’ARIA en cinq règles. Grave la première.

N’utilise pas ARIA si un élément HTML natif existe. Un <button>, un <nav>, un <input type="checkbox"> t’offrent rôle, focus, clavier et états sans une ligne d’ARIA. C’est toujours le premier réflexe.
Ne change pas la sémantique native sans raison. Écrire <h2 role="tab"> détruit le titre : le lecteur d’écran n’annonce plus « titre niveau 2 ». Ne surcharge que si tu sais pourquoi.
Tout widget ARIA doit être utilisable au clavier. Si un utilisateur de souris peut l’actionner, un utilisateur de clavier doit le pouvoir aussi. Pas de widget ARIA « souris seule ».
Ne mets pas role="presentation" ni aria-hidden="true" sur un élément focusable. Tu créerais un « fantôme » : l’utilisateur peut y arriver au clavier, mais le lecteur d’écran n’annonce rien. Piège de focus classique.
Tout élément interactif a un nom accessible. Un bouton, un champ, un lien doivent avoir un libellé exploitable (texte visible, aria-label, aria-labelledby…). Sinon le lecteur d’écran dit « bouton » et rien de plus.

« No ARIA better than bad ARIA »

La formule officielle du W3C. Une ARIA fausse est pire que pas d’ARIA du tout, parce qu’elle ment : un aria-expanded="false" figé fait croire qu’un menu est fermé alors qu’il est ouvert ; un role="button" sans clavier promet une action impossible. Sans ARIA, le lecteur d’écran retombe au moins sur la sémantique native ou reste silencieux — ce qui est moins trompeur qu’une information erronée. Le doute doit toujours te ramener vers moins d’ARIA, pas plus.

💡 Réflexe — Avant d’ajouter un attribut ARIA, pose-toi trois questions : (1) un élément natif ne le ferait-il pas mieux ? (2) suis-je capable de coder le clavier et de tenir l’état à jour ? (3) est-ce que je teste le résultat au lecteur d’écran ? Si tu hésites sur l’une des trois, retire l’ARIA.

Quand ARIA est légitime

ARIA n’est pas l’ennemi — elle est indispensable là où le HTML natif n’a pas d’équivalent. Il n’existe pas de balise native pour un système d’onglets, une fenêtre modale, un arbre déroulant, une barre de progression riche, une combobox à autocomplétion, un carrousel annoncé. Pour ces composants complexes, ARIA fournit le vocabulaire (role="tablist", role="dialog", aria-selected…) que tu combines avec ton JS clavier. C’est précisément le rôle du catalogue APG (ARIA Authoring Practices Guide) — on l’exploitera en Partie 10.

🧭 Sur A11yLearn — Le menu de navigation d’A11yLearn est une simple liste de liens : zéro ARIA nécessaire, <nav> + <a> suffisent. En revanche, le sélecteur d’onglets « Mes cours / Terminés / Favoris » du tableau de bord n’a aucun équivalent natif : là, on assumera role="tablist", role="tab", aria-selected — et on codera nous-mêmes la navigation aux flèches. La bonne question n’est jamais « où mettre de l’ARIA ? » mais « le natif suffit-il ? ».

📚 Aller plus loin — Les cinq règles sont détaillées dans « Using ARIA » (W3C, w3.org/TR/using-aria). Le critère WCAG central pour ARIA est le 4.1.2 (Nom, rôle, valeur) : tout composant d’interface doit exposer un nom, un rôle et son état aux technologies d’assistance. ARIA est l’un des outils pour le satisfaire — le HTML natif en est un autre, souvent meilleur.

✏️ Exercices

Exercice 1 — Répare le faux bouton. Ce code est annoncé « Supprimer, bouton » mais reste inutilisable au clavier. Corrige-le de deux façons : (a) en gardant la <div>, (b) idéalement.


<div role="button" onclick="supprimer()">Supprimer</div>

✅ Solution

(a) Il faut tenir le contrat ARIA : rendre l’élément focusable et gérer les touches d’activation.


<div role="button" tabindex="0"
     onclick="supprimer()"
     onkeydown="if(event.key==='Enter'||event.key===' '){event.preventDefault();supprimer()}">
  Supprimer
</div>

(b) La bonne solution, c’est la règle n°1 : un élément natif fait tout gratuitement.


<button type="button" onclick="supprimer()">Supprimer</button>

Le <button> apporte le rôle, le focus, Entrée et Espace, la gestion de disabled — sans JS clavier à maintenir.

Exercice 2 — Vrai ou faux. « Ajouter role="dialog" sur ma <div> la rend modale : le focus y sera piégé et Échap la fermera. » Justifie.

✅ Solution

Faux. role="dialog" ne fait qu’annoncer « boîte de dialogue » au lecteur d’écran. Il n’ajoute aucun comportement : ni piège de focus, ni fermeture à Échap, ni retour du focus à l’ouvrant. Tout cela est à coder (ou à obtenir avec l’élément natif <dialog> et sa méthode showModal()). ARIA décrit, elle n’implémente pas.

🧠 Quiz de révision

1. Sur quels trois axes ARIA agit-elle ?

Sur le nom, le rôle et la valeur/état exposés dans l’arbre d’accessibilité. Elle modifie ce que le lecteur d’écran annonce, pas le comportement du navigateur.

2. Cite trois choses qu’ARIA n’ajoute jamais.

Au choix : aucun comportement, aucun focus (pas d’entrée dans l’ordre de tabulation), aucune touche clavier, aucun style. ARIA décrit ; c’est à toi de coder le fonctionnement.

3. Que dit la première règle d’ARIA ?

N’utilise pas ARIA si un élément HTML natif existe. Un <button>, un <nav>, un <input> offrent rôle, focus, clavier et états sans une ligne d’ARIA. C’est toujours le premier réflexe.

4. Que signifie « No ARIA better than bad ARIA » ?

Qu’une ARIA fausse est pire que pas d’ARIA, parce qu’elle ment au lecteur d’écran (état figé, action promise mais impossible). Sans ARIA, l’utilisateur retombe sur la sémantique native ou le silence — moins trompeur qu’une information erronée.

5. Donne un cas où ARIA est vraiment légitime.

Tout composant complexe sans équivalent natif : système d’onglets, fenêtre modale, arbre déroulant, combobox à autocomplétion, carrousel annoncé. ARIA y fournit le vocabulaire (role="tablist", aria-selected…) que tu combines avec ton JS clavier — voir le catalogue APG.

Chapitre suivant : Les rôles — les catégories de rôles ARIA et le danger d’écraser la sémantique native.