Liste des rôles ARIA : meilleures références comparées

La liste des rôles ARIA comprend 82 valeurs définies dans la spécification WAI-ARIA 1.2 du W3C, organisées en six catégories fonctionnelles : rôles de document, de point de repère, de widget, de structure, de fenêtre et d’état abstrait. Choisir la référence appropriée pour les consulter dépend du fait que vous ayez besoin d’un un tableau rapide, une documentation avec des exemples de code ou un guide de décision concernant chaque application.

Points clés à retenir

• La spécification WAI-ARIA 1.2 définit 82 rôles, mais seul un sous-ensemble réduit est utilisé dans la pratique quotidienne d’un site XHTML/CSS accessible.
• La première règle d’ARIA est toujours vigente : s’il existe un élément HTML natif avec la sémantique nécessaire, utilisez-le à la place d’ajouter un rôle.
• Les rôles abstraits (comme role="widget" ou role="input") ne doivent pas être écrits dans le balisage ; ils servent uniquement de comme base taxonomique.
• Une référence utile pour le front-end doit inclure le rôle, ses attributs obligatoires ARIA, les états autorisés et un exemple de balisage réel.
• Les rôles de point de repère et de widget concentrent la plupart des erreurs détectées par les auditeurs automatiques comme axe-core ou Lighthouse.

Qu’est-ce qu’un rôle ARIA et pourquoi il faut une liste fiable

Un rôle ARIA est une valeur qui est attribuée à un élément intermédiaire dans l’attribution du « rôle » pour indiquer aux technologies d’assistance le type de composant qu’il représente. Le navigateur expose ce rôle en passant par l’arbre d’accessibilité, et un lecteur d’écran comme NVDA, JAWS ou VoiceOver le traduit dans une annonce concrète : “bouton”, “onglet”, “région”, “boîte de dialogue”.

La spécification WAI-ARIA, gérée par le W3C dans le groupe de travail ARIA, définit chaque rôle conjointement avec ses attributs d’état et de propriété autorisés. La version 1.2 est la recommandation actuelle, et ARIA 1.3 est disponible. Pour un développeur travaillant avec XHTML et CSS, la liste des rôles n’est pas un catalogue décoratif : chaque valeur mal appliquée génère un conflit entre la sémantique native de l’élément et la déclaration, et les lecteurs d’écran résolvent ce conflit de formes distinctes selon le navigateur.

La documentation officielle des rôles d’ARIA sur MDN (Mozilla Developer Network) est la référence technique la plus consultée en espagnol et en anglais, mais elle n’est pas la seule. Il existe des feuilles de référence, des guides de modèles et des outils de validation qui nécessitent des distinctions. Les comparer aide à choisir celle qui s’adapte à votre flux de travail.

Les six catégories de rôles ARIA

La taxonomie officielle du groupe définit les rôles selon votre fonction. Connaître les catégories permet d’éviter de chercher dans la mauvaise liste.

Rôles du document. Décrit la structure d’une page ou d’une section : article, document, feed, heading, img, list, listitem, math, none, note, presentation, row, separator, table, term, toolbar, tooltip. Beaucoup d’entre eux font doublon avec des éléments HTML natifs, c’est pourquoi ils sont rarement écrits à la main.

Connexes : UserWay — Widget d'accessibilité avec plan gratuit pour gagner aujourd'hui.

Rôles de point de repère. Définissez les zones navigables de la page : banner, complémentaire, contentinfo, form, main, navigation, region, search. C’est ce qui est le plus utilisé sur les sites dont la sémantique HTML est incomplète.

Rôles des widgets. Représente les contrôles interactifs : button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, radio, scrollbar, searchbox, slider, spinbutton, switch, tab, tabpanel, textbox, treeitem. Nécessite une gestion du focus et du clavier.

Rôles de structure. Les widgets d’organisation incluent : application, grid, group, listbox, menu, menubar, radiogroup, tablist, tree, treegrid, rowgroup, columnheader, rowheader.

Ça vaut le coup d'oeil : AudioEye — Accessibilité gérée : automatisation combinée avec révision humaine.

