TechEthic-E1-FaceB - 10:04:2021 14.09.mp3

TechEthic-E1-FaceB - 10:04:2021 14.09.mp3: Audio automatically transcribed by Sonix

TechEthic-E1-FaceB - 10:04:2021 14.09.mp3: this mp3 audio file was automatically transcribed by Sonix with the best speech-to-text algorithms. This transcript may contain errors.

Manu:
Bonjour à tous, bienvenue pour ce deuxième épisode de Tech Ethic. Pour rappel ce Podcast a pour but d'aborder tous les domaines de la tech éthique, que ce soit le green IT, l'accessibilité ou autres sujets en relation avec ce thème. Chaque épisode est composé de deux parties. On a déjà eu la face A la semaine dernière avec Céline Boeuf, où on a eu le point de vue utilisateur ou utilisatrices de sites Web, accessibles ou pas. Et aujourd'hui, on va aborder la partie technique avec une experte du sujet, Angela Ritchie. Bonjour Angela, ça va ?

Angela:
Bonjour ! Ça va,

Manu:
Ça va, ça va. Est ce que tu peux te présenter rapidement? Qu'est ce que tu fais, ta vie, ton oeuvre et comment tu es arrivée dans le domaine de l'accessibilité?

Angela:
Bon, je m'appelle Angela Ricci, je suis web designer. Je travaille avec le web depuis plus de 25 ans et je travaille sur l'accessibilité. J'ai découvert l'accessibilité vers 2004 quand j'ai dû faire un site, on a dû créer un site pour le Parlement européen et c'était la première fois que l'on entendait parler d'accessibilité. Donc, j'ai commencé à chercher un peu partout parce que même sur W3C, c'était quelque chose qui commençait, et c'est quelque chose qui notamment ça devrait être naturel dans le Web et ça n'a pas été pris en compte depuis le début.

Manu:
Tu parles d'un projet de 2004 pour le Parlement européen. C'était une obligation légale, d'avoir un site accessible à cette époque ?

Angela:
C'était déjà pas une obligation, mais Je ne sais pas si c'était un obligation légale. Je sais que c'était une obligation du client. Le Parlement européen ils demandaient déjà que leur site soit accessible, même si eux, ils ne savaient pas trop Qu'est ce que ça voulait dire. Et moi non plus. On a dû découvrir ensemble avec les clients ce que c'était l'accessibilité web.

Manu:
Pour info pour les auditeurs depuis plusieurs années, la législation a changé, que ce soit au niveau européen ou au niveau français, qu'on travaille dans le domaine public ou dans le domaine privé, on a des obligations en termes de développement d'applications accessibles aux obligations. Encore mal connue, malheureusement. Mais on vous conseille, de vous y intéresser parce que normalement, maintenant, on devrait tous s'intéresser au moins au sujet et développer des applications Web accessibles pour tous. Très bien Angela. La première question : D'après toi pourquoi l'accessibilité Web n'est pas ou mal gérée dans les équipes de développement, quelle que soit la société, sociétés de services ou clients finaux? Pourquoi l'accessibilité c'est toujours la dernière roue du carrosse, voire totalement oubliée? Est ce que tu as une petite idée de ça?

Angela:
Pour moi, les premiers points super importants, c'est que l'accessibilité n'est pas enseignée dans les écoles d'ingénieurs. Même pour le Web, si tu fais webdesign, ça n'est jamais enseigné. Même HTML, CSS sont très mal enseignés. Quand on parle, pas ce qu'est le vrai HTML, qu'elle est la vraie nature, la sémantique, les rôles des éléments, des éléments HTML, les basiques de l'accessibilité n'est même pas mentionnée. Et si c'est mentionné, c'est très rapidement. Donc, on sort de l'école déjà sans savoir ce que c'est. Et je crois que si c'était bien enseigné depuis les débuts, si les étudiants étaient vraiment sensibilisés à l'école et motivés, là, le développeur qui va sortir de l'école il va déjà avoir intégré ça naturellement. Donc, pour moi, c'est le premier point.

Manu:
Pour pas te mentir, je suis sorti d'école il y a 10 ans. J'ai peut-être eu une demi-journée d'initiation en HTML pour le corps professoral. C'était peut-être un sujet assez simple à appréhender, mais c'est tout. On utilise des balises, on sait pas pourquoi on les utilise et on ne réfléchit même pas, même si le langage HTML a évolué depuis 12 ans. Mais juste l'initiation d'une journée ou deux sans vraiment comprendre le but de telles balises, de tels attributs, de la sémantique, Tout ça... En école, je sais pas si ça a changé depuis. Je ne pense pas ...

Angela:
Malheureusement, je ne crois pas que ça a beaucoup changé, malheureusement.

Manu:
Est ce que tu penses aussi qu'il y a peut-être un frein en terme de fonctionnalités visibles pour les clients et pour les responsables de projet? Ils préfèrent peut être développer rapidement de la fonctionnalité, tout en mettant de côté la qualité du produit, l'accessibilité, les performances, ce qu'il veut, c'est juste de la fonctionnalité ? Ça sonne un peu Fordisme : Je sors de la fonctionnalité comme ça mes clients sont contents. Pas tous les clients, mais une partie. Qu'est ce que tu en penses ?

Angela:
C'est justement ça. Ils sont formés entre guillemets pour ça. Ils sont formés pour aller résoudre des problèmes et l'accessibilité n'est jamais ajoutée à ces problèmes là. Elle n'est jamais considérée comme un problème à résoudre. Donc c'est mis de côté. Donc quand tu démarres dans la vie active, tu arrives dans ta boite, ce que tu veux, c'est développer. C'est e qu'on t'a appris à faire. C'est aussi ce qui te donne plaisir. Et bien sûr, l'accessibilité ça ne fait pas partie de ta palette de compétence, de ta palette de ce qui te procure du plaisir dans ton expérience de développeur ou développeuse. Et là, il y a le deuxième point, qui est aussi un problème concernant l'accessibilité : Si les clients ne demandent pas, les boîtes de presta ne vont pas développer accessible. Ça, c'est clair que si ça ne vient pas des développeurs qui ne sont pas formés, ça doit venir des clients. Et là, qu'est ce qui arrive, on est désespéré parce qu'on ne sait pas quoi faire.

