Accessibilité numérique : la bonne volonté ne remplace pas la compétence

Par Philippe Poisse le jeudi, juillet 4 2019, 16:04 - Accessibilité Numérique - Lien permanent

En début d’année 2019, suite à un accident, j’ai dû subir une intervention chirurgicale au coude gauche. Honnêtement je n’aurais jamais crû que l’épicondyle était aussi fragile.
Suite à cette opération, pendant de longues semaines j’ai donc eu le bras immobilisé. Mais ça ne m’a pas empêché d’utiliser un ordinateur.
C’est juste qu’avec un seul bras, bien que droitier, beaucoup de choses deviennent difficiles. Une bonne partie de ces difficultés sont liées à l’absence de politique d’accessibilité numérique. Et quand on se retrouve en situation de « handicap » on devient plus sensible.
Voici donc des mauvaises pratiques vues sur le web ces derniers mois.

Pour mieux exclure soyons « inclusif »

Un exemple parmi tant d’autres : https://www.lespetitsdebrouillardsoccitanie.org/spip.php?article1008
Je sais, j’ai mes têtes (et trois vis dans le bras).

Essayez de lire attentivement le texte au moins deux fois avant de dire : non, y’a pas de problème, faut arrêter le tramadol mon gars !

En fait il y a deux problèmes ; l’un est évident si on lit à voix haute, l’autre est plutôt subtil et malheureusement fréquent.

« IELS » ou comment flinguer une synthèse vocale.

