Écriture inclusive : le point d’hyphénation rend-il vraiment meilleure la lecture par les lecteurs d’écran ?

Ces derniers mois, je me suis retrouvée dans plusieurs discussions sur l’écriture inclusive où des personnes partageaient un article qui dit qu’il faudrait utiliser le point d’hyphénation plutôt que le point médian lorsqu’on utilise des abréviations inclusives parce que la lecture par les lecteurs d’écran serait meilleure. Cet article s’intitule « Point médian final : point d’hyphénation ‧ » et a été écrit par Matti Schneider en 2019.

Si cet article n’est pas inintéressant, il y a malgré tout un problème de taille : un seul lecteur d’écran a été testé, VoiceOver sur MacOS. Or, il existe différents lecteurs d’écran et tous ne se comportent pas de la même façon. Le synthétiseur se trouvant dans ces logiciels peut aussi faire varier les choses ainsi que la voix utilisée. De plus, tout ceci évolue dans le temps.

Qu’en est-il concrètement ?

La restitution des caractères par les lecteurs d’écran

Les lecteurs d’écran ont différents niveaux de verbosité ajustables. Concernant la ponctuation, on peut choisir de la leur faire prononcer un peu, la plupart, tout, pas du tout. Un effeuillage de marguerite.

Par défaut, les lecteurs d’écran sont configurés pour lire un peu de ponctuation ; ce qui signifie que la plupart de la ponctuation est ignorée (mais si on épelle les mots, elle est restituée). Évidemment, si le lecteur d’écran est configuré pour lire toute la ponctuation, aucun caractère ne sera ignoré à moins qu’il ne soit pas reconnu.

Lorsqu’un caractère n’est pas reconnu par le lecteur d’écran (ou son synthétiseur ou la voix ; on ne sait pas toujours à quel niveau ça se joue), alors, généralement, il est simplement ignoré. Mais un caractère ignoré à un instant T ne le sera pas forcément toute sa vie !

De plus, il existe plusieurs façons de faire lire un texte par un lecteur d’écran. On peut par exemple lui faire lire une phrase entière mais on peut aussi lui faire épeler les caractères. Et c’est en lui faisant épeler les caractères qu’on va vraiment pouvoir comprendre ce qui se passe : le caractère est-il ignoré sciemment par le lecteur d’écran quand il lit la phrase ? Ou bien est-il ignoré aussi quand on l’épelle ; ce qui ne serait alors pas normal ?

Voici donc quelques tests de restitution, réalisés en juillet 2024, avec différents lecteurs d’écran en reprenant la phrase testée dans l’article sur le point d’hyphénation : Merci à tous et toutes les contributrices qui sont venues (mais en version avec les abréviations). Les réglages des lecteurs d’écran sont ceux de base pour la ponctuation, c’est-à-dire que seuls peu de signes sont restitués lorsqu’on leur fait lire le contenu en mode phrase (sans épeler). Quant au synthétiseur et à la voix, les deux sont dans leur paramétrage d’origine à l’installation du lecteur d’écran.

J’ai testé le fameux point d’hyphénation et son concurrent le point médian. J’ai également testé le tiret et l’apostrophe qui sont deux caractères régulièrement utilisés qu’on m’avait soumis à interrogation lors des discussions.

La phrase avec le point d’hyphénation

Le point d’hyphénation s’appelle en réalité, en français, le point de coupure de mot (hyphenation point est son nom en anglais).

Merci à tou‧te‧s les contributeur‧trices qui sont venu‧e‧s.

• NVDA 2024.2 : Merci à tou point de coupure de mot te point de coupure de mot esse les contributeur point de coupure de mot traïceusse qui sont venu point de coupure de mot e point de coupure de mot esse.
  • NVDA pense que « trices » est un mot anglais et le lit à l’anglaise, on ne sait pas pourquoi…
  • NVDA restitue le caractère en prononçant « point de coupure de mot » ;
  • Lecture non fluide et incompréhensible.
• JAWS 2024 : Merci à tou point d’interrogation te point d’interrogation esse les contributeur point d’interrogation trices qui sont venu point d’interrogation euh point d’interrogation esse.
  • JAWS ne reconnaît pas le caractère et le signale comme un point d’interrogation (un peu comme quand certains caractères non reconnus par une plateforme affichent un point d’interrogation dans un losange noir : le caractère de remplacement �) ;
  • Lorsqu’on fait épeler à JAWS, il ne dit rien lorsqu’on tombe sur le point d’hyphénation ; ce qui appuie l’hypothèse du caractère non reconnu ;
  • Lecture non fluide et incompréhensible.