Manu:
Je rigole intérieurement parce que j'ai des projets en tête là, que j'ai eu il y a plusieurs années, où on te dit faire des codes accessibles pour ce genre d'applications, ça ne servait à rien parce que la personne avec un certain handicap ne va jamais utiliser mon application. A quoi ça sert de faire un site accessible ?

Angela:
Ah oui "Un aveugle ne jamais l'utiliser !" Ça arrive tout le temps ça..

Manu:
Des personnes avec un handicap moteur. Il ne faut jamais aller chez Decathlon, ou un site de sport de manière générale, des argumentaires où tu peux te dire OK ou on va ramer un petit peu. On va y aller où? À force de faire des Podcasts, des initiations, des conférences, ça va peut-être rentrer au bout d'un moment, mais des fois, tu te sens un peu tout seul.

Angela:
Ben oui, oui, tout à fait. Mais même aujourd'hui, j'entends beaucoup : "Mais ça sert à rien de faire accessible parce que de toute façon, un aveugle ne jamais utiliser ça". Donc déjà ça coupe la fonctionnalité pour une grande partie de la population. Pourquoi? A partir de quoi on donne cette idée que les aveugles ou malvoyants peuvent pas utiliser ça ? Et en plus, ça limite l'accessibilité: C'est seulement pour les mal ou non-voyants. Ça montre le manque de connaissance totale du sujet accessibilité même.

Manu:
Parce qu'en fait, je ne sais pas ce que tu en penses. Mais quand on parle d'accessibilité, on pense tout de suite aux personnes en situation de handicap. Mais moi, je n'y vois l'accessibilité de manière plus générale. Rendre un service numérique accessible à tout le monde, en situation de handicap ou pas, que tu trouves dans la Creuse ou que tu as pas beaucoup de réseau. Que tu sois sur un téléphone portable de cinquième génération versus un Nokia 33 10. C'est juste rendre accessible un service numérique à La plus grande majorité des personnes. Même si, dans l'esprit des gens, qu'on parle d'accessibilité des personnes en situation de handicap. Moi, j'essaye d'agrandir un peu cette définition pour englober tous les cas d'utilisation.

Angela:
Voilà, ça c'est un discours qu'on doit surtout bien renforcer. Oui, l'accessibilité, ce n'est pas seulement pour les personnes en situation de handicap, mais c'est donner accès à la totalité des contenus et des fonctionnalités à tout le monde, indépendamment des contraintes techniques, matérielles et physiques. Donc, ça veut dire si j'ai pas une souris, bon, il faut, il faut que je puisse cliquer sur un bouton. Même sans la souris, il faut que je puisse naviguer avec clavier. Il faut que je puisse lire mon texte si je suis dehors avec mon téléphone. Donc, il y a une multitude de confort et de facilité qu'on peut donner aux utilisateurs si on pense notre fonctionnalité, notre application Web accessible. Pas seulement pour qui est en situation de handicap.

Manu:
Et sachant que même pour une personne en situation de handicap. Un handicap peut être permanent ou temporaire. On peut être aussi en situation de handicap, par exemple si un jour je me casse le bras, etc. Et que je retrouve la motricité totale au bout d'un certain nombre semaine. A l'heure actuelle, j'y pense pas, mais peut être qu'un jour ça va m'arriver.

Angela:
Mais tu peux attendre quand tu avoir 40 45 ans, quand tu vas commencer à avoir ta vision qui diminue. Donc, tu vas devoir un peu zoomer ton texte. Tu te rends pas compte mais quand tu es sur ton Visual Studio, tu vas quand même faire Ctrl + pour augmenter un peu la taille du texte. Tu vas augmenter les contrastes couleurs. Ce sont des choses que c'est impressionnant. On m'a dit ça quand j'étais jeune, avant 40 45 ans et je disais "Ben non!". Mais le jour où tu te vois en train d'éloigner ton téléphone ou à augmenter les contrastes de couleurs pour que tu puisses bien lire... Et moi, j'ai une vision normale. C'est seulement mon âge qui est arrivé. Et voila, j'ai besoin que les logiciels et les sites que je consulte prennent ça en compte aussi.

Manu:
Ça marche. Alors comment on fait un site accessible? Déjà le B.A.BA? Qu'est ce qu'il faut connaître pour faire un site accessible pour toi ? Si on a rien à faire ce week end et qu'on veut monter en compétence sur les sites accessibles, qu'est ce que je dois garder?

Angela:
Première chose? HTML.Si on se repose sur le HTML sémantique. Sur les éléments natifs du navigateur, c'est à dire des inputs du navigateur. Le type d'input, le type de bouton. Tu profites des éléments HTML natifs et sémantiques et standards, bien sûr. Là, on a a mon avis, on a déjà fait une bonne partie pour l'accessibilité.

Manu:
Donc j'utilise des div partout, c'est ça ?

Angela:
Non, voilà div et span, ce que les personnes de Bootstrap et de Tailwind n'ont jamais compris, c'est que les div et les span n'ont pas de valeur sémantique et ne passent pas d'informations au navigateur sur "Ça, c'est quoi". Dans on a une série de propriétés, d'états et des fonctions derrière un élément HTML. Si on utilise le bon élément HTML, on a gratuitement tous ces propriétés, tous ces styles, toutes ces étapes. Si on a un div, on doit tout donner. On doit fournir tout ça. Donc on ajoute du travail. On ajoute des probabilités d'erreur. On ajoute des problèmes de compatibilité.

Manu:
Donc grosso modo, si on écrit du code qui n'est pas sémantique qui est une soupe de div. Si un jour on veut le rendre accessible. La solution, on va dire la plus compliquée à maintenir, c'est de rajouter, en plus de mes balises div c'est de rajouter des attributs supplémentaires pour donner la même sémantique que des éléments qui existent déjà en HTML. Grosso modo, j'ai écrit du code. En plus, j'écris du code en plus. Pour avoir la même sémantique qu'un élément qui existe déjà.

