ARIA, ce scalpel de l'accessibilité web

Quand ARIA est la bonne réponse

Si la première règle du W3C est "n'utilise pas ARIA", c'est qu'ARIA existe pour les cas où le HTML ne suffit pas. Et ces cas existent. Pas sur chaque page, mais quand tu les rencontres, ARIA est la seule réponse.

Le contenu qui change sans prévenir

Un message de succès qui apparaît après l'envoi d'un formulaire. Un compteur de panier qui se met à jour. Une notification d'erreur de connexion. Un message dans un chat. Dans tous ces cas, le contenu change visuellement, mais le lecteur d'écran ne le sait pas. Il lit la page telle qu'elle était au chargement. Sans instruction contraire, le nouveau contenu est invisible.

C'est le problème que résolvent les live regions, le seul mécanisme qui permet de dire au lecteur d'écran "quelque chose a changé, annonce-le". Sara Soueidan en détaille chaque nuance dans sa série de référence sur le sujet.

<!-- Confirmation non urgente — le lecteur d'écran
     attend une pause dans sa lecture -->
<p aria-live="polite">
  Article ajouté au panier (3 articles).
</p>
 
<!-- Erreur critique — le lecteur d'écran
     interrompt immédiatement sa lecture -->
<p aria-live="assertive">
  Connexion perdue. Tes modifications ne sont pas
  enregistrées.
</p>

aria-live="polite" est une notification discrète : le lecteur d'écran attend que l'utilisateur soit disponible avant d'annoncer le changement. aria-live="assertive" est une interruption : elle coupe ce que le lecteur d'écran est en train de dire pour annoncer le message immédiatement. La règle est simple : si l'utilisateur peut attendre, c'est polite. Si l'information est critique et urgente, c'est assertive.

L'élément <output> porte un rôle implicite status avec une live region polite, mais il est conçu pour les résultats de calcul, pas pour les notifications génériques. Pour le cas général, des confirmations d'action aux alertes d'erreur, aucun élément HTML natif ne couvre le besoin. C'est un cas où ARIA est la seule réponse.

Les widgets que le HTML n'a pas

Le HTML a des boutons, des liens, des cases à cocher, des champs de texte, des listes déroulantes. Mais il n'a pas d'onglets, pas d'arborescence dépliable, pas de combobox riche avec filtrage et groupes.

Le GOV.UK Design System et Heydon Pickering dans Inclusive Components montrent comment construire des onglets accessibles à partir d'une liste de liens internes : une <ul> avec des <li> et des <a href="#section">. Sans JavaScript, c'est une table des matières fonctionnelle. Avec JavaScript, la liste devient un groupe d'onglets :

<!-- Sans JavaScript : une table des matières -->
<ul>
  <li><a href="#general">Général</a></li>
  <li><a href="#securite">Sécurité</a></li>
  <li><a href="#notifications">Notifications</a></li>
</ul>
 
<!-- Avec JavaScript : les rôles ARIA
     transforment la sémantique -->
<ul role="tablist">
  <li role="presentation">
    <a role="tab" href="#general" id="tab-general"
       aria-controls="general" aria-selected="true">Général</a>
  </li>
  <li role="presentation">
    <a role="tab" href="#securite" id="tab-securite"
       aria-controls="securite" aria-selected="false"
       tabindex="-1">Sécurité</a>
  </li>
  <li role="presentation">
    <a role="tab" href="#notifications" id="tab-notifications"
       aria-controls="notifications" aria-selected="false"
       tabindex="-1">Notifications</a>
  </li>
</ul>
 
<section id="general" role="tabpanel" aria-labelledby="tab-general">
  <!-- ... -->
</section>

La <ul> devient un tablist, les <a> deviennent des tab, jusque-là, c'est la sémantique qui évolue avec le comportement. Mais les <li> posent un problème : dans un tablist, il n'y a pas de "liste d'éléments". Si tu les laisses tels quels, le lecteur d'écran annonce "liste, 3 éléments, onglet, Général", un mélange de deux sémantiques qui n'a aucun sens. Le role="presentation" efface la sémantique de list item sans retirer l'élément du DOM, c'est exactement le cas prévu par la deuxième règle d'ARIA : modifier la sémantique native quand elle entre en conflit avec le rôle réel de l'élément.

Le balisage ne fait que la moitié du chemin. Chaque <a> pointe vers son panneau via aria-controls, chaque panneau reçoit role="tabpanel" et aria-labelledby, et le JavaScript doit encore fournir la couche clavier : flèches gauche/droite pour circuler entre les onglets (le tabindex="-1" sort les onglets inactifs du parcours Tab, c'est le roving tabindex du pattern de l'APG), bascule d'aria-selected, masquage des panneaux inactifs. Sans cette couche, le composant annonce "onglet" mais se comporte comme une liste de liens : la promesse du rôle n'est pas tenue.

Le même principe s'applique aux tree views (une arborescence navigable au clavier) ou aux combobox riches (un champ avec filtrage, groupes et navigation clavier que <datalist> ne couvre pas). Dans tous ces cas, ARIA ne remplace pas le HTML, il le complète.

