Que sont les rôles ARIA ? A Practical Guide for Devs

Quels sont les rôles d’ARIA ? Les rôles ARIA sont le vocabulaire de 87 valeurs définies (à partir de WAI-ARIA 1.2) qui indiquent aux technologies d’assistance ce qu’est un élément et comment il doit se comporter quelle que soit sa balise HTML. Un rôle tel que button, navigation ou dialog attribue un <div> ou <span> générique à un type de widget connu afin que les lecteurs d’écran l’annoncent correctement et exposent les interactions clavier correctes.

Pourquoi les rôles ARIA existent

Pour comprendre ce que sont les rôles aria, il faut voir qu’ils résolvent un problème structurel que HTML seul ne peut pas résoudre. Les éléments HTML natifs ont une sémantique implicite : un <button> s’annonce comme un bouton, peut être focalisé, répond à Entrée et à la barre d’espace, et affiche un état enfoncé si nécessaire.

Lorsque les développeurs créent des widgets personnalisés (une liste déroulante, un panneau d’onglets, une arborescence), ils utilisent souvent <div> et <span>, qui ne contiennent aucune sémantique. Les rôles ARIA comblent cette lacune en permettant aux auteurs d’indiquer explicitement le sens manquant.

La spécification WAI-ARIA est maintenue par le groupe de travail sur les applications Internet riches accessibles du W3C. La première version, ARIA 1.0, est devenue une recommandation du W3C en 2014 ; ARIA 1.1 a suivi en 2017 et ARIA 1.2 a atteint le statut de recommandation en 2023. Des rôles, des états et des propriétés ont été ajoutés à chaque révision, et chacun est lié à un document de pratiques de création qui décrit le comportement attendu du clavier.

Une distinction clé sépare les rôles des deux autres catégories ARIA. Les rôles répondent : « Qu’est-ce que c’est ? » Les états et les propriétés répondent : « Dans quel état est-il ? » et “A quoi est-ce lié ?” Un role="checkbox" déclare le type de widget ; aria-checked="true" indique son état actuel. La confusion des deux est l’une des causes les plus courantes de widgets personnalisés défectueux.

Les six catégories de rôles

Pour comprendre ce que sont les rôles ARIA, il est utile de savoir que la spécification ARIA regroupe les rôles en six familles. Comprendre la famille vous permet de prédire les états et les propriétés pris en charge par un rôle et les modèles de clavier applicables.

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

Catégorie	Objectif	Rôles représentatifs
Abstrait	Définitions de superclasse, jamais utilisées dans le balisage	widget, input, section
Widget	Contrôles interactifs	button, checkbox, slider, tab
Structure du document	Points de repère et régions de la page	banner, main, navigation, region
Point de repère	Régions de page navigables (sous-ensemble de structure)	banner, complementary, contentinfo, form
Région en direct	Annoncer des modifications de contenu dynamique	alert, status, log, timer
Fenêtre	Fenêtres du navigateur ou de l’application	dialog, alertdialog

Les rôles abstraits ne sont utilisés que pour organiser la taxonomie. Les auteurs ne doivent jamais écrire role="widget" ou role="input" dans le balisage ; cela entraîne un comportement indéfini et la validation échoue. Les cinq catégories restantes sont celles que vous appliquez réellement.

Rôles implicites et première règle d’ARIA

Chaque élément HTML possède une fonction ARIA implicite (qui explique ce que sont les rôles aria) définie par la spécification HTML Accessibility API Mapping (AAM). Un élément <nav> a un role="navigation" implicite. Un <ul> a un role="list" implicite. Un <h1> à <h6> a role="heading". Un <table> a role="table".

La première règle du W3C sur l’utilisation d’ARIA stipule clairement : Si un élément ou un attribut HTML natif véhicule déjà la sémantique et le comportement requis, utilisez-le au lieu de réutiliser un élément avec ARIA. L’ajout de role="button" à un <button> n’est pas nécessaire. Pire encore, si vous ajoutez role="button" à un <div>, vous obtiendrez l’annonce mais aucun comportement : pas de focus, pas d’activation du clavier, pas de soumission de formulaire.

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

La redondance n’est pas toujours anodine. Remplacer un rôle implicite peut perdre la sémantique dont dépend la technologie d’assistance. Écrire role="presentation" dans un <table> élimine complètement la sémantique des tables, ce qui est parfois intentionnel avec les tableaux de disposition mais désastreux avec les tableaux de données.

Comment les rôles interagissent avec les états et les propriétés

Les rôles agissent comme des conteneurs pour les états et les propriétés qu’ils prennent en charge. La spécification définit quels attributs sont valides pour quels rôles, et les navigateurs exposent uniquement les combinaisons prises en charge dans l’arborescence d’accessibilité.

Comprendre quels sont les rôles aria aide à savoir qu’un role="checkbox" prend en charge aria-checked avec les valeurs true, false ou mixed. Un role="slider" prend en charge aria-valuenow, aria-valuemin, aria-valuemax et éventuellement aria-valuetext. Un role="combobox" prend en charge aria-expanded, aria-controls et aria-activedescendant. Appliquer aria-checked à un role="button" n’a aucun sens et sera ignoré ou produira des résultats déroutants dans certains lecteurs d’écran.

Les propriétés requises sont également importantes. Un role="checkbox" sans aria-checked n’est pas valide ; l’État est obligatoire et non facultatif. Un role="slider" sans aria-valuenow laisse l’utilisateur incapable de déterminer la valeur actuelle. La spécification ARIA les qualifie d’« états et propriétés requis » et les vérificateurs de conformité tels que axe-core et IBM Equal Access Accessibility Checker soulignent leur absence.

Rôles, l’arborescence d’accessibilité et la prise en charge du navigateur

Les navigateurs traduisent les fonctions ARIA en API d’accessibilité de la plateforme (UIA sous Windows, AXAPI sur macOS, ATK/AT-SPI sous Linux) et les lecteurs d’écran utilisent ces API. Un rôle qu’aucun navigateur n’attribue correctement est pratiquement invisible pour les utilisateurs.

La prise en charge varie selon la fonctionnalité et le navigateur. Les fonctions de base telles que « Bouton », « Lien », « En-tête », « Liste » et « Navigation » sont universellement prises en charge. Les rôles plus récents ou plus spécialisés (« flux », « mathématiques », « doc-footnote » du module WAI-ARIA de Digital Publishing) ont une prise en charge plus inégale. Le role=“switch” est pris en charge dans les navigateurs modernes, mais a été annoncé de manière incohérente il y a dix ans.

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

Tester les combinaisons réelles utilisées par votre public reste essentiel. Un widget qui fonctionne dans NVDA avec Firefox peut se comporter différemment dans VoiceOver avec Safari, car les deux lecteurs d’écran consomment des API de plateforme différentes et appliquent des heuristiques différentes.

Rôles marquants et structure des pages

Les rôles Landmark permettent aux utilisateurs de lecteurs d’écran d’accéder directement aux zones d’une page. Les huit rôles marquants sont « bannière », « complémentaire », « contentinfo », « formulaire », « principal », « navigation », « région » et « recherche ». Le HTML moderne a pour la plupart des équivalents natifs : <header> devient banner, <footer> devient contentinfo, <main> devient main, <nav> devient navigation, <aside> devient complémentaire, <form> avec un nom accessible devient form et <section> avec un nom accessible devient region.

L’utilisation d’éléments natifs est préférable car ils fonctionnent même en cas d’échec de CSS ou JavaScript et car ils réduisent le risque de conflits rôle/attribut. Le repère « recherche » n’a pas d’équivalent HTML natif, donc « role=“search” » est toujours le bon choix pour la région de recherche.

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

Une erreur courante est d’appliquer role="banner" à un <div> qui se trouve à l’intérieur d’un <main> ou <article>. Les rôles de repère ne créent des repères que s’ils ne sont pas imbriqués dans certains autres rôles ; une « bannière » à l’intérieur de « principal » ne sera pas du tout affichée comme point de repère. L’emplacement dans le DOM est aussi important que la valeur du rôle. Pour ceux qui se demandent quels sont les rôles ARIA, ces repères sont un élément clé de la spécification.

Rôles de région en direct

Lorsque l’on considère ce que sont les rôles d’aria, les rôles régionaux en direct annoncent les changements de contenu sans changer le focus. Les quatre fonctions de région en direct sont « alerte », « statut », « journal » et « minuterie », ainsi que le « marquee » plus général. Chacun porte implicitement une valeur « aria-live » : alert et log impliquent en pratique assertive et polite, respectivement, tandis que status implique polite.

Choisir entre « alerte » et « statut » est une décision de conception avec de réelles conséquences. Une « alerte » arrête tout ce que lit le lecteur d’écran, ce qui est approprié pour les erreurs et les notifications urgentes, mais dangereux en cas d’utilisation excessive. Un « statut » attend une pause, qui coïncide avec les messages de progression et les textes de confirmation.

Les régions actives doivent exister dans le DOM avant que le contenu ne change. L’insertion simultanée d’un élément role="alert" et de son texte n’entraîne souvent aucune annonce car la région n’existait pas au moment du changement. Le modèle fiable consiste à afficher une région dynamique vide lors du chargement de la page et à mettre à jour son contenu textuel ultérieurement.

Quand NE PAS utiliser les rôles ARIA

La deuxième règle d’utilisation d’ARIA est que les auteurs ne doivent pas modifier la sémantique native à moins qu’ils n’en aient vraiment besoin. La cinquième règle stipule que chaque élément interactif, quelle que soit sa fonction, doit être accessible et focalisable via le clavier.

L’ajout d’un rôle n’ajoute pas de comportement. role="button" sur un <div> l’empêche de se concentrer, de répondre à la saisie ou à la barre d’espace et de ne pas soumettre le formulaire. Vous devez ajouter tabindex="0", un gestionnaire de frappe pour la saisie et l’espace, et souvent une gestion de l’état « adaptée au rôle ». À ce stade, utiliser un vrai <button> nécessite moins de code et moins d’erreurs.

Certains rôles sont activement nuisibles lorsqu’ils sont mal appliqués. role="presentation" et role="none" suppriment la sémantique d’un élément et, dans certaines implémentations, de ses descendants requis. L’application de role="application" fait passer les lecteurs d’écran dans un mode dans lequel ils arrêtent d’intercepter les frappes au clavier, ce qui peut piéger les utilisateurs si la gestion du clavier personnalisé est incomplète.

Un cadre décisionnel pour choisir les rôles

Travailler sur une courte séquence évite la plupart des erreurs de rôle ARIA. Pour comprendre ce que sont les rôles ARIA et comment les utiliser, procédez comme suit :

1. Identifiez le widget ou la région. Nommez ce qu’est réellement l’élément en langage simple.
2. Recherchez un équivalent HTML natif. Consultez le mappage HTML-AAM. Si <button>, <select>, <details> ou <dialog> convient, utilisez-le.
3. Si aucun élément natif ne convient, sélectionnez le rôle ARIA le plus proche. Vérifiez qu’il existe dans la spécification actuelle et qu’il n’est pas abstrait.
4. Ajoutez les états et propriétés requis. Vérifiez la définition du rôle pour les attributs obligatoires.
5. Implémentez le modèle d’interaction du clavier. Suivez le guide des pratiques de création WAI-ARIA pour le type de widget.
6. Testez avec au moins deux combinaisons de lecteurs d’écran et de navigateurs. Vérifiez les annonces, les états et le flux du clavier.

Les étapes trois à six correspondent à celles où se produisent la plupart des erreurs de widget personnalisé. Ignorer le modèle de clavier à l’étape cinq crée un widget qui s’annonce correctement mais qui est inutilisable, ce qui est sans doute pire que de ne pas avoir d’ARIA du tout.

Outils de test et de validation

Les outils automatisés détectent les erreurs structurelles : valeurs de rôle non valides, propriétés requises manquantes et rôles appliqués à des éléments qui ne les prennent pas en charge. axe-core, le moteur derrière de nombreuses extensions de navigateur, vérifie un sous-ensemble défini de règles ARIA. Le vérificateur d’accessibilité d’IBM Equal Access et le vérificateur Nu HTML du W3C montrent également des abus de rôle.

Les outils automatisés ne peuvent pas vérifier si un rôle produit l’annonce correcte ou si l’interaction au clavier fonctionne. Des tests manuels avec NVDA et Firefox, JAWS et Chrome, ou VoiceOver et Safari sont toujours requis. L’extension Accessibility Insights for Web combine des contrôles automatisés avec une évaluation manuelle guidée qui inclut la vérification du clavier et du lecteur d’écran.

La spécification ARIA elle-même, le WAI-ARIA Authoring Practices Guide et le document de mappage HTML-AAM sont les références faisant autorité sur ce que sont les rôles aria. La référence ARIA de MDN Web Docs est une source secondaire pratique et bien sélectionnée qui fait référence à la spécification de chaque rôle.

Points clés à retenir

• Les rôles ARIA déclarent ce qu’est un élément ; WAI-ARIA 1.2 définit 87 rôles dans six catégories et les rôles abstraits ne peuvent jamais apparaître dans le balisage.
• Les éléments HTML natifs ont des rôles implicites et des comportements intégrés, donc la première règle lors de l’utilisation d’ARIA est de les préférer à « div » plus « rôle ».
• Les rôles nécessitent leurs états et propriétés pris en charge : un role="checkbox" sans aria-checked n’est pas valide et ne peut pas être utilisé.
• L’ajout d’un rôle n’ajoute jamais le comportement du clavier ou la possibilité de se concentrer ; ceux-ci doivent être mis en œuvre et testés séparément.
• Les rôles Landmark et Live Region ont des règles de localisation et de synchronisation qui déterminent s’ils fonctionnent ou non.
• Les inspecteurs automatisés détectent uniquement les erreurs structurelles ; des tests de lecteurs d’écran pour différentes combinaisons de navigateurs sont toujours nécessaires.

Pour comprendre quels sont les rôles ARIA, n’oubliez pas qu’ils définissent le but d’un élément de technologie d’assistance.

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

Que sont les rôles ARIA en termes simples ?

Les rôles ARIA sont des étiquettes que vous attachez aux éléments HTML pour indiquer à la technologie d’assistance ce que représente l’élément. Un <div role="button"> est annoncé comme un bouton plutôt que comme un texte générique. Les rôles fournissent une signification que la balise sous-jacente ne fournit pas, mais ils n’ajoutent aucun comportement, gestion du focus ou prise en charge du clavier par eux-mêmes.

Quelle est la différence entre les rôles ARIA et les attributs ARIA ?

Les rôles décrivent le type d’un élément, tandis que les attributs décrivent son état, sa valeur ou ses relations. role="slider" identifie un curseur ; aria-valuenow="50" rapporte sa position actuelle et aria-labelledby pointe vers son étiquette. Les rôles et les attributs sont utilisés ensemble et chaque rôle définit les attributs qu’il prend en charge.

Combien y a-t-il de rôles ARIA ?

WAI-ARIA 1.2 définit 87 rôles regroupés en six catégories : abstraits, widget, structure du document, point de repère, région en direct et fenêtre. Les rôles abstraits comme « widget » et « input » n’existent que pour la taxonomie interne de la spécification et ne doivent jamais être écrits en HTML. Ce nombre augmente à chaque révision des spécifications.

Dois-je utiliser des rôles ARIA au lieu du HTML sémantique ?

Non. La première règle d’utilisation d’ARIA dit de préférer un élément HTML natif chaque fois qu’il en existe un avec la sémantique et le comportement requis. Utilisez <button> plutôt que <div role="button"> et <nav> plutôt que <div role="navigation">. Les rôles ARIA constituent une solution de secours dans les cas où aucun élément natif approprié n’existe.

Les rôles ARIA fonctionnent-ils dans tous les navigateurs et lecteurs d’écran ?

Les rôles principaux tels que button, link, heading et navigation sont pris en charge de manière fiable par les navigateurs et lecteurs d’écran modernes. Les rôles plus récents ou plus spécialisés, y compris ceux du module Publication numérique, offrent une prise en charge plus variable. Ce n’est qu’en testant avec les combinaisons spécifiques de navigateur et de lecteur d’écran que votre public utilise que vous pourrez en être sûr.

L’ajout d’un rôle ARIA peut-il perturber l’accessibilité ?

Oui. Remplacer un rôle implicite peut perdre une sémantique utile, par exemple lorsque role="presentation" est appliqué à une table de données. L’application de role="application" peut bloquer les utilisateurs si la gestion du clavier personnalisé est incomplète. Les rôles redondants dans les éléments natifs créent du bruit inutile et conduisent parfois à des annonces contradictoires.