Angela:
Exactement. C'est ce qu'ils ont fait avec Bootstrap. Donc ils ont pas changé tout leur snippets HTML. Donc qu'est ce qu'ils ont fait, ils ont ajouté pleins d'ARIA, pleins de d'attribut ARIA pour donner du sens à leur snippets qui ne servait à rien, qui n'était rien d'un point de vue accessibilité. Qui était des divs. Qu'est ce que ça fait? Oui, ça va fonctionner. C'est un travail de fou. C'est un travail de fourmi. On doit tester beaucoup plus. Parce que là, on va vraiment devoir tester tout. Et en plus, on va accumuler des erreurs. Sans doute, on va accumuler des erreurs. Donc sincèrement, si on a une soupe de div, on doit faire accessible, malheureusement, Ben là, c'est pour ça que le HTML, c'est le plus important, on doit recommencer à zéro.

Manu:
Parce que ton HTML, c'est ton markup quoi c'est ta fondation. Si ta fondation n'est pas bonne ...

Angela:
Oui, c'est ton markup quoi. C'est la matrice de ton site. Tout va partir de là. Ta CSS va partir de là, Ton javascript va partir de là. Si tu as une mauvaise matrice, tu ne vas avoir du mal à corriger.

Manu:
Donc il ne faut pas mettre de div cliquable pour un bouton ?

Angela:
Oui, tu peux, tu le peux. Mais tout ce qui est fait pour un bouton qui est un élément natif tu vas le perdre. Donc le fait que le navigateur connaît le nombre de propriétés, il connait tous les etats, il va donner un style, même visuellement, il a un style par défaut de cet élément natif. Et par exemple quand on a un bouton de type submit même l'action, elle, est prise en compte par les navigateurs. Si tu mets un div cliquable, qu'est ce que tu dois faire? Tu dois donner a cette div cliquable tout les paramètres qui sont déjà donnés nativement pour un élément bouton. Tout ça, donc oui, tu vas devoir dire qu'il est cliquable, tu vas donner un tabIndex, etc...

Manu:
Est ce qu'il est désactivé ou pas?

Angela:
Voilà tu dois prévoir tous les états.

Manu:
Pouvoir cliquer via la touche espace. Ce genre de chose, si on utilise pas un composant natif, si tu veux te rapprocher de l'expérience utilisateur d'autres sites, si tu veux réimplanter ton propre bouton tu es obligé de tout te retaper à la main.

Angela:
Tu imagines la complexité de la chose. Qu'est ce qui est intéressant dans le CSS? C'est l'héritage. C'est le cascading. Si tu as une div à laquelle tu vas donner la classe bouton, tu imagines qu'est ce que cette div là, dans la CSS, va devoir être différente et comment elle va devoir être différenciée dans CSS parce qu'elle hérite de rien. Par contre, elle partage beaucoup de choses avec tous les autres div donc du coup ton CSS va surement pas être optimisée. Donc ça, c'est le point numéro 1 .

Manu:
La remarque qu'on a souvent, quand on fait des audits : "Ah j'ai mis une div cliquable parce que je ne sais pas désactiver le style par défaut d'un bouton. Parce qu'un bouton vient avec un background, avec une bordure, avec des arrondis... Mais juste dans 4 propriétés CSS, tu désactives le style par défaut. C'est juste que les gens ne le connaissent pas.

Angela:
Ben oui, mais voilà. Et là, là, on en atteint encore en deuxième point très important, qui vient de la formation aussi On apprend par l'HTML et on apprend pas le CSS, donc on sort développeur front web sans savoir qu'est ce que c'est le HTML, sans connaitre le CSS et on fait un mélange de tout. Donc on mélange tout. On comprend pas comment fonctionnait le navigateur même. Et voilà, ça donne ça. Donc on va dans les plus sûrs, entre guillemets. Sauf que le plus sûr, c'est le plus compliqué. C'est qu'il va donner beaucoup plus le mal de tête plus tard.

Manu:
Donc là on a énoncé grosso modo deux problématiques, enfin une grosse problématique car en fait c'est la même. C'est la non-utilisation des éléments sémantiques en HTML, on a pas cité, mais les boutons, les balises sémantiques comme la navigation, le mail et tout ça. Est ce que tu as d'autres problématiques, d'autres erreurs que tu rencontres souvent quand tu fait des audits dans ta boîte?

Angela:
Donc déjà, ça, c'est très important. Après, on a les problèmes du design parce que même si le design impacte de premier abord on a l'impression que ça n'impacte pas beaucoup l'accessibilité. Il y a beaucoup de boites de développement passer par une "web agency" pour faire le design. Je fais bien entre guillemets web agency, car certaines ne connaissent pas le web visiblement. Elles ne savent pas qu'est ce que c'est, même pas la notion d'accessibilité. Donc tu reçois des choses qui sont peut-être très belle, mais c'est illisible. C'est un texte gris clair qui s'ouvre sur du blanc. Une palette de couleurs absolument difficile à utiliser parce qu'il est impossible d'avoir des contrastes, des polices qui sont pas très lisibles, des tailles de polices aussi compliquées. Donc, ça peut impacter aussi beaucoup l'accessibilité.

Manu:
Parce que c'est pas l'accessibilité c'est pas juste l'accès au clavier de tous les éléments, c'est aussi celui du design. Par exemple la typographie. mais apparemment il y a des typographies qui sont plus faciles à lire, plus agréables à lire que d'autres.

Angela:
Plus facile oui, plus agréable c'est un confort en plus, mais il faut qu'il soit au moins ce soit lisible. Je viens de prendre en main une application là où les textes étaient pâteux, les polices en gras bavaient. Complètement. C'était illisible. C'est horrible. C'est horrible pour n'importe qui qui dirait pour quelqu'un qui est malvoyant. OK, ok, y'a vraiment problème cognitive pour identifier les lettres et les mots.

Manu:
Si police est un peu empâtée, peut-être qu'il y a les lettres qui commencent à se superposer les unes sur les autres visuellement et ils n'arrivent pas à lire le contenu du site.

