Chapitre 2.2 — ARIA & l’APG

⏱️ TL;DR — WAI-ARIA est une spécification du W3C qui permet d’enrichir la sémantique exposée aux technologies d’assistance, quand le HTML natif ne suffit pas. Retiens ce qu’ARIA fait — changer le nom, le rôle, l’état annoncés — et surtout ce qu’il ne fait pas : aucun comportement, aucun style, aucun focus. D’où la première règle d’ARIA : ne pas utiliser ARIA si un élément HTML natif fait déjà le travail. Pour les composants où ARIA est vraiment nécessaire, le catalogue de référence est l’APG (ARIA Authoring Practices Guide).

🎯 Objectifs

• Situer WAI-ARIA dans le paysage normatif (spec W3C, complément des WCAG).
• Distinguer rôles / états / propriétés.
• Comprendre ce qu’ARIA change et ce qu’il ne change pas.
• Connaître et appliquer les règles d’ARIA, surtout la première.
• Utiliser l’APG comme catalogue de patterns fiables.

ARIA dans le paysage

Les WCAG disent quoi atteindre (« le rôle et l’état du composant sont exposés »). ARIA est l’un des moyens d’y arriver. C’est une spécification distincte du W3C — Accessible Rich Internet Applications — pensée pour les interfaces riches (widgets JavaScript) que le HTML seul ne sait pas décrire : un système d’onglets, un arbre, une modale, une barre de progression custom.

ARIA agit sur l’arbre d’accessibilité (vu en Partie 1) : il modifie le nom / rôle / valeur qu’un lecteur d’écran annonce, sans toucher aux pixels. Il se décline en trois familles d’attributs :

• Rôles (role) — ce qu’est l’élément : role="button", role="dialog", role="tab", role="navigation".
• États (states) — la condition actuelle, qui change dans le temps : aria-expanded, aria-checked, aria-disabled, aria-selected.
• Propriétés (properties) — des caractéristiques plus stables : aria-label, aria-labelledby, aria-describedby, aria-controls.

On approfondit chaque catégorie en Partie 6 ; ici, on situe l’outil.

Ce qu’ARIA fait — et ne fait PAS

C’est le malentendu à corriger tout de suite. ARIA ne fait qu’une chose : changer ce qui est annoncé aux technologies d’assistance. Il ne fournit aucun comportement.

Autrement dit, role="button" sur une <div> la fait annoncer « bouton »… mais elle reste inatteignable au clavier, n’a pas de focus, ne réagit ni à Entrée ni à Espace, et n’a aucun style. Tu dois tout recoder à la main. C’est là qu’ARIA devient un piège.

<!-- ❌ Annoncé « bouton », mais : pas focusable, pas de clavier, aucun comportement natif -->
<div role="button" onclick="valider()">Valider</div>
 
<!-- 😐 Rattrapage laborieux et fragile pour imiter le natif -->
<div role="button" tabindex="0"
     onclick="valider()"
     onkeydown="if (event.key === 'Enter' || event.key === ' ') valider()">
  Valider
</div>
 
<!-- ✅ Rôle, focus, clavier, états disabled : tout est natif et gratuit -->
<button type="button" onclick="valider()">Valider</button>

♿ Côté utilisateur — Face à la première <div role="button">, une personne au clavier ne peut même pas atteindre le bouton : Tab passe à côté. Une personne au lecteur d’écran l’entend bien « bouton », tente de l’activer… et rien ne se passe si le développeur a oublié le onkeydown. Le <button> natif, lui, est atteignable, activable par Entrée et Espace, et gère disabled. ARIA a menti sur l’étiquette sans livrer la fonction.

Les règles d’utilisation d’ARIA

Le W3C publie cinq règles d’ARIA (Rules of ARIA use). La première domine toutes les autres.

1. N’utilise pas ARIA si un élément ou attribut HTML natif existe avec la sémantique voulue. Préfère <button> à <div role="button">, <nav> à <div role="navigation">, <input type="checkbox"> à role="checkbox".
2. Ne change pas la sémantique native sans raison (<h2 role="button"> est presque toujours une erreur).
3. Tout composant ARIA interactif doit être utilisable au clavier.
4. Ne masque pas un élément focusable avec role="presentation" ou aria-hidden="true" : un élément atteignable au clavier mais masqué à la restitution crée un « trou » déroutant.
5. Tout élément interactif doit avoir un nom accessible.

💡 Réflexe — Avant de taper role=, pose-toi une seule question : « existe-t-il une balise HTML native pour ça ? » Bouton, lien, case, menu de navigation, champ, tableau, titre : oui, presque toujours. Le meilleur ARIA, c’est celui qu’on n’écrit pas, parce que le HTML natif apporte rôle et comportement et clavier d’un coup. ARIA se réserve aux composants qui n’ont pas d’équivalent natif.

L’APG : le catalogue de patterns

Quand ARIA est réellement nécessaire (onglets, modale, combobox, menu, arbre, carrousel…), ne l’invente pas : suis l’APG — ARIA Authoring Practices Guide, publié par le W3C. C’est un catalogue de patterns qui, pour chaque composant, donne :

• le rôle et les attributs ARIA attendus ;
• les interactions clavier conventionnelles (quelles touches font quoi) ;
• un exemple fonctionnel de référence.

L’APG n’est pas normatif (ce n’est pas une loi), mais c’est le standard de facto : il code les conventions que les utilisateurs de lecteurs d’écran connaissent déjà. Suivre l’APG, c’est parler la langue que ton utilisateur attend.

🧭 Sur A11yLearn — Le tableau de bord d’A11yLearn contient un composant d’onglets fait maison (des <div> avec des classes CSS) que le lecteur d’écran annonce comme du simple texte. Plutôt que de bricoler des role au hasard, on ouvrira la page Tabs de l’APG : elle nous donne les rôles (tablist, tab, tabpanel), les états (aria-selected), et la navigation clavier attendue (flèches gauche/droite, Home/End). On le construira en Partie 6 — ici, on retient juste où chercher le bon pattern.

📚 Aller plus loin — Spec WAI-ARIA et ARIA Authoring Practices Guide (APG) sur w3.org/WAI. Garde en tête l’adage officiel : « No ARIA is better than bad ARIA » — un mauvais ARIA (qui ment sur le rôle ou masque un état) est pire que pas d’ARIA du tout, car il trompe activement l’utilisateur.

✏️ Exercices

Exercice 1 — Corrige l’ARIA de trop. Un dev écrit <a href="/cours" role="button">Voir les cours</a> pour « que ce soit annoncé comme un bouton ». Qu’en penses-tu ?

Exercice 2 — div ou button ? Explique en deux phrases pourquoi <button> est presque toujours préférable à <div role="button" tabindex="0">, en te servant de la distinction « ARIA fait / ne fait pas ».

🧠 Quiz de révision

Chapitre suivant : Le RGAA (France) — la déclinaison française des WCAG, ses obligations concrètes et ses sanctions.