Comprendre les rôles d'accessibilité en HTML

Les rôles d’accessibilité indiquent aux technologies d’assistance ce qu’est un élément, et non à quoi il ressemble. Lorsqu’un lecteur d’écran rencontre un bouton, il doit savoir qu’il s’agit d’un bouton — qu’il s’agisse d’un élément natif <button> ou d’un composant personnalisé avec role="button". Se tromper sur ce point signifie que des millions d’utilisateurs ne peuvent pas naviguer efficacement dans votre interface.

Ce guide explique comment les rôles d’accessibilité s’intègrent dans l’arbre d’accessibilité plus large, quand utiliser les rôles ARIA par rapport au HTML sémantique, et les bonnes pratiques qui maintiennent votre code à la fois accessible et maintenable.

Comment fonctionnent les rôles dans l’arbre d’accessibilité

Chaque page web possède deux arbres : l’arbre DOM que vous connaissez, et l’arbre d’accessibilité que les technologies d’assistance lisent réellement. L’arbre d’accessibilité suit un modèle simple : chaque élément possède un nom, un rôle et une valeur/état.

<!-- Élément DOM -->
<button aria-pressed="true">Mute</button>

<!-- Représentation dans l'arbre d'accessibilité -->
Name: "Mute"
Role: button
Value/State: pressed=true

Le navigateur construit automatiquement cet arbre d’accessibilité à partir de votre HTML, en associant les éléments sémantiques à leurs rôles implicites. Un élément <nav> devient un repère de navigation, un <button> devient un widget bouton. Les rôles ARIA vous permettent de modifier cet arbre lorsque le HTML natif ne suffit pas — mais ils doivent être votre dernier recours, pas votre premier choix.

Les quatre principales catégories de rôles

Rôles de repères (Landmark Roles)

Les rôles de repères définissent les régions de la page pour la navigation. Le HTML5 moderne fournit la plupart de ces rôles nativement :

• <header> → rôle banner (lorsqu’il n’est pas dans <article> ou <section>)
• <nav> → rôle navigation
• <main> → rôle main
• <aside> → rôle complementary
• <footer> → rôle contentinfo (lorsqu’il n’est pas dans <article> ou <section>)

Bonne pratique : Utilisez les éléments HTML sémantiques plutôt que <div role="navigation">. La redondance de <nav role="navigation"> n’apporte aucune valeur — l’élément possède déjà ce rôle implicitement.

Rôles de widgets

Les rôles de widgets décrivent les contrôles interactifs. Ils sont cruciaux pour les composants personnalisés qui ne peuvent pas utiliser d’éléments natifs :

<!-- Bon : Interface à onglets personnalisée -->
<div role="tablist">
  <button role="tab" aria-selected="true">Settings</button>
  <button role="tab" aria-selected="false">Profile</button>
</div>

<!-- Mauvais : ARIA inutile -->
<button role="button">Click me</button> <!-- Redondant -->

Rôles de structure de document

Ces rôles décrivent l’organisation du contenu : titres, listes, articles et séparateurs. Encore une fois, privilégiez le HTML sémantique :

<!-- Préférez ceci -->
<article>
  <h2>Article Title</h2>
</article>

<!-- Plutôt que cela -->
<div role="article">
  <div role="heading" aria-level="2">Article Title</div>
</div>

Rôles abstraits

Les rôles abstraits comme command ou composite sont des modèles fondamentaux dans WAI-ARIA. Ne les utilisez jamais directement — ils existent uniquement pour que la spécification puisse définir d’autres rôles.

Bonnes pratiques modernes pour les rôles ARIA

Privilégiez d’abord le HTML sémantique

La première règle d’ARIA est de ne pas utiliser ARIA. Les éléments HTML natifs intègrent la prise en charge du clavier, la gestion du focus et la sémantique d’accessibilité :

<!-- Préférez toujours ceci -->
<button onclick="submit()">Submit</button>

<!-- Plutôt que cet anti-pattern -->
<div role="button" tabindex="0" onclick="submit()">Submit</div>

La version avec <div> nécessite du JavaScript supplémentaire pour la prise en charge du clavier, le style de focus et l’activation correcte — un travail que le bouton natif effectue automatiquement.

Évitez les rôles de repères redondants

Depuis HTML5, l’ajout de rôles explicites aux éléments sémantiques est inutile et peut créer de la confusion :

<!-- Ne faites pas cela -->
<main role="main">
<nav role="navigation">
<header role="banner">

<!-- Ces éléments ont déjà des rôles implicites -->
<main>
<nav>
<header>

Ne surchargez jamais les rôles interactifs natifs

Changer le rôle d’un bouton brise son comportement attendu :

<!-- Ne faites jamais cela -->
<button role="heading">Section Title</button>

<!-- Cela casse l'interaction au clavier et les attentes du lecteur d'écran -->

Quand les rôles personnalisés ont du sens

Les composants personnalisés nécessitent parfois réellement des rôles ARIA. Voici des cas d’usage valides :

Pattern de dialogue personnalisé

<div role="dialog" aria-labelledby="dialog-title" aria-modal="true">
  <h2 id="dialog-title">Confirm Action</h2>
  <button>Cancel</button>
  <button>Confirm</button>
</div>

Interface à onglets personnalisée

<div role="tablist" aria-label="User settings">
  <button role="tab" aria-selected="true" aria-controls="panel-1">General</button>
  <button role="tab" aria-selected="false" aria-controls="panel-2">Privacy</button>
</div>
<div role="tabpanel" id="panel-1">General settings content</div>

Gestion des descriptions et des labels

Pour les noms et descriptions accessibles, suivez cette hiérarchie :

1. Texte visible (meilleur pour tous les utilisateurs)
2. aria-labelledby (référence du texte visible ailleurs)
3. aria-describedby (ajoute des informations supplémentaires)
4. aria-label (lorsque le texte visible n’est pas possible)

<button aria-describedby="help-text">Delete</button>
<span id="help-text">This action cannot be undone</span>

Note : aria-description émerge dans WAI-ARIA 1.3 mais a un support limité. Restez sur aria-describedby pour le code en production.

Anti-patterns courants à éviter

Boutons basés sur des div : Créer <div role="button"> quand <button> fonctionne parfaitement
Soupe de rôles : Ajouter des rôles à chaque élément « au cas où »
Sémantiques conflictuelles : <h2 role="button"> mélange structure et interaction
Rôles redondants : <nav role="navigation"> n’apporte aucune valeur

Tester votre implémentation

Vérifiez toujours les rôles avec de vraies technologies d’assistance. Les outils de développement des navigateurs incluent désormais des inspecteurs d’arbre d’accessibilité — utilisez-les pour voir exactement ce que perçoivent les lecteurs d’écran. Testez avec NVDA sur Windows ou VoiceOver sur macOS pour vous assurer que vos rôles se traduisent par une expérience utilisable.

Conclusion

Les rôles d’accessibilité existent pour décrire ce qu’est quelque chose, et non à quoi cela ressemble. Le HTML sémantique natif fournit la plupart des rôles implicitement — utilisez-le en premier. Réservez les rôles ARIA aux composants véritablement personnalisés où le HTML ne suffit pas. Lorsque vous utilisez ARIA, assurez-vous qu’il s’aligne sur les directives WCAG et testez avec de vraies technologies d’assistance. Rappelez-vous : pas d’ARIA vaut mieux qu’un mauvais ARIA.

FAQ

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.