Bien écrire pour un lecteur d’écran

Tout le monde se secoue ! 

J’ai commencé (jeudi 23 février 2023 à 15h07) la rédaction d’un tutoriel au doux nom de « Bien écrire pour un lecteur d’écran » et j’ai pour objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limites pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l’adresse suivante :

Merci !

Salut ! J’ai commencé à écrire quelques cours autour de l’accessibilité numérique, dans l’intention d’en faire une collection sur quelques sujets que je juge important, et peut-être à terme un plus gros cours sur comment rendre un site web ou une production numérique accessible, peut-être parler de RGAA, d’accessibilité IRL, etc.

Ce cours est le premier vraiment rédigé que je publie en bêta, et il adresse le sujet des lecteurs d’écran. Il est lisible tant par des développeurs·euses web que par des personnes utilisant internet (écriture sur des blogs, dans des cours/billets/articles, sur les réseaux sociaux, …) — ce pourquoi je parle d’accessibilité numérique et non d’accessibilité en développement web. Il est d’ailleurs adapté d’ateliers que j’ai donné dans un contexte d’accessibilité sur les réseaux sociaux et en vulgarisation, notamment dans le cadre du festival Double•Science.

Tout n’est pas terminé (il manque quelques sections, les sources qui pour le moment sont au chaud dans mon Zotero, pas mal de raffinage, et des références à mes autres cours dés lors qu’ils seront publiés), mais la structure ne devrait pas trop changer. J’ai pensé ce cours comme picorable, et pour que même en ne lisant que la table des matières, on ait une idée de comment agir.

De la vidéo ?

Dans ce cours, j’ai commencé à utiliser la vidéo  — une première dans ce contexte pour moi. Actuellement, ce ne sont que des vidéos de démonstration avec une voix off pour expliquer, mais j’hésite à aller plus loin et à incarner les vidéos (en me filmant, quoi), en restant dans cette logique de faire des démonstrations concrètes cela dit. Je pense que ça peut apporter quelque chose de voir vraiment quelqu’un utiliser les technologies d’assistance, et peut-être plus généralement d’humaniser le cours en général.

Mais je doute un peu : qu’en pensez-vous ? Devrais-je aller en ce sens ou n’est-ce que peu utile ? Et à quel point (juste des exemples, aussi une introduction générale, tout le cours en double vidéo+texte) ? Est-ce que le fait que je ne suis pas totalement concerné (je n’ai pas besoin de ces technologies d’assistance, je sais juste m’en servir) pourrait desservir le propos en volant un peu la place d’une personne concernée ?

Je suis en pleine réflexion autour de ces questions, et si vous avez une opinion (idéalement argumentée, mais l’avis personnel ressenti a également sa pertinence ici), je suis intéressé.

Zeste de Savoir Accessibility Universe

Mes autres cours en cours d’écriture, que je pense pour certains publier en bêta prochainement, traitent des sujets suivants.

• Bien écrire pour un lecteur d’écran  — un cours général sur comment écrire et se comporter afin qu’un lecteur d’écran, utilisé par les personnes aveugles ou malvoyantes, comprenne au mieux le texte ; ce cours est complémentaire du cours sur les textes alternatifs.
• De bons textes alternatifs pour vos médias  — complémentaire à ce cours, avec beaucoup plus de détails sur ce sujet en particulier, les deux cours se référenceront.
• Sous-titrer Twitch ou YouTube Live en temps réel  — pour parler d’accessibilité dans le domaine techniquement complexe de la vidéo en direct.
• Le petit guide de l’accessibilité sur les réseaux sociaux  — pour avoir une vue d’ensemble concrète et appliquée aux réseaux sociaux sur comment se comporter pour être accessible au mieux, et quels compromis faire entre le temps qu’on peut y passer, l’énergie qu’on peut donner à l’accessibilité, et le gain que ça a pour les personnes concernées.
• Rendre un site web accessible par l’exemple  — l’esprit initial était de partir d’un exemple d’un site web pas accessible et de le rendre de mieux en mieux, point par point, ça se voulait plus orienté développement web ; ce serait potentiellement ce plus gros cours dont je parlais plus haut.

Je ne suis pas non plus le seul à écrire des cours d’accessibilité, je pense notamment à @viki53 qui en a écrit sur le focus et que je sais fort sensibilisé sur ce sujet (on s’est même croisés par hasard à un salon d’accessibilité, c’est dire !).

