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.

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.