Transcription de Développeurs déficients visuels: nos possibilités et difficultés - RMLL2014

Présentation

• conférence donnée par Shérab et Irina Lambla
• date : 10 juillet 2014
• lieu : Montpellier
• lien vers la vidéo : RMLL2014 Shérab et Irina - Développeurs déficients visuels: nos possibilités et difficultés
• licence :
• Transcription : https://2014.rmll.info/slides/270/D%C3%A9veloppeurs%20d%C3%A9ficients%20visuels-%20nos%20possibilit%C3%A9s%20et%20difficult%C3%A9s.txt

00' relu MO

Shérab

Je voulais raconter quelques trucs que je trouvais sympas dans ces RMLL, d'abord. Ce sont des révolutions en cours, que je trouve chouettes. Il y en a une, c'est que, vous avez peut-être remarqué que les handicapés commencent à parler d'autre chose que d'accessibilité, et je trouve ça chouette, parce que finalement si on ne parlait que de ça, il y aurait un côté un peu, alors c'est bien, mais c'est un peu stigmatisant. Et le complémentaire, on a pu observer à la conférence d'avant, qu'il y a des non-handicapés qui parlent d'accessibilité. Et ça aussi c'est cool, je trouve.

Et la prochaine révolution que j'espère, c'est que les handicapés se mettent de plus en plus à devenir des développeurs. Et il y a plusieurs raisons pour lesquelles je trouverais ça chouette. D'abord parce que, finalement ce sont les mieux placés pour savoir ce dont ils ont besoin. Souvent, c'est nous qui avons les difficultés, donc si on a la compétence pour les résoudre, c'est nous qui pouvons vraiment faire les outils peut-être les plus adaptés. Ensuite parce que, si on y arrive, ça veut dire qu'on va devenir acteurs des solutions qu'on utilise, donc plus seulement des consommateurs mais des acteurs à part entière. Et moi je trouve que c'est complètement aligné avec la philosophie du libre, et avec, oui, finalement une société non consumériste, que je souhaite. Et aussi, parce que je trouve que parfois dans l'accessibilité il y a un côté, comment dire, genre on pourrait s'imaginer qu'il y a ceux qui la font, et il y a ceux pour qui on la fait. Et alors du coup, voilà, on fait de l'accessibilité parce que « vous comprenez, ces pauvres handicapés ». Bon ! Comme on l'a dit déjà dans les conférences sur le thème, c'est pas si simple puisqu'il y a des gens qui sont valides et qui peuvent en avoir besoin, soit parce qu'ils vieillissent, soit parce que les accidents de la vie font qu'ils en ont besoin. Ça c'est une première chose qui casse cette barrière, et une deuxième c'est que les principaux concernés fassent eux-mêmes l'accessibilité, et là on sera dans un monde où cette barrière n'existera plus.

Donc maintenant, je vais vous raconter ce qu'on peut faire et ce qui est difficile, de mon point de vue de personne qui ne voit pas du tout. Et ensuite je pense qu'Irina fera la même chose pour les personnes qui voient mal.

Donc déjà, en termes de qu'est-ce qu'on développe, déjà il y a, on va dire, on peut classer les applications en trois : 1. les applications en ligne de commande, et les bibliothèques (librairies). 2. les applications à interface graphique 3. et les applications web.

Quand on développe une application en ligne de commande, ce n'est pas mal, ce n'est pas mal parce qu'on peut tout tester. Donc ça c'est quelque part le cas idéal, mais même dans ce cas-là , il y a quand-même des choses qui sont difficiles. Par exemple, il y a des choses auxquelles on n'a pas accès, et c'est assez frustrant. Notamment, par exemple vous savez, il existe des débogueurs qui affichent les données de manière graphique. Par exemple des listes de listes de listes, on est capable de faire une représentation de ça, dans laquelle on peut se déplacer rapidement. Par exemple y a un truc qui s'appelle DDD, ça doit être "data display debugger", ou un truc comme ça. Eh bien moi j'ai toujours été frustré de ne pas avoir accès à un truc comme ça, parce que finalement, même dans mes trucs en ligne de commande, quand j'ai des listes chaînées à déboguer, je pleure. Je suis sous GDB, et je vois des pointeurs, et ce n'est pas facile, quoi. Donc ça c'est le genre d'applications qui manquent.

Ensuite, bien évidemment, quand on fait des applications avec interface graphique, on ne peut pas soi-même exactement se rendre compte de comment ça se passe. Donc que ce soit d'ailleurs sur ordinateur ou téléphone mobile, ce n'est pas un truc qu'on peut faire de manière complètement autonome. Il existe des solutions, un peu partielles, comme par exemple des environnements qui permettent de développer par contraintes. Donc on dit voilà, telle chose on aimerait l'afficher à tel endroit, on donne des poids aux contraintes. et en gros, en fonction de ces poids, le système se débrouille pour répartir les choses au mieux, mais ça ne vaudra quand même jamais la validation par un voyant.