Angela:
Oui tout à fait. Et ca fatigue. Par exemple, chose qui est très simple, très basique, n'importe quel designer connait, c'est que nous ne pouvons pas faire des blocs de texte long de la taille de l'écran. Si toi, tu tiens un écran de 3000 pixels, tu ne vas pas faire un texte, une phrase de 3 000...

Manu:
Bah oui, je ne suis pas webdesigner, mais ça, je le sais.

Angela:
Oui, mais voilà, c'est déjà ça. Visuellement, c'est horrible et c'est hyper fatiguant de lire toutes les lignes ou tu as trois pixels de largeur dans une fenêtre. Donc c'est basique. Donc ça, c'est aussi prendre en compte. Donc tu, tu dois savoir utiliser la typographie, utiliser l'espacement à respecter. Il y a le design. C'est quand même important aussi. Mais bon, ça, c'est quelque chose qui vient d'externe. Pour le développement, une autre chose qui est basique, c'est les alternatives aux images. Comment tu vas traiter les images, les picto? Comment tu vas les traiter? Quelle est la stratégie que tu veux utiliser pour qu'il soit compris ou non? Qu'elles sont des images décoratives. Donc, on va seulement les ignorer. On va laisser de côté. Donc ça c'est super important, mais c'est super important qu'on soit en partenariat avec les stratégies de contenu, la personne qui va vraiment définir le contenu éditorial du site. Si ce n'est pas uniquement du ressort des développeurs non plus. Et le Focus. La gestion du focus. C'est vraiment "un petit problème" .

Manu:
Petit problème. Si je reviens sur les alternatives textuelles. Tu parles des alternatives textuelles pour les images, décoratives ou pas. On met l'attribut alt à vide ou avec une bonne valeur. Mais il y a aussi les alternatives textuelles sur les éléments focusables. Si j'ai un bouton avec juste une icone dedans, il faut quand même proposer une alternative. Verdict tu mets cette alternative sur l'image ou sur le bouton ? Plutôt sur l'image ?

Angela:
Oui, oui, ça, c'est une vraie stratégie que tu dois avoir. Par exemple, moi beaucoup de sprites, donc des picto pour des soucis de performance. Donc, je vais utiliser la plupart du temps des picto. Je vais mettre dans une même image. Je vais par les coordonnées de cette image, je vais afficher l'icone ue je veux pour mon bouton. C'est à dire? C'est à dire que c'est super. J'ai un picto. Quand je vois, j'ai un bouton avec un picto. Donc pour la personne qui voit, c'est nickel. Sauf que je dois expliquer qu'est ce que c'est? Même pour la personne qui voit la page, je dois expliquer qu'est ce que c'est? Parce qu'elle peut ne pas comprendre la représentation du picto. Donc, je dois la donné. Donc, comment? Comment on va faire ça? Et si je ne charge pas l'image pour une certaine raison ? Par exemple, les images n'ont pas eu le temps de charger. Je suis en mobilité. Voila, j'ai perdu la connexion. J'ai mon contenu, mais j'ai pas mes images. Bon, je vois un bouton que tu ne sais pas ce que c'est. Donc, il faut vraiment penser comment tu vas gérer l'affichage des images, surtout quand elle passe de l'information.

Manu:
Il y a plusieurs exemples. Quand j'ai lu les choses sur le sujet, sur ces alternatives textuelles. J'ai vu plusieurs écoles soit tu définis l'alternative textuelle via un attribut comme le alt ou on en parlera peut-être tout à l'heure des attributs arial-label. Mais ce genre d'attribut sont pas internationalisable par défaut pour les navigateurs. Je sais pas si t'as vu ça, mais un navigateur peut automatiquement traduire le contenu d'un site nativement. Mais Chrome commence à le faire, mais pas encore, il ne traduit pas les valeurs associées à un attribut. Donc, toi, quelle est ta préférence ? Tu laisses comme ça, tu t'en fous la traduction? Ou bien tu préfères mettre un label qui est dans un autre élément HTML caché et tu fais le lien entre le bouton et cet élément caché via un attribut aria-labelledby par exemple, où ce genre de choses ? est ce que tu a une préférence ou pas?

Angela:
Moi, je préfère faire ce que nous appelons du progressive enhancement, de l'amélioration progressive. Donc, je vais faire mon HTML nickel. Boutons, boutons, je ferme la balise bouton. J'ai mon intitulé, "Supprimez" par exemple, je ferme la balise bouton. Voilà ça, c'est dans mon HTML. C'est ça que j'ai. Donc j'ai mon élément en natif avec les propres intitulés. Parce que ça, c'est très important aussi pour l'accessibilité, parce que l'intitulé de mon bouton par exemple, c'est ce qu'on appelle les noms accessibles. Donc ce nom accessible va être utilisé par les navigateurs aussi. C'est super important aussi. Donc voilà, après, je préfère faire comme ça parce que si je n'ai plus rien, plus de feuille style, plus rien, au moins j'ai mon bouton. Après, qu'est ce que je vais faire? Je vais cacher l'intitulé. Sauf que je ne vais pas faire un display:none, non? Parce que sinon, il ne sera plus lu. Donc, je vais cacher par CSS. Je vais les envoyer ailleurs. Je vais charger les pictos par la CSS dans un sprite. Mais j'ai toujours un petit JavaScript de côté, donc c'est un petit script qui vérifie si les images sont chargées. Dans les cas où les images ne sont pas chargées, il va montrer l'intitulé. Il va transformer les boutons et au lieu de montrer les picto il va montrer l'intituler. Donc là on couvre 100% des cas.

Manu:
Tu as ta petite palette de composants que tu réutilises dans la plupart de tes projets. Comme ça, tu ne réinventes pas la roue chaque fois.

Angela:
Exactement

Manu:
Je pense que c'est un des problèmes des développeurs. C'est qu'on n'utilise pleins de frameworks externes qui sont peut être mal conçus, frameworks, librairies ou n'importe quoi. Ils ont peut être mal conçu. Mais si on construit sa propre librairie de composants accessibles et performant au fur et à mesure des projets qu'on réalise, enfin

