Attributs ARIA invalides : quand vouloir aider aggrave les choses

Les attributs ARIA (Accessible Rich Internet Applications) existent pour combler ce que le HTML natif ne peut pas exprimer seul : décrire aux technologies d'assistance le rôle, l'état ou les relations d'un composant sur mesure. Leur puissance vient précisément de ce que navigateurs et lecteurs d'écran leur font entièrement confiance : aria-expanded="true" est pris pour argent comptant, que ce soit vrai ou non. C'est cette confiance qui rend un ARIA invalide si dommageable : une faute de frappe ne se contente pas de ne rien faire, elle peut activement induire en erreur.

Cela relève du critère de succès 4.1.2 des WCAG (Nom, rôle et valeur), niveau A.

Les trois façons dont ARIA casse

Noms d'attributs invalides - une faute comme aria-lable au lieu de aria-label ne correspond à aucun attribut ARIA. Navigateurs et lecteurs d'écran ignorent silencieusement les attributs inconnus : l'élément se comporte donc exactement comme si aucune étiquette n'avait été fournie.

<!-- Ignoré silencieusement - ce n'est pas un vrai attribut ARIA -->
<button aria-lable="Fermer">×</button>

<!-- Correct -->
<button aria-label="Fermer">×</button>

Valeurs d'attributs invalides - aria-expanded n'accepte que "true" ou "false" ; une valeur comme aria-expanded="oui" échoue à la validation et est traitée comme si l'attribut n'était pas défini.

<!-- Valeur invalide -->
<button aria-expanded="oui">Menu</button>

<!-- Correct -->
<button aria-expanded="false">Menu</button>

Rôles invalides ou mal employés - attribuer une valeur de role qui n'existe pas dans la spécification WAI-ARIA, ou un rôle qui exige des attributs que vous n'avez pas fournis. role="tab", par exemple, est censé se trouver dans un conteneur role="tablist" et nécessite généralement aria-selected : l'utiliser isolément empêche les technologies d'assistance de se représenter correctement le composant.

<!-- Incomplet : un onglet a besoin des attributs requis et du bon contexte -->
<div role="tab">Paramètres</div>

<!-- Complet -->
<div role="tablist">
  <div role="tab" aria-selected="true" id="onglet-1">Paramètres</div>
</div>

Comment le détecter de façon fiable

Contrairement à beaucoup de problèmes d'accessibilité, un ARIA invalide est automatisable à près de 100 % : la spécification WAI-ARIA définit une liste exacte et finie d'attributs valides, de valeurs admises par attribut et de rôles, si bien qu'un analyseur peut vérifier la syntaxe avec certitude. Si vous écrivez ARIA à la main, référez-vous à la spécification (ou aux modèles de composants du guide des pratiques de rédaction WAI-ARIA) plutôt que de deviner les noms d'attributs de mémoire : c'est l'un des rares domaines de l'accessibilité où il existe une réponse strictement juste, et non une appréciation.

La vue d'ensemble : « pas d'ARIA vaut mieux qu'un mauvais ARIA »

C'est la seconde moitié de la première règle bien connue d'ARIA (la première étant « n'utilisez pas ARIA si le HTML natif fait déjà le travail »). Une <div> portant un role="button" défectueux et sans gestion du clavier est souvent pire pour une personne utilisant un lecteur d'écran qu'une <div> ordinaire : l'ARIA cassé annonce activement « ceci est un bouton » pour quelque chose qui ne se comporte pas comme tel, créant un décalage déroutant entre ce qui est annoncé et ce qui se produit réellement.

Références officielles

• Deque University : aria-hidden-focus
• Deque University : aria-required-attr
• Deque University : aria-roles
• Deque University : aria-valid-attr
• Deque University : aria-valid-attr-value