Bien écrire pour un lecteur d’écran

Comment rédiger en s’assurant d’être compréhensible pour les personnes aveugle ou malvoyantes ?

a marqué ce sujet comme résolu.

Tout le monde se secoue ! :D

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 :) .

+4 -0

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 :D ), 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é1, 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 meilleure2.

Ç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 !


  1. Même si la vidéo ci-dessus n’est que très vite fait scénarisée, certes.
  2. Et notamment pour reprendre ce que tu disais : « 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 paraître beaucoup plus simple qu’elle ne l’est en réalité (comprendre la navigation sans le visuel, ou la langue sans sous-titres). »
+2 -0

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 !

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.

Dans ce cours, j’ai commencé à utiliser la vidéo
[…] 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) ?

Amaury

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.

Suggestion mineure de forme, c’est enlever les points des titres.

qwerty

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

Écrivez correctement, avec de la ponctuation.

+1 -0

Bonsoir,

Tes tutoriels sont une excellente initiative comme il y en a malheureusement bien trop peu. Je suis moi-même non-voyant et donc j’utilise un lecteur d’écran, donc en matière de conseil tu ne peux pas mieux tomber.

Par contre je ne suis pas du tout d’accord avec certaines choses.

le texte alternatif fait pleinement partie du contenu. Il n’est donc pas gênant qu’il soit long, d’autant plus qu’un lecteur d’écran permet très facilement de passer à la suite.

De façon générale, je trouve au contraire que le texte alternatif des images doit être court. IL doit dire l’essentiel, mais avec concision. Sauf dans certains contexte bien précis comme peut-être les écrits littéraires où l’objectif peut être de s’évader dans les descriptions de paysages et autres.

Généralement, les lecteurs d’écran se débrouillent bien avec l’écriture inclusive et les points médians. Au pire, ils liront un e en plus sans que ce ne soit gênant.

Au contraire, je trouve que c’est rapidement gênant, et je suis loin d’être le seul à le dire. Quand on a des points médians et des e s tous les trois mots, ça devient pénible à écouter; pénible à lire en braille aussi. C’est aussi vite problématique pour les dyslexiques qui ont déjà de la peine à lire du texte normal.

Selon moi, l’écriture dite inclusive n’est en tout cas pas inclusive pour les utilisateurs de lecteur d’écran. Plus globalement, je trouve même que c’est fondamentalement une connerie. Ca va trop loin, et c’est ridicule, mais bon ça, ce n’est que mon avis.

Alors oui on peut ajouter "client.e.s" et toutes les variantes genre "client(e)(s)" dans le dictionnaire de prononciation et le remplacer par "clientes et clients"; mais du coup ça donne rapidement un style pompeux ignoble à lire. Et puis le dictionaire de prononciation, comme le nom l’indique, ne s’applique pas en braille. Pour rappel, une plage braille, c’est petit, ça affiche entre 20 et 40 caractères à la fois, parfois même moins de 20 pour les plages mobiles; plus de 40 ça existe mais c’est gros et encombrant… donc encore une fois dans ce contexte la concision (à l’opposé des formes pompeuses) a une certaine vertu.

Dans la même catégorie, je parlerais des traits d’union virtuels et autre séparateurs conditionnels du même genre. Oubliez-les, c’est une plaie ! Ils provoquent une division des mots en syllabes et/ou affichent des caractères non prononçables. Ca devient très vite totalement incompréhensibles. Leur support n’est pas toujours très bon, et dépend à la fois du système, du navigateur et du lecteur d’écran. Normalement, les dictionnairs de césure, ça devrait exister pour gérer ces cas sans avoir rien à faire.

Évitez à tout prix les faux italiques, faux gras, et similaire.

Là par contre j’applaudis à 1000% ! J’ai arrêté de lire des articles sur LinkedIn, parce que c’est de toute façon devenu totalement illisible. Ils font juste c….. avec ça !

Quand est-ce que LinkedIn permettra d’écrire du vrai gras/italique et de mettre des titres de niveau ? Je n’arrive même pas à comprendre qu’ils ne l’ont encore pas autorisé depuis le temps. Ce n’est pas une plate-forme faite pour poster des articles ?! De ce fait ils cautionnent indirectement des absurditées pareilles, et c’est … désolant, surtout pour un réseau social qui est à vocation professionnelle.

Bonus point: on peut configurer certains lecteurs d’écran pour changer de voix ou varier l’intonnation pour les passages en gras ou en italique, ehoui.