• VoiceOver sur MacOS Sonoma 14.5 : Merci à toutes les contributeur trices qui sont venues.
  • VoiceOver ignore le caractère et lit comme s’il n’y avait pas de séparateur au milieu des mots ;
  • Lorsqu’on fait épeler à VoiceOver, il dit « hyphenation point », soit le nom du caractère en anglais mais lu à la française. Il manque donc une traduction. C’est nouveau car, lors de tests en mars, il n’était pas restitué du tout même en épelant ;
  • Lecture fluide et compréhensible.
• Talkback FOSS (version libre de Talkback sur les téléphones dégooglisés) : Merci à tou te esse les contributeur trices qui sont venu é esse.
  • Talkback FOSS ignore le caractère mais tient compte du séparateur au milieu des mots ;
  • Lorsqu’on fait épeler à Talkback FOSS, le caractère est ignoré ; ce qui semble indiquer qu’il n’est pas encore reconnu.
  • Lecture plutôt fluide et plutôt compréhensible.

La phrase avec le point médian

Le point médian (ou point milieu) est un point bien particulier qui ne doit pas être assimilé au point de fin de phrase ou à la puce ou à tout autre point.

Merci à tou·te·s les contributeur·trices qui sont venu·e·s.

• NVDA 2024.2 : Merci à tou te esse les contributeur traïceusse qui sont venu euh esse.
  • NVDA ignore le point médian mais tient compte du séparateur au milieu des mots ;
  • Lorsqu’on fait épeler à NVDA, le caractère est lu « point médian ». Celui-ci est donc sciemment ignoré lors de la lecture d’une phrase ;
  • NVDA continue à considérer « trices » comme un mot anglais ;
  • Lecture plutôt fluide et peu compréhensible.
• JAWS 2024 : Merci à tou point te point esse les contributeur point trices qui sont venu point euh point esse.
  • JAWS lit le point médian comme s’il s’agissait d’un point y compris lorsqu’on lui fait épeler ;
  • Lecture non fluide et peu compréhensible.
• VoiceOver sur MacOS Sonoma 14.5 : Merci à tou te esse les contributeur trices qui sont venu euh esse.
  • VoiceOver ignore le point médian mais tient compte du séparateur au milieu des mots ;
  • Lorsqu’on fait épeler à VoiceOver, il dit « point centré » ;
  • Lecture plutôt fluide et plutôt compréhensible.
• Talkback FOSS : Merci à tou point médian te point médian esse les contributeur point médian trices qui sont venu point médian é point médian esse.
  • Talkback FOSS lit le point médian ;
  • Lecture non fluide et incompréhensible.

La phrase avec le tiret

Le tiret, ou trait d’union-signe moins, est le fameux « tiret du 6 ».

Merci à tou-te-s les contributeur-trices qui sont venu-e-s.

• NVDA 2024.2 : Merci à tou te esse les contributeur trices qui sont venu esse.
  • NVDA ignore le caractère mais tient compte du séparateur au milieu des mots sauf pour le « e » de « venu » qui semble ignoré ;
  • Lorsqu’on fait épeler à NVDA, le caractère est lu « tiret » ;
  • Lecture plutôt fluide et plutôt compréhensible.
• JAWS 2024 : Merci à tou te esse les contributeur trices qui sont venu euh esse.
  • JAWS ignore le caractère mais tient compte du séparateur au milieu des mots ;
  • Lorsqu’on fait épeler à JAWS, le caractère est lu « tiret » ;
  • Lecture plutôt fluide et plutôt compréhensible.
• VoiceOver sur MacOS Sonoma 14.5 : Merci à tou te esse les contributeur trices qui sont venu euh esse.
  • VoiceOver ignore le caractère mais tient compte du séparateur au milieu des mots ;
  • Lorsqu’on fait épeler à VoiceOver, le caractère est lu « trait d’union » ;
  • Lecture plutôt fluide et plutôt compréhensible.
• Talkback FOSS : Merci à toutes les contributeur trices qui sont venues.
  • Talkback FOSS ignore la présence du caractère et lit comme s’il n’y avait pas de séparateur au milieu des mots ;
  • Lorsqu’on fait épeler à Talback FOSS, il restitue le caractère comme étant un « tiret » ;
  • Lecture fluide et compréhensible.

La phrase avec l’apostrophe et le guillemet-apostrophe

L’apostrophe ' est le caractère qui s’écrit par défaut via nos claviers dans leur configuration de base. Certains logiciels la remplacent parfois automatiquement par le « guillemet-apostrophe ».

