Aller au contenu principal
Niquelao Accessibilité web et développement front-end : normes WCAG, widgets accessibles et extensions Firefox, expliqués avec du code concret.

Certains liens de ce site sont des liens d'affiliation : si vous effectuez un achat via ceux-ci, nous pouvons percevoir une commission sans frais supplémentaires pour vous. Cela n'influence jamais nos recommandations. Consultez notre divulgation d'affiliation pour plus de détails. Divulgation d'affiliation.

Aide-mémoire sur les rôles ARIA : meilleurs choix comparés

Une aide-mémoire sur les rôles aria est une référence qui attribue chaque rôle ARIA à votre élément HTML équivalent d’origine, à votre catégorie (widget, point de repère, structure, région en direct ou fenêtre) et aux propriétés et états qui l’accompagnent. WAI-ARIA 1.2 définit 82 rôles, et la plupart des projets n’ont besoin que de 15 à 20 de forme récurrente. Ce comparatif récapitule les meilleures heures de référence disponibles en 2026 et explique comment vous accompagner dans votre flux de travail.

Pourquoi un aide-mémoire des rôles ARIA reste nécessaire

Les spécifications de WAI-ARIA 1.2 et de son successeur WAI-ARIA 1.3 sont des documents denses, pensés pour les implémenteurs de navigateurs et de technologies d’assistance, pas pour celui qui maquette un formulaire un mardi après-midi. La première règle d’ARIA — utiliser le HTML natif dès qu’il existe — résout la plupart des cas, mais il y a des modèles qui n’ont pas d’équivalent natif : onglets, arbres, grilles interactives, combobox avec saisie automatique, menus avec sous-menus. Ici, il y a un aide-mémoire fait gagner du temps et, sur tout, vous éviterez des erreurs.

L’erreur la plus courante n’est pas d’effacer un rôle, mais ajouter un inutile. Un <button> avec role="button" n’apporte rien et peut casser le comportement natif sur certains lecteurs d’écran. Un aide-mémoire bien marqué indique explicitement que les rôles sont redondants sur les éléments naturels, que les rôles nécessitent une gestion de foco par JavaScript et que les attributs sont obligatoires devant les options.

La deuxième raison est la vérification. Les rôles ont des relations de propriété : aria-labelledby pointe vers un id, aria-activedescendant exige que l’élément de référence existe et soit visible, aria-owns seul se justifie lorsque l’ordre du DOM ne coïncide pas avec l’ordre visuel. Un tableau qui joue un rôle crucial, les attributs requis et les attributs interdits détectent les erreurs avant de arriver jusqu’à un audit.

Ce que doit inclure un bon aide-mémoire des rôles ARIA

Une table de référence utile pour développer un front-end avec cinq critères. La liste est donc exactement celle qu’il a utilisée pour évaluer les options de cette comparaison.

  • **Couverture des cinq catégories de rôles. **WAI-ARIA regroupe les rôles dans les résumés, les widgets, la structure du document, les points de repère et les régions en direct. Les résumés (roletype, widget, input) ne sont pas utilisés dans le framework ; une bonne référence aux données de forme visibles.
  • Équivalent HTML natif pour le rôle. Sans cette colonne, la référence vous invite à y utiliser ARIA sans y toucher.
  • Attributs obligatoires, pris en charge et interdits. role="checkbox" nécessite aria-checked ; role="heading" nécessite aria-level ; role="presentation" n’est pas autorisé.
  • Modèle de clavier associé. Un rôle sans gestion teclado est une promesse incluse. role="tablist" implique différents éléments/derecha, Home et End.
  • Format consultable. Recherche, filtre par catégorie, version de spécification et possibilité de copier le fragment de code.

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

Le tableau suivant reprend les options les plus solides. Aucun n’est payant ; tous restent actifs et citent la version de la spécification qu’ils couvrent.

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

RessourceApprocheCatégories couvertesÉquivalent naturelPatron de clavierIdéal pour
Guide des pratiques de création WAI-ARIA (APG), W3CPatrons complets avec exemplesWidgets, points de repère, structure, régions en directOui, dans chaque modèleOui, détailléImplémenter un widget concret
MDN Web Docs, référence des rôles ARIAFiche par rôleTous, y compris les résumésOuiParcialConsulter un rôle ponctuel
ARIA Authoring Practices, indice de rôlesTableau rôle → attributsWidgets et structureParcialNonVérifier les attributs requis
Université Deque, référence ARIAFiches avec notes de supportWidgets et points de repèreOuiParcialTrouver un support réel pour le lecteur
Liste de contrôle du projet A11YListe de vérificationTransversaleAucune applicationNonAuditer avant de publier
HTML-ARIA (W3C), tableau d’équivalencesRôle permis par élémentTousOui, c’est son butNonDécider si ARIA est nécessaire

