ARIA en HTML : les pièges à éviter et bonnes pratiques
En Bref : L'essentiel à retenir
- Les pages utilisant ARIA ont 41% d'erreurs d'accessibilité supplémentaires par rapport aux pages sans ARIA selon WebAIM.
- La première règle d'ARIA : si un élément HTML natif avec la sémantique voulue existe, utilisez-le plutôt qu'ARIA.
- Les erreurs fréquentes incluent les rôles redondants, les états statiques non mis à jour et aria-hidden sur des éléments interactifs.
- ARIA est indispensable pour les composants complexes non natifs en HTML, mais doit toujours être testé avec les technologies d'assistance.
ARIA (Accessible Rich Internet Applications) est un outil puissant pour rendre les interfaces web accessibles. Mais mal utilisé, il fait plus de mal que de bien. Les statistiques sont claires : les pages avec ARIA contiennent 41% d'erreurs d'accessibilité supplémentaires. Voici comment éviter les pièges.
La règle d'or : le HTML d'abord
Avant toute chose, retenez ce principe fondamental :
Si vous pouvez utiliser un élément HTML natif avec la sémantique et le comportement voulu, faites-le plutôt que d'ajouter ARIA.
Pourquoi privilégier le HTML natif ?
- Comportement intégré : Un
<button>est focusable et activable au clavier par défaut - Sémantique automatique : Un
<nav>est reconnu comme navigation sans attribut supplémentaire - Support universel : Les éléments HTML sont supportés par toutes les technologies d'assistance
- Moins de code : Pas besoin de JavaScript pour les interactions de base
Exemples concrets
Mauvais :
<div role="button" tabindex="0" onclick="action()">Cliquer</div>
Bon :
<button onclick="action()">Cliquer</button>
Mauvais :
<div role="navigation">...</div>
Bon :
<nav>...</nav>
Les erreurs les plus fréquentes
Voici les pièges dans lesquels tombent même les développeurs expérimentés.
1. Les rôles redondants
Ajouter un rôle sur un élément qui le possède déjà nativement est inutile et peut créer des comportements inattendus.
<!-- Inutile -->
<button role="button">OK</button>
<nav role="navigation">...</nav>
<main role="main">...</main>
<!-- Correct -->
<button>OK</button>
<nav>...</nav>
<main>...</main>
2. L'attribut aria-label mal orthographié
L'erreur la plus basique mais tellement fréquente : oublier le tiret.
<!-- Incorrect (ne fonctionne pas) -->
<button arialabel="Fermer">X</button>
<!-- Correct -->
<button aria-label="Fermer">X</button>
Astuce
Utilisez un linter d'accessibilité dans votre IDE pour détecter ces erreurs de syntaxe automatiquement.
3. aria-expanded statique non mis à jour
Un attribut aria-expanded doit refléter l'état réel du composant. Un attribut statique qui ne change jamais est pire que pas d'attribut du tout.
<!-- Problématique : jamais mis à jour -->
<button aria-expanded="false">Menu</button>
<!-- Correct : mis à jour par JavaScript -->
<button aria-expanded="false" id="menu-btn">Menu</button>
<script>
btn.addEventListener('click', () => {
const expanded = btn.getAttribute('aria-expanded') === 'true';
btn.setAttribute('aria-expanded', !expanded);
});
</script>
4. aria-hidden sur des éléments interactifs
Un élément avec aria-hidden="true" devient invisible pour les technologies d'assistance. S'il reste interactif, c'est un piège pour les utilisateurs.
<!-- Dangereux : bouton invisible mais cliquable -->
<button aria-hidden="true">Action</button>
<!-- Si vous voulez vraiment cacher et désactiver -->
<button aria-hidden="true" tabindex="-1" disabled>Action</button>
5. Surcharge ARIA inutile
Plus d'ARIA ne signifie pas plus d'accessibilité. Chaque attribut doit avoir un objectif clair.
<!-- Surcharge inutile -->
<button
role="button"
aria-label="Bouton de soumission"
aria-describedby="desc"
aria-pressed="false"
>
Soumettre
</button>
<span id="desc">Cliquez pour soumettre le formulaire</span>
<!-- Plus simple et tout aussi efficace -->
<button>Soumettre le formulaire</button>
Quand ARIA est vraiment nécessaire
ARIA devient indispensable pour les composants complexes qui n'existent pas nativement en HTML.
Composants nécessitant ARIA
Menus déroulants :
<button aria-expanded="false" aria-haspopup="menu">Options</button>
<ul role="menu" hidden>
<li role="menuitem">Option 1</li>
<li role="menuitem">Option 2</li>
</ul>
Onglets :
<div role="tablist">
<button role="tab" aria-selected="true" aria-controls="panel1">Onglet 1</button>
<button role="tab" aria-selected="false" aria-controls="panel2">Onglet 2</button>
</div>
<div role="tabpanel" id="panel1">Contenu 1</div>
<div role="tabpanel" id="panel2" hidden>Contenu 2</div>
Zones de mise à jour dynamique :
<div aria-live="polite" aria-atomic="true">
<!-- Contenu mis à jour dynamiquement -->
</div>
Les live régions
Pour annoncer des changements dynamiques sans déplacer le focus :
aria-live="polite": Annonce quand l'utilisateur est inactifaria-live="assertive": Interrompt pour annoncer immédiatementaria-atomic="true": Annonce tout le contenu, pas seulement les changements
Pour approfondir ce sujet, consultez notre article sur les live régions pour tableaux de bord.
Tester avec les technologies d'assistance
ARIA ne peut pas être validé par les seuls tests automatisés. Vous devez tester avec de vrais lecteurs d'écran.
Les combinaisons à tester
| Navigateur | Lecteur d'écran | Plateforme |
|---|---|---|
| Firefox | NVDA | Windows |
| Chrome | JAWS | Windows |
| Safari | VoiceOver | macOS |
| Safari Mobile | VoiceOver | iOS |
| Chrome | TalkBack | Android |
Points de vérification
- Les rôles sont-ils annoncés correctement ?
- Les états (expanded, selected, pressed) sont-ils communiqués ?
- Les mises à jour dynamiques sont-elles annoncées ?
- L'ordre de lecture est-il logique ?
Note
Chaque combinaison navigateur/lecteur d'écran peut avoir des comportements légèrement différents. Testez au minimum avec NVDA/Firefox et VoiceOver/Safari.
Les attributs ARIA les plus utiles
Pour les labels
aria-label: Texte de remplacement invisiblearia-labelledby: Référence à un élément visible servant de labelaria-describedby: Description supplémentaire
Pour les états
aria-expanded: Élément dépliablearia-selected: Élément sélectionnéaria-pressed: Bouton basculearia-checked: Case à cocher personnaliséearia-disabled: Élément désactivé visuellement mais présent dans le DOM
Pour les relations
aria-controls: Élément contrôlé par celui-ciaria-owns: Relation de propriétéaria-describedby: Élément décrivant celui-ci
Les ressources de référence
Documentation officielle
- WAI-ARIA Authoring Practices : Patterns recommandés par le W3C
- ARIA in HTML : Spécification d'utilisation d'ARIA avec HTML
- MDN Web Docs : Documentation détaillée en français
Outils de validation
- axe DevTools : Détecte les erreurs ARIA courantes
- WAVE : Signale les mauvais usages
- Notre outil : Audit RGAA vérifie la conformité ARIA
Conclusion
ARIA est un outil puissant mais dangereux entre des mains inexpertes. La clé est de toujours privilégier le HTML sémantique natif, de n'utiliser ARIA que pour les composants vraiment complexes, et de toujours tester avec les technologies d'assistance réelles. Avant de déployer des composants ARIA, vérifiez leur conformité avec notre outil d'audit et consultez notre guide ARIA complet.
Guides RGAA associés
Pour aller plus loin sur les sujets abordés dans cet article, consultez nos fiches techniques :
Chaque champ de formulaire doit avoir une étiquette (label) qui lui est liée explicitement.
Chaque image porteuse d'information doit avoir une alternative textuelle pertinente via l'attribut alt. Les images décoratives doivent avoir un attribut alt vide.
L'intitulé de chaque lien doit permettre de comprendre sa destination ou sa fonction, soit par l'intitulé seul, soit par l'intitulé complété par son contexte (phrase, titre de section, item de liste ou cellule de tableau).
Articles similaires
Votre site est-il conforme ?
Ne prenez pas de risques avec l'accessibilité. Lancez un audit complet de votre site en quelques minutes et obtenez un rapport détaillé des corrections à apporter.