loading . . . Les lecteurs d’écran ne restituent pas le (vrai) gras et italique (strong, em, b, i) des textes Depuis fort fort longtemps (la plus vieille trace trouvée au fil de l’écriture de cet article date de 2007), de nombreuses personnes relaient l’idée selon laquelle les lecteurs d’écran :
* Liraient plus fort les textes balisés via l’élément HTML `strong`, qui a la particularité de mettre visuellement le texte en gras ;
* Ou encore liraient différemment ou restitueraient la sémantique des éléments `strong` et `em` (mais pas des éléments `b` et `i` ni d’un simple `span` avec du gras ajouté via CSS).
Les WCAG, par le biais de la technique H49 associée au critère 1.3.1 « _Info and relationships_ », ainsi que le RGAA, par le biais du critère 3.1 « Dans chaque page web, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ? » (cf. note en fin d’article à ce sujet), permettent l’usage des éléments HTML `strong` et `em` afin de véhiculer techniquement une information de manière accessible, y compris pour les personnes aveugles.
J’imagine que, pour justifier cela, les affirmations précédentes ont dû être prononcées. Mais saviez-vous que ces affirmations sont fausses ou pas totalement vraies ?
Je vous livre le résultat de mes tests.
## Scénario de test
J’ai fait lire à différents lecteurs d’écran les textes suivants utilisant les différentes manières de mettre en gras ou en italique pour le mot « mouche » :
* Témoin : T’as une mouche à l’envers sur ta tête de grenouille.
* `strong` (gras) : T’as une **mouche** à l’envers sur ta tête de grenouille.
* `em` (italique) : T’as une _mouche_ à l’envers sur ta tête de grenouille.
* `b` (gras) : T’as une **mouche** à l’envers sur ta tête de grenouille.
* `i` (italique) : T’as une _mouche_ à l’envers sur ta tête de grenouille.
* `span` + CSS gras : T’as une mouche à l’envers sur ta tête de grenouille.
* `span` + CSS italique : T’as une mouche à l’envers sur ta tête de grenouille.
## Résultats des tests avec différents lecteurs d’écran
### NVDA 2025.2 (avec Firefox 141 et Chrome 139)
**Par défaut, avec NVDA, aucune lecture différenciée des éléments en gras ou en italique** , quels qu’ils soient, n’est opérée.
Mais **un paramétrage est disponible afin de lire les emphases** (dans « Mise en forme des documents », sélectionner la valeur « Parole » pour le champ « Attributs de la police » puis cocher « Emphase »).
NVDA lit alors : "T’as une gras mouche non gras à l’envers…" et "T’as une italique mouche non italique à l’envers…" dans tous les cas.
**Peu importe que les éléments`strong`, `b`, `em`, `i`, ou `span` avec du CSS soient utilisés**, la lecture est identique.
J’ai remarqué une différence notable entre la lecture dans LibreOffice (version 25.2.5.2) et la lecture dans une page web dans le navigateur : dans LibreOffice, la lecture est très fluide et s’enchaîne alors que dans le navigateur, NVDA marque une pause avant de dire "gras mouche non gras".
**Pour information :** il existe une discussion ouverte dans un ticket GitHub de NVDA sur l’idée de différencier la vocalisation de `strong` et `em` par rapport aux autres façons de mettre en gras ou italique. Dans celle-ci, il est expliqué que le mot « _strong_ » n’est pas très clair pour les personnes. D’ailleurs, si on devait le traduire en français, je ne sais même pas comment on pourrait le faire de façon claire non plus !
On apprend également, dans l’article de tempertemper « _Bold and italics aren’t read by screen readers_ », que **NVDA avait, dans une version, forcé la lecture différenciée des éléments en gras et italique avant de faire machine-arrière suite à de nombreuses plaintes des utilisateurices** : c’est donc devenu une option. (Et honnêtement, je les comprends !)
### JAWS 2025.2506.170 (avec Firefox 141)
**Par défaut, avec JAWS, aucune lecture différenciée des éléments en gras ou en italique** , quels qu’ils soient, n’est opérée.
Mais, **dans le centre des paramètres, afin de faire lire le gras et l’italique, on peut aller modifier le schéma actif** (menu « Schémas de sons et de voix »). En choisissant le schéma « Attributs et couleurs », les textes en gras et italique seront notamment restitués comme tels.
Il est aussi possible de modifier le schéma actif pour ajouter la lecture du gras et de l’italique si on ne souhaite pas changer de schéma. Pour cela, se référer à la documentation de JAWS (en anglais, titre « _Create a Scheme to Speak Bold Text Using the Bold Voice Alias_ »). J’ai eu du mal à trouver cette information.
Attention, si vous changez le schéma pour « Attributs et couleurs », n’oubliez pas de remettre le schéma que vous aviez au départ (sûrement « Classique ») quand vous avez terminé vos tests.
Lorsque JAWS restitue les passages en gras et italique, il dit : "T’as une gras mouche normal à l’envers…" et "T’as une italique mouche normal à l’envers…" dans tous les cas.
Vous pouvez aussi paramétrer JAWS pour qu’il fasse un son pendant la lecture de ces éléments ou pour qu’il lise avec une autre voix. **La lecture avec une autre voix est une option à la fois extrêmement drôle et très élégante car elle n’accentue pas le niveau de verbosité.**
À noter que tout cela fonctionne sur le web mais pas dans LibreOffice (version 25.2.5.2).
### VoiceOver sur MacOS Sequoia 15.6 (avec Safari 18.6)
**Par défaut, avec VoiceOver, aucune lecture différenciée des éléments en gras ou en italique** , quels qu’ils soient, n’est opérée.
Mais, là encore, **on peut paramétrer le lecteur d’écran**. La documentation d’Apple « Écouter VoiceOver énoncer les modifications d’attribut de texte sur Mac » explique comment procéder en activant la lecture des « Attributs de texte ». Les attributs de texte sont notamment la couleur, la police d’écriture, la taille du texte, le caractère gras ou italique, etc.
Les phrases de test sont ainsi lues : "T’as une gras mouche standard à l’envers…" et "T’as une italique mouche standard à l’envers…" dans tous les cas.
Mais, pour être tout à fait honnête, voici comment VoiceOver lit un point de liste en entier : "Puce blanc sur noir 16 points Times Une nuance de sur noir Strong gras T’as une gras mouche standard à l’envers sur ta tête de grenouille". (Je n’ai pas compris ce que signifie "Une nuance de sur noir".)
En résumé, **c’est tellement verbeux qu’il y a, à mon avis, à peu près aucune chance qu’une personne active cette option au quotidien pour tout ce qu’elle lit**.
### Sur mobile, Talkback et VoiceOver
Que ce soit avec Talkback (version 15.1, Android 15, Samsung) ou VoiceOver (sur iOS 18.5), **aucune lecture différenciée des éléments en gras ou en italique** , quels qu’ils soient, n’est opérée.
De plus, **aucune option** n’a été trouvée pour ce faire.
## Conclusions sur ces résultats
Mes conclusions sur les résultats de ces tests sont :
* **Par défaut, aucun lecteur d’écran ne semble lire de manière différenciée les textes en gras ou en italique** (peu importe la façon de faire) ;
* Il est **faux d’affirmer que les lecteurs d’écran lisent plus fort les textes balisés avec l’élément`strong`** : aucun lecteur d’écran n’a fait ça, même après paramétrage. Un esprit fort imaginatif a sans doute créé cette rumeur ;
* **Les lecteurs d’écran sur mobile ne permettent pas de les paramétrer** de manière à ce qu’ils restituent le gras ou l’italique de manière différenciée (peu importe qu’il s’agisse de `strong` et `em` ou non) ;
* Lorsqu’on configure les lecteurs d’écran sur ordinateur, ils ne font **pas de distinction entre les manières de mettre en gras ou en italique** : la sémantique n’importe pas, seules des propriétés visuelles sont restituées ;
* Le **paramétrage des lecteurs d’écran peut s’avérer extrêmement compliqué** (notamment avec JAWS) et pas intuitif. Ainsi, seules des personnes ayant une grande maîtrise de leur lecteur d’écran et sachant comment trouver l’information pourront y parvenir ;
* Le paramétrage de lecture du gras et de l’italique peut mener, notamment pour VoiceOver et NVDA, à une **très grande verbosité qui sera vite agaçante**. Les personnes testant l’option la désactiveront sans doute très vite ou ne l’activeront qu’en cas de réel besoin (je pense notamment à l’édition d’un document ou d’un article). Les plaintes reçues par NVDA lors de la mise en place de la fonctionnalité, qui n’était alors pas en option, le confirment.
Ainsi, je me permets d’écrire la généralité suivante : **les lecteurs d’écran ne restituent pas le (vrai) gras et italique des textes** , même si c’est un peu plus compliqué que ça.
**Aparté :** au cas où vous ne suiviez pas ce blog assidument, le « (vrai) » est une référence au fait que les gens utilisent beaucoup le « faux gras » sur les réseaux sociaux qui produit des textes hautement inaccessibles. Ce sont bien deux choses différentes dont il est question ici. Mon article sur le sujet est « Faux gras, caractères fantaisistes, abus d’émojis : le détournement des caractères Unicode, fléau pour l’accessibilité du web ».
## Mes recommandations
* **Continuez à mettre en forme vos textes avec du (vrai) gras et de l’italique** si vous le souhaitez. C’est ici plus de la mise en forme, même si cela permet de mettre l’emphase et donc de montrer l’importance de certains passages ; on ne perd pas vraiment d’information en n’ayant pas la mise en forme.
* Mais si c’est vraiment très important, mettez une accroche visible de tout le monde comme « Attention : » ou « Note importante : ». C’est tout.
* **N’ajoutez surtout pas de texte caché** pour dire « texte important » et « fin de texte important » ou « gras »/« non gras » sinon ça sera imbuvable, d’autant plus si la personne a choisi de ne pas paramétrer son lecteur d’écran de la sorte ou si elle l’a configuré pour lire ces informations car ça fera doublon. **Ne vous substituez pas au lecteur d’écran.**
* **Toutefois, n’utilisez pas uniquement le gras et l’italique (même avec`strong` et `em`) pour donner des vraies informations.** Par exemple :
* Dire « Les nouveautés sont affichées en gras » sera un problème car les personnes aveugles n’y auront majoritairement pas accès : il faut trouver une autre façon de faire ;
* Ou encore mettre l’élément de menu actif en gras uniquement : ajouter un attribut `aria-current="true"` sur le lien sera un complément vraiment efficace.
Voilà, j’espère avoir bien tordu le cou à ces idées reçues qui traînent depuis si longtemps, même si d’autres l’avaient déjà fait avant moi.
## Ressources complémentaires
* « _Screen Readers support for text level HTML semantics_ », Steve Faulkner, TPGi, 26 janvier 2023 ;
* « _Bold and italics aren’t read by screen readers_ », tempertemper, 2 avril 2021.
## À propos du RGAA et du critère 3.1
La version 4 du RGAA a retiré certains critères permettant de vérifier la pertinence de l’application du critère le précédant qui, lui, vérifie la présence d’un élément. De mon point de vue, c’est une immense bêtise qui, loin de clarifier le référentiel, a ajouté du bazar ; d’autant plus que ça a été mal appliqué puisqu’il reste des critères fonctionnant ainsi donc ça a cassé la logique.
Ainsi, le critère 3.2 du RGAA 3 « Dans chaque page Web, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle implémentée de façon pertinente ? » a été supprimé et la définition de glossaire associée au mot « pertinence » (« Pertinence (information autrement que par la couleur) ») a été retirée.
Dans des archives, on peut la retrouver :
> Le moyen pour récupérer une information autrement que par la couleur doit être accessible à tous. Par exemple, dans le cas d’une liste d’articles dont les articles en jaune sont en promotion, l’utilisation de texte caché via CSS est un moyen de récupérer l’information « en promotion », mais il n’est pas pertinent car cette information restera cachée à l’utilisateur qui visualise la page CSS activée.
>
> **Note :** l’utilisation d’une balise d’emphase (`strong` ou `em`) comme autre moyen pour récupérer une information donnée par la couleur permet de valider le critère même si ces éléments ne sont généralement pas supportés par les technologies d’assistance, particulièrement les lecteurs d’écran.
Aujourd’hui, le critère 3.1 a toujours sa définition de glossaire pour « Information (donnée par la couleur) » qui dit ceci (extrait) :
> Les moyens de transmettre une information autrement que par la couleur peuvent être :
>
> * […]
> * Un autre style typographique (gras, italique, taille de texte, autre police, etc) et par le biais d’un complément au niveau du code (`aria-label`, `title`, texte masqué, `aria-current`, etc.).
>
On pourrait donc croire qu’utiliser `strong` ou `em` ne suffit pas, pour le RGAA 4. Or, il faut comprendre ici que ces éléments agissent comme style typographique + complément au niveau du code (puisque ce sont des éléments sémantiques) et ce même si ça ne fonctionne pas dans les faits (se référer pour cela aux WCAG, technique H49). En résumé, entre le RGAA 3 et 4, la demande n’a pas changé.
De mon point de vue, c’est absurde et cela ne devrait pas être permis, ni avec le RGAA ni avec les WCAG : **si ça ne fonctionne pas, pourquoi considérer que ça puisse être conforme ?** Ça n’a tout simplement pas de sens.
* * *
Merci, encore, à Romain Gervois pour nos échanges et ses tests sous iOS. https://www.lalutineduweb.fr/lecteurs-ecran-restitution-gras-italique/