Le guillemet-apostrophe ’ est une apostrophe courbée. Certains logiciels remplacement automatiquement l’apostrophe de base par ce caractère plus stylisé et qui est à priori le bon caractère apostrophe pour les puristes de la typographie.

Merci à tou'te's les contributeur'trices qui sont venu'e's.

Merci à tou’te’s les contributeur’trices qui sont venu’e’s.

Pour ces deux phrases, la restitution d’ensemble a été la même à chaque fois. Seule la lecture en épelant permet de différencier le nom du caractère.

• NVDA 2024.2 : Merci à tou te esse les contributeur trices qui sont venu esse.
  • NVDA ignore le caractère mais tient compte du séparateur au milieu des mots sauf pour le « e » de « venu » qui semble ignoré ;
  • Lorsqu’on fait épeler à NVDA, le premier caractère est lu « apostrophe » et le deuxième « apostrophe droite » ;
  • Lecture plutôt fluide et plutôt compréhensible.
• JAWS 2024 : Merci à touteuse les contributeur trices qui sont venues.
  • JAWS ignore la présence du caractère et lit comme s’il n’y avait pas de séparateur au milieu des mots ;
  • Il nous invente également un nouveau néologisme avec « touteuse » ;
  • Lorsqu’on fait épeler à JAWS, les deux caractères sont lus « apostrophe » de manière indifférenciée ;
  • Lecture fluide et compréhensible.
• VoiceOver sur MacOS Sonoma 14.5 : Merci à toutse les contributeur trices qui sont venusse.
  • VoiceOver ignore la présence du caractère et lit comme s’il n’y avait pas de séparateur au milieu des mots ;
  • Certains mots sont lus un peu bizarrement ;
  • Lorsqu’on fait épeler à VoiceOver, le premier caractère est lu « apostrophe » et le deuxième « guillemet-apostrophe » ;
  • Lecture fluide et plutôt compréhensible.
• Talkback FOSS : Merci à toooutes les contributeur trices qui sont venues.
  • Talkback FOSS ignore la présence du caractère et lit comme s’il n’y avait pas de séparateur au milieu des mots ;
  • Le « ou » de « toutes » est appuyé donc plus long mais ça ne gêne pas la compréhension ;
  • Lorsqu’on fait épeler à Talkback FOSS, le premier caractère est lu « apostrophe » et le deuxième « simple guillemet fermant » ;
  • Lecture fluide et compréhensible.

Résumé de lecture par les lecteurs d’écran

D’après ces tests sur quatre lecteurs d’écran différents, il semblerait que le point d’hyphénation et le point médian soient les grands perdants. Lorsqu’ils sont restitués, la lecture de la phrase test est absolument imbuvable. Toutefois, il faut tenir compte du fait que cette phrase contient bien trop de séparateurs et aurait largement pu être optimisée. La phrase aurait pu être écrite avec un seul point médian (ou pas du tout, cf. l’introduction des tests) : Merci à toustes les contributeurices qui sont venu·es et ça aurait été moins pire.

Le point d’hyphénation me semble quand même avoir un résultat de restitution pire que le point médian. Dans l’ordre du meilleur au pire en termes de fluidité et de compréhensibilité, je séparerais ainsi les concurrents :

1. L’apostrophe 👏 (mais ne nous emballons pas, ce n’est quand même pas la perfection !) ;
2. Le tiret ;
3. Le point médian ;
4. Le point d’hyphénation (ou point de coupure de mot).

Pour chacun des cas testés, on remarque qu’il y a toujours certains lecteurs d’écran pour lesquels l’effort cognitif nécessaire pour comprendre les phrases est exagéré. Cela signifie que certaines personnes comprendront certainement mieux que d’autres ce qui est écrit et avec plus ou moins d’effort. Il ne faut pas le négliger.

La lisibilité des abréviations inclusives : le problème du retour à la ligne

Un jour, j’ai lu un livre écrit avec de (trop) nombreuses abréviations inclusives. Celles-ci étaient formées à l’aide du point de fin de phrase. Or, dans les livres, les textes sont généralement justifiés (alignés à gauche et à droite) ; ce qui oblige à la mise en place de césures dans les mots en bout de ligne. Ce livre a été extrêmement difficile à lire car l’écriture inclusive était utilisée de façon fort mal réfléchie d’une part, mais d’autre part parce que les césures au milieu de mots contenant des abréviations inclusives séparées par des points rendaient difficile la compréhension des phrases. L’effort cognitif demandé aux lecteurices voyantes était bien trop grand !

