Qu’est-ce que WAI-ARIA et pourquoi l’utiliser ?
WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) est une spécification technique publiée par le W3C. Son objectif principal est de combler le fossé entre le contenu HTML statique et les interfaces utilisateur modernes et dynamiques, souvent construites avec JavaScript.
Pour un utilisateur voyant, un élément visuel comme un menu déroulant ou un onglet est intuitif. Cependant, pour une personne utilisant un lecteur d’écran, ces éléments ne sont pas toujours interprétés correctement si le HTML utilisé est générique (comme des balises <div> ou <span>). Les attributs ARIA permettent donc de fournir des informations sémantiques supplémentaires aux technologies d’assistance sans modifier la présentation visuelle de la page.
La règle d’or de l’accessibilité est la suivante : si un élément HTML natif existe et remplit la fonction souhaitée (par exemple, utiliser <button> au lieu de <div role="button">), utilisez-le. ARIA ne doit être utilisé que lorsque le HTML natif est insuffisant.
Les trois piliers des attributs ARIA
Le standard ARIA repose sur trois concepts fondamentaux : les rôles, les états et les propriétés. Comprendre la distinction entre ces trois notions est essentiel pour implémenter une accessibilité rigoureuse.
Les rôles (Roles)
Un rôle définit ce qu’est l’élément. Il indique au lecteur d’écran la nature de l’objet. Par exemple, role="navigation", role="main" ou role="alert". Contrairement aux états, un rôle est généralement statique : un bouton reste un bouton tout au long de la session.
Les états (States)
Les états décrivent la situation actuelle d’un élément et sont destinés à changer dynamiquement via JavaScript. Le plus courant est aria-expanded, qui indique si un menu est ouvert ou fermé, ou aria-checked pour une case à cocher personnalisée.
Les propriétés (Properties)
Les propriétés définissent des caractéristiques essentielles de l’élément qui ne changent pas forcément, mais qui apportent un contexte. Par exemple, aria-labelledby permet de lier un élément à son intitulé, tandis que aria-required="true" indique qu’un champ de formulaire est obligatoire.
Implémenter les rôles ARIA pour structurer le contenu
L’utilisation des rôles est particulièrement utile pour créer des composants d’interface complexes. Prenons l’exemple d’un système d’onglets (Tabs), qui n’existe pas nativement en HTML. Sans ARIA, un lecteur d’écran verrait simplement une liste de liens et des blocs de texte.
Voici comment structurer correctement un composant d’onglets pour le rendre accessible :
<div class="tabs-container">
<div role="tablist" aria-label="Sections de profil">
<button role="tab"
aria-selected="true"
aria-controls="panel-1"
id="tab-1">
Informations personnelles
</button>
<button role="tab"
aria-selected="false"
aria-controls="panel-2"
id="tab-2"
tabindex="-1">
Paramètres de sécurité
</button>
</div>
<div id="panel-1"
role="tabpanel"
aria-labelledby="tab-1">
<p>Contenu des informations personnelles...</p>
</div>
<div id="panel-2"
role="tabpanel"
aria-labelledby="tab-2"
hidden>
<p>Contenu des paramètres de sécurité...</p>
</div>n
lt;/div>
Dans cet exemple, role="tablist" regroupe les onglets, role="tab" identifie les éléments cliquables et role="tabpanel" désigne la zone de contenu associée. L’attribut aria-controls crée un lien logique entre l’onglet et son panneau.
Gérer les états et propriétés dynamiques
L’accessibilité ne s’arrête pas à la structure ; elle concerne également l’interaction. Lorsqu’une action utilisateur modifie l’interface, le lecteur d’écran doit en être informé en temps réel. C’est ici qu’interviennent les attributs d’état et les régions « live ».
Le contrôle de l’expansion
Pour un menu accordéon ou un menu burger, l’attribut aria-expanded est indispensable. Il doit être basculé entre true et false via JavaScript lors du clic.
<button aria-expanded="false" aria-controls="menu-list" id="menu-btn">
Menu principaln</button>
<ul id="menu-list" aria-labelledby="menu-btn" hidden>
<li><a href="/home">Accueil</a></li>
<li><a href="/about">À propos</a></li>n</ul>
Les régions ARIA Live
Certaines mises à jour de page se produisent sans rechargement (comme un message de confirmation après l’envoi d’un formulaire). Pour que l’utilisateur en soit informé, on utilise aria-live.
aria-live="polite": Le lecteur d’écran attend que l’utilisateur ait fini sa lecture actuelle avant d’annoncer la mise à jour.aria-live="assertive": L’annonce est prioritaire et interrompt l’utilisateur (à utiliser avec parcimonie pour les alertes critiques).
Exemple d’une zone de notification :
<div id="notification-area" aria-live="polite">
<!-- Le texte inséré ici dynamiquement sera lu par le lecteur d'écran -->
</div>
Les erreurs classiques et les bonnes pratiques d’accessibilité
L’utilisation incorrecte des attributs ARIA peut être plus préjudiciable que leur absence totale. Un rôle mal attribué peut induire l’utilisateur en erreur et rendre la navigation confuse.
| Erreur courante | Conséquence | Solution recommandée |
|---|---|---|
Utiliser role="button" sur un <div> sans gérer le clavier | L’utilisateur clavier ne peut pas activer l’élément | Utiliser la balise <button> native |
Redondance (ex: <nav role="navigation">) | Bruit inutile pour le lecteur d’écran | Supprimer le rôle ARIA si la balise HTML5 est sémantique |
Oublier de mettre à jour aria-expanded | L’utilisateur ignore si le menu est ouvert | Lier le changement d’état à l’événement JS de clic |
Pour valider vos implémentations, il est fortement recommandé d’utiliser des outils de test automatisés comme Axe ou Lighthouse, mais surtout de tester manuellement avec un lecteur d’écran tel que NVDA (Windows) ou VoiceOver (macOS).
Conclusion
L’utilisation des attributs ARIA est un levier puissant pour transformer une interface web visuellement riche en une expérience réellement inclusive. En maîtrisant les rôles, les états et les propriétés, vous permettez aux utilisateurs de technologies d’assistance de naviguer avec la même efficacité que les autres.
L’essentiel à retenir est la sobriété : privilégiez toujours le HTML sémantique et réservez ARIA pour les composants personnalisés et les interactions dynamiques. L’accessibilité n’est pas une option, mais une composante fondamentale de la qualité logicielle.
Avez-vous déjà rencontré des difficultés pour rendre un composant complexe accessible ? N’hésitez pas à partager vos retours d’expérience ou vos questions en commentaires.