Guide des pratiques de création WAI-ARIA (APG)

L’APG du W3C est la référence canonique pour les clients. Chaque modèle comprend la structure HTML, les rôles, les états, l’interaction du clavier et un exemple fonctionnel. Il est important que vous ne limitiez pas la liste des rôles : expliquez le comportement attendu. Son point faible est qu’il ne s’agit pas d’un tableau rapide; Pour consulter « quels attributs lleva role="slider"» vous devez naviguer jusqu’au patron correspondant.

APG regroupe les utilisateurs de widgets les plus courants : accordéon, alerte, fil d’Ariane, bouton, case à cocher, zone de liste déroulante, boîte de dialogue, divulgation, flux, grille, lien, zone de liste, menu, barre de menus, groupe radio, curseur, bouton rotatif, commutateur, tableau, liste d’onglets, barre d’outils, info-bulle, arborescence de grille et arborescence. Si votre projet en utilise un, exécutez-le ici.

MDN Web Docs : la référence par rôle

MDN maintient une page pour chaque rôle ARIA, avec la description, les attributs requis, les attributs autorisés, les problèmes d’accessibilité associés et des liens vers la spécification. C’est l’option la plus rapide lorsque vous savez ce que vous faites. Votre couverture comprend des rôles abstraits et des rôles utilisés, bien que de nombreux rappels soient omis.

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

Un détail pratique : MDN a marqué que les rôles sont obsolètes ou en risque d’élimination dans les futures versions de la spécification. Consultez cette marque pour éviter d’adopter un rôle qui disparaîtra.

HTML-ARIA : le tableau qui évite l’ARIA inutile

La spécification HTML-ARIA du W3C définit, pour chaque élément HTML, quels rôles ARIA peuvent être appliqués et certains sont redondants. C’est l’outil décisif lorsque vous hésitez entre un élément natif ou un « div » avec rôle. Si le rôle que vous souhaitez appliquer apparaît comme redondant pour cet élément, la réponse n’est pas ajoutée.

Université Deque et projet A11Y

Deque University propose des fiches de rôle avec des notes sur le support réel des lecteurs d’écran, même si la spécification ne le couvre pas car ce n’est pas son rôle. La liste de contrôle du projet A11Y n’est pas un aide-mémoire pour les rôles, mais fonctionne comme une liste de vérification préalable à la publication et complète bien les précédentes.

Comment choisir selon votre cas

La décision dépend de trois questions. Premièrement, savez-vous déjà de quel rôle vous avez besoin ? Si la réponse est oui, MDN est la voie la plus courte. Deuxièmement, est-ce que vous construisez un widget avec une interaction complète ? Donc, vous avez besoin de l’APG, car le rôle n’est pas nécessaire pour décrire le comportement du clavier. Troisièmement, vous hésitez entre HTML natif et ARIA ? Consultez HTML-ARIA avant de trouver une autre source.

Pour les équipes qui travaillent avec XHTML et CSS sans frameworks, la combinaison la plus efficace est : HTML-ARIA pour décider, APG pour implémenter et MDN pour vérifier les attributs. Un aide-mémoire d’une seule page sert de mémoire à votre place, mais ne remplace pas ces trois sources lorsqu’il apparaît dans un cas limite.

Un critère supplémentaire qui convient à l’application : si le rôle nécessite JavaScript pour fonctionner correctement (gestion du focus, actualisation de « aria-expanded », synchronisation de « aria-selected »), il s’agira d’une décision d’architecture, mais pas d’un attribut décoratif. Les rôles du widget dans la logique associée génèrent plus de barrières que l’utilisation du rôle.

Connexes : — La qui accrédite votre expérience en accessibilité.

Erreurs fréquentes qu’aucun aide-mémoire n’évite à lui seul

Les rôles des doubles de points de repère confondent la navigation des régions. Un role="main" sur un <main> est redondant ; deux role="navigation" ont une étiquette distincte et ambiguë. La solution est « aria-label » ou « aria-labelledby » à chaque repère répété.