Et la même chose est vraie pour les applications web où c'est la galère. Déjà parce qu'on ne sait pas, on ne se rend pas compte si visuellement c'est bien ou pas. Mais même au-delà de ça, c'est beaucoup moins facile, pour nous, par exemple, de savoir, c'est quoi la propriété CSS à tel endroit du document. En fait c'est beaucoup moins facile pour nous que pour quelqu'un qui voit. Moi je ne connais pas d'équivalent à tout ce qui est Developer tools, en fait l'ex extension Firebug de Firefox, par exemple, on n'a pas l'équivalent. Et je me suis laissé dire que dans Chrome c'était même mieux. Et tout ça on ne l'a pas, donc c'est galère.

Autre chose qui est difficile, c'est quand on fait du développement réseau, ou même toujours pour le développement web, quand on a par exemple un site web qui communique avec un autre web service et tout ça, on peut, souvent c'est facile avec un truc comme etherRead (Wireshark) de regarder les flux. Hop, on se balade,n regarde tel flux, qu'est-ce qui c'est passé, on clique sur tel autre. Nous on n'a pas ça en fait. Donc on fait du TCPdump. Après il existe des programmes, qui savent reconstituer les flux. Mais franchement c'est tout sauf pratique. Donc pour le moment, ça c'est super dur.

Un autre point, qui est difficile, je trouve, c'est tout ce qui a trait au travail collaboratif, parce que là on retombe dans tout ce qui est accessibilité du web, avec par exemple github, qui n'est, à mon sens, pas hyper accessible. C'est-à-dire que, dans une des présentations précédentes, cette après-midi, on a entendu que, qu'en fait forker un dépôt c'était juste un clic de souris, merger une branche c'était juste un clic de souris. Peut-être, (léger rire) mais quand on n'a pas de souris, eh bien non. (léger rire) ce n'est pas comme ça ! Donc ça c'est un peu galère !

Idem les systèmes de gestion de tickets, à la Redmine et tout ça. Il commence à y avoir des interfaces en ligne de commande, pour Redmine. Mais moi je trouve que globalement, même si c'est un peu accessible, j'ai vraiment l'impression que ça reste dur d'être aussi efficace que quelqu'un qui voit. C'est peut-être un film que je me fais, mais je pense que sur un projet où y a beaucoup de bugs, beaucoup de choses, c'est dur.

Alors que par exemple, a contrario, je n'ai pas du tout cette impression pour la gestion d'e-mails avec Mutt, par exemple. J'ai l'impression que je suis aussi efficace, et parfois même plus, que quelqu'un qui voit. Alors peut-être je me fais des films, mais voilà. C'est un retour d'expérience, donc évidemment il y a une part de subjectivité.

Autre outil à la mode qui est compliqué pour nous ce sont les pads, où on écrit à plusieurs. On est carrément sur le bord du chemin, avec ces trucs-là. En tout cas, moi j'en ai pas encore trouvé, que je pouvais utiliser de manière confortable.

Sinon donc un autre point, ouais, je précise qu'il y a quand-même des choses qu'on peut faire, je veux dire tout ce qui est utiliser Emacs ça marche très bien, je ne voudrais pas avoir l'air de donner une impression sombre du tableau. Mais, finalement quand j'ai réfléchi à ce que je voulais raconter, ce qui m'est venu c'est surtout les trucs un peu compliqués, quoi.

Sinon autre chose qui peut être difficile, c'est la documentation. Pour développer on a besoin d'accéder à de la documentation. Parfois c'est facile, quand elle est sous forme textuelle, peu importe le format, que ce soit du LaTeX, du TexInfo, du Markdown ou autre, c'est facile. Modulo, parfois la navigation dans la doc, n'est pas toujours simple. Parfois, ce n'est pas facile quand ce sont des images, des choses graphiques, « on voit bien sur la figure que », non en fait !S'il n'y a pas d'alternative on ne voit pas !

J'ai aussi un peu remarqué qu'il y avait pas mal la mode des tutoriels vidéos. Et bien c'est frustrant, parce qu'on sent que non seulement on n'y a pas accès, mais en plus on sent que pour ceux qui y ont accès, ça va être super efficace, ça va leur donner en peu de temps beaucoup d'informations. Donc quelque part ça peut donner l'impression que ça creuse un peu le fossé. Ce n'est pas pour dire qu'il ne faut pas le faire ; c'est plutôt pour se demander ce qu'on peut trouver comme alternative pour que nous on ne soient pas trop lésés,

Et puis dans le même ordre d'idées, ça a un peu émergé là pendant les RMLL, enfin je m'en suis souvenu, les conférences, on ne suit pas, enfin c'est dur. Par exemple, les conférenciers souvent disent "on voit bien que ce code-là, est plus efficace que celui-là", eh bien , sans doute ! Donc là, ce sont peut-être des points où on peut améliorer les choses en fait. Si les personnes peuvent garder présent à l'esprit que tout le monde ne voit pas leurs slides, peut-être qu'elles auront naturellement la tendance à dire « on voit bien que la fonction » , je ne sais pas moi, « unetelle est plus efficace parce que ceci ». Du coup on pourra mieux comprendre.

10' 10

Je voulais aussi parler aussi de « accessibilité n'est pas efficacité ».