Les états que le HTML ne peut pas exprimer

Un menu déroulant est ouvert ou fermé. Un lien pointe vers la page courante. Un champ est lié à un message d'aide. Le HTML ne sait pas exprimer ces états, ARIA le fait :

<!-- Le bouton annonce "Menu, réduit" ou
     "Menu, développé" -->
<button aria-expanded="false"
        aria-controls="menu-navigation">
  Menu
</button>
<ul id="menu-navigation" hidden>
  <li><a href="/produits">Produits</a></li>
  <li><a href="/contact">Contact</a></li>
</ul>
 
<!-- Le lecteur d'écran annonce
     "Accueil, lien, page actuelle" -->
<nav aria-label="Navigation principale">
  <a href="/" aria-current="page">Accueil</a>
  <a href="/produits">Produits</a>
  <a href="/contact">Contact</a>
</nav>
 
<!-- Le message d'aide est lu après le champ -->
<label for="email">Adresse email</label>
<input id="email" type="email"
       aria-describedby="email-aide">
<p id="email-aide">
  Utilisée uniquement pour la confirmation
  de commande.
</p>

aria-expanded transforme un bouton muet en bouton qui annonce son état. aria-current="page" dit à l'utilisateur où il se trouve dans la navigation, sans ça, tous les liens se ressemblent. aria-describedby associe un texte d'aide à un champ sans toucher à son label : le lecteur d'écran lit d'abord le label, puis la description complémentaire.

Aucun attribut HTML natif ne fait ce travail. C'est ARIA dans son rôle exact : exprimer ce que le HTML ne peut pas dire.

Tester en profondeur

Les trois vérifications en 30 secondes de l'article précédent utilisent l'arbre d'accessibilité des outils de développement. C'est un bon premier filtre. Mais pour tester ce que l'utilisateur entend réellement, il faut activer un lecteur d'écran.

VoiceOver sur macOS

Active VoiceOver avec Cmd + F5 (Fn + Cmd + F5 sur les claviers récents, ou triple pression sur Touch ID). Navigue ta page avec Tab (éléments interactifs) et Ctrl + Option + flèches (lecture séquentielle). Écoute ce que le lecteur d'écran annonce pour chaque élément : le rôle, le nom, l'état.

Le rotor (Ctrl + Option + U) est ton outil d'audit structurel. Il affiche la liste des titres, des liens, des landmarks et des contrôles de formulaire. Si un élément manque dans le rotor alors qu'il devrait y être, ou s'il y apparaît avec un nom incompréhensible, ton ARIA a un problème.

Les autres lecteurs d'écran

VoiceOver n'est pas le seul outil, et tes utilisateurs n'utilisent pas tous macOS :

• NVDA + Firefox sur Windows : gratuit et open source, le plus utilisé par les développeurs sous Windows. Navigation par Tab (éléments interactifs) et flèches (lecture séquentielle). La liste d'éléments (Insert + F7) joue le même rôle que le rotor.
• JAWS + Chrome ou Edge sur Windows : la référence professionnelle, payant. Même logique de navigation, avec la liste de liens (Insert + F7) et la liste de titres (Insert + F6).
• TalkBack + Chrome sur Android : le lecteur d'écran mobile. Navigation par balayage (gauche/droite pour le séquentiel, haut/bas pour changer de mode de navigation). Le menu de lecture (balayage vers le bas puis vers la droite) donne accès aux titres, liens et contrôles.

Chaque lecteur d'écran a ses particularités, mais les signaux d'alerte restent les mêmes.

Ce qu'il faut écouter

Quatre signaux d'alerte :

1. Un rôle annoncé sans comportement. Le lecteur d'écran dit "bouton" mais Entrée ne fait rien. Tu as un role="button" sans gestionnaire clavier.

2. Un nom qui ne correspond pas. Le lecteur d'écran annonce "Trouver un produit" mais tu lis "Rechercher" à l'écran. Tu as un aria-label qui contredit le texte visible.

3. Un silence là où tu attends du contenu. Tu navigues avec Tab et le focus s'arrête sur un élément muet. Tu as un aria-hidden="true" sur un élément focusable.

4. Une annonce qui ne vient pas. Tu soumets un formulaire, un message de succès apparaît, mais le lecteur d'écran ne dit rien. Il manque un aria-live sur la zone de notification.

Chacun de ces signaux correspond à un anti-pattern de la section précédente. Le lecteur d'écran ne fait que révéler ce que l'arbre d'accessibilité contenait déjà.

Sources

• WebAIM Million 2026 — Accessibility analysis of the top 1,000,000 home pages
• W3C — Using ARIA
• W3C — ARIA Authoring Practices Guide, Read Me First
• W3C — WAI-ARIA 1.2 Specification
• GOV.UK Design System — Tabs component
• Heydon Pickering — Tabbed Interfaces, Inclusive Components
• Léonie Watson — Tink
• TetraLogical
• Ben Myers — Don't use aria-label on static text elements
• Sara Soueidan — Accessible notifications with ARIA Live Regions
• MDN — ARIA live regions
• W3C — F96: Failure due to the accessible name not containing the visible label text
• RGAA — Critères et tests