En effet, certains caractères, comme le point de fin de phrase, autorisent le retour à la ligne automatique en cas de manque de place. Or, aller à la ligne en plein milieu d’une terminaison de mots n’a absolument aucun sens. Cela complexifie la lecture. Par exemple, si j’écris « contributeur.trices », la terminaison « trices » peut se retrouver sur la ligne d’en-dessous. Les lecteurices pourraient alors se demander ce que signifie ce mot puisqu’il n’est plus vraiment rattaché à sa base « contributeur » et que le lien en devient donc moins clair. C’est ce qui m’est arrivé avec ce maudit bouquin !

Parmi les caractères testés ci-dessus, le point d’hyphénation et le tiret autorisent également le retour à la ligne (lorsqu’il n’y a plus assez de place sur une ligne, le mot peut se retrouver couper en deux, sur deux lignes) ; ce qui en fait des caractères inappropriés.

À noter que je n’ai pas testé le point de fin de phrase (point classique .) ci-dessus car ce caractère marque la fin d’une phrase et est donc extrêmement perturbant dans son usage pour les abréviations inclusives. Le fait qu’il permette le retour à la ligne est une raison de plus pour ne pas l’utiliser. Par ailleurs, lorsqu’on l’utilise pour certaines abréviations comme « venu.es », dans certains cas (réseaux sociaux, mails…), cela crée automatiquement des liens involontaires. Ça devient donc une faille de sécurité si jamais, un jour, cela menait vers un vrai site qui pourrait être malveillant sans qu’on le sache.

En revanche, le point médian ou les apostrophes ne permettent pas les retours à la ligne. C’est un bon point pour ces caractères.

L’apostrophe semble donc être un choix raisonnable pour la restitution par les lecteurs d’écran et parce qu’elle ne crée pas de césure. Toutefois, cela peut être perturbant puisque ce caractère ne s’utilise pas, habituellement, pour marquer des terminaisons. La perturbation me semble tout de même moins importante que pour le point de fin de phrase. De plus, gardons à l’esprit que les tests que j’ai réalisé ne sont pas exhaustifs !

Comme toujours, cela mériterait aussi des tests avec plein de gens et notamment des personnes handicapées qui utilisent des technologies d’assistance et/ou ont des difficultés de lecture ou compréhension.

Conclusion

Le caractère séparateur d’abréviations inclusives parfait n’existe probablement pas.

Si le caractère choisi entraîne une restitution plutôt correcte par certains lecteurs d’écran, cela peut être catastrophique pour d’autres. Voici quelques points essentiels à considérer :

• Ne vous fiez jamais aux résultats de tests réalisés pour un seul lecteur d’écran. Même moi, ici, je ne les ai pas tous testés : il existe aussi VoiceOver sur iOS, l’original Talkback sur Android, le Narrateur sur Windows, ORCA sur Linux… Mais il existe également différents synthétiseurs et différentes voix pour ces lecteurs d’écran qui peuvent donner des résultats très différents. À minima, il faut tester avec NVDA, JAWS et VoiceOver MacOS. Dans l’idéal, testez aussi avec Talkback et VoiceOver iOS ;
• Rien ne garantit qu’une personne aveugle, ou toute autre personne utilisant un lecteur d’écran, aura configuré son lecteur d’écran en mode « peu de ponctuation » : la configuration peut tout changer ;
• Les résultats peuvent changer dans le futur !

Par ailleurs, il n’y a pas que les lecteurs d’écran à considérer. Par exemple, dans son article, Matti Schneider testait aussi Google Traduction mais il existe de nombreux outils de traduction également (à noter que le point négatif relevé dans son article par rapport à l’apostrophe côté traduction automatique n’est plus vrai d’après mon test du jour). De mon côté, j’ai évoqué ici le problème des retours à la ligne que certains caractères autorisent et qui complexifient la lecture.

Je l’avais déjà dit par le passé mais je me répète :

• Limitons le nombre d’abréviations dans nos textes ;
• Limitons le nombre de séparateurs dans nos mots : utiliser un seul caractère sera moins verbeux qu’en utiliser deux : « venu·es » plutôt que « venu·e·s », par exemple ;
• Si le mot peut s’écrire sans séparateur en collant toutes les lettres, ce sera d’autant plus sûr : « contributeurices » et « toustes », par exemple. Cela crée des néologismes qu’on peut même utiliser à l’oral et qui restent compréhensibles car ils sont fondés sur une base de mot connue ;
• Utilisons des tournures de phrase qui permettent d’éviter les abréviations pour n’utiliser ces dernières qu’en dernier recours.
  À ce sujet, vous pouvez creuser via mon article « Écriture inclusive et accessibilité numérique, table ronde lors des Journées d’étude technologies et déficience visuelle ».