Merci pour vos retours ou avis, si vous en avez ! J’ai un peu traîné pour avancer ces cours, notamment à cause d’une période pas franchement évidente ; je commence à publier en bêta avant tout pour avoir in fine un contenu plus qualitatif, mais également pour me motiver à avancer et finir ces cours pas si complexes que ça à écrire, finalement .

Excellente initiative !

J’ai juste lu le truc en diagonale, et je me dis que tu pourrais facilement rajouter un truc en introduction : un exemple d’une lecture d’écran sans le support visuel associé, pour montrer à quoi ça ressemble en réalité pour (la plupart des) personnes qui les utilisent. Parce que je comparerais l’effet a « comprendre une langue étrangère sans sous-titres » : si tu as le support pour d’aider (le visuel ou les sous-titres), la tâche va paraitre beaucoup plus simple qu’elle ne l’est en réalité (comprendre la navigation sans le visuel, ou la langue sans sous-titres). Ça permet aussi de faire l’expérience en directe : « qu’est-ce que j’ai compris de la page » vs « ce à quoi elle ressemble visuellement ». J’ai essayé sur ton exemple, j’étais loin du compte !

Merci

C’est une bonne idée !

C’est amusant que tu en parles, car j’ai déjà co-produit avec @sgble une vidéo, que j’utilise comme sensibilisation avant des conférences ou ateliers sur le sujet, qui donne des exemples d’usage d’un lecteur d’écran sans voir l’écran. Elle sert notamment à montrer à quel point le web n’est pas accessible.

Cela dit, comme elle a été conçue pour faire de la sensibilisation, et donc pour être frustrante (c’était le cahier des charges ), elle n’est peut-être pas suffisante dans l’idée que tu proposes et que je trouve très pertinente. Peut-être qu’un exemple plus brut, moins scénarisé¹, serait mieux.

De plus, les sous-titres de la vidéo sont brûlés dedans, ce que je trouve important dans le contexte d’une conférence où je ne peux pas savoir à l’avance si tout le monde entend bien et où je n’ai pas envie de m’embêter avec des détails techniques comme s’assurer que Keynote affiche bien les sous-titres… Mais là, on pourrait rendre les sous-titres optionnels pour que l’immersion soit encore meilleure².

Ça permet aussi de faire l’expérience en directe : « qu’est-ce que j’ai compris de la page » vs « ce à quoi elle ressemble visuellement ». J’ai essayé sur ton exemple, j’étais loin du compte !

Peut-être qu’il serait pertinent de renforcer ça et de proposer des exemples vidéo avec ce genre de défi, maintenant que j’y pense. Ce serait pas mal pour se rendre compte en étant directement concerné·e !

Est-ce que le fait que je ne suis pas totalement concerné (je n’ai pas besoin de ces technologies d’assistance, je sais juste m’en servir) pourrait desservir le propos en volant un peu la place d’une personne concernée ?

Je ne pense pas que ça desserve le propos. Déjà, que quelqu’un en parle, c’est mieux que personne, peu importe s’il en a la nécessité ou pas. Si seulement les personnes directement concernées avait le droit de communiquer ou de travailler sur un sujet, on ne ferait plus grand chose.

Sinon pour le cours en bêta en tant que tel, je trouve qu’il va dans la bonne direction. Quand on connaît rien, on apprend des choses ! Il y a quelques bricoles que je connaissais d’autres de tes vidéos, mais pas tout.

Je pense aussi que les vidéos (ou au moins le son) sont bien pour mieux se rendre compte. Typiquement, dans ta vidéo frustrante, on se rend bien compte que des sites avec lesquels on peut être familiers visuellement sont durs à reconnaître, alors même qu’on sait comment ils sont structurés visuellemment !

Suggestion mineure de forme, c’est enlever les points des titres. Sinon très très bon contenu !

Salut,

Très bonne idée cette série de contenu. Ne connaissant personne utilisant les outils d’accessibilité, ça me permet vraiment de découvrir et me rendre compte des problématiques liées. Autrement je ne fait pas de recherche particulière sur le sujet, j’essaie d’utiliser le bon sens mais ce n’est pas suffisant.
J’ajouterai quand même que décrire une image dans un texte alternatif est difficile. L’image est un langage visuel qui a ses propres codes et interprétations. Je me contente donc de souligner les éléments qui servent le propos à mon sens. Est-ce qu’il faudrait plutôt que j’essaie d’être le plus exhaustif possible ?
Edit : l’article suivant est fait pour répondre à cette question.

