ARIA : ce que votre site dit à ceux qui ne le voient pas

Certains de vos visiteurs ne regardent pas votre site : ils l'écoutent. Un lecteur d'écran lit la page à voix haute, élément par élément. D'autres se déplacent uniquement au clavier, de lien en bouton. Pour eux, ce qui compte n'est pas ce que la page montre, mais ce qu'elle dit.

ARIA, en deux mots

WAI-ARIA est une norme du W3C, l'organisme qui définit les standards du web. Elle ajoute au code des pages des indications invisibles à l'écran : ce qu'est un élément (un bouton, un menu, une boîte de dialogue), son nom et son état (ouvert, fermé, activé).

Prenez le cœur « j'aime » placé sous une photo. À l'écran, tout le monde comprend. Pour un lecteur d'écran, sans ces indications, ce n'est qu'un « bouton ». Avec elles :

<button aria-label="J'aime cette photo" aria-pressed="false">♥</button>

Le visiteur entend, à peu de chose près : « J'aime cette photo, bouton, non enfoncé ». Il sait ce que fait le bouton, et s'il l'a déjà utilisé.

La première règle : en faire le moins possible

Le W3C le dit lui-même : quand un élément HTML natif fait l'affaire, il faut l'utiliser plutôt que d'ajouter de l'ARIA. Un attribut mal placé est pire qu'un attribut absent : il annonce un menu qui n'existe pas, ou une grille dans laquelle on ne peut pas se déplacer. Le visiteur se retrouve perdu, sans comprendre pourquoi.

L'approche Xanata

Sur les sites que nous construisons :

le natif d'abord : fenêtres de confirmation, menu mobile et choix de la langue reposent sur des éléments HTML natifs. Le navigateur gère alors lui-même le clavier et annonce l'état ouvert ou fermé, sans script ajouté ;
des états annoncés : le cœur « j'aime » dit s'il est déjà activé, le sélecteur de langue indique la langue en cours ;
des icônes qui se taisent : une icône décorative est masquée aux lecteurs d'écran, pour qu'on n'entende pas « image » au milieu d'une phrase. Une icône qui porte seule une information reçoit un nom ;
des photos qui ont un nom : dans une galerie, chaque vignette ouvre la photo en grand. Si la photo n'a pas encore de description, le lien reçoit quand même un nom, « Agrandir la photo », plutôt que l'adresse du fichier.

Reste une part que le code ne peut pas faire à votre place : décrire vos photos. Votre espace d'administration liste celles qui n'ont pas encore de description, pour que rien ne passe entre les mailles.

Nous relisons notre propre code

Une règle ne vaut que si l'on vérifie qu'elle est appliquée. Notre moteur existe depuis plus de dix ans. Il a été entièrement réécrit depuis, mais une habitude n'a jamais changé : relire le code, le vérifier, l'améliorer, revue après revue. Sécurité, performance, accessibilité : chaque revue a son angle, et chaque correction profite d'un coup à tous les sites que nous hébergeons. C'est l'avantage d'un moteur commun.

Ce que vous y gagnez

Plus de visiteurs bien servis : personnes aveugles ou malvoyantes, personnes âgées, mais aussi tous ceux qui naviguent au clavier, par habitude ou par nécessité.
Une obligation qui s'étend : depuis le 28 juin 2025, l'acte européen sur l'accessibilité impose ces exigences à de nombreux services en ligne destinés aux consommateurs, dont le commerce en ligne. Selon votre activité et votre taille, vous y êtes peut-être déjà soumis.
Un site mieux compris : les moteurs de recherche lisent eux aussi les descriptions des images et la structure des pages.

Envie de savoir ce que votre site dit à ceux qui ne le voient pas ? Écrivez-nous.