Technique2 août 20265 min

La première règle d'ARIA : préférer le HTML natif à ARIA

En Bref : L'essentiel à retenir

  • "Si vous pouvez utiliser un élément HTML natif avec la sémantique requise, faites-le plutôt que d'ajouter ARIA" - W3C WAI-ARIA Authoring Practices.
  • Les pages utilisant ARIA présentent en moyenne 34,2% d'erreurs d'accessibilité en plus que celles sans ARIA selon WebAIM 2025.
  • ARIA n'ajoute pas de comportement, seulement de la sémantique : un div avec role="button" n'est pas cliquable au clavier sans JavaScript supplémentaire.
ARIAHTMLSémantiqueAccessibilité

ARIA (Accessible Rich Internet Applications) est une spécification technique puissante qui permet de rendre accessibles les interfaces web complexes. Mais son utilisation est devenue un piège pour de nombreux développeurs. Le rapport WebAIM Million 2025 révèle un paradoxe frappant : les pages utilisant ARIA présentent 34,2% d'erreurs d'accessibilité en plus que celles sans ARIA.

Ce n'est pas qu'ARIA est mauvais, c'est qu'il est mal utilisé. La première règle d'ARIA est souvent ignorée : "Ne pas utiliser ARIA si vous pouvez vous en passer."

Qu'est-ce qu'ARIA et pourquoi existe-t-il ?

Le problème qu'ARIA résout

Le HTML offre un ensemble d'éléments avec une sémantique prédéterminée : <button>, <input>, <nav>, etc. Les technologies d'assistance comprennent ces éléments nativement.

Mais les interfaces modernes vont au-delà : onglets, arbres hiérarchiques, carrousels, éditeurs WYSIWYG... Ces composants n'existent pas en HTML natif. ARIA permet de leur donner une sémantique que les lecteurs d'écran comprennent.

Ce qu'ARIA fait

ARIA ajoute de la sémantique aux éléments HTML via :

  • Rôles : qu'est cet élément ? (role="tab", role="menu")
  • Propriétés : quelles sont ses caractéristiques ? (aria-label, aria-describedby)
  • États : quel est son état actuel ? (aria-expanded, aria-selected)

Ce qu'ARIA ne fait PAS

ARIA n'ajoute aucun comportement. C'est le point crucial que beaucoup oublient.

CODE
<!-- Ceci N'EST PAS un bouton fonctionnel -->
<div role="button">Valider</div>

<!-- Il manque :
  - La possibilité de recevoir le focus (tabindex)
  - L'activation au clavier (Entrée/Espace)
  - L'apparence de bouton (CSS)
-->

Note

Un élément natif HTML fournit rôle, comportement et souvent style par défaut. ARIA ne fournit que le rôle.

Les 5 règles d'ARIA

Règle 1 : N'utilisez pas ARIA si vous pouvez utiliser HTML natif

C'est LA règle fondamentale. Si un élément HTML natif fait le travail, utilisez-le.

CODE
<!-- INCORRECT : ARIA inutile -->
<div role="button" tabindex="0" onclick="submit()">Envoyer</div>

<!-- CORRECT : élément natif -->
<button type="submit">Envoyer</button>

L'élément <button> fournit automatiquement :

  • Le rôle "button" pour les technologies d'assistance
  • La réception du focus
  • L'activation par Entrée et Espace
  • L'apparence de bouton (modifiable par CSS)

Règle 2 : Ne modifiez pas la sémantique native sauf nécessité absolue

CODE
<!-- INCORRECT : rôle contradictoire -->
<h2 role="button">Titre cliquable</h2>

<!-- CORRECT : structure cohérente -->
<h2>
  <button type="button">Titre cliquable</button>
</h2>

Règle 3 : Tous les composants ARIA doivent être utilisables au clavier

Si vous créez un composant custom avec ARIA, vous devez implémenter tout le comportement clavier attendu.

CODE
<!-- Tabs accessibles : nécessitent du JavaScript -->
<div role="tablist">
  <button role="tab" aria-selected="true" aria-controls="panel1">Tab 1</button>
  <button role="tab" aria-selected="false" aria-controls="panel2">Tab 2</button>
</div>
<div role="tabpanel" id="panel1">Contenu 1</div>
<div role="tabpanel" id="panel2" hidden>Contenu 2</div>

<!-- Script nécessaire pour :
  - Flèches gauche/droite pour changer de tab
  - Home/End pour premier/dernier tab
  - Gestion de aria-selected
  - Affichage du bon panel
-->

Règle 4 : N'utilisez pas role="presentation" ou aria-hidden sur les éléments focusables

CODE
<!-- INCORRECT : élément focusable caché -->
<button aria-hidden="true">Bouton invisible mais focusable</button>

<!-- Problème : l'utilisateur peut naviguer vers un élément "invisible"
pour les technologies d'assistance -->

Règle 5 : Tous les éléments interactifs doivent avoir un nom accessible

CODE
<!-- INCORRECT : bouton sans nom -->
<button>
  <svg><!-- icone recherche --></svg>
</button>

<!-- CORRECT : nom accessible -->
<button aria-label="Rechercher">
  <svg aria-hidden="true"><!-- icone recherche --></svg>
</button>

Quand ARIA est-il vraiment nécessaire ?