Rôles des fenêtres. Gestion de contenu superposé ou modal : alertdialog, dialog.

Rôles abstraits. Aucun élément n’est écrit dans le balisage : command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget, window. Ils servent à ce que la spécification hérite des propriétés entre les rôles.

Comparatif : les meilleures références de rôles ARIA

Le tableau suivant compare les références les plus utilisées par les développeurs hispanophones selon les critères pratiques.

Référence	Type	Langues	Exemples de code	Idéal pour
MDN Web Docs (Rôles ARIA)	Documentation officielle	Multilingue (inclut l’espagnol)	Oui, pour un rôle	Consultation technique profonde
WAI-ARIA 1.2 (W3C)	Spécification normative	Francés	Non	Vérifier le comportement exact
Guide des pratiques de création WAI-ARIA	Guide des clients	Francés	Oui, modèles complets	Implémenter des widgets avec clavier
Feuille de triche de type de référence	Tableau résumé	Francés	Minimaux	Repas rapide dans l’éditeur
accessibility.build (référence ARIA)	Référence pratique	Francés	Oui	Apprendre avec des exemples commentés
Auditores (axe-core, Lighthouse)	Outils	Multilingue	Non	Détecter les rôles invalides

Le choix dépend du moment. Durant l’écriture du marquage, une feuille de référence compacte gagne en rapidité. Lors du débogage d’un widget qui n’annonce pas correctement son état, la spécification du W3C et le guide des clients de WAI sont les sources qui résolvent le problème.

Comment décider quel rôle appliquer : critères pratiques

La décision correcte est toujours prise en écartant ARIA. Ces critères, ordonnés, évitent la majorité des erreurs.

1. Existe-t-il un élément HTML natif ? Un <button> a déjà le rôle implicite d’un bouton. L’ajout de role="button" est redondant et peut introduire des conflits.
2. Le rôle nécessite-t-il des attributs obligatoires ? role="checkbox" nécessite aria-checked. role="slider" nécessite aria-valuenow, aria-valuemin et aria-valuemax. Si vous ne pouvez pas maintenir ces états, le rôle nuit plus qu’il n’aide.
3. Le rôle implique-t-il la gestion du clavier ? Les rôles de widget nécessitent une navigation avec des flèches, Début, Fin et Échap selon le modèle. Un role="tablist" sans gestion des flèches est pire que de ne pas l’avoir.
4. Le rôle est-il abstrait ? S’il figure dans la liste des rôles abstraits, il ne doit pas être écrit.
5. Le rôle est-il obsolète ou désuet ? Certaines valeurs ont été modifiées entre ARIA 1.0 et 1.2. Consultez toujours la version actuelle.

La première règle d’utilisation d’ARIA, reconnue dans le guide des techniques du W3C, est le principe : utiliser le HTML natif autant que possible. ARIA est un correctif lorsque HTML ne suffit pas, et non un substitut.

Connexes : IAAP CPACC / WAS Certification — La certification professionnelle qui accrédite votre expérience en accessibilité.

Erreurs fréquentes lors de la consultation et application de la liste des rôles

Une erreur habituelle consiste à copier un rôle d’une feuille de référence sans vérifier ses attributs requis. role="combobox" dans ARIA 1.2 a changé par rapport à la version 1.0 et attend désormais que aria-expanded et une relation avec une listbox via aria-controls. Appliquer l’ancienne version rompt l’annonce dans les lecteurs mis à jour.

Il est également courant d’utiliser role="presentation" ou role="none" pour “nettoyer” la sémantique sans comprendre que cela élimine l’élément de l’arborescence d’accessibilité, y compris ses enfants dans certains cas. Cela apparaît également avec la fréquence role="application", qui transfère tout le contrôle du clavier au widget et désactive les raccourcis du lecteur d’écran ; il est réservé aux applications Web complexes, pas aux formulaires.

