Contenu pour lecteurs d'écran : qui le relit vraiment ?

Une partie du contenu de votre site n'est jamais relue. Pas parce qu'on l'a oubliée, mais parce que personne ne la voit : les alternatives d'images, les noms accessibles des boutons à icône, les textes masqués visuellement, les messages de statut. Ce sont des phrases écrites par un développeur pressé, validées par personne, et pourtant lues à voix haute à une partie de vos visiteurs.

Cet article montre pourquoi le RGAA a déjà anticipé ce problème dans sa structure même, où se situent les angles morts de la chaîne éditoriale, et comment organiser une relecture qui ne demande ni compétence technique ni outil payant.

---

Le RGAA sépare déjà la présence et la pertinence

Regardez comment le référentiel est construit. Deux critères se suivent, et ils ne posent pas la même question :

• Le critère RGAA 11.1 demande si chaque champ de formulaire a une étiquette.
• Le critère RGAA 11.2 demande si chaque étiquette associée à un champ est pertinente.

Le même dédoublement se retrouve ailleurs. Le critère 1.1 porte sur l'existence d'une alternative textuelle pour les images porteuses d'information. Le critère 11.9 porte sur la pertinence de l'intitulé de chaque bouton. Le critère 6.1 demande si chaque lien est explicite.

Cette architecture n'est pas un hasard de rédaction. Elle sépare ce qu'une machine peut constater de ce qu'un humain doit juger. Un analyseur voit très bien qu'un attribut est vide. Il ne peut pas décider si « Continuer » est un intitulé pertinent, parce que la réponse dépend de ce que fait réellement ce bouton.

En pratique, la moitié automatisable du référentiel reçoit toute l'attention, et la moitié éditoriale n'a jamais trouvé de responsable.

---

Trois angles morts qui expliquent l'absence de relecture

Le rédacteur ne voit pas ces textes. Dans la plupart des interfaces de publication, le champ d'alternative est un petit encart secondaire, souvent replié, parfois absent. Le texte qui compose l'interface elle-même (libellés de boutons, messages de confirmation) ne passe même pas par le CMS : il vit dans le code.

L'intégrateur considère la tâche faite. Renseigner un aria-label est une action technique qui se termine quand l'attribut est rempli. La question de savoir si le contenu de l'attribut est bien formulé sort du cadre du ticket.

La relecture d'épreuves porte sur le visible. Un relecteur professionnel travaille sur ce qui s'affiche. Il ne lui viendrait pas à l'idée d'ouvrir l'inspecteur du navigateur, et personne ne le lui a demandé.

Résultat : trois métiers se croisent autour de ce texte, et aucun ne le possède.

---

Les quatre défauts typiques du texte invisible

Ce sont toujours les mêmes, et ils sont éditoriaux, pas techniques.

La sur-description. « Sélectionner pour fermer la fenêtre » là où « Fermer » suffit. « Bouton précédent pour aller à la diapositive précédente » là où « Diapositive précédente » fait le travail. Le lecteur d'écran énonce déjà la nature de l'élément : répéter « bouton » dans le libellé produit « bouton bouton ». Ayesha Semfel a documenté plusieurs de ces cas dans un article d'Intopia sur la relecture du contenu destiné aux lecteurs d'écran publié le 9 juillet 2026.

Le code resté en place. Une variable de gabarit non remplacée, un texte de remplissage provisoire, un identifiant technique. Ces défauts survivent des années parce qu'ils ne cassent aucun affichage et ne déclenchent aucune alerte.

La faute de frappe jamais corrigée. Un nom propre mal orthographié dans une alternative reste tel quel indéfiniment. Aucun correcteur orthographique ne parcourt les attributs HTML.

L'absence de ponctuation. Une synthèse vocale s'appuie sur la ponctuation pour marquer ses pauses. Une alternative rédigée en style télégraphique, sans point ni virgule, produit un débit continu difficile à suivre.

---

Un protocole de relecture qui ne demande pas d'être développeur

L'objectif n'est pas de former vos rédacteurs à l'ARIA. Il est de leur donner accès au texte pour qu'ils fassent leur métier dessus.

1. Extraire la liste. La plupart des lecteurs d'écran proposent une liste des liens et une liste des titres de la page. Les outils de développement des navigateurs exposent l'arbre d'accessibilité, qui affiche le nom calculé de chaque élément. Sortez cette liste dans un document.
2. Lire hors contexte. Un libellé se juge sans la page autour. « En savoir plus », lu isolément dans une liste de quinze liens identiques, ne permet pas de choisir. C'est exactement ce que vérifie le critère 6.1.
3. Faire lire par quelqu'un qui n'a pas écrit la page. L'auteur d'une alternative sait ce qu'il a voulu dire. Il est le plus mal placé pour juger si la formulation tient toute seule.
4. Écouter la page une fois. Un passage avec NVDA ou VoiceOver donne en quelques minutes une perception que la lecture silencieuse ne donne jamais, notamment sur la ponctuation et les répétitions.

Cette relecture est peu coûteuse et ne se refait pas à chaque déploiement. Elle se cale utilement au même rythme que la relecture des contenus visibles.

---

Ce qu'un outil mesure, ce qu'il ne juge pas

La frontière est stable, et elle recoupe exactement la distinction du référentiel.

Un scan automatisé constate de façon fiable :

• qu'une image porteuse d'information n'a aucune alternative ;
• qu'un bouton ou un lien n'a aucun nom accessible ;
• qu'un champ de formulaire n'a pas d'étiquette associée ;
• qu'une alternative reprend mot pour mot le nom du fichier image.

Il ne peut pas conclure :

• qu'une alternative décrit bien ce que l'image apporte à cet endroit précis ;
• qu'un intitulé de bouton correspond à ce que le bouton déclenche ;
• qu'un lien reste compréhensible sorti de son paragraphe ;
• qu'un message de statut arrive au bon moment et dans les bons termes.

C'est la raison pour laquelle environ 60 % des critères RGAA applicables demandent une vérification humaine. Cette part n'est pas un défaut des outils à combler un jour : elle correspond à des questions de sens, et le sens ne se mesure pas.

Pour aller plus loin sur la mécanique des attributs, notre guide sur aria-label et aria-labelledby couvre le versant technique, et nos principes de rédaction web accessible s'appliquent au contenu visible.

---

Conclusion

Le texte destiné aux lecteurs d'écran est du contenu. Il souffre exactement des mêmes maux que le reste quand personne ne le relit : approximations, répétitions, coquilles, provisoire devenu définitif. La différence est qu'ici, aucun lecteur voyant ne les signalera jamais.

La correction ne demande pas d'outillage supplémentaire, seulement une décision d'organisation : désigner qui relit ces textes, et lui donner le moyen de les lire. Vous pouvez analyser une page pour repérer les alternatives et les noms accessibles manquants, ce qui vous donne la liste de départ. La qualité de ce qui y est écrit, elle, reste un travail d'écriture.