1. Composants qui n'existent pas en HTML

Certains patterns d'interface n'ont pas d'équivalent HTML natif :

  • Tabs/onglets : role="tablist", role="tab", role="tabpanel"
  • Accordéons : aria-expanded
  • Menus déroulants : role="menu", role="menuitem"
  • Arbres hiérarchiques : role="tree", role="treeitem"
  • Dialogues modaux : role="dialog", aria-modal

2. Contenu dynamique

Les modifications de contenu doivent être annoncées :

CODE
<!-- Région live pour les notifications -->
<div aria-live="polite" aria-atomic="true">
  3 nouveaux messages.
</div>

<!-- Annonce d'erreur de formulaire -->
<span role="alert">
  Veuillez corriger les erreurs ci-dessous.
</span>

3. Relations entre éléments

Quand le HTML ne peut pas exprimer une relation :

CODE
<!-- Description associée à un champ -->
<input type="password" aria-describedby="pwd-rules">
<p id="pwd-rules">
  8 caractères minimum, 1 majuscule, 1 chiffre.
</p>

<!-- Compteur de caractères -->
<textarea aria-describedby="char-count"></textarea>
<span id="char-count">0/500 caractères</span>

4. Masquer le contenu décoratif

CODE
<!-- Icône décorative -->
<button>
  <svg aria-hidden="true"><!-- icone --></svg>
  Ajouter au panier
</button>

Erreurs ARIA courantes

1. ARIA redondant

CODE
<!-- INUTILE : le rôle est déjà implicite -->
<nav role="navigation">...</nav>
<button role="button">Cliquer</button>
<a href="/" role="link">Accueil</a>

2. aria-label quand le texte visible suffit

CODE
<!-- INUTILE : le texte visible est le nom accessible -->
<a href="/contact" aria-label="Page de contact">Contact</a>

<!-- CORRECT -->
<a href="/contact">Contact</a>

3. role="button" sans comportement clavier

CODE
<!-- Problème : pas activable au clavier -->
<div role="button" onclick="action()">Click me</div>

<!-- SOLUTION complète -->
<div
  role="button"
  tabindex="0"
  onclick="action()"
  onkeydown="if(event.key==='Enter'||event.key===' ')action()"
>
  Click me
</div>

<!-- MEILLEURE SOLUTION : utilisez button -->
<button type="button" onclick="action()">Click me</button>

4. aria-hidden="true" sur du contenu interactif

CODE
<!-- DANGEREUX : liens invisibles mais navigables -->
<div aria-hidden="true">
  <a href="/important">Lien important</a>
</div>

Outils pour vérifier l'utilisation d'ARIA

Notre outil d'audit

Notre outil d'audit RGAA détecte automatiquement :

  • Les rôles ARIA redondants
  • Les éléments avec rôle sans comportement
  • Les problèmes d'aria-label
  • Les conflits aria-hidden

Extensions navigateur

  • axe DevTools : signale les mauvaises pratiques ARIA
  • WAVE : indique les erreurs ARIA en contexte
  • Accessibility Insights : vérifications ARIA détaillées

Test manuel

  1. Naviguez au clavier : tous les éléments interactifs sont-ils accessibles ?
  2. Utilisez un lecteur d'écran : les composants sont-ils correctement annoncés ?
  3. Vérifiez l'arbre d'accessibilité dans les DevTools

Astuce

Chrome DevTools > Éléments > Accessibility pane vous montre l'arbre d'accessibilité et le nom calculé de chaque élément.

Conclusion

ARIA est un outil puissant mais dangereux entre des mains inexpertes. La première règle "n'utilisez pas ARIA si vous pouvez vous en passer" devrait guider toutes vos décisions.

Avant d'ajouter un attribut ARIA, posez-vous ces questions :

  1. Un élément HTML natif peut-il faire le travail ?
  2. Ai-je implémenté tout le comportement clavier nécessaire ?
  3. Cet ARIA apporte-t-il vraiment quelque chose ?

Le HTML sémantique correctement utilisé couvre 90% des besoins d'accessibilité. ARIA est là pour les 10% restants, pas pour compenser un HTML mal structuré. Maîtrisez d'abord les bases HTML avant de vous aventurer dans ARIA.

Questions fréquentes

Quelle est la première règle d'ARIA ?

Ne pas utiliser ARIA quand un élément HTML natif porte déjà la sémantique voulue. Un bouton natif apporte gratuitement le rôle, l'activation au clavier par Entrée et Espace, la prise de focus et l'état désactivé ; un div doté d'un rôle de bouton n'apporte que le rôle.

ARIA ajoute-t-il du comportement à un élément ?

Non, uniquement de la sémantique. Un élément portant role égal button est annoncé comme un bouton mais ne devient ni focusable ni activable au clavier pour autant. Il faut ajouter tabindex égal 0 et gérer soi-même les touches Entrée et Espace, travail que l'élément natif rend inutile.

Pourquoi les pages qui utilisent ARIA comptent-elles plus d'erreurs ?

Parce qu'ARIA est employé le plus souvent pour rattraper une sémantique absente, et qu'un rôle posé sans le comportement correspondant crée un problème là où il n'y en avait pas. La règle pratique est qu'un ARIA mal utilisé vaut moins qu'aucun ARIA du tout.

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.