L’écriture inclusive doit compenser des problèmes grammaticaux parfois vieux de plusieurs siècles, comme l’absence de neutre en français. Dans le cas présent il suffit de créer un nouveau pronom.
En anglais il n’existe qu’un seul pronom personnel à la troisième personne du pluriel : « they ». En français il y a en deux : « ils » et « elles ». Remarquez qu’au singulier il y a en trois.
Pour régler le problème ont donc été inventés « iels », « illes », « iel », « ul », « ol » ou encore « ele ». Lisez la page Wikipedia à ce sujet pour plus de détails (https://fr.wikipedia.org/wiki/Non-binaire#Utilisation_d'abr%C3%A9viations_et_de_pronoms_non_genr%C3%A9s).

Le truc avec les néologismes c’est qu’au final, personne ne les connaît, et donc une personne qui utilise une synthèse vocale risque de buter sur le sens d’une phrase qui commence par le son « yel ».
De la même manière une personne dyslexique peut avoir de sacrés problèmes avec l’utilisation de ce type de termes.
L’écriture inclusive a pour but de modifier le rapport à la langue écrite, d’où son nom. Elle échoue dans les grandes largeurs dès que l’on touche à l’oral. Hors certaines populations ne peuvent appréhender l’écrit sans passer obligatoirement par l’oral.
Une utilisation irréfléchie de ce type de néologismes peut rapidement exclure donc tous les utilisateurs de synthèses vocales (ce qui va au-delà des seuls malvoyants) et les personnes souffrant de « troubles dys ».

Concernant les « troubles dys » je ne serais trop vous conseiller de lire le site de la FFDys : http://www.ffdys.com/troubles-dys

Une petite recherche sur le Web montre que je ne suis pas le seul à me poser la question.
Des dizaines de pages traitent du sujet.
La plupart des auteurs de ces pages mettent en avant l’écriture épicène comme solution. Les pronoms disparaissant, le problème disparaît.
L’effort n’est plus à la charge du lecteur mais à celle du rédacteur. Ce dernier doit améliorer son style et élever son niveau.
D’un certain point de vue tout le monde est gagnant.

Pour finir, et parce que la culture c’est bien, un petit lien sur l’étymologie des pronoms personnels : https://fr.wiktionary.org/wiki/ille#Latin

Ça se prononce comment ?

Vous l’avez vu le « habitant.e.s » ? Cette forme est tellement banale qu’elle ne semble plus poser de problème.
Sauf qu’elle en pose pour les synthèses vocales. Parce qu’en pratique ça se prononce : « habitant point[pause]eu point[pause]s ».
Bon, les logiciels s’améliorent avec le temps, mais ce genre de subtilités peut mettre pas mal d’années avant d’être correctement gérées.

Là aussi on trouve pas mal d’articles qui traitent du problème. Et la plupart des auteurs préconisent l’usage du point médian.
Ce signe typographique, qui n’est plus utilisé en français, ne semble pas poser de gros problèmes, sans doute parce qu’il ne se prononce pas.

Le point médian a aussi une petite externalité positive : c’est un poil plus esthétique ! Il faut donc privilégier la « habitant·e·s ».

Pour en savoir plus sur cette petite bête : https://fr.wikipedia.org/wiki/Point_m%C3%A9dian

Quelques liens

Je ne serais trop vous invitez à vous questionner sur vos pratiques en termes de rédaction, à en parler autour de vous et à lire le plus possible de textes au sujet de l’écriture inclusive, du handicap et de l’accessibilité numérique.
En effet une pratique qui a pour conséquence d’exclure une part non négligeable de la population entre dans le cadre de la discrimination.
Discriminer pour inclure est une bien curieusement vision du monde !

Voici donc quelques liens trouvés au fil de l’eau : Le point médian sur le site de l’APF France handicap : http://c-rnt.apf.asso.fr/2017/10/08/recommandations-en-ecriture-inclusive-et-point-milieu-ou-point-median/
Un site dédié à l’écriture inclusive sur lequel vous pourrez télécharger un manuel d’aide : https://www.ecriture-inclusive.fr/
Des conseils simples pour l’écriture inclusive : https://www.mecanismes-dhistoires.fr/usage-point-milieu-ecriture-inclusive/
Le guide pour l’accessibilité universelle et l’inclusion dans les bibliothèques : https://accessibibabf.wordpress.com/2017/10/18/mediathemes-accessibilite-universelle-et-inclusion-en-bibliotheque/
D’autres recommandation sur l’écriture inclusive : https://legothequeabf.wordpress.com/2017/11/07/recommandations-pour-une-ecriture-inclusive-et-accessible/
Un tableau de conjugaison : https://leconjugueur.lefigaro.fr/blog/conjugaison-ecriture-inclusive/
Un tableau des abréviations inclusives : https://codepen.io/vincent-valentin/full/woGLVL

En conclusion je dirais qu’en communication l’important est que le receveur comprenne le message. Dans le cas contraire, l’intérêt de la démarche est faible et le résultat peut être contraire aux buts recherchés.

Je connais pas l’API, mais je code quand même

Le code c’est bien, le code c’est bon, le code mangez-en ! Et surtout, n’hésitez pas à le pisser !
https://www.imaginelespo.fr/question/mettez-sur-la-carte-votre-proposition/

Essayez de zoomer avec juste votre souris, vous allez voir c’est vachement ergonomique.
En cherchant un peu ce problème se retrouve sur énormément de sites Web qui utilise Google Maps.

On pourrait écrire un petit laïus sur les pratiques d’enseignement de la programmation. Parce qu’il faut reconnaître qu’à force de mettre en avant la capacité à « pisser du code » (faut livrer dans les délais, ma p’tite dame) on finit par oublier l’utilisateur final, c’est-à-dire que tout ce qui touche à l’ergonomie, l’esthétisme et l’accessibilité passe à la trappe.
Petit aparté, la plupart des structures qui font de l’animation autour du numérique semblent méconnaître l’importance de certaines des compétences nécessaires dans ce secteur d’activité. L’analyse logique et la capacité à l’abstraction ne sont que très rarement mises en avant, hors ce sont des compétences de base, notamment pour les développeurs.
Je rappelle en passant que dans le vocabulaire de la profession, personne ne code. On programme, on développe, on écrit/relit du code, etc., mais on ne code pas.

Dans le cas de Google Maps on assiste à un effet de bord intéressant. Le blocage de la molette pour le zoom est une fonctionnalité implémentée délibérément pour améliorer l’ergonomie des sites intégrant des cartes.
Le but est d’éviter qu’un personne qui fait défiler l’écran avec sa molette (du bon vieux scrolling en somme) ne se retrouve bloquer si le curseur passe au-dessus de la carte.
Personnellement je trouve cette fonctionnalité très pratique. Ce n’est pas elle que je critique, mais la façon dont certains développeurs Web l’utilisent.

Utilisée bêtement elle empêche de zoomer sans l’aide du clavier. Pour les personnes ayant deux bras et deux mains valides, pas de soucis. Pour les autres, qu’elles soient handicapées ou juste blessées, le problème est évident.
C’est bien pour cela que l’API Google Maps intègre des fonctionnalités pour la gestion de l’interface. Il est donc possible de rajouter des boutons + et – pour la gestion du zoom.
C’est juste une ligne de code en JavaScript, vous savez, JavaScript, le langage orienté prototype que personne ne veut prendre au sérieux mais que tout le monde utilise.

Bref avec juste un peu de réflexion sur l’ergonomie de l’application et sans dégrader ses qualités esthétiques on peut arriver à un bon résultat en termes d’utilisation et d’accessibilité.

Conclusion

Quelques mois d’arrêt et d’indisponibilité du bras gauche m’ont permis de voir l’importance de l’accessibilité d’un autre œil. J’ai eu pas mal de temps pour cogiter un peu.
Dans le cadre du Web, qui est sans doute le medium majeur des années à venir, le boulot de sensibilisation et de formation reste énorme.
Et ça tombe bien, je cherche du taf !

Et pour finir : back in the game, kicking ass again !

Sources

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

La discussion continue ailleurs

URL de rétrolien : http://blog.philippe-poisse.eu/index.php?trackback/252

Fil des commentaires de ce billet