Les rôles du widget sur les éléments qui ne peuvent pas être activés interrompent l’interaction. role="button" sur un <div> exige tabindex="0" et le bouton Enter et Espace. Cependant, le rôle annonce un bouton qui ne peut pas être activé avec le clavier.

Les états interrompus sont la cause la plus courante de baisse d’audience. aria-expanded qui ne change pas pour ouvrir un accord, aria-selected qui ne se met pas à jour lorsque l’onglet change ou aria-checked dans un role="switch" qui est corrigé. Aucun tableau ne le détecte : il faut tester avec le clavier et un vrai lecteur d’écran.

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

Les rôles abstraits sur le marché sont en principe une erreur. role="widget", role="input" ou role="section" ne doivent pas apparaître en HTML ; exister seul pour la hiérarchie de la spécification.

Points clés à retenir

  • WAI-ARIA 1.2 définit 82 rôles, mais la plupart des projets sont utilisés seuls entre 15 et 20 de forme récurrente.
  • La première règle d’ARIA —utiliser HTML natif lorsqu’il existe— convertit le tableau HTML-ARIA du W3C en la référence la plus importante avant d’écrire n’importe quel rôle.
  • L’APG du W3C est insurmontable pour les utilisateurs de widgets car il inclut l’interaction du clavier ; MDN est plus rapide pour consulter un rôle concret.
  • Un rôle sans gestion de foco et sans actualisation des états génère plus de barrières d’accessibilité que ne pas utiliser ARIA.
  • Aucun aide-mémoire ne remplace la vérification avec le clavier et avec le lecteur d’écran : les états désincronisés ne sont détectés qu’en utilisation réelle.

Questions fréquentes

Combien de rôles ARIA existent-ils ?

WAI-ARIA 1.2 définit 82 rôles, répartis dans cinq catégories : résumés, widgets, structure de document, points de repère et régions en direct. Les rôles abstraits ne sont pas appliqués uniquement au marché ; Ils servent à organiser la hiérarchie de la spécification. Dans la pratique, un projet typique utilise entre 15 et 20 rôles distincts.

C’est quoi la meilleure aide-mémoire des rôles ARIA ?

Cela dépend de l’utilisation. Pour implémenter un widget avec clavier, le WAI-ARIA Authoring Practices Guide du W3C est la référence la plus complète. Pour consulter les attributs d’un rôle concret, MDN Web Docs est plus rapide. Pour décider si un rôle est nécessaire sur un élément HTML, le tableau HTML-ARIA du W3C est la source décisive.

Voulez-vous utiliser ARIA s’il existe un élément HTML natif ?

Non. La première règle d’ARIA est que s’il existe un élément HTML avec la sémantique et le comportement nécessaire, cet élément est utilisé à la place d’un « div » avec le rôle. Ajouter role="button" à un <button> est redondant et vous pouvez modifier le comportement naturel de certains lecteurs d’écran.

Quelle différence y a-t-il entre un rôle de widget et un rôle de point de repère ?

Les rôles du widget décrivent des contrôles interactifs —button, checkbox, slider, tablist— et nécessitent une gestion du focus et du clavier. Les rôles de point de repère sont décrits dans les régions de la page —main, navigation, banner, contentinfo— et sont utilisés pour la navigation dans les régions. Un autre élément ne doit pas remplir toutes les fonctions.

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

Si. WAI-ARIA 1.2 a ajouté des rôles comme blockquote, caption, code, deletion, emphasis, insertion, meter, paragraph, strong, subscript et exposant. Certains rôles sont devenus obsolètes dans les versions postérieures. Assurez-vous de comparer avec MDN ou avec les spécifications appropriées si vous êtes vigilant avant de l’adopter.

¿Un aide-mémoire des rôles ARIA basé sur les WCAG ?

No. Les rôles ARIA sont une partie du critère 4.1.2 Nom, rôle et valeur, mais WCAG 2.2 inclut beaucoup d’autres exigences : contraste, champ visible, taille d’objet, texte alternatif, structure d’encastrement. Une aide-mémoire aide à implémenter correctement les rôles, sans remplir le ensemble des critères de conformité.

Sources et lectures complémentaires

  • Aide-mémoire — Wikipédia : Une aide-mémoire (également aide-mémoire) ou une aide-mémoire ou une aide à l’emploi est un ensemble concis de notes utilisé pour une référence rapide. Les aide-mémoire étaient historiquement utilisés par les étudiants sans…

Comment utiliser les WCAG sans consulter le code ?

Superposición de IA qui promet d’obtenir les WCAG dans 48 heures