Technique31 mai 20268 min

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.
ARIAHTMLTechniqueaccessibilité

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 :

CODE
<div role="button" tabindex="0" onclick="action()">Cliquer</div>

Bon :

CODE
<button onclick="action()">Cliquer</button>

Mauvais :

CODE
<div role="navigation">...</div>

Bon :

CODE
<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.

CODE
<!-- 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.

CODE
<!-- 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.

CODE
<!-- 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.

CODE
<!-- 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.

CODE
<!-- 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 :

CODE
<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 :

CODE
<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 :

CODE
<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 inactif
  • aria-live="assertive" : Interrompt pour annoncer immédiatement
  • aria-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

NavigateurLecteur d'écranPlateforme
FirefoxNVDAWindows
ChromeJAWSWindows
SafariVoiceOvermacOS
Safari MobileVoiceOveriOS
ChromeTalkBackAndroid

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 invisible
  • aria-labelledby : Référence à un élément visible servant de label
  • aria-describedby : Description supplémentaire

Pour les états

  • aria-expanded : Élément dépliable
  • aria-selected : Élément sélectionné
  • aria-pressed : Bouton bascule
  • aria-checked : Case à cocher personnalisée
  • aria-disabled : Élément désactivé visuellement mais présent dans le DOM

Pour les relations

  • aria-controls : Élément contrôlé par celui-ci
  • aria-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.

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.