Angela:
Là, on est en train de développer une librairie qui va mettre en open source. Mais j'ai la mienne. J'ai ma librairie personnelle dans laquelle je vais toujours piocher mes composants qui m'intéresse. C'est bon, ça, c'est fait, c'est testé, c'est prouvé que c'est bon. Voilà, j'ai pas besoin de réinventer la roue à chaque fois.

Manu:
Tu parlais de date de nom accessibles. Je ne suis plus le terme exact que tu as employé. Que c'était utilisé par le navigateur, mais aussi utilisé par le synthétiseur vocal. Le synthétiseur vocal est un logiciel qui est installé sur vos téléphones, ordinateurs, qui lit le contenu d'une application ou d'un site web. Donc, si le bouton, quand il a le focus dessus, il n'y a pas d'alternative, le synthétiseur vocal ne sera pas capable de dire quel est ce bouton. La semaine dernière, Céline a parlé de captchas. Quel est ton avis sur le sujet?

Angela:
C'est une horreur. Je déteste d'abord.

Manu:
Passons à la question suivante

Angela:
Je ne crois pas que quelqu'un aime ce truc. De toute façon, c'est une horreur. Elle a bien expliqué. C'est une catastrophe. Ca fait peur à n'importe qui. En plus, aux utilisateurs de lecteurs d'écran, c'est une horreur. Et quand on sait qu'il y a, il existe des façons de faire. Parce que c'est le Captcha, les captchas, c'est pour voir si on n'est pas un robot. Donc il existe des astuces assez "ranked". Je crois que s'appelle la stratégie Honeypot, qui te permet de faire la même chose. On va poser une question par un input caché, et si cet input caché est répondu, il y a les réponse, là, on sait que c'est un robot, parce que une personne ne va pas pouvoir accéder à ce champs. Donc, on ne peut pas remplir une écoute cachée. Seulement un robot peut le faire. Donc ça, c'est une façon très simple de faire. Bien sûr, ça prend pas 100% des cas, mais là, ça, ça rentre dans quelque chose que je ne connais pas énormément : la sécurité. Mais au moins, dans un premier temps, ça se fait. C'est transparent, l'utilisateur, il n'est pas embêté et au moins, ça donne déjà un premier barrage au robot. Il y a une page sur Wikipédia. Si je me trompe pas à propos, si on fait une recherche sur Captcha accessible, il y a Patrick Lock, qui a fait une liste avec des commentaires de tous les captcha connus. Il montre et il explique quels sont les pros et cons de chaque chaque captcha. C'est super intéressant.

Manu:
Je reviens sur un point abordé tout à l'heure : la gestion du focus. D'après toi, le deuxième point le plus important après la sémantique HTML? Est ce que tu peux en parler un petit peu? Qu'est ce que c'est, la gestion du focus? Quelles sont les différentes problématiques à appréhender?

Angela:
La gestion de focus. Nous, utilisateurs de souris, quand on utilise les curseurs, on voit le curseur. Donc on n'a pas besoin de savoir où "on est dans la page". On est là où le curseur est. Nos yeux suivent le curseur. Par contre, les navigateurs, lui, il est en train d'enregistrer une position dans la page. Il y a un registre là où on est dans la page, n'est pas forcement la ou je balade mon curseur. Et par exemple, quand on navigue avec les claviers avec la touche Tab, si on fait la touche Tab, on va sauter d'éléments qu'on appelle les éléments focusables, les éléments qui acceptent les focus. Il va sauter d'éléments focusables à l'autre. Dans un navigateur, les éléments focusables sont des éléments actifs fonctionnels, sont donc les boutons, les liens, les éléments de formulaire, un input, une checkbox, radiobox... Donc, si on l'attaque avec la touche Tab, on peut sauter dans un élément à l'autre. Sauf qu'il y a des moments où je dois dompter ce focus, dire non ce focus doit être ici et pas là, OK. Par exemple, dans le cas d'une modale, quand on ouvre une modale, qu'est ce qui arrive? Si on est avec la touche tab, on doit être piégé dans la modale. Pourquoi? Parce que la modale qu'est ce qu'elle est? Elle est comme un layer qui cache la page où elle est. OK, donc, si on est, on ouvre une modale, on doit faire un tabulation, on doit être enfermé dans cette modale, jusqu'à ce qu'on la ferme. Cela s'appelle le focus trap. On est dans le dernier élément focusable, quand on fait tab, on va au premier. Donc on va tourner en rond dans les modales jusqu'à ce qu'on décide de la fermer. Pour ça, bien sûr, on a besoin de JavaScript et on a besoin de contrôler et de faire de la gestion de ça avec JavaScript.

Manu:
Mais qui définissait ces règles? Pour un composant riche comme une modale, tu dois garder le focus à l'intérieur de la modale, tu ne peux pas sortir de cette modale ? Qu'est ce qui définit ces règles ? C'est pas le HTML qui définit.

Angela:
Non, c'est plutôt une règle d'utilisation. C'est plutôt une recommandation. C'est même une recommandation W3C WCAG. Pourquoi? Parce que tu imagines? Si, si tu dis dans ta page OK, on est un utilisateur de lecteur d'écran, donc on voit pas où en est, on ne voit pas, on voit pas notre page, donc on écoute. Si j'ai créé un widget d'une modale, je clique un bouton. Il va me dire si j'ai bien fait, comme je dois faire avec les protocoles ARIA, il va me dire "dialog modal", donc je sais que je suis sorti de la page. Je sais que je suis dans un niveau supérieur de la page. Donc je sais que ke ne vais pas sortir de là dedans. C'est une question logique.

Angela:
On est d'accord, on est d'accord. Quand on voit, on est dans la modale, on a pas accès, on ne va pas cliquer sur quelque chose en dehors de la modale, parce qu'on ne peut pas. Donc on doit donner cette cette même sensation? cette même fonctionnalité aux utilisateurs de lecteurs d'écran. Donc c'est juste une question de logique.