L’émoji «p � » s’appelle Diya Lamp, ou Diya en français

C’est quoi diya ? JE ne sais même pas ce que c’est… heureusement que l’anglais peu m’aider Oil lamp => Lampe à huile ou lampe à pétrole (j’ai un doute). J’aurais trouvé cet émoji dans un texte, je n’aurais pas pu savoir du tout ce que ça représente. C’est quoi ce nom, et pourquoi pas juste "lampe à huile" ou "lampe à pétrole" ? C’est pas si simple… les appellations enregistrées dans les dictionnaires des lecteurs d’écran ne sont pas toujours très claires.

Par contre il faut faire très attention, ce que tu expliques marche pour un certain nombre d’émojis standardisés. Ca veut dire, pas tous ! Et pas pour des points de code custom utilisées par exemple pour afficher les icônes de réseaux sociaux.

Pour donner un exemple, la phrase « Les quelques infos que je glane sont contradictoires 🤷‍♂️ »pourra être lue ainsi : Les quelques infos que je glane sont contradictoires, homme qui hausse les épaules.

Là ce n’est pas une remarque sur le tutoriel, mais une question. Chez moi (Chrome + Jaws 2023), j’obtiens:
Les quelques infos que je glane sont contradictoires haussement d’épaule, signe mâle

En lisant caractère par caractère, j’obtiens que cet émoji est composé de 4 éléments: "haussement d’épaule", <non prononcé>, "signe mâle", <non prononcé>. Comment ça se fait ? Comment ces émojis sont-ils construits ? Est-ce que je peux combiner "signe mâle" avec n’importe quoi ? Comment ça marche ? Y a-t-il d’autres émojis combinables ?

Quoi qu’il en soit tu peux constater que ce genre de combinaisons ne sont pas supportés par Jaws (NVDA non plus, au passage). Donc, encore une fois, prudence !

Merci et bonne soirée.

+3 -0

@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 !

+0 -0

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.

+1 -0

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])
+1 -0

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…

+0 -0

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 ?

+2 -0

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 ?

Rien ne vaut de véritables testeurs en chair et en os, car les validateurs automatiques sont tous plus ou moins limités. Ils sont plutôt bons pour te rappeler les choses simples: labels, textes alternatifs, hiérarchie de titres, etc. Ils sont aussi assez bons pour te donner des conseils. Par contre, il peut y avoir pas mal de faux positifs, et ils ne sont évidemment pas capables de dire, par exemple, au-delà de la présence d’un label ou d’un texte alternatif, s’il est véritablement pertinent.

Pour les choses plus compliquées comme ARIA, les outils automatiques ne sont pas d’un très grand secours.

Quel lecteur d’écran on peut facilement se procurer pour essayer par nous-même ?

Ca en fait c’est assez simple:

  • Windows:
  • iPhone/iPad: VoiceOver, qu’on peut activer en appuyant trois fois sur le bouton d’allumage
  • MacOS: VoiceOver, activable avec Pomme+F5
  • Linux: Orca
  • Android: Talkback
+4 -0

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…)

+0 -0

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 ?)

+1 -0

Bonjour,

Désolé pour la réponse très tardive, je ne vois vos derniers messages que maintenant.

Concernant les textes en plusieurs langues, il y a deux grandes catégories d’utilisateurs:

  • Ceux qui préfèrent quand la synthèse vocale change en fonction de la langue, et qui ne comprennent pas du tout ce qui est lu quand ça ne marche pas
  • Ceux qui préfèrent qu’elle ne change pas car ils ont l’habitude avec la synthèse par défaut et pour qui avoir de courts textes en anglais lus avec un accent françAis ne dérange absolument pas

En ce qui me concerne c’est plutôt la seconde

Mais quoi qu’il en soit, il faut indiquer les parties de texte dans une autre langue avec l’attribut lang, que tu peux mettre sur à peu près toutes les balises.

Exemple:

<p>Shakespeare a dit: <q lang="en">To be or not to be, that's the question</q></p>

Pour la première catégorie, l’attribut lang provoque le switch de synthèse automatiquement, à condition qu’une synthèse pour la langue correspondante soit installée. Pour la deuxième, ce comportement peut être désactivé.

Pour le code, je ne sais pas trop dire si c’est utile, vu que j’ai l’habitude en professionel comme en privé de lire et d’écrire du code en franglais. Je dirais plutôt non, mais il faudrait d’autres avis pour confirmer ou infirmer.

