Une mauvaise ARIA est pire que pas d'ARIA : le code d'accessibilité qui brise discrètement les sites Web ontariens (2026)

Il existe un fait contre-intuitif au cœur de l'accessibilité Web qui piège chaque année des propriétaires d'entreprise bien intentionnés : l'outil le plus souvent invoqué pour « rendre un site accessible » est aussi l'un des moyens les plus courants de le rendre moins accessible. Cet outil, c'est l'ARIA (Accessible Rich Internet Applications, ou applications Internet riches accessibles) — un ensemble d'attributs HTML qui indiquent aux lecteurs d'écran ce qu'est une commande et ce qu'elle fait. Utilisée correctement et avec parcimonie, l'ARIA comble des lacunes que le HTML brut ne peut pas combler. Utilisée à la légère — répandue sur une page par un développeur qui la comprend à moitié, ou injectée en bloc par une surcouche — elle ment activement aux technologies d'assistance, annonçant des boutons qui n'existent pas, des étiquettes erronées et des rôles qui ne correspondent pas. Le lecteur d'écran croit le code, pas l'écran. Et le client est plus mal loti que si personne n'y avait touché.

Faits essentiels

• Le WebAIM Million 2026 — l'analyse annuelle par WebAIM d'un million de pages d'accueil — a constaté que les pages d'accueil comportant de l'ARIA présentaient en moyenne 59,1 erreurs détectées, contre 42 sur les pages sans ARIA ; plus une page utilisait d'attributs ARIA, plus elle tendait à présenter d'erreurs d'accessibilité détectées (WebAIM, 2026 WebAIM Million).
• Ce même rapport a relevé des manquements WCAG 2 détectables sur 95,9 % des pages d'accueil en 2026, en hausse par rapport à 94,8 % en 2025 — inversant plusieurs années d'amélioration lente (WebAIM, 2026 WebAIM Million).
• Le propre guide du W3C énonce une règle sans détour : « Pas d'ARIA vaut mieux qu'une mauvaise ARIA. » La première règle de l'ARIA veut que, si un élément HTML natif peut faire le travail, on l'utilise au lieu de le recréer avec de l'ARIA (W3C, WAI-ARIA Authoring Practices).
• Le critère WCAG 4.1.2 Nom, rôle et valeur est de niveau A (Web Content Accessibility Guidelines, ou Règles pour l'accessibilité des contenus Web) : chaque commande interactive doit exposer un nom, un rôle et une valeur corrects aux technologies d'assistance — et une ARIA incorrecte est l'un des moyens les plus rapides d'y échouer (W3C).
• L'art. 14 du RNAI (Règlement sur les normes d'accessibilité intégrées, Règl. de l'Ont. 191/11) de l'Ontario exige des organisations comptant 50 employés ou plus que leurs sites Web publics soient conformes à WCAG 2.0 niveau AA, et le prochain RCL (Rapport de conformité en matière d'accessibilité) pour les organisations comptant 20 employés ou plus est dû le 31 décembre 2026 (ontario.ca, Règl. de l'Ont. 191/11).

Qu'est-ce que l'ARIA, et qu'exige réellement WCAG à son sujet ?

L'ARIA est un vocabulaire d'attributs — des éléments comme role="button", aria-label, aria-expanded, aria-hidden — qu'on ajoute au HTML pour transmettre du sens à un lecteur d'écran. Son objectif est étroit : décrire des composants personnalisés et du contenu dynamique pour lesquels le HTML brut n'a pas d'élément intégré. Une liste déroulante véritablement sur mesure, un panneau à onglets, un total de panier qui se met à jour en direct — ceux-ci peuvent légitimement avoir besoin d'ARIA pour qu'un lecteur d'écran annonce ce qui se passe.

Ce que WCAG exige, ce n'est pas « utilisez l'ARIA ». Il exige, en vertu de 4.1.2 Nom, rôle et valeur (niveau A), que chaque commande interactive expose un nom, un rôle et un état corrects — par quelque moyen que ce soit. Un <button>Ajouter au panier</button> standard le fait déjà gratuitement. Dès que vous le remplacez par un <div> stylisé avec un role="button" ajouté, vous vous chargez de réimplémenter tout ce que le bouton natif offrait : le focus clavier, les touches Entrée et Espace, le rôle annoncé. Ratez le moindre morceau et vous avez bâti quelque chose qui paraît accessible dans le code mais échoue en pratique. C'est pourquoi la première règle de l'ARIA du W3C est de privilégier le HTML natif, et pourquoi son guide affirme sans détour que pas d'ARIA vaut mieux qu'une mauvaise ARIA.

Pourquoi ajouter de l'ARIA rend-il si souvent un site moins accessible ?

Parce que l'ARIA modifie ce que le lecteur d'écran annonce sans changer ce que la page fait réellement — de sorte qu'une erreur reste invisible pour la personne voyante qui l'a commise. Quelques schémas reviennent :

• aria-hidden="true" sur le mauvais élément. Destiné à masquer le fouillis décoratif, il se retrouve sur une vraie commande ou un bloc de contenu — qui disparaît alors complètement pour les utilisateurs de lecteur d'écran tout en restant pleinement visible pour les autres.
• Un aria-label qui remplace le texte visible. Un bouton affiche « Soumettre » à l'écran mais annonce « bouton » ou, pire, une étiquette résiduelle de la version précédente — de sorte qu'un utilisateur de commande vocale qui dit « cliquer Soumettre » n'atteint rien.
• Un rôle qui contredit l'élément. Un lien marqué role="button", ou un titre marqué role="presentation", dit une chose au lecteur d'écran tandis que la page se comporte autrement. C'est la même rupture structurelle que dans les lecteurs d'écran et la structure du site : la carte de la technologie d'assistance ne correspond plus à la réalité.
• Un état qui ne se met jamais à jour. aria-expanded="false" sur un menu désormais ouvert, ou une erreur signalée par ARIA dont le lecteur d'écran n'est jamais informé — la lacune derrière une bonne part de l'accessibilité des formulaires et de la gestion des erreurs.

C'est aussi exactement pourquoi une analyse n'est pas un audit. Un analyseur automatisé peut confirmer qu'un aria-label existe ; il ne peut généralement pas dire si l'étiquette est correcte, si le rôle correspond au comportement, ou si le contenu masqué aurait dû l'être. Ce sont des jugements humains — ce qui explique justement pourquoi les données de WebAIM montrent que plus d'ARIA est corrélé à plus d'erreurs détectées, et non moins.

Pourquoi les surcouches d'accessibilité aggravent-elles le problème de l'ARIA ?

Une surcouche est un script unique que vous collez sur votre site et qui promet de corriger l'accessibilité automatiquement — et une grande partie de ce qu'elle injecte est de l'ARIA. C'est la pire source possible. La surcouche ne peut pas savoir lequel de vos <div> est réellement un bouton, ce que vos commandes à icône seule sont censées dire, ni si une région devrait être masquée — alors elle devine à grande échelle, superposant de l'ARIA générique sur une structure qu'elle ne comprend pas. Le résultat : plus d'attributs, plus de contradictions, et davantage des erreurs mêmes que le WebAIM Million ne cesse de mesurer. C'est la faille au centre du débat sur les surcouches contre la vraie remédiation, et c'est pourquoi l'action de 1 million de dollars US de la FTC contre un fournisseur de surcouche (accessiBe) portait sur l'écart entre l'argument marketing et ce que l'outil livrait réellement. Une mauvaise ARIA n'est pas un extra inoffensif — c'est un préjudice mesurable, et il est greffé automatiquement.

Comment vérifier si votre ARIA aide ou nuit — et quel est le risque en Ontario ?

Vous pouvez faire vous-même un premier passage utile. Activez un lecteur d'écran — VoiceOver est intégré à chaque Mac (Cmd-F5), Narrateur sous Windows (Ctrl-Win-Entrée), et le gratuit NVDA est largement utilisé — et accomplissez une tâche réelle : trouver un produit, l'ajouter au panier, remplir le formulaire, atteindre la caisse. Soyez attentif aux signaux. Chaque commande annonce-t-elle un nom qui correspond à son texte visible ? Les menus et accordéons rapportent-ils le bon état ouvert/fermé ? Quelque chose de visible devient-il muet, ou le lecteur annonce-t-il quelque chose qui n'est pas à l'écran ? Chacun de ces cas est probablement un défaut d'ARIA — et la correction honnête est presque jamais plus d'ARIA. C'est retirer les attributs brisés et, lorsque c'est possible, utiliser l'élément HTML natif qui n'a jamais eu besoin d'ARIA au départ. Bâtir selon WCAG 2.2, la norme actuelle, garde cette base propre.

Sur le plan juridique : en Ontario, la LAPHO (Loi sur l'accessibilité pour les personnes handicapées de l'Ontario) ne prévoit pas de droit d'action privé — une personne ne peut pas poursuivre en vertu de cette loi. La voie pour un particulier passe par le TDPO (Tribunal des droits de la personne de l'Ontario), qui entend les plaintes de discrimination en vertu du Code des droits de la personne de l'Ontario ; un client qui ne peut pas conclure un achat qu'un client voyant peut conclure a une réclamation plausible d'accès inégal aux biens et services. Si vous vendez aussi aux États-Unis, les commandes brisées comptent parmi les problèmes les plus cités dans les litiges relatifs à l'ADA — une partie des plus de 5 000 poursuites en accessibilité numérique déposées devant les tribunaux américains en 2025 (UsableNet). Comme toujours, la position durable est la remédiation documentée : les défauts trouvés, l'ARIA brisée retirée, les correctifs natifs livrés et les dates — ce que devrait aussi refléter un RCL honnête d'ici le 31 décembre 2026.

Vérifiez si votre site signale une ARIA brisée, du code de surcouche ou d'autres problèmes d'accessibilité — rapport Vayle gratuit, environ 30 secondes : vayle.art. Il détecte les surcouches, fait ressortir de vrais manquements WCAG et vous indique exactement ce qui s'applique légalement à votre organisation en Ontario. Sans engagement.

Vayle est une studio d'ingénierie de l'accessibilité à distance au service de l'Ontario. Renseignements généraux, pas un avis juridique.