ARIA : Accessible Rich Internet Applications

Qu'est-ce qu'ARIA ?

ARIA (Accessible Rich Internet Applications, aussi écrit WAI-ARIA) est une spécification du W3C composée d'attributs HTML qui indiquent aux technologies d'assistance ce qu'est un élément, dans quel état il se trouve et comment il se rattache aux autres. Elle sert aux widgets personnalisés que le HTML seul ne peut pas décrire, comme les onglets, les listes déroulantes à saisie semi-automatique et les zones mises à jour en direct.

ARIA ne change que ce qui est communiqué à la technologie d'assistance. Elle n'ajoute aucun comportement : elle ne rend pas un élément focalisable, cliquable ni utilisable au clavier. Cela exige toujours du HTML et du JavaScript.

Rôles, états et propriétés

WAI-ARIA 1.2, la Recommandation W3C en vigueur, définit trois sortes d'attributs :

• Rôle (role) : l'indicateur principal de ce qu'est un élément, par exemple role="tablist" ou role="dialog".
• Propriété (property) : une caractéristique de l'élément qui change rarement, par exemple aria-label ou aria-controls.
• État (state) : une caractéristique qui change selon l'action de l'utilisateur ou un script, par exemple aria-expanded ou aria-checked.

Les règles d'usage d'ARIA

Le guide « Using ARIA » du W3C énonce quatre règles. La première est la plus souvent enfreinte :

1. Utilisez d'abord le HTML natif. Si un élément ou un attribut offre déjà la sémantique et le comportement voulus, employez-le au lieu d'ajouter ARIA à un autre élément.
2. Ne modifiez pas la sémantique native sauf nécessité réelle.
3. Tous les contrôles ARIA interactifs doivent être utilisables au clavier.
4. Ne mettez pas role="presentation" ni aria-hidden="true" sur un élément focalisable, sinon l'utilisateur tombe sur quelque chose qui semble n'être rien.

<!-- Native: no ARIA needed -->
<button type="button">Save</button>

<!-- Avoid: a div pretending to be a button -->
<div role="button" tabindex="0">Save</div>

Le bouton natif est focalisable, réagit à Entrée et à Espace et est annoncé correctement sans travail supplémentaire. Le div oblige à tout reconstruire à la main. Un lecteur d'écran n'annonce que ce que le balisage lui dit.

Exemple : un bouton de déploiement

Un bouton qui affiche et masque un panneau est un cas où ARIA apporte une vraie valeur, car le HTML seul ne peut pas dire si le panneau est ouvert :

<button type="button" aria-expanded="false" aria-controls="faq-1">
  Shipping details
</button>
<div id="faq-1" hidden>Orders ship within two days.</div>

Votre script doit passer aria-expanded à true quand il retire hidden, puis le remettre à false à la fermeture. Pour les contrôles qui n'ont qu'une icône, un nom via aria-label est nécessaire :

<!-- Icon-only button: no visible text, so it needs a name -->
<button type="button" aria-label="Close dialog"><svg aria-hidden="true">...</svg></button>

Rôles courants et zones dynamiques

• dialog pour les boîtes de dialogue modales, tablist, tab et tabpanel pour les onglets, combobox pour les champs à saisie semi-automatique.
• Les repères comme navigation et main, que <nav> et <main> fournissent déjà nativement.
• aria-labelledby et aria-describedby pour pointer vers un texte visible qui nomme ou explique un élément.
• aria-current="page" pour marquer le lien courant dans une navigation.

Les zones dynamiques (live regions) annoncent des changements que l'utilisateur n'a pas provoqués en déplaçant le focus. role="status" est poli et attend la fin de la lecture en cours ; role="alert" est assertif et interrompt, à réserver aux erreurs qui exigent une attention immédiate.

<div role="status">Draft saved</div>
<div role="alert">Connection lost</div>

Erreurs fréquentes

• ARIA à la place du bon élément. La plus courante : un div avec un rôle là où un bouton, un lien ou un select suffirait.
• Des rôles sans prise en charge du clavier. Un role="tab" sans gestion des flèches est annoncé comme un onglet et se comporte comme rien.
• Des états périmés. Laisser aria-expanded="false" alors que le menu est ouvert dit le contraire de ce que voit l'utilisateur.
• Masquer du contenu focalisable. aria-hidden="true" sur un bouton ou un lien le laisse atteignable au clavier mais muet.
• Des libellés qui contredisent le texte visible. Si le bouton affiche « Rechercher » mais que son aria-label dit « Aller », l'utilisateur de la commande vocale ne peut pas dire ce qu'il voit. Voir aussi formulaires accessibles.
• Ne jamais tester avec une technologie d'assistance. Un balisage valide ne garantit pas une annonce cohérente.

ARIA et tests d'accessibilité

ARIA est un élément de la conformité aux WCAG, car plusieurs critères de succès supposent que les éléments exposent nom, rôle et valeur. Les outils automatiques repèrent les mauvais usages d'ARIA vérifiables à partir du seul balisage : valeurs de rôle invalides, attributs interdits sur un rôle ou aria-hidden sur des éléments focalisables font partie du score d'accessibilité de Lighthouse. Ils ne peuvent pas juger si un widget fonctionne ; associez-les donc à des tests au clavier, à un passage au lecteur d'écran et à des tests d'accessibilité automatisés en CI. Notre comparatif des outils de test d'accessibilité (en anglais) passe en revue les options. La surveillance de la vitesse des pages de LoadFocus enregistre la catégorie Accessibility de Lighthouse à chaque audit, pour suivre le score dans le temps.

Questions fréquentes : ARIA

Quelle est la première règle d'ARIA ?

Utiliser un élément ou un attribut HTML natif qui fournit déjà la sémantique et le comportement voulus, plutôt que de détourner un autre élément et d'y ajouter ARIA. Les éléments natifs intègrent la prise en charge du clavier et des annonces correctes.

ARIA rend-elle un élément utilisable au clavier ?

Non. ARIA ne change que la manière dont un élément est décrit à la technologie d'assistance. Le focus, la gestion des touches et le comportement restent à construire en HTML et JavaScript.

Vaut-il mieux pas d'ARIA qu'un mauvais ARIA ?

Souvent, oui. Des rôles incorrects et des états périmés peuvent desservir l'utilisateur davantage qu'un HTML simple et correct. Ajoutez ARIA quand le HTML natif ne peut pas exprimer le widget, et testez-le.

Quelle différence entre aria-label et aria-labelledby ?

aria-label fournit le nom accessible sous forme de chaîne de texte. aria-labelledby pointe vers l'id d'un autre élément dont le texte visible devient le nom. Privilégiez le texte visible quand c'est possible.

Où trouver des modèles ARIA éprouvés ?

L'ARIA Authoring Practices Guide (APG) du W3C décrit des modèles de conception pour les widgets courants, chacun avec des exemples fonctionnels. Suivez un modèle plutôt que d'inventer le comportement au clavier.