Accessibilité web : comprendre la première règle d’ARIA
Analyse d’un article de CSS-Tricks (Hashim Quraishi) sur un bug d’accessibilité causé par un mauvais usage d’ARIA, et sur l’importance de privilégier la sémantique HTML native.
- 3 min read
Où est-ce que je l’ai trouvé ?
J’ai trouvé cet article sur mon dashboard Glance (info.ancay.ch), dans un de mes flux RSS issu de la source CSS-Tricks.
L’article, écrit par Hashim Quraishi le 21 janvier 2026, partage une expérience concrète autour d’ARIA, un outil central pour l’accessibilité web.
Source : https://css-tricks.com/i-learned-the-first-rule-of-aria-the-hard-way/
De quoi parle-t-il ?
L’auteur raconte un problème rencontré lors du développement d’un composant front-end. Dans la pratique, tout fonctionne : aucune alerte dans le navigateur, les tests passent, et l’interface semble correcte.
Cependant, lorsqu’il teste son composant en conditions réelles d’accessibilité (notamment la navigation au clavier), il découvre un bug majeur : il est impossible d’activer un bouton au clavier. L’auteur montre alors un extrait de code très simple : un bouton HTML natif avec une classe et un rôle ARIA ajouté.
De manière surprenante, le problème disparaît lorsqu’il supprime cet attribut role. Le bouton redevient utilisable immédiatement. Cette expérience le mène à rappeler ce qu’il appelle la première règle d’ARIA :
“If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.”
Source : W3C https://www.w3.org/TR/using-aria/#secondrule
La leçon principale est que la sémantique native HTML fournit déjà une grande partie des comportements nécessaires à l’accessibilité (focus, clavier, interactions). À l’inverse, ajouter ARIA sans nécessité peut accidentellement casser des comportements natifs, et produire l’effet inverse de celui attendu.
L’auteur propose ensuite une méthode simple pour comprendre ce type de problème et éviter les erreurs :
- Commencer avec la balise la plus simple possible
- Observer son comportement natif (navigation clavier, focus, screen reader)
- Ajouter uniquement le ARIA réellement utile
- Supprimer le ARIA superflu (certains attributs peuvent neutraliser un comportement natif)
En conclusion, il explique que “override” la sémantique HTML revient à prendre une responsabilité complète sur les interactions (clavier, focus, comportements attendus). ARIA est donc utile lorsqu’il ajoute des états ou des informations, mais il ne doit pas remplacer une sémantique déjà correcte.
Pourquoi l’avoir sélectionné ?
J’ai sélectionné cet article pour plusieurs raisons.
Tout d’abord, dans mon cursus de bachelor en Ingénierie des Médias, nous avons peu pratiqué la mise en place de l’accessibilité dans le développement front-end. Or, c’est un sujet fondamental, et je dois être capable d’intégrer ces principes dans mes projets.
Ensuite, l’accessibilité est particulièrement importante dans des contextes de médiation culturelle, sociale et scientifique, car ce sont des domaines qui doivent être accessibles à tous les publics. Cet article est donc un bon exemple : il est très concret, basé sur une erreur réelle, et il m’aide à approfondir mes connaissances techniques de manière applicable.
Sources
https://css-tricks.com/i-learned-the-first-rule-of-aria-the-hard-way/ https://www.w3.org/TR/using-aria/#secondrule https://info.ancay.ch