Maintenant concernant la balise <pre> et la mise en garde de la MDN:

Il est important de fournir une description alternative pour toute image ou diagramme créé avec du texte préformaté.

Le code n’est évidemment ni une image, ni un diagramme. Les équations mathématiques non plus. En fait l’avertissement s’applique surtout pour les dessins et schémas créés en ascii-art.

En-dehors du cas spécifique de l’ascii-art, remplacer un texte pour une autre alternative texte est en général une très très mauvaise idée. C’est une question assez courante et je me bats pour faire passer le message.

+4 -0

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(a+b)2 » —soit « 2×(a+b)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+b2a+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>)

+0 -0

MathML est interprété correctement par les dernières versions de Jaws (pas sûr pour NVDA), par l’intermédiaire d’une bibliothèque comme MathJax.

Avec Jaws, on peut entrer dans l’équation et la parcourir terme par terme dans une sorte d’arborescence. C’est pas trop mal.

Par contre, j’ai tellement eu l’habitude de lire les équations en LaTeX ou an ascii simplifié pendant mes études que, personnellement, je rêverais de pouvoir désactiver ce visualisateur arborescent pour plutôt avoir le code à la place. C’est vrai sur ZDS, mais aussi sur Wikipédia. En plus ce visualisateur d’équation est très très lent, et ralentit passablement la page quand il y en a plein…

L’autre souci de ce visualisateur est qu’on ne peut pas copier facilement l’équation. Du coup quand on lit un cours par exemple, c’est pas pratique pour revenir dessus, travailler, ou la décortiquer pour essayer de comprendre comment on en arrive là…

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…

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 * (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

Il y a plein de cas comme ça où l’équation n’est pas correctement balisée. Ici tout bêtement, ça pourrait arriver si, au lieu d’utiliser <sup>, on décale le 2 en CSS.

Pour ce genre de truc, on ne peut se fier qu’au contexte pour savoir, et il faut faire un peu de déduction. La même chose pour déduire si la parenthèse est ouvrante ou fermante. Ici par exemple, le multiplicateur se trouvent en général avant la parenthèse. S’il est après, il y a beaucoup plus de chances pour que ce soit une puissance.

Je dis ça, mais en même temps, il faut connaître ce genre de convention. Quand on débute avec l’algèbre à l’école secondaire, effectivement, on ne peut pas trop savoir.

Ceci dit, j’ai aussi connu des gens et même des profs qui disaient juste "deux" ou "trois" sous-entendu "à la 2" ou "à la 3". Bizarrement le "à la" ne disparaissait jamais pour des nombres >=4.

De façon plus générale, il y a plein de choses où on doit jouer de déduction et de contextn pour comprendre. Outre les maths, il y a le fameux gag récurrent des dates et heures, par exemple pour "1:23", certains lecteurs d’écran vont lire quelque chose comme "une heure vingt trois" tandis que d’autre vont lire "une minute vingt trois secondes" ou juste "un, vingt trois". Charge à soi-même de savoir lequel est le bon selon où on se trouve ou ce qu’on fait, en général il n’y a jamais trop de doutes (cf. mes liens vers stackoverflow).

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 »

A l’oral, en plus du contexte, on est tout de même aidé par l’intonation ou les minuscules pauses, presque imperceptibles et par chance généralement instinctives ON est aussi très attentif à ce genre de détail quand on ne voit pas.

Bien sûr, ça ne marche plus tant quand le contenu est lu avec une synthèse vocall, car l’intonnation et les micro-pauses, quand il y en a, sont moins marquées, et on peut rarement aller configurer ça aussi profondément.

D’où l’utilité, très vite, de lire caractère par caractère, ou en braille si on en a la possibilité.

Avec ça j’espère que j’ai fini de convaincre que les traductions math -> français en toutes lettres, c’est une énorme bêtise.

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.

Rien ne t’interdit d’utiliser <figure> et <figcaption> pour ce cas.

En revanche pour le code en images, il est dit explicitement dans le WCAG que, si l’image contient du texte, alors le texte alternatif doit reprendre ce texte intégralement.

A quoi j’ajoute que l’attribut alt n’est pas fait pour accueillir des longs textes. Certains lecteurs d’écran les coupent sauvagement après quelques centaines de caractères, et dans tous les cas les sauts de ligne ne sont pas pris en charge, le texte est au kilomètre, et donc totalement illisible pour du code. C’est vrai aussi pour les équations en images.

+3 -0

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. aa 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 nn' est important ».

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte