Quelle différence entre role="status" et role="alert" ?

Le role="status" (implicitement aria-live="polite" et aria-atomic="true") fait annoncer le message par le lecteur d'écran une fois sa lecture en cours terminée : idéal pour une confirmation comme « Enregistré ». Le role="alert" (implicitement aria-live="assertive" et aria-atomic="true") interrompt pour l'annoncer immédiatement : à réserver aux messages urgents, par exemple une erreur bloquante. C'est l'objet du critère RGAA 7.5 (messages de statut). Dans les deux cas, la région doit exister dans le DOM avant d'être remplie, et le focus ne doit pas être déplacé.

Qu'est-ce qu'un piège de focus et pourquoi une modale en a besoin ?

Quand une modale est ouverte, la tabulation clavier doit rester à l'intérieur : après le dernier élément focusable, Tab revient au premier, et Maj+Tab fait l'inverse. Sans ce piège, la personne qui navigue au clavier peut « sortir » de la modale et interagir avec la page masquée derrière, ce qui est désorientant. À la fermeture, le focus doit revenir sur l'élément qui a ouvert la modale.

Le RGAA impose-t-il un style de focus visible ?

Oui. Le critère 10.7 exige que la prise de focus soit visible pour chaque élément susceptible de la recevoir. Concrètement : ne jamais appliquer outline: none sans fournir d'alternative, par exemple :focus-visible avec un anneau contrasté. Un focus invisible rend la navigation au clavier impraticable.

Faut-il toujours ajouter un aria-label ?

Non. On privilégie toujours le HTML natif : un bouton avec un texte visible n'a besoin d'aucun attribut ARIA. On ajoute aria-label (nom non visible) ou aria-labelledby (nom repris d'un élément existant) uniquement quand aucun libellé textuel n'est disponible, par exemple un bouton à icône seule. La règle d'or de WAI-ARIA reste : « pas d'ARIA vaut mieux qu'un mauvais ARIA ».

Ce code me rend-il conforme au RGAA ?

Ces patrons appliquent les bonnes pratiques WAI-ARIA et couvrent des exigences clés comme le focus visible, les messages de statut et le pilotage clavier. Mais la conformité d'un composant réel dépend de son intégration : il faut le tester au clavier et avec un lecteur d'écran comme NVDA ou VoiceOver dans votre contexte. Le code fourni est un point de départ fiable, pas une garantie de conformité.

Outil gratuit

Patterns ARIA prêts à coller

Les quatre patterns ARIA les plus critiques regroupés en un seul outil. Modale accessible, notifications dynamiques, focus ring conforme et attributs ARIA. Code HTML, JS, CSS et Tailwind générés à la volée, conformes RGAA 4.1 et WAI-ARIA.

En Bref

Quatre patrons ARIA critiques réunis en un outil : modale accessible, notifications (régions live), focus ring et attributs ARIA (aria-label / aria-labelledby / aria-describedby).
Une modale accessible combine role="dialog", aria-modal="true", un libellé (aria-labelledby), un piège de focus clavier, la fermeture par Échap et la restitution du focus au déclencheur.
Une notification s'annonce via une région live : role="status" (poli) pour une confirmation, role="alert" (assertif) pour une alerte urgente, sans jamais déplacer le focus.
La prise de focus doit rester visible (critère RGAA 10.7) : jamais de outline: none sans alternative :focus-visible contrastée.
Le code généré (HTML, JS, CSS, Tailwind) est un point de départ fiable ; un composant réel doit ensuite être testé au clavier et au lecteur d'écran. Ces patrons aident à la conformité, ils ne la garantissent pas.

Chargement des patterns…

Pour bien nommer vos composants, lisez notre guide aria-label ou aria-labelledby. L'ensemble des exigences est détaillé dans les critères RGAA.

Questions fréquentes

Allez plus loin dans l'accessibilité

Cet outil cible les patterns ARIA (modale, notifications, focus, labels), un aspect parmi d'autres de l'accessibilité. Lancez un audit complet gratuit pour analyser les 106 critères du RGAA.

Scanner mon site gratuitement