Les rôles des duplications de points de repère génèrent une confusion : deux role="main" sur la même page, ou un role="banner" à l’intérieur d’un <article>, produisent une navigation par régions incohérente. La validation avec axe-core ou avec les outils d’accessibilité du navigateur détecte divers cas, même si aucun outil automatique ne remplace la vérification par le lecteur de l’écran réel.

Si vous faites du shopping : accessiBe — Superposición de IA qui promet d’obtenir les WCAG dans 48 heures.

Outils pour valider les rôles dans votre balisage

La compréhension des rôles combine une inspection manuelle et une automatisation. Les DevTools de Chrome et Firefox incluent un panneau d’accessibilité qui montre l’arbre tel qu’il est reçu par le système d’exploitation, avec le rôle calculé de chaque nœud. C’est la forme la plus directe de voir si un rôle déclaré subsiste ou est écrasé par la sémantique native.

axe-core, intégré à Lighthouse et disponible comme extension, signale les rôles invalides, les attributs obligatoires manquants et combinaisons contradictoires. L’extension Accessibility Insights for Web, basée sur les règles de l’axe, ajoute des vérifications guidées. Pour les tests effectués par les utilisateurs réels, NVDA sur Windows et VoiceOver sur macOS proposent la vérification définitive : aucun validateur n’est détecté si l’annonce est compréhensible dans le contexte.

La documentation d’accessibilité de MDN et le guide des clients de WAI-ARIA du W3C sont les deux sources qui vous permettront d’être ouvertes pendant le développement. La première explication de chaque rôle ; la deuxième montre comment ils se combinent en composants complets.

Sources et lectures complémentaires

• WAI-ARIA — Wikipédia : Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) est une spécification technique publiée par le World Wide Web Consortium (W3C) qui…

Questions fréquemment posées

Combien de rôles ARIA existent-il ?

La spécification W3C WAI-ARIA 1.2 définit 82 rôles au total, répartis entre les rôles de document, de point de repère, de widget, de structure, de fenêtre et abstrait. Dans ce contexte, seule une fraction est utilisée dans le développement habituel : les rôles abstraits ne sont jamais écrits et de nombreux rôles de document dupliquent des éléments HTML natifs.

Quelle est la différence entre un rôle ARIA et un attribut ARIA ?

Un rôle ARIA décrit ce qu’est un élément, tandis que les attributs ARIA décrivent son état ou vos propriétés. Par exemple, role="checkbox" identifie le composant et aria-checked="true" communique s’il est coché. Les rôles sont attribués à l’attribut « rôle » ; les états et propriétés utilisent le préfixe « aria- ».

Vous souhaitez utiliser ARIA si vous utilisez HTML sémantique ?

Dans la majorité des cas, non. Le HTML sémantique expose déjà des rôles implicites : <nav> est équivalent à role="navigation" et <main> est équivalent à role="main". L’ajout explicite du rôle est redondant et peut créer des conflits. ARIA est réservé aux composants que HTML ne couvre pas, comme les onglets, les arborescences ou les menus complexes.

Quels rôles ARIA ne dois-je jamais écrire dans le balisage ?

Les rôles abstraits ne doivent jamais apparaître : command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget et window. Ils n’existent que pour la spécification permettant de définir l’héritage des propriétés entre les rôles. Les écrire produit un rôle invalide que les validateurs signalent.

Comment vérifier qu’un rôle ARIA fonctionne correctement ?

La vérification combine trois étapes : inspecter l’arborescence d’accessibilité dans les DevTools du navigateur pour confirmer le rôle calculé, passer un validateur comme axe-core pour détecter les attributs obligatoires manquants et tester avec un véritable lecteur d’écran comme NVDA ou VoiceOver. Seule la dernière étape confirme que l’annonce est compréhensible pour une personne.

Les rôles ARIA changent-ils entre les versions de la spécification ?

Oui. ARIA 1.1 a ajouté des rôles comme « feed » et « switch », et ARIA 1.2 a modifié le comportement de « combobox » et a consolidé d’autres valeurs. ARIA 1.3 est disponible. Consultez toujours la version actuelle de la spécification pour éviter d’appliquer des modèles obsolètes que les lecteurs de l’écran moderne interprètent de manière distincte.