Manu:
Tu parlais du WCAG tout à l'heure. Peut être pour les auditeurs, WCAG, c'est le working group, l'équipe - je ne trouve pas le terme français - l'organisation, qui travaille sur les problématiques d'accessibilité au W3C World World Wide Web Consortium. Moi, j'ai l'habitude de dire que ces règles là, c'est surtout pour s'assurer qu'une modale développée à la main, une modale développée avec un framework, une modale développée avec une autre façon, Comme on a définit un pattern d'utilisabilité, l'utilisateur final, que ce soit sur un site A, un site B, un site C , les automatismes, il va les garder. Moi, je crois que c'est toi qui prenais cette définition il y a quelque temps, quand on a discuté de ce problème, mais de l'affordance. C'est que si tu vois théière, même si c'est pas la même théière que tu as la maison, tu sais t'en servir. Si tu vois une modale développée en pur JavaScript, en React ou encore Angular, comme il y a des règles comme le focus trap ou le fait que si je clique sur la touche Echap, je ferme la modale. Si toutes les modales respectent cela, on est pas perdu.

Angela:
Oui, On doit pas perdre l'utilisateur. Il dit si on dit ca c'est modales, ça doit se comporter comme une modale. Donc voilà donc, à la limite, si tu, pour les plus simples, on ne fait pas de modal, on ne dit pas que c'est une modale, on fait juste une ancre sur une partie de la page. Et là, oh, c'est peut être plus simple. Et après? Visuellement, on peut, avec la CSS, se transformer cela en une modale. Mais aujourd'hui, comme on a ARIA, on peut, on peut améliorer l'expérience utilisateur, même pour les utilisateurs de lecteurs d'écran avec rien.

Manu:
C'est très bien. Donc la on a vu les erreurs courantes. Quel est toi dans ta vie de tous les jours, au boulot en tout cas, ta stratégie de conception et de développement d'applications Web accessible. Est-ce que tu as une bonne pratique qu'on pourrait suivre pour essayer de de au moins réduire les dégâts.

Angela:
Je me rappelle, j'ai fait une conférence une fois et on m'a posé la question. Ouais, mais c'est sur l'accessibilité. Oui, c'est bien, mais bon, nous, on est une boite, on est une quinzaine de développeurs. Si on doit commencer à faire accessible, à développer accessible, comment on fait ? les mecs ils étaient tout perdus et moi, j'ai dit "on se forme", il faut faire une formation en accessibilité. Ça m'a paru très clair, mais c'est clair aujourd'hui aussi. Un peu plus tard, en réfléchissant sur ca, la formation former les développeurs, former tout le monde. Donc, quand je travaille avec les développeurs, il y a très peu que sont formés en accessibilité vraiment. Et même s'ils sont formés, tu fais une formation de deux ou 3 jours d'accessibilité, ils ne vont pas sortir super fonctionnel, super performant d'un jour à l'autre. La formation accessibilité que je donne, c'est deux jours, c'est deux jours qui suffi aux gens de réfléchir de façon accessible, savoir comment et ou le problème peut être. Donc savoir corriger et réfléchir à u problème d'accessibilité. C'est tout. Donc, on va leur donner des pistes, leur donner une lumière pour savoir là où ils peuvent aller

Manu:
Tu leur apprends à se débrouiller.

Angela:
Oui, c'est un peu ça. Oui, on apprend les B.A.BA, mais après? Voilà, avec ça, vous pouvez vous débrouiller de cette façon. Mais l'accessibilité, oui. Il y a une grosse grosse partie d'expérience qui vient avec l'expérience. Donc, c'est qui, c'est qui on doit faire? C'est absolument avoir, pas seulement former tout le monde, bien sûr, et former les développeurs, former des designers, former les experts UX. Oui, mon Dieu ils doivent être formés abstraitement, les chefs de projet... Il faut qu'ils soient vraiment tout le monde soit conscients et sensibilisés aux enjeux de l'accessibilité. Il faut un référent dans une équipe, par exemple cinq développeurs. Il faut au moins un développeur avec un peu plus d'expérience puisse être un référent afin de concentrer les questions et les problématiques et essayer de les aider dans un premier temps. Et il faut quand même un conseil civique, quelqu'un un expert en accessibilité, quelqu'un de plus expérimenté, expérimenté, qui va faire un suivi , ce que je fais aujourd'hui beaucoup en interne, je suis et je conseille les équipes de développement pour les nouvelles fonctionnalités ou pour les débuts d'un projet.

Manu:
Quand on est développeur, dans les cérémonies agiles on a l'habitude de parler d'une définition du done. Définition du done, c'est avoir la fonctionnalité qui est implémentée. A voir la fonctionnalité qui fonctionne, déjà testée, performante, peut être qu'un jour on aura dans la "définition of done" avoir une fonctionnalité qui est accessible. Si c'est pas accessible, la fonctionnalité n'est pas terminée. Peut être ...

Angela:
Oui, ça ...

Manu:
Je donne des idées aux équipes de développeurs.

Angela:
Oui, c'est ça. Oui, c'est clair.

Manu:
Parce que Céline le disait la semaine dernière, je reprends sa phrase de mémoire. C'est que l'accessibilité, ça ne se prend pas en compte à la fin du projet. Parce que si on essaie de corriger un site en fin de projet, c'est plus de la rustine qu'autre chose.

Angela:
Combien de sites on a dû faire table rase et commencer à nouveau? Pas moyen. Il n'y a pas moyen. Et comme vous avez parlé des sous couches accessibles

Manu:
FACIL'it

Angela:
FACIL'iti. Ce sont de choses... ah ... Mais je n'ose pas dire ce que je pense de ça. Mais ça ne sert absolument à rien. Ça sert à ajouter une complexité sur ton développement et une complexité que va résoudre pratiquement rien de ton problème en accessibilité

Manu:
Je vais du reverse engineering de FACIL'it la semaine dernière, juste pour regarder. Ça change juste le contraste des couleurs, la police peut être, la taille des éléments focusables, .... Mais si t'es sur le site de Ventes privées, Comme disait Céline, les images n'ont pas d'alternatives textuelles, les images de la page d'accueil, C'est pas FACIL'iti qui va te les ajouter.

