ARIA, pourquoi ajouter des attributs peut parfois rendre une interface moins accessible
Il y a une phrase que l’on entend régulièrement lorsqu’on parle d’accessibilité avec des équipes de développement :
« On a ajouté les attributs ARIA nécessaires. »
Souvent, cette phrase arrive après une bonne intention.
Le développeur a identifié un problème.
Il a cherché une solution.
Il a lu une documentation.
Il a ajouté des rôles, des états, des propriétés.
Sur le papier, la démarche semble logique et efficace.
Pourtant, dans la réalité, on rencontre parfois une situation paradoxale :
une interface qui était difficilement accessible devient encore plus difficile à utiliser après l’ajout des fameux attributs ARIA.
Ce n’est pas parce qu’ARIA est un mauvais outil.
Au contraire, ARIA est indispensable dans de nombreux cas.
Le problème vient plutôt d’une idée répandue :
Ajouter des informations à une interface ne signifie pas forcément qu’on la rend plus compréhensible.
Parfois, le meilleur choix pour l’accessibilité consiste justement à écrire moins de code.
ARIA un outil pour combler un manque, pas pour remplacer les fondations
ARIA signifie « Accessible Rich Internet Applications ».
Son objectif est simple : permettre aux développeurs de transmettre davantage d’informations aux technologies d’assistance lorsque le HTML seul ne suffit pas.
Par exemple, une interface moderne contient souvent des éléments qui n’existent pas directement en HTML natif :
- menus complexes
- composants dynamiques
- fenêtres modales
- onglets
- autocomplétion
- applications web riches
Dans ces situations, ARIA permet d’expliquer au lecteur d’écran ce qui se passe.
Un composant peut avoir :
- un rôle
- un état
- une propriété
- une relation avec d’autres éléments
Le problème apparaît lorsque ARIA devient un réflexe.
Le piège : vouloir réparer un mauvais HTML avec ARIA
Prenons un exemple très courant.
Un bouton est créé avec une balise générique :
<div class="button">
Envoyer le formulaire
</div>
Le composant ressemble visuellement à un bouton grâce : class= »button »
Il a donc une couleur
Il possède une bordure
Il réagit au clic
Un utilisateur avec une souris pense voir un bouton.
Mais techniquement, ce n’est pas un bouton.
Le navigateur ne sait pas que cet élément doit être activable.
Le lecteur d’écran ne sait pas qu’il s’agit d’une action.
La première réaction peut être :
« Ajoutons un rôle ARIA. »
Par exemple :
<div role="button">
Envoyer le formulaire
</div>
C’est mieux.
Mais ce n’est pas encore un vrai bouton.
Il manque notamment :
- la gestion du clavier
- le comportement attendu avec Entrée
- le comportement attendu avec Espace
- la gestion du focus
On a donné un nom au problème, mais on n’a pas forcément corrigé le comportement.
La solution la plus simple était probablement :
<button>
Envoyer le formulaire
</button>
Une ligne de HTML natif remplace parfois plusieurs lignes de JavaScript et d’ARIA.
Le HTML natif connaît déjà beaucoup de choses
C’est probablement l’un des points les plus importants en accessibilité web :
les éléments HTML standards sont déjà conçus pour communiquer avec les technologies d’assistance.
Un bouton HTML sait qu’il est :
- interactif
- activable
- focalisable
Une case à cocher HTML sait qu’elle peut être :
- cochée
- décochée
- annoncée comme telle
Un champ de formulaire HTML sait qu’il attend une valeur.
Quand on utilise ces éléments correctement, le navigateur fournit déjà une grande partie du travail.
À l’inverse, lorsqu’on reconstruit des composants à partir d’éléments génériques, il faut recréer manuellement toutes ces informations.
Et c’est là que les erreurs apparaissent.
Le deuxième piège : trop informer l’utilisateur
L’accessibilité ne consiste pas à transmettre un maximum d’informations.
Elle consiste à transmettre les bonnes informations au bon moment.
Un exemple simple :
Une équipe ajoute beaucoup d’annonces vocales dans une interface.
Chaque changement d’état déclenche un message.
Chaque bouton possède une description supplémentaire.
Chaque élément reçoit une indication.
L’intention est bonne.
Mais le résultat peut devenir épuisant.
L’utilisateur entend constamment des informations qui ne l’aident pas à avancer.
C’est un problème de conception.
Une interface accessible doit réduire l’effort nécessaire pour comprendre.
Pas l’augmenter.
Pourquoi ces erreurs arrivent-elles ?
Dans beaucoup de projets, ARIA intervient trop tard.
Le scénario classique ressemble à ceci :
- Le design est terminé
- Le composant est développé
- Les tests d’accessibilité révèlent des problèmes
- On cherche à corriger rapidement
- ARIA devient une solution de secours
Mais ARIA ne peut pas remplacer une bonne conception.
Il ne corrige pas :
- une mauvaise structure
- une navigation confuse
- une interaction mal pensée
- un composant construit sans logique
Il peut enrichir une interface.
Il ne peut pas lui donner du sens si ce sens n’existe pas.
Comment utiliser ARIA correctement ?
Une approche simple consiste à suivre une règle :
1. Utiliser d’abord le HTML natif
Avant d’ajouter ARIA, se demander :
« Existe-t-il déjà un élément HTML qui correspond à ce besoin ? »
Souvent, la réponse est oui.
2. Ajouter ARIA lorsqu’il apporte une information nécessaire
ARIA est particulièrement utile lorsque l’interface possède des comportements qui ne peuvent pas être exprimés simplement en HTML.
Par exemple :
- état d’un composant dynamique
- relation entre plusieurs éléments
- changement de contenu annoncé automatiquement
3. Tester le comportement réel
Un attribut ARIA peut être techniquement présent mais inutile.
La vraie question n’est pas :
« Est-ce que l’attribut existe ? »
Mais :
« Est-ce que l’utilisateur comprend mieux ce qui se passe ? »
La vraie leçon derrière ARIA
ARIA n’est pas un problème.
La mauvaise utilisation d’ARIA est un symptôme.
Elle montre souvent une tendance plus large dans le développement moderne : on construit parfois des interfaces très sophistiquées en oubliant les mécanismes simples qui permettent au web de fonctionner.
L’accessibilité nous rappelle une chose essentielle : une interface n’est pas seulement ce que l’on voit à l’écran.
C’est aussi ce que le navigateur comprend
Ce que les technologies d’assistance peuvent interpréter
Ce que l’utilisateur peut réellement contrôler
La meilleure utilisation d’ARIA n’est donc pas d’en mettre partout.
C’est de savoir quand il est nécessaire.
Et surtout, quand il ne l’est pas.