Personnellement, ce qui fait que j’adore ce site, c’est qu’on y trouve encore essentiellement des contenus textuels ! En effet, j’ai l’impression que la tendance globale va plutôt vers des tutos vidéos, j’y ai été confronté très souvent en cherchant pour des technos particulières, mais j’apprécie moins car la vidéo impose un rythme. J’aime pouvoir survoler mon tuto puis revenir plus tard en détails, ou avancer plus ou moins vite sur chacun des paragraphes selon le contenu. Certes, les vidéos proposent quelques outils de navigation mais on est pas du tout au même niveau de confort.
Cela dit je pense que la vidéo a certaines vertus, et les tiennes les exploitent très bien. Difficile d’écrire à propos de comportement vidéos ou audio, autant les montrer !
J’apprécie donc l’usage que tu as fait de ces vidéos. Je penses qu’en tant qu’illustration elles sont parfaites. Je ne pense pas que ça soit utile par contre de doubler tout le cours en vidéo, tout comme je ne sens pas le besoin de voir le visage de quelqu’un m’accueillir pour me parler face à la caméra.

Je m’avance peut-être un peu, mais ce serait dissonant avec le propos du tuto :

Écrivez correctement, avec de la ponctuation.

@QuentinC: Alors je rentrerais peut-être sur le sujet de l’écriture inclusive plus tard et pourquoi je pense au contraire que c’est une bonne chose. Voir, une très bonne chose.

Mais je voulais avant tout te répondre sur ta question sur les émojis. Déjà, c’est un sujet complexe pour tout le monde et effectivement j’ai remarqué que la documentation associée en anglais était quasiment incompréhensible si je ne voyais pas ce qu’elle essaye de dire.

Restons sur l’essentiel qui est plutôt bien documenté. Tu le sais très certainement, les émojis sont pratiquement tous formalisés par l’Unicode. Il existe alors des émojis caractères et des émojis séquences. Ça répond donc à ta question, non tu ne peux pas faire n’importe quoi, les séquences possibles sont toutes définies.

Mais elles sont très nombreuses ! 👷 associé à ♀️ donne 👷‍♀️, ça marche pour à peu près tous les métiers. Il n’y a pas que le genre que tu peux modifier, tu peux modifier la couleur de peau et la couleur/ le type de cheveux !

Par exemple 🧑‍🦯 (une personne marchant avec une canne blanche) est composé de 🧑 (émoji d’un adulte) et de 🦯 (émoji d’une canne blanche). Il ne suffit pas de mettre ces deux émojis l’un à côté de l’autre pour qu’il ne fasse qu’un seul caractère. On doit en plus mettre un caractère spécial entre les deux, qui va les fusionnés, pour former un caractère séquence.

Ce caractère a une taille de 0 et n’est donc pas représentable. On l’appelle couramment ZWJ pour « Zero Width Joiner » soit « Joint de taille zéro » mais je préfère personnellement la traduction « Ligature de taille zéro ». Ainsi, on parle de séquence d’émoji ZWJ (que je prononce personnellement en toutes lettres, Z, W puis J mais le plus souvent je le lis seulement).

Pour finir, le support des émojis ZWJ est limité par la plateforme sur lesquels tu lis l’émoji et la police d’écriture qui l’affiche. Pour ma part, je m’interroge sur comment les polices d’écriture possède autant de combinaisons. C’est-à-dire est-ce qu’elles ont toutes les séquences où est-ce qu’elle embarque un algorithme pour représenter un émoji.

Bref, tout ça pour dire que 👩🏼‍💻‍ (une informaticienne aux cheveux bouclés et la peau claire) peut ne pas être affiché partout. Il existe, comme tu l’as remarqué, des séquences spécifiques aux plateformes. La plus connue est certainement le chat ninja de Microsoft.

Il y a des spécificités rigolotes pour les drapeaux régionaux qui ne sont pas des émojis ZWJ. Comme par exemple ce code python:

print("🇧🇬"[::-1])

Qui affiche le drapeau de la Grande-Bretagne alors que le code affiche le drapeau de la Bulgarie en inversant la chaîne de caractère.