Angela:
C'est tout une stratégie. C'est toute une logique qui doit être prise en compte depuis le début du projet depuis la conception. C'est pour ça que je mets l'accent dans les experts UX, donc les ergonomes et les experts UX qui, à mon avis, sont malheureusement encore pas assez sensibilisés à ça et qui doivent être sensibilisés et doivent penser à l'accessibilité dès leur conception, prendre en compte et ne pas venir avec les "ah non les malvoyants et les non-voyants ne vont pas utiliser ça...."

Manu:
J'ai fait l'exercice de contacter Ventes Privées pour savoir, même si leur site n'est pas accessible, le but de l'accessibilité, c'est pas au moins de proposer une alternative. Je leur ai posé la question. Je ne peux pas aller sur votre site parce que je n'arrive pas à comprendre avec synthétiseur vocal quel est le contenu des images? Parce qu'il n'y a pas d'alternatives textuelles? Pourquoi? Pourquoi déjà ?. Mais si vous voulez, on n'utilise pas FACIL'iti. Tout ça. Donc notre site est accessible. En fait, non. Si tu intéresse un petit peu, ton site n'est pas accessible, même si tu as FACIL'iti. Il corrige pas tout. Mais on a plein d'équipes d'ingénieurs qui travaillent sur ce sujet. Bla bla, bla bla. Je dis OK, pas de soucis. Très bien, ça me va comme réponse. Mais est ce que vous proposez une alternative pour moi, consommateur, qui souhaite acheter chez vous? Non, mais je vous assure on n'a pas d'ingénieurs qui travaillent dessus.

Angela:
Et ils ont perdu un ou plusieurs utilisateurs. C'est tout. Et bien, j'espère bien pour eux qui y sont vraiment en train de travailler à ça.

Manu:
J'ai posé la question aussi du prix de FACIL'iti. Je n'ai pas eu la réponse encore, mais c'était par curiosité intellectuelle. Quel est le. Combien tu payes FACIL'iti si tu souhaites l'installer sur ton site? Je ne pourrais pas donner la réponse pendant le podcast car je ne l'ai pas, mais une fois que je l'aurai, je le partagerai sur Twitter. Mais comparer le prix d'installation et de maintenance, la gestion FACIL'iti versus le temps de formation et le temps de mis en place, l'application des bonnes pratiques d'activité sur une application Web. Je ne pense pas que le moins cher soit FACIL'iti. Je ne sais pas si les gens sont bien formés. Le surcoût n'est pas énorme. Non, non, c'est juste un automatisme.

Angela:
C'est bien sûr. Et il y a, il y a. Au début, on a commencé un projet avec une équipe qui n'est pas sensibilisée à l'accessibilité. Oui, on a eu un investissement entre guillemets qui c'est former tout le monde et avoir quelqu'un qui va conseiller et faire un suivi de conception et développement. Mais c'est cet investissement. C'est fait une seule fois. Il se dilue hyper rapidement et l'expertise, l'expérience, la mise en pratique. Ça vient tellement facilement après. Bon, un développeur est fait un, deux projets accessibles. Bon, c'est intégré. Si il a envie. Bien sûr, si on est réfractaire on est réfractaire. Mais si on a vraiment envie en deux, c'est fait.

Manu:
Je suis totalement d'accord. Est ce que tu as des bonnes pratiques en terme d'audit? Quand tu dois auditer un site, tu fais un audit avec de l'outillage, manuel. Qu'est ce que tu fais? Qu'est ce que les règles de l'art en tout cas, en terme d'audit?

Angela:
Audit. J'ai fait une formation uniquement pour l'audit. Et ce qu'on nous apprend, c'est prendre les checklists dans les recommandations RGAA, et "checklister" chacune. G. Je ne peux pas, je ne supporte pas. J'ai horreur de chaque liste. Donc bon, moi, j'ai aussi beaucoup d'expérience. Déjà, c'est plus facile pour moi, mais moi, je vais tout de suite dans la première chose. Première chose je regarde le HTML. Je vois le niveau de dégats ô combien il est, il est sémantique,, s'il est standard, s'il est valide parce que bon, des fois, on a des codes qui ne valident pas. Donc c'est la première chose. Contraste de couleurs rapidement. Tester les contrastes couleurs, ça. Bon aussi, je suis designer, donc je vois tout de suite là où ça pêche, c'est vrai qu'il y a quelque chose que j'utilise beaucoup pour ça c'est les plugin web développeur : Il y en a pour Firefox, Chrome. C'est super pratique. Par exemple, tu peux montrer tous les alt des images. Donc on voit tout de suite les images qui pas de alt. Donc il y a des outils. Il y a Wave aussi. Très bon, c'est un plugin aussi pour navigateur. C'est bien parce que ça te donne un aperçu rapide. Donc là, on voit déjà rapidement les dégâts. Quand le site est bien développé, l'accessibilité a été pris en compte depuis le début, on sait que l'accessibilité était vraiment un enjeu dans le développement. Là, oui, là, ça vaut la peine de prendre une checklist et tester vraiment 5 6 pages pour vérifier. Pourquoi? Parce que là, on va vraiment en cherry-picking. On va prendre vraiment les détails qui peuvent faire la différence. Mais normalement, quand les sites que j'audite, normalement en une heure, je vois un le nombre, non ce n'est même pas a peine.

Manu:
Même pas besoin de sortir le référentiel que tu sais déjà qu'il y a pas mal de choses.

Angela:
An. Alors oui,

Manu:
Si des outils me trouvent des erreurs automatiques, j'ai même pas besoin de faire un travail intellectuel pour savoir qu'il y a tout cela à corriger. Quand tout ça est corrigé, je commence à faire un audit, peut être manuel, pour essayer d'être un peu pointilleux voir vraiment les autres problèmes. Si la première étape n'est pas valide, pourquoi?

Angela:
Voilà ce n'est pas la peine. C'est d'ailleurs même pas la peine de prendre un lecteur d'écran et d'écouter, on sait déjà que ça va être une catastrophe. Après, après? Bien sûr, de toute façon, il n'y a pas d'audit qui soit automatique. L'audit automatique, ça va te prendre donner des indications vraiment sur le code : la validation HTML. Des choses comme ça, mais c'est vraiment très, très peu de choses.

Manu:
Une analyse statique.

