Retour au Blog
X

Accessibilité en React : au-delà de aria-label

Dans cet article

Mettre aria-label partout ne rend pas une interface accessible. Dans les projets avec compliance, ce qui aide le plus est le HTML sémantique, la navigation clavier et un feedback clair pour les lecteurs d’écran.

J’ai travaillé sur des dashboards LGPD, e-commerce et portails enterprise. Ces pratiques comptent pour qui utilise un lecteur d’écran ou seulement le clavier.


1. HTML sémantique avant ARIA

La règle WAI-ARIA tient : si un élément natif existe, utilisez-le.

tsx
// ❌ div qui fait semblant d’être un bouton
<div role="button" tabIndex={0} onClick={handleClick}>Enregistrer</div>

// ✅ vrai bouton
<button type="button" onClick={handleClick}>Enregistrer</button>

Utilisez <nav>, <main>, <article>, <button> et des headings en ordre (h1 → h2). Les lecteurs naviguent par landmarks — une div générique casse ce flux.


2. Focus visible et ordre de tabulation

Chaque élément interactif a besoin d’un :focus-visible clair. Ne supprimez pas l’outline sans alternative :

css
button:focus-visible {
  outline: 3px solid rgba(124, 58, 237, 0.55);
  outline-offset: 4px;
}

Dans les modales et menus, gardez le focus dans le panneau et rendez-le au bouton d’ouverture à la fermeture. Testez avec Tab et Shift+Tab seulement.


3. Accordéons et panneaux extensibles

Pour FAQ, filtres et menus, le bon pattern est :

  • aria-expanded sur le bouton trigger
  • aria-controls pointant vers l’id du panneau
  • role="region" sur le contenu avec aria-labelledby
tsx
<button
  aria-expanded={isOpen}
  aria-controls="faq-panel-1"
  id="faq-trigger-1"
>
  Question
</button>
<div id="faq-panel-1" role="region" aria-labelledby="faq-trigger-1">
  Réponse
</div>

Évitez display: none sans penser à l’annonce — le contenu doit être accessible quand il est ouvert.


4. Live regions pour les mises à jour dynamiques

Recherche, filtres et toasts doivent annoncer ce qui a changé :

tsx
<div aria-live="polite" aria-atomic="true" className="visually-hidden">
  {resultCount === 0 ? 'Aucun résultat' : `${resultCount} résultats`}
</div>

Utilisez polite pour les mises à jour normales et assertive seulement pour les erreurs critiques.


5. Testez avec outils et clavier

Automatisez le basique avec axe-core ou eslint-plugin-jsx-a11y, mais validez manuellement :

  • Navigation clavier seule
  • VoiceOver (macOS) ou NVDA (Windows)
  • Contraste avec Lighthouse ou DevTools

Un bon aria-label ne corrige pas un contraste faible ou des headings sautés.


Conclusion

L’accessibilité en React est du travail produit : HTML correct, focus prévisible, états annoncés et tests continus.

Commencez par le HTML natif, priorisez le clavier et testez avec des personnes réelles quand possible. Les interfaces accessibles sont souvent plus robustes pour tout le monde.

Glauber Ariel Magalhães

Écrit par Glauber Ariel Magalhães

Ingénieur logiciel senior. J'écris sur React, performance, accessibilité et sécurité — avec des exemples de projets réels.

Commentaires

Connectez-vous avec votre compte GitHub pour commenter. Les commentaires sont publics et stockés comme Discussions sur le dépôt de commentaires du blog.