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 :
cssbutton: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-expandedsur le bouton triggeraria-controlspointant vers l’id du panneaurole="region"sur le contenu avecaria-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.




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.