Angela:
Après, c'est la navigation par clavier. Tester le clavier, prendre un lecteur d'écran. Écouter, bien prendre quand même quelques temps pour apprendre à utiliser, par exemple, NVDA qui est un très bon lecteur d'écran sur Windows, il est gratuit et open source, donc très facile à utiliser. Encore, on prend quelques temps pour apprendre les raccourcis clavier. Après, n'importe qui peut vraiment tester facilement avec NVDA. Bien sûr, il faut un peu d'expérience, mais bon, il n'y a pas besoin de 1 mois pour ça si c'est quelque chose qui, avec un peu de bonne volonté, on en prend rapidement et c'est comme ça qu'on peut

Manu:
Après éventuellement avec des tests utilisateurs. Moi, j'ai eu la chance chez un client d'avoir des tests utilisateurs avec des personnes en situation de handicap qui testent notre produit.

Angela:
Ça, c'est l'idéal. Ça, c'est après l'audit. L'audit a été fait. Le site est relativement bien. Là on va passer au test parce que c'est que l'utilisateur, les utilisateurs, qui vont te donner, te dire les endroits là où il y a des problèmes. C'est seulement eux qui peuvent le dire.

Manu:
Pour finir cet entretien, gardez en tête, en tout cas vous quand vous êtes développeur, qu'on vous fait des retours comme quoi votre site n'est pas accessible? D'accepter la remarque, en tout cas de ne pas être brute de fonderie et dire bah si tu veux contribuer, c'est open source, bah vas y.

Angela:
Absurde. Quand elle a dit ça. C'est horrible

Manu:
Oui Céline a dit cela de Prestashop.

Angela:
Ben oui, on est utilisateur, on n'a pas développeur.

Manu:
Il faut garder ça en tête quand on ne l'est pas. Nous, ceux, qui écoutent cette phase B, vont surtout être développeur, mais les utilisateurs de vos produits, la plupart d'entre eux ne sont pas développeurs. Donc oui, soyez indulgent. Acceptez les retours négatifs, c'est comme un bug. Un bug, vous le corrigez, un problème d'accessibilité, il faut prendre en compte. Ouais, ça m'a tué aussi quand Céline a parlé de cela.

Angela:
Vraiment un manque de tact commercial. Tout, tout, tout, vraiment.

Manu:
Et il faut accepter qu'on fait des erreurs, on fait des erreurs, on ne fait pas des trucs de qualité tout le temps. Mon but, c'est de c'est d'accepter les retours et de s'améliorer.

Angela:
Donc voilà. Oui, mais oui, on va pas créer un site 100% nickel accessible. De la même façon que l'on a des bugs quand on fait un script qui marche pas exactement comme on l'attendait. L'accessibilité, c'est pareil. Oui, on a fait ça, mais finalement, ça marche pas tout à fait comme on veut avec les lecteurs d'écran. Donc on va corriger. Il y a toujours des choses à améliorer

Manu:
Et un site accessible n'est pas accessible tout le temps. Si on fait des mises à jour, et on a fait un travail de mise en conformité en avril 2021, avec des mises à jour plus tard, il faut s'assurer qu'il n'y a pas de régulation.

Angela:
Mais ça, c'est très important, ça. On, ça arrive tout le temps, ça arrive très souvent. Qu'un projet démarre avec l'accessibilité en tête? Vraiment pris en compte. Et au fur et à mesure, les développeurs changent. L'équipe change un peu. Bon, on perd de vue. Il y a de nouvelles fonctions qui sont ajoutées, l'accessibilité n'est pas prise en compte. Et voilà, c'est une régression. Donc, il faut toujours toujours la balle, faut toujours la tenir.

Manu:
Ça marche. Pour finir, est ce que tu as un conseil à donner à nos auditeurs ?

Angela:
Pour les développeurs, oui. Le meilleur conseil que je peux donner,

Manu:
développeurs ou design ou ergonome. Le potentiel public qu'on pourrait avoir aujourd'hui.

Angela:
Les experts UX doivent absolument être sensibilisés. Qu'ils sachent ce que c'est l'accessibilité et qu'ils prennent en compte tout le temps dans leur conception. C'est super important. Pour les développeurs. La principale chose que je dois dire, c'est l'accessibilité, c'est... Le chouette de l'accessibilité, c'est super intéressant, c'est un challenge. C'est vraiment Léonie Watson qui a dit ça. C'est vraiment une opportunité pour la création. C'est un défi créatif. C'est pas, c'est pas un encombrement. Ce n'est pas quelque chose qui doit nous embêter, non. C'est vraiment quelque chose qui nous pousse, nous pousse à être meilleur, qui nous pousse à être plus créatifs, plus performants. Et sincèrement, c'est très cool. C'est très intéressant. Il faut, il faut s'y mettre parce que toi, tu peux le dire. C'est un défi délicieux.

Manu:
Moi, je pense que le message est passé. J'espère qu'on a fait naître des vocations. Merci Angela pour cet entretien. Où est ce qu'on peut te suivre sur Twitter? Sur Facebook?

Angela:
Non, je n'ai pas que Facebook. @GeRicci sur Twitter et j'ai mon site gericci.me avec quelques articles.

Manu:
On mettra les liens dans les notes de l'épisode. Merci beaucoup à toi. Merci.

Angela:
Merci à vous deux. Fanny toi, pour m'inviter, pour penser à moi. Je souhaite beaucoup de succès dans votre.

Manu:
Merci bien et merci aux auditeurs. Rendez vous. Prochaine épisode je crois que c'est l'accessibilité dans le monde du développement mobile natif Android. Rester, rester à l'écoute dans les prochaines semaines y aura de nouveaux épisodes. Bonne écoute à tous et à bientôt.

Sonix is the world’s most advanced automated transcription, translation, and subtitling platform. Fast, accurate, and affordable.

Automatically convert your mp3 files to text (txt file), Microsoft Word (docx file), and SubRip Subtitle (srt file) in minutes.

Sonix has many features that you'd love including automated translation, advanced search, enterprise-grade admin tools, world-class support, and easily transcribe your Zoom meetings. Try Sonix for free today.