Aussi, merci pour ton retour sur le tutoriel d'@Amaury !

Salut,

Merci pour toutes ces explications détaillées.

Concernant les émojis, si je reprends ton exemple:
👩🏼‍💻‍

J’obtiens "Femme peau moyennement claire, ordinateur personnel". Si je lis caractère par caractère dans Chrome avec Jaws 2023, j’ai "Femme", "Peau moyennement claire", <non prononcé>, "Ordinateur personnel", <non prononcé>. Avec NVDA, à la lecture, j’ai bien "Informaticienne peau moyennement claire, mais si je lis caractère par caractère, je peux voir la décomposition. C’est assez troublant de ne pas avoir la même chose en lecture normale et en lisant caractère par caractère.

Autre fait troublant, si je colle le texte dans le bloc-notes, j’obtiens un seul caractère et je n’ai plus accès à la décomposition ! Pareil dans Word, ou dans WordPad. Pareil aussi dans la zone de texte de rédaction du présent post.

Autre question, pourquoi il n’y a pas de caractère de jointure entre "Femme" et "Peau moyennement claire" ? ET pourquoi il y en a un après "Ordinateur personnel" ? Car si je comprends bien, dans cette position, ça n’a aucune utilité. Je suppose que c’est un bug de Chrome vu ce qui précède, mais ne sait-on jamais.

Le contenu du print dans ton exemple python n’est pas lu chez moi, le caractère est inprononçable.

Concernant l’écriture inclusive, je ne suis pas uniquement contre pour les raisons pratiques que j’ai déjà évoquée. Je trouve qu’on exagère un peu avec toutes ces questions de genre, race et orientation sexuelle de manière générale, et ce n’est pas faute d’être aussi parfois confronté moi-même à d’autres formes de discriminations avec mon handicap. Cependant, c’est un autre sujet. Je serais intéressé d’avoir tes arguments, mais il serait sans doute plus sage dans le faire dans un autre topic pour ne pas polluer celui-ci.

Pour l’instant il faut juste retenir que non, l’écriture inclusive, c’est vraiment pas génial pour les lecteur d’écran.

C’est assez troublant de ne pas avoir la même chose en lecture normale et en lisant caractère par caractère.

C’est considéré comme un seul caractère après tout. Donc, ça a du sens que ça ne soit jamais décomposé. C’est plutôt le lecteur d’écran qui lorsqu’il décompose en caractère fait une décomposition de cet émoji qui agis bizarrement.

Bref, c’est un véritable casse tête dans à peu prêt tous les langages de programmation au point que trouver la taille d’une chaîne de caractère peu avoir 4 réponses différente dans le même langage ! Et ce à cause des émojis principalement. Alors imagine entre les langages de programmation !

Autre question, pourquoi il n’y a pas de caractère de jointure entre "Femme" et "Peau moyennement claire" ?

Alors ça c’est dû à la particularité de l’émoji couleur de peau qui est techniquement un « emoji modifier » et qui s’applique sur l’émoji le précédent directement quand cela à du sens. Donc, juste ces émojis n’ont pas besoin de ZWJ (il n’y a pas encore d’autres émoji dans la catégorie « emoji modifier » que les couleurs de peaux).

Pourquoi il y en a un après "Ordinateur personnel" ?

Semble-t-il que j’en ai mis un en trop ! Comme il ne se voit pas, je n’ai pas vu que j’avais mis ce caractère. >_<"

Le contenu du print dans ton exemple python n’est pas lu chez moi, le caractère est inprononçable.

Curieux, chez moi ça donne 🇬🇧 qui est le drapeau de la Grande-Bretagne. Peut-être utilise-tu Python 2 qui différencie les chaînes de caractères Unicode des autres et où donc le code devrait donc être :

print(u"🇧🇬"[::-1])

Curieux, chez moi ça donne 🇬🇧 qui est le drapeau de la Grande-Bretagne. Peut-être utilise-tu Python 2 qui différencie les chaînes de caractères Unicode

Pardon, je me suis mal exprimé, je parlais de ton code à la lecture directement dans le navigateur. Je n’ai même pas essayé en fait, mais il ne sera certainement pas plus prononçable dans la console (vu qu’en plus sous windows, UTF-8 dans la console, ça marche assez mal).

JE ne suis certainement pas à jour vu que python n’est pas parmi mes langages usuels, mais j’ai python 3 quand même. Python 2 n’est pas encore mort ?!

Bref, c’est un véritable casse tête dans à peu prêt tous les langages de programmation au point que trouver la taille d’une chaîne de caractère peu avoir 4 réponses différente dans le même langage ! Et ce à cause des émojis principalement. Alors imagine entre les langages de programmation !

C’est intéressant comme question. En fait c’est plutôt le terme longueur ou taille qui est ambigu et/ou qui n’a pas le même sens selon dans quel secteur on travaille.

On devrait préciser à chaque fois si on parle de longueur en nombre de caractères affichés, en nombre de points de code, en nombre de codets, ou en octets selon l’encodage utilisé, mais d’un autre côté, devoir à chaque fois préciser est lourd, et source d’erreurs et de confusion. En même temps, selon ce qu’on fait, on a besoin des quatre ! Unicode, c’est compliqué…

Ce n’est pas si facile d’expliquer la différence, même à de bons développeurs…

j’étais en train de mettre des icônes sur mon site et je tombe sur ça :
https://forkaweso.me/Fork-Awesome/accessibility/

c’est à dire des recommandations d’accessibilité pour l’utilisation des icônes. ça se gère un peu différemment des images.
Et notamment, ces recommandation font appel aux fonctionnalités ARIA. Personnellement je ne connaissais pas (mais je ne fais pas du web, qu’à titre expérimental). Ce serait cool d’avoir un petit tour de ces outils.

Par ailleurs, ce serait bien aussi d’avoir une partie qui explique comment on vérifie qu’on a bien fait les choses. Quels outils de test/diagnostic il existe ? Quel lecteur d’écran on peut facilement se procurer pour essayer par nous-même ?

Bonjour,

Je viens de rejoindre Zeste de Savoir car le site a l’air très intéressant et je voulais poser une question sur cette discussion, en particulier à @QuentinC.

Je travaille sous MacOs et j’ai des difficultés à configurer VoiceOver pour tester l’accessibilité de mon site. C’est un site de documentation en français. En théorie, si mon lecteur d’écran est bien configuré, est-ce que les extraits de code, que ce soit les lignes simples ou les blocs, peuvent être lus automatiquement en anglais ?

Pour donner plus de détail, je travaille sur la traduction d’un site de documentation technique, et j’aimerais comprendre quel serait l’usage idéal d’attributs lang="en" locaux (sachant que la page globale est "fr").

Il y a par exemple des titres d’article que je ne traduis pas, car c’est simplement le nom réel de la ressource en anglais, et je traduis uniquement la description du contenu. Il y a aussi des moments où je donne à la fois les termes français et anglais pour être plus pédagogique, par exemple: "un composant à espace de nom (ou namespaced component)". Est-ce que ça peut justement gêner la lecture d’avoir un changement de langue pour lire le terme anglais ? ou est-ce que ce serait au contraire une meilleure expérience de lecture ? J’ai du mal à me rendre compte sans réussir à tester moi-même.

Il y a par exemple des titres d’article que je ne traduis pas, car c’est simplement le nom réel de la ressource en anglais, et je traduis uniquement la description du contenu. Il y a aussi des moments où je donne à la fois les termes français et anglais pour être plus pédagogique, par exemple: "un composant à espace de nom (ou namespaced component)". Est-ce que ça peut justement gêner la lecture d’avoir un changement de langue pour lire le terme anglais ? ou est-ce que ce serait au contraire une meilleure expérience de lecture ? J’ai du mal à me rendre compte sans réussir à tester moi-même.

Il y a encore des progrès à faire au niveau des assistants que j’ai pu voir à l’œuvre. Mais dans le principe, il est bien de baliser sémantiquement le changement de langue (remarquer que nous faisons la même chose pour les visuels en mettant les titres et expressions en langues étrangères en italique avec parfois des variations de police/teinte/que-sais-je.) Le lecteur de pages web qui comprend le balisage saura quoi en faire (en gros, il vaut mieux que l’information soit disponible si c’est exprimé dans les règles, plutôt qu’elle fasse défaut parce-qu’on aura testé sur une techno en retard) ; ce peut être par exemple de lire la partie concernée avec les réglages linguistiques qui vont bien (voix différente si configurée et surtout la bonne prononciation…)

Merci pour la réponse, ça correspond bien à mon intuition. J’imagine que les développeurs et développeuses qui savent configurer leur lecteur d’écran peuvent aussi faire des choix pour les balises de code, vu qu’elles ont une sémantique HTML particulière ?

Présenter du code est une question épineuse même quand c’est vu par des personnes sans problème apparent… Je n’ai pas trop suivi l’évolution ces derniers temps, mais j’aime les mises en garde de MDN sur la balise <pre> par exemple : ça va être sport de trouver la description alternative d’un listing de code (paraphraser ? réécrire le code en prose si tant est il que ce soit possible ?)

Pour les équations mathématiques, il y a heureusement MathML (je dis heureusement sans avoir testé avec les lecteurs brailles et les lecteurs d’écran, mais dans l’idée qu’il y a toute la sémantique pour se débrouiller avec.)
Dans le premier exemple, j’ai pas mal de personnes qui disent, pour la première partie, quelque chose comme « parenthèse a plus b parenthèse 2 » (la première fois que j’ai entendu cela, ça venait d’une personne qui n’est pas restée assez longtemps sur les bancs de l’école pour dire « carré » ou « puissance deux ») ; ce qui peut être compris comme « $(a+b)2$ » —soit « $2\times(a+b)$ »— et c’est fort malheureux. Il manque, dans ce cas, juste la précision de savoir quand les parenthèses sont ouvrantes ou fermantes (pensons par exemple aux intervalles, avec le signe tiret au lieu du plus.)
Dans ce même exemple, la plupart des gens (y compris mes profs au lycée) disent « a plus b au carré » (les parenthèses, qui peuvent être grandes ou peuvent être remplacée par une autre paire dans certains contexte, disparaissent parce-qu’on trouve cela simple) qui peut/doit être compris comme « $a+b^2$ » (le truc c’est surtout que l’on s’adresse à des personnes voyantes qui ont l’affichage devant les yeux… la donne n’est plus la même quand on est aveugle.) C’est tout aussi malheureux.

Pour le code, je tombe souvent sur des trucs en image (comme vu récemment sur un exemple de CodeWithC mais on a le cas parfois aussi sur ZdS comme je l’ai vu récemment…) L’usage de <pre> s’est généralisé avec l’arrivée de bibliothèques pour ajouter de la coloration ; et cela se fait souvent en détournant l’attribut lang= au passage (ce n’est heureusement pas le cas sur ZdS, et cette mode est en train de passer). Je rêve d’un CodeML ou (juste/plus-simplement) d’un h-code pour harmoniser le balisage sémantique …afin que tout le monde ait accès aux informations (les assistants d’accessibilité en tête, mais on ne dépendrait plus de ce que fait la bibliothèque utilisée pour styliser visuellement et on pourra en changer plus facilement.)
Il y aussi quelques rares cas où le code balisé gagnerait à avoir un texte alternatif (comme si c’était une image), pour extraire-et-résumer l’idée clef. C’est le cas en général pour des articles génériques qui sont illustrés par des extraits de code dans un langage que les locuteurices peuvent ne pas connaître et se retrouver donc coupés d’une partie de l’article à cause du bruit syntaxique du langage choisi par l’auteurice. (la solution dans ce cas précis aurait été d’utiliser un méta langage algorithmique, à la exalgo, mais cela est hélas méconnu ou trop ignoré/dédaigné…)

Sinon, hormis ma digression, je suis bien d’accord que la description alternative de <pre> est au cas par cas (et MDN précise bien parler du cas d’« image ou diagramme » où effectivement un dessin peut ne pas passer par une balise <img>)

Pendant que j’y suis, petite question: c’est quoi l’intérêt d’activer le mode mathématique juste pour écrire un truc simple genre "a+b", voire même juste "n" ? Genre sur ZDS il y en a plein qui, quand ils écrivent une phrase genre "J’ai N objets", activent le mode mathématique juste pour le "N" ? Ca me parait complètement ridicule…

L’intérêt principal, c’est que le caractère est rendu correctement. $a$ et a n’apparaissent pas pareil visuellement et cette différence a un sens pour le lecteur. On peut même être extrême et trouver des cas où ce n’est pas juste du confort visuel, mais la compréhension devient difficile : « Ce n' est important » versus « Ce $n'$ est important ».