Rôles et attributs ARIA : meilleurs choix comparés

Les rôles et attributs ARIA de la spécification WAI-ARIA 1.2 du W3C ont dépassé le centenaire, bien qu’une poignée résolve la plupart des problèmes d’accessibilité des widgets XHTML et CSS. Un rôle définit ce qu’est un élément et un attribut son état ou ses relations, mais ARIA ne modifie pas le comportement du navigateur : chaque rôle nécessite la mise en œuvre d’une interaction avec JavaScript.

Accessible Rich Internet Applications (ARIA) est une spécification du W3C qui ajoute une sémantique aux éléments HTML qui ne les possèdent pas sous une forme native. Un rôle décrit ce qu’est un élément (un « bouton », un « onglet », un « dialogue »), tandis qu’un attribut décrit son état ou ses relations (aria-expanded, aria-controls, aria-labelledby). La première règle d’ARIA, publiée par le W3C dans Using ARIA, est directe : s’il existe un élément HTML natif qui fait déjà le travail, utilisez-le et n’ajoutez pas d’ARIA.

La raison est qu’ARIA ne modifie pas le comportement du navigateur. Un <div role="button"> ne reçoit pas le focus avec Tab, ne répond pas à la touche Entrée ou à l’espace et n’est pas soumis avec un formulaire.

Cela ne change que ce qu’annonce la technologie d’assistance. Toutes les interactions doivent être implémentées avec JavaScript et gérées avec soin. Dans les projets XHTML/CSS où le HTML est statique et le JS minimal, cela signifie que chacun des rôles et attributs aria ajoutés est une promesse que votre code doit remplir.

La deuxième règle d’ARIA demande de ne pas changer la sémantique native sauf si elle est indispensable. Un <h2 role="tab"> brise la structure des titres et confond les lecteurs d’écran qui naviguent par régions. La troisième règle exige que toutes les commandes ARIA puissent être actionnées avec un clavier. La quatrième demande de ne pas utiliser aria-hidden="true" sur les éléments qui reçoivent le focus. La cinquième, et le plus oublié, rappelle que tout élément interactif nécessite un nom accessible : un rôle sans label est un bouton muet.

Comment choisir : critères avant la liste

Le choix d’un rôle ou d’un attribut n’est pas une question de goût. Ces critères, appliqués dans l’ordre, évitent la plupart des erreurs concernant les rôles et attributs des aria :

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

1. Existe-t-il un élément HTML natif ? Si oui, utilisez-le. <button>, <details>, <dialog>, <input type="checkbox"> couvrent plus de cas qu’on ne le pense.
2. Le widget a-t-il besoin d’états dynamiques ? S’il change entre ouvert/fermé, sélectionné/non sélectionné ou développé/réduit, vous avez besoin d’attributs d’état (aria-expanded, aria-selected, aria-pressed).
3. A-t-il besoin de relations entre les éléments ? Les attributs de relation (aria-controls, aria-labelledby, aria-describeby, aria-owns) relient des éléments que l’arborescence d’accessibilité ne peut pas déduire du DOM.
4. A-t-il besoin d’annonces en direct ? Les régions en direct (aria-live, role="status", role="alert") résolvent les mises à jour sans déplacer le focus.
5. Puis-je le conserver ? Un modèle ARIA complexe sans tests de clavier ou de lecteur d’écran est pire que de ne rien avoir.

Le coût de maintenance est le critère le plus ignoré. Un role="tablist" bien conçu nécessite la gestion des touches fléchées, la rotation du tabindex, la synchronisation de aria-selected et aria-controls et le masquage correct des panneaux inactifs. Si l’équipe ne peut pas gérer cela, un ensemble de liens avec des ancres est plus accessible et moins cher.

Comparatif des rôles ARIA les plus utiles

Le tableau suivant résume les rôles qui apparaissent sans cesse dans des audits réels, avec leur équivalent natif quand il existe et le piège le plus courant.

Rôle	Utilité	Alternative native	Piège fréquent
button	Contrôle qui exécute une action	<button>	Ne pas ajouter la gestion de Entrée/Espace ni tabindex="0"
link	Navigation vers une autre URL	<a href>	L’utiliser pour des actions qui ne sont pas de la navigation
dialog	Fenêtre modale ou non modale	<dialog>	Ne pas capturer le focus ni le rendre à la fermeture
tablist / tab / tabpanel	Interface d’onglets	Aucune directe	Ne pas synchroniser aria-selected avec le panneau visible
menu / menuitem	Menu d’application	<select> la liste des liens	Utiliser les menus de navigation Web
alerte	Message urgent et immédiat	role="status" pour rien d’urgent	Abuser de lui et saturer le lecteur de l’écran
statut	Mise à jour informative	<sortie>	Ne pas insérer dans le DOM avant d’actualiser
barre de progression	Progrès d’une tâche	<progrès>	Pas d’actualisation de aria-valuenow
info-bulle	Description émergente	title (limité)	Ne vous associez pas à aria-describeby
boîte combo	Champ avec liste de suggestions	<datalist> (limité)	Ne pas annoncer le nombre de résultats

Le choix entre role="alert" et role="status" est un bon exemple de décision avec des nuances concernant les rôles et attributs des arias. « alert » interrompt la lecture en cours du lecteur d’écran ; status attend que l’utilisateur ait terminé. Pour une erreur de validation de formulaire, « alert » est approprié. Pour “3 résultats trouvés” pendant que l’utilisateur écrit, le “statut” est correct et “l’alerte” se révèle intrusif.

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

Attributs ARIA imprescindibles et comment se combiner

Les attributs sont associés à quatre familles, et chacune résout un problème distinct.

Étiquetage. aria-label fournit un nom lorsqu’il n’y a pas de texte visible. aria-labelledby fait référence à l’identifiant d’un autre élément et est préférable lorsque le texte existe déjà à l’écran, car il maintient une source unique de vérité. aria-describeby ajoute une description plus longue, comme le texte d’aide d’un champ. La différence est importante : le nom est ce que l’utilisateur entend lors de la mise au point ; la description est un contexte supplémentaire qui peut être interrompu.

États. aria-expanded (vrai/faux) pour les accordéons et les menus déroulants. aria-selected pour les onglets et les options. aria-checked pour les cases à cocher personnalisées, avec la valeur mixed pour les états à trois états. aria-pressed pour les boutons à bascule. aria-disabled lorsque l’élément est toujours focalisable mais non utilisable, par opposition à l’attribut natif disabled, qui le supprime de l’ordre de tabulation.

Relations. aria-controls indique quel élément un bouton contrôle. aria-owns réorganise l’arborescence d’accessibilité lorsque le DOM ne reflète pas la relation visuelle. aria-activedescendant vous permet de rester concentré sur un conteneur pendant qu’il annonce l’élément actif, un modèle courant dans les listes déroulantes.

Régions en direct. aria-live="polite" ou "assertive" définissent l’urgence. aria-atomic="true" provoque l’annonce de la totalité du bloc au lieu de seulement la partie modifiée. Filtres « aria-relevant » dont les changements sont annoncés.

Un détail souvent négligé : les attributs ARIA ne fonctionnent que sur les éléments ayant un rôle valide. aria-expanded sur un <div> sans rôle ne sera pas annoncé. Et les valeurs booléennes ARIA sont des chaînes de texte (« true », « false »), et non des valeurs booléennes JavaScript ; écrire aria-expanded="false" comme propriété booléenne produira des résultats incohérents.

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

Erreurs qui empêchent l’accès à un widget

L’erreur la plus coûteuse est d’utiliser ARIA pour corriger un HTML mal structuré. Ajoutez role="navigation" à un <div> lorsque vous avez un <nav> disponible en double région et confondez la navigation par points de repère.

La deuxième erreur est la mise au point. Un widget modal qui ne déplace pas le focus lorsqu’il est ouvert, ne le piège pas lorsqu’il est ouvert et ne le renvoie pas au déclencheur lors de la fermeture laisse l’utilisateur du clavier naviguer dans un contenu invisible. L’élément natif <dialog> résout une partie de ce problème, mais pas tout : le retour du focus reste de la responsabilité du développeur.

La troisième erreur est occultée par des éléments « aria-hidden » qui sont toujours exécutables. Un menu fermé avec aria-hidden="true" mais sans affichage: aucun ou visibilité: caché garde vos liens dans l’ordre de tabulation, et l’utilisateur met en évidence les éléments qu’il ne peut pas voir. La combinaison correcte est visuellement occultante et l’arbre d’accessibilité à la fois.

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

La quatrième erreur est le nom accessible absent. Un <button> avec une seule icône SVG nécessite un aria-label ou un <span class="visually-hidden"> avec du texte. Un SVG décoratif nécessite aria-hidden="true" et focusable="false" donc Internet Explorer et certains navigateurs plus anciens ne l’incluent pas dans l’ordre de tabulation.

Outils pour tester les rôles et les attributs ARIA

Il n’existe aucun outil à la place des tests avec un véritable lecteur d’écran, mais la combinaison de divers outils détecte la plupart des échecs dans les rôles et attributs d’aria.

Validation statique. Le validateur W3C ARIA (qui fait partie de Nu HTML Checker) détecte les rôles inexistants, les attributs mal écrits et les combinaisons interdites. ax DevTools et Lighthouse signalent des rôles sans noms accessibles et avec des attributs obligatoires manquants.

Inspection de l’arborescence d’accessibilité. Les DevTools Chrome et Firefox vous permettent de voir l’arborescence d’accessibilité exactement telle qu’elle est reçue par la technologie d’assistance. C’est le moyen le plus rapide de vérifier si un rôle a été réellement appliqué et quel nom accessible le navigateur a calculé.

Test manuel. Naviguez dans l’ensemble du widget uniquement avec le clavier (Tabulation, Maj+Tabulation, flèches, Entrée, Espace, Échap) puis avec NVDA sous Windows, JAWS si disponible, ou VoiceOver sur macOS et iOS. La combinaison d’un lecteur de bureau et d’un lecteur mobile couvre la majorité des cas réels.

Documentation de référence. Le ARIA Authoring Practices Guide (APG) du W3C comprend des modèles complets avec des exemples de clavier et de code. C’est la source qu’il faut consulter avant d’inventer un nouveau modèle.

Comment décider d’un projet XHTML/CSS réel

Sur les sites XHTML avec CSS et JavaScript légers, la stratégie la plus rentable consiste à commencer avec du HTML natif et à ajouter ARIA uniquement là où le natif n’atteint pas. Un formulaire avec <label>, <fieldset> et <legend> corrects nécessite très peu d’ARIA.

Une table de données avec <th scope> ne le fait pas non plus. Les rôles ARIA entrent en jeu lorsque des modèles apparaissent que HTML ne couvre pas : onglets, accordéons, listes déroulantes avec filtrage, boîtes de dialogue modales et notifications dynamiques.

Il est conseillé de documenter chaque utilisation des rôles et attributs ARIA dans le code lui-même avec un commentaire expliquant pourquoi il est là. Lorsque quelqu’un refactorisera le composant six mois plus tard, il saura si les « contrôles aria » sont toujours nécessaires ou sont devenus orphelins. Les attributs ARIA orphelins, qui pointent vers des « identifiants » qui n’existent plus, sont une source silencieuse d’échecs qu’aucun validateur ne détecte de manière fiable.

Enfin, considérez l’accessibilité comme faisant partie de la définition de « terminé » du composant, et non comme un audit ultérieur. Un widget avec des rôles ARIA testé avec le clavier et le lecteur d’écran dès le premier commit coûte bien moins cher qu’un widget réparé après l’audit.

Points clés à retenir

• Les rôles et attributs ARIA n’ajoutent pas de comportement : un rôle sans gestion du clavier et du focus est pire que de ne rien avoir.
• La première règle d’ARIA est d’utiliser le HTML natif dès qu’il existe ; <button>, <dialog> et <details> couvrent plus de cas qu’on pourrait le penser.
• Les attributs sont regroupés en étiquetage, états, relations et régions actives ; chaque famille résout un problème différent.
• role="alert" interrompt et role="status" attend : un mauvais choix sature l’utilisateur du lecteur d’écran.
• Les valeurs booléennes ARIA sont des chaînes (“true”/”false”`), et les attributs ne fonctionnent que sur les éléments ayant un rôle valide.
• Les tests avec un clavier et un véritable lecteur d’écran sont obligatoires ; les validateurs ne détectent qu’une partie des échecs.

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

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

Un rôle définit ce qu’est un élément pour la technologie d’assistance, tel que role="tab" ou role="dialog". Un attribut décrit son état ou ses relations, comme « aria-expanded » ou « aria-labelledby ». Les rôles sont appliqués à l’élément qui représente le composant ; les attributs sont généralement appliqués au même élément ou à ceux qui lui sont liés.

Voulez-vous utiliser ARIA à la place du HTML natif ?

Uniquement lorsqu’aucun élément HTML ne recouvre le motif. La première règle du W3C ARIA est explicite : s’il existe un élément natif, utilisez-le. Les rôles ARIA sont nécessaires pour les onglets, les accordéons, les listes déroulantes avec filtrage et les boîtes de dialogue modales, entre autres modèles que HTML ne peut pas implémenter seul.

¿Qué signifie qu’un élément a un nom accessible ?

Un nom accessible est le texte que le lecteur d’écran annonce lors du focus sur l’élément. Il est calculé à partir du contenu, à partir de aria-label, à partir de aria-labelledby ou à partir d’un <label> associé, dans un ordre de priorité défini par la spécification. Un rôle interactif sans nom accessible est un contrôle que l’utilisateur ne peut pas identifier.

¿Pourquoi mon role="button" ne répond-il pas au clavier ?

Parce qu’ARIA n’ajoute pas de comportement. Un <div role="button"> a besoin de tabindex="0" pour recevoir le focus et les gestionnaires keydown pour Enter et Space. La solution la plus simple et la plus robuste consiste à utiliser l’élément natif <button>, qui inclut déjà le focus, l’activation du clavier et la soumission du formulaire.

Vous n’utilisez pas aria-hidden="true" ?

Il est correct de masquer le contenu décoratif ou en double de l’arborescence d’accessibilité, mais il ne doit jamais être appliqué aux éléments qui reçoivent le focus. Si un élément focalisable reste avec aria-hidden="true", l’utilisateur du clavier peut focaliser quelque chose que le lecteur d’écran n’annonce pas. Combinez-le toujours avec une véritable dissimulation visuelle.

¿Qué les outils valident les rôles et les attributs d’ARIA ?

Le W3C Nu HTML Checker inclut la validation des rôles et attributs ARIA et détecte les rôles inexistants ou les combinaisons interdites. axe DevTools et Lighthouse signalent des rôles sans nom accessible et avec des attributs obligatoires manquants. Pour vérifier le résultat final, l’inspecteur d’arborescence d’accessibilité dans le navigateur DevTools montre exactement ce que reçoit la technologie d’assistance.