Accessibilité RGAA avec React : le guide de correction
React ne rend pas un site inaccessible — mais ses habitudes le peuvent : composants sur des div, focus perdu au changement de route, modales sans piège de focus. Voici les corrections qui débloquent le plus de critères RGAA.
Sémantique : arrêtez la div soup
Un onClick sur une div n'est ni focusable ni annoncé par un lecteur d'écran. Utilisez les éléments natifs (button, a, label) : ils apportent gratuitement le rôle, le focus et la gestion clavier.
- Bouton d'action → <button>, pas <div onClick>.
- Lien de navigation → <a>/<Link>, avec un intitulé explicite.
- Champs → <label htmlFor> associé, jamais un simple placeholder.
Gérer le focus dans une SPA
Au changement de route, le navigateur ne recharge pas la page : le focus reste où il était et les utilisateurs au clavier/lecteur d'écran sont perdus. Déplacez le focus vers le titre de la nouvelle vue (ou un conteneur tabindex=-1) après la navigation.
Pour les modales : piégez le focus à l'intérieur, restaurez-le à l'élément déclencheur à la fermeture, et fermez sur Échap.
ARIA : le moins possible, le mieux
La première règle d'ARIA est de ne pas utiliser ARIA quand un élément natif existe. Réservez aria-label, aria-expanded, aria-live aux composants réellement custom (menus, tabs, toasts) et testez au clavier.
Scannez une page de votre app React
FAQ
eslint-plugin-jsx-a11y suffit-il ?
Il attrape les erreurs statiques (alt manquant, label absent) mais pas les problèmes d'exécution (focus, contraste, parcours). Un scan sur le rendu réel reste nécessaire.
Faut-il une librairie de composants accessibles ?
Des primitives comme Radix ou React-Aria aident beaucoup pour les composants complexes, mais ne dispensent pas de vérifier le résultat rendu.