Exemples de rôles ARIA : un guide complet
Les exemples de rôles ARIA montrent comment les attributs de rôle mappent les éléments d’interface à l’arborescence d’accessibilité, et la spécification WAI-ARIA 1.2 définit 6 catégories de rôles (widget, structure de document, point de repère, région active, fenêtre et abstrait) couvrant plus de 80 rôles concrets. Ce guide présente des exemples pratiques prêts à copier pour chaque catégorie, ainsi que les règles qui déterminent quand un rôle aide et quand il nuit activement.
Points clés à retenir
- Les rôles ARIA indiquent à la technologie d’assistance ce qu’est un élément ; ils n’ajoutent jamais de comportement, de focus ou de prise en charge du clavier par eux-mêmes.
- La première règle d’utilisation d’ARIA est de préférer les éléments HTML natifs, qui portent déjà implicitement des rôles, des états et une gestion du clavier.
- Les six catégories de rôles WAI-ARIA 1.2 sont le widget, la structure du document, le point de repère, la région active, la fenêtre et l’abstrait — les rôles abstraits ne doivent jamais apparaître dans votre balisage.
- Les rôles Landmark sont les ARIA les plus rentables et les moins risqués que vous puissiez ajouter à un site XHTML/CSS existant.
- Les rôles de widget nécessitent presque toujours un mappage JavaScript pour l’interaction au clavier et la gestion de l’état, ou ils créent une expérience pire que le HTML simple.
- Valider chaque rôle avec un lecteur d’écran et un vérificateur automatisé ; un rôle valide dans la spécification peut toujours être erroné pour votre contenu.
Ce que font réellement les rôles ARIA
Les rôles ARIA sont des jetons que vous placez dans l’attribut role pour remplacer ou fournir l’identité sémantique d’un élément dans l’arborescence d’accessibilité. Un <div role="button"> indique à un lecteur d’écran d’annoncer “bouton”, mais le navigateur le traite toujours comme un conteneur générique : il n’est pas focalisable, il ne répond pas à Entrée ou Espace, et il n’a pas d’état désactivé.
Cet écart entre la sémantique annoncée et le comportement réel est la source la plus courante d’échec d’ARIA. Ce sont des exemples courants de rôles d’aria montrant comment la sémantique peut diverger du comportement.
La spécification WAI-ARIA, maintenue par le groupe de travail sur les applications Internet riches accessibles du W3C, définit les rôles ainsi que les états et les propriétés. Les rôles sont la couche « qu’est-ce que c’est » ; les états et les propriétés comme « aria-expanded », « aria-checked » et « aria-label » sont la couche « dans quelle condition se trouve-t-il ». Un rôle sans ses états requis est incomplet — role="checkbox" nécessite aria-checked, et role="combobox" nécessite aria-expanded plus une liste listbox contrôlée.
Les éléments HTML natifs portent des rôles implicites. <button> correspond au rôle du bouton, <nav> à la navigation, <h1> à <h6> au titre et <input type="checkbox"> à la case à cocher. Étant donné que le navigateur fournit automatiquement le rôle, le comportement du clavier et l’état, la première règle d’utilisation d’ARIA (documentée dans le guide des pratiques de création ARIA du W3C) consiste à utiliser la sémantique native chaque fois qu’un élément équivalent existe. Recherchez des rôles explicites uniquement lorsqu’aucun élément natif n’est approprié, comme une arborescence personnalisée ou un panneau à onglets construit à partir de <div>.
Les six catégories de rôles WAI-ARIA
WAI-ARIA 1.2 organise les rôles en six catégories, et savoir à quelle catégorie appartient un rôle vous indique combien de JavaScript vous lui devez. Voici quelques exemples courants de rôles d’aria :
Connexes : — Widget d'accessibilité avec plan gratuit pour gagner aujourd'hui.
| Catégorie | Objectif | Exemples de rôles | Javascript requis ? |
|---|---|---|---|
| Widget | Contrôles interactifs | bouton, case à cocher, onglet, curseur, combobox | Oui – clavier + état |
| Structure du document | Organisation du contenu | titre, liste, listitem, table, article | Non |
| Point de repère | Régions de page pour la navigation | bannière, main, navigation, complémentaire | Non |
| Région en direct | Annoncer des mises à jour dynamiques | alerte, statut, log, timer | Habituellement — pour déclencher des mises à jour |
| Fenêtre | Sous-fenêtres et boîtes de dialogue | dialogue, dialogue d'alerte | Oui – gestion de la concentration |
| Abstrait | Rôles de superclasse, jamais créés | widget, input, section, landmark | N/A — ne pas utiliser |
Les rôles abstraits n’existent que pour organiser la taxonomie. Écrire role="input" ou role="section" dans votre HTML est une erreur de validation et produit des annonces imprévisibles car ces rôles n’ont pas de comportement défini pour la technologie d’assistance.
Exemples de rôles de point de repère
Les rôles Landmark sont les exemples de rôles ARIA les plus sûrs et les plus efficaces que vous puissiez ajouter à un ancien site XHTML/CSS, car ils ne nécessitent aucun JavaScript et correspondent directement aux régions que vous possédez déjà. Un squelette de page typique :
<header role="banner">
<nav role="navigation" aria-label="Principal">
<ul>...</ul>
</nav>
</header>
<main role="main">
<article>...</article>
<aside role="complementary" aria-label="Artículos relacionados">...</aside>
</main>
<footer role="contentinfo">...</footer>Chaque rôle de marqueur correspond à un élément natif — banner à <header> au niveau supérieur, main à <main>, navigation à <nav>, complementary à <aside>, contentinfo à <footer>. Lorsque vous utilisez l’élément natif, le rôle est implicite et vous ne devez pas le répéter. L’attribut explicite role gagne sa place uniquement lorsque vous êtes coincé avec le balisage <div> que vous ne pouvez pas modifier, ce qui est courant dans les anciens modèles et les sorties CMS.
Ça vaut le coup d'oeil : — Accessibilité gérée : automatisation combinée avec révision humaine.
Deux mises en garde s’imposent ici. Premièrement, banner, main et contentinfo doivent apparaître une fois par page ; plusieurs points de repère « principaux » perturbent la navigation. Deuxièmement, lorsque plusieurs points de repère du même type existent – par exemple trois éléments «
Questions fréquentes
Que sont les rôles ARIA et comment fonctionnent-ils ?
Les rôles ARIA sont des valeurs dans l'attribut role qui définissent l'identité d'un élément dans l'arborescence d'accessibilité, afin que les lecteurs d'écran l'annoncent correctement. Ils modifient uniquement la sémantique, pas l'apparence, le focus ou le comportement du clavier. La spécification WAI-ARIA 1.2 définit six catégories de rôles et plus de 80 rôles concrets, chacun avec des états et des propriétés requis.
Quand dois-je utiliser des rôles ARIA au lieu du HTML natif ?
Utilisez les rôles ARIA uniquement lorsqu'aucun élément HTML natif ne fournit la sémantique dont vous avez besoin. Les éléments natifs comme <button>, <nav> et <input type='checkbox'> portent des rôles implicites ainsi qu'une prise en charge du clavier et une gestion de l'état intégrées. La première règle d'utilisation d'ARIA est de préférer la sémantique native et d'ajouter des rôles explicites uniquement pour les widgets personnalisés ou le balisage hérité que vous ne pouvez pas restructurer.
Quelle est la différence entre les rôles ARIA et les attributs ARIA ?
Les rôles ARIA répondent « quel est cet élément », tandis que les attributs ARIA tels que aria-expanded, aria-checked et aria-label répondent « dans quel état se trouve-t-il » ou « comment s'appelle-t-il ». Les rôles et leurs attributs requis fonctionnent ensemble : comme exemples de rôles aria, role='checkbox' est incomplet sans aria-checked, et role='combobox' a besoin d'aria-expanded plus une listbox contrôlée.
Puis-je utiliser des rôles ARIA sur n’importe quel élément HTML ?
Les rôles ARIA peuvent être appliqués à la plupart des éléments, mais certaines combinaisons sont invalides ou nuisibles. Les rôles abstraits tels que widget et entrée ne doivent jamais être créés. Changer le rôle d'un lien en role='button' interrompt le comportement attendu du lien, et role='presentation' sur un élément focalisable supprime sa sémantique tout en le laissant dans l'ordre des tabulations.
Les rôles ARIA fonctionnent-ils sans JavaScript ?
La structure du document et les rôles de repère fonctionnent sans JavaScript car ils modifient uniquement la sémantique. Les rôles de widget tels que l'onglet, le curseur et la zone de liste déroulante nécessitent JavaScript pour implémenter l'interaction du clavier et mettre à jour les états. Sans cela, l'élément s'annonce comme un contrôle mais ne se comporte pas comme tel, ce qui est pire que du HTML simple.
Comment puis-je vérifier si mes rôles ARIA sont corrects ?
Combinez les tests automatisés et manuels. Exécutez ax DevTools, WAVE ou Lighthouse pour détecter les rôles non valides et les attributs requis manquants, puis testez avec NVDA, JAWS et VoiceOver pour confirmer les annonces et le comportement du clavier. Le panneau Accessibilité dans Chrome et Firefox DevTools affiche le rôle calculé, révélant tous les rôles que le navigateur remplace ou ignore.
Comment utiliser les WCAG sans consulter le code ?
Superposición de IA qui promet d’obtenir les WCAG dans 48 heures