TechEthic-E2-FB - 16:05:2021 21.13.mp3
TechEthic-E2-FB - 16:05:2021 21.13.mp3: Audio automatically transcribed by Sonix
TechEthic-E2-FB - 16:05:2021 21.13.mp3: this mp3 audio file was automatically transcribed by Sonix with the best speech-to-text algorithms. This transcript may contain errors.
Fanny:
Bonjour François, Tu va bien .
François:
Je vais bien merci.
Fanny:
Je suis ravi de te recevoir aujourd'hui pour parler d'accessibilité mobile. Alors en plus, tu es un copain puisque tu fais de l'Android comme moi, mais n'ayez pas peur, ne fuyez pas tout de suite les développeurs iOS, l'accessibilité, les règles, que ce soit sur Android ou iOS, ça va être les mêmes. C'est plutôt dans l'application et dans le code que ça va plus ou moins changer. Restez là, n'ayez pas peur. On vous aime bien quand même. François, est ce que tu peux te présenter?
François:
Oui, bien sûr. Moi, c'est François. Donc, je bosse sur Android pour une startup américaine depuis quelques temps déjà. Et donc, dans mes valises, j'ai aussi la balise de l'accessibilité. Donc, pour InstaCart, je dois m'assurer qu'on passe les audits d'accessibilité avec succès. Pas mal de ta taff.
Fanny:
Du coup, InstaCart c'est une appli pour faire son shopping. C'est ça?
François:
C'est ça à la base de tout ce qui était les courses alimentaires en français et on a un peu, plus c#a va plus c'est shopping en général. En fait, c'est une app où tu te connectes, tu fais ta petite liste de courses sur un magasin. Quelqu'un va acheter des courses pour toi et les livrer chez toi. C'est d'autant plus un service pour lequel les personnes malvoyantes ou les problèmes de locomotion sont très friandes.
Fanny:
Et du coup, toi, t'en es arrivé comment a travailler sur l'accessibilité?
François:
On devait le faire tout simplement. Il fallait quelqu'un pour guider ça du côté Android. Du coup, on a monté une équipe accessibilité, on est quatre. Donc il y a une lead générale, c'est une juriste en tête, parce qu'il y a un gros aspect légale surtout aux États-Unis. Et ensuite, voilà lead Android, lead iOS et lead Web. Et en fait, quand on a une compagnie comme InstaCart, aux Etats-Unis, il y a assez peu de lois. niveau accessibilité. En général, tout ce qui est protection de consommateur aux États-Unis, c'est pas la France. Il n'y a pas grand chose. Par contre, il y a quand même quelques petites choses. Déjà d'une part, InstaCart, on va faire les courses dans les magasins, on les livre, donc on a des partenariats plus ou moins forts avec des magasins, pour lesquels on gère quasiment tout pour eux. Et on a vraiment une app à part avec un équivalent américain d'un Auchan ou un Carrefour. Quand je télécharge l'App sur l'App Store, c'est vraiment l'app avec le nom du magasin, derrière c'est juste notre app reskinné. Mais bon, du coup, on a vraiment un contrat avec plein de requirements sur ce qu'on doit leur fournir et entre autres, ces compagnies là se sont engagées à être accessibles. Donc nous aussi, on s'engage à être accessible. C'est la première partie pour laquelle on doit être accessible. La deuxième, c'est que il n'y a pas beaucoup de lois aux Etats-Unis, mais il y en a quand même quelques unes. En fait, ce qui se passe, c'est que l'état où il y a le plus de lois, c'est un peu lui qui décide du minimum que les compagnies doivent supporter. Et donc, ici, c'est l'Etat de New York, où on doit supporter le standard d'accessibilité, qui est celui que tout le monde supporte WCAG 2.0. Et donc on doit supporter boite à New York ou bien sûr, du coup, on le supporte un peu partout.
Fanny:
Sachant qu'en terme de loi en France, pour l'instant sur le mobile, il n'y a aucune obligation si ça vient d'arriver sur le Web. Il me semble pour les entreprises qu'ils font plus de X millions de bénéfices, mais ce qui est vite fait pour des boites types comme tu dis Auchan, etc. Là, il commence à y avoir des prérequis. Et le mobile, il me semble que ça ne va pas tarder à arriver. C'est vrai qu'on est en retard par rapport aux US et au UK où il y a déjà beaucoup plus de choses mises en place pour réglementer tout ça. Ca arrive.
François:
Ici il y a quelques lois légères et après, le truc, c'est que tu implémentes pour ne pas te faire attaquer en justice.
Fanny:
Je ne suis pas sûr qu'ils vont venir beaucoup contrôler, mais on ne sait jamais quoi le jouer. Je ne sais pas, mais je me demande
François:
Bien, du coup. Encore une fois, on connait la mentalité. Tu veux vraiment le faire a minima, c'est couvrir tes arrières au cas où tu te fasses attaquer en justice. On fait n peu plus que le minima. Si tu voulais faire ça donc l'idée, par exemple, on embauche une compagnie tierce dont le travail, c'est d'auditer notre application pour tout ce qui est accessibilité.
Fanny:
J'aurai plein de questions plus tard sur l'audit. Avant ça, je voudrai savoir du coup comment tu t'es former à l'accessibilité, quand vous avez décidé quand vous êtes dit là il faut qu'on rende l'application accessible. Comment tu as démarré ?
François:
Un peu formé sur le tas. Malheureusement, il n'y a pas énormément de ressources niveau accessibilité. Après, la plupart des problématiques d'accessibilité ne sont pas d'une complexité folle. Typiquement, faire fonctionner l'application avec TalkBack. Tu fermes le yeux, est-ce que tu sais utiliser l'applications ? . Bon, ce n'est pas ultra complexe en soi. Et après? Ça tombe beaucoup autour des content descriptions, de l'ordre des vues et ainsi de suite. C'était un peu apprendre en allant, voir ce qui fonctionne, ce qui ne fonctionne pas et itérer.
Fanny:
Je pense que du coup c'est vraiment qu'au départ il n'y a pas énormément de matériel pour se lancer puisque c'est pas très compliqué comme tu dis. Apprendre à utiliser Talkback, et puis regarder trois vidéos, que ce soit Google ou Apple. Il y en a vraiment beaucoup pour vraiment entrer et s'initier au sujet. Ensuite, je pense que ce qui va permettre de gagner en expérience, j'imagine, c'est tomber sur des cas concrets. Se demander comment c'est quoi, les règles? C'est quoi le WCAG ? C'est quoi ce qui est attendu ? Ça va être surtout les corner cases comme ça, ou on va beaucoup s'appliquer sur le WCAG, comme tu disais tout à l'heure pour valider les audits.
François:
C'est justement là où c'est intéressant, c'est que du coup, on fait vdes audits mais on en parlera après, mais surtout que les audits, ça se passe par des passes de QA ou derrière on récupère une liste de problèmes simplement à fixer dans l'applications. C'est donc ça qui guide vraiment là où on va concentrer nos efforts. Et c'est un peu subjectif, toujours. Il y a toujours une part de subjectivité dans ce que l'auditeur trouve comme problème. Il y a toujours une part ou discuter avec l'auditeur pour identifier ce qui ne va pas et suivant la complexité du problème, voir comment on peut gérer ça tout simplement.
Fanny:
On parle encore d'audit, donc on va aller directement sur le sujet, comme ça ça sera plus clair pour tout le monde maintenant. Un audit? Comment ça va se matérialiser? Comment ça se passe?
François:
Ah alors, ça dépend entièrement de la compagnie avec laquelle tu fais ça. C'est une compagnie tierce. Nous, on les paie pour faire les audits. Ils ont aucune obligation derrière de dire que InstaCart satisfait les conditions accessibilité, toussa. Si on les payaient et qu'on avait juste une lettre derrière ça n'aurait aucune valeur. Donc ils vont tester l'application. Donc ils sont toute une équipe de testeurs, dont certains sont non voyants. Et donc cette équipe va construire une série de tickets sur chaque plateforme avec : j'essaie d'utiliser la recherche. Par exemple, je n'arrive pas à lire les résultats. On va avoir des ticket comme ça. Et donc, voilà. Donc, on récupère une autre petite liste de problèmes à régler. Et voilà. On va essayer de les fixer. Et on a une nouvelle application. On leur renvoie. Ce qui peut être un peu compliqué s'ils veulent uniquement valider des applications disponibles sur un AppStore. Donc en production? Dans tous les cas on fait des releases toutes les semaines, mais on doit quand mème un peu module ça pour être efficace, surtout pour éviter 'être sur des cycles qui durent plus longtemps. Et une fois qu'ils sont satisfaits d'applications, on a ce qu'on appelle une lettre de conformance.
Fanny:
Ça c'est la fameuse lettre A, AA, AAA ? C'est ça ?
François:
C'est ça, c'est ça, c'est une lettre ou voilà. Donc, le cabinet d'audit en question atteste que l'application InstaCart satisfait..
Fanny:
Est plus ou moins accessible à un certain niveau. C'est ça, vous pouvez l'afficher, vous avez un tampon et vous pouvez l'afficher fièrement.
François:
Voilà encore une fois si pour une raison X ou Y, quelqu'un contesté que l'application n'est pas accessible, bon, on a déjà ça à présenter pour dire comment on a fait un effort tout à fait honnête. Ça est donc entre la lettre et le fait que voilà des problèmes, on les fixe, normalement de ce point de vue là, on est bon. Et normalement, on a un produit qui est plutôt accessible.
Fanny:
Ok, ça marche. Du coup, l'accessibilité dans le déroulement d'un projet mobile, pour toi, ça doit être pris en considération a partir de quel moment?
François:
Plutôt s'est fait le plus facile ça va être en fait.Parce que y'a rien d'ultra complexe en soi dans l'accessibilité. Mais si tu as déjà une application toute faite, forcément, on a fait des choix techniques ou il y a toujours des cas particuliers, ou tu as du faire des choses un peu compliqué. Tu n'as pas du tout pensé que tout doit être accessible. D'un coup, tu vas te rendre compte que forcément, certains choix qui ont été faits "ah, je n'aurais pas du faire ca comme ca". Et donc plutôt, tu prends cela en compte,le mieux, c'est nettement. Surtout le moins d'effort tu devras passer pour rendre accessible. Nous, nous, ce qu'on fait, c'est dans notre squelette de Pull Request, une petite case pardon où tu dois cocher pour dire voilà tu as fais les tests d'accessibilité sur la feature.
Fanny:
À chaque fois, c'est bien pensé. Du coup, on va rentrer dans le vif du sujet. Pour la partie dev, en quoi une app est accessible ou elle ne l'est pas? C'est quoi? Qu'est ce qui va faire qu'on va passer dans la case pas accessible?
François:
Du coup, c'est un peu compliqué. Comment est ce qu'on définit une app accessible? Du coup,
Fanny:
On va dire utilisable. Tu vois dans l'interview avec Manuel, il qualifie d applications utilisables et je pense qu'il dit utilisable, c'est pour dire j'arrive à l'utiliser. Ce n'est pas optimal, mais c'est clairement l'UX est clairement complexe pour moi. Mais j'arrive à l'utiliser et il y a des tas d'applications je pense qu'ils ne sont même pas au stade utilisable. Est-ce que tu as une idée pourquoi?
François:
Le pourquoi c'est juste que les devs ne sont pas sensibilisées? Ils ne passent pas le temps de rendre l'app accessible, quoi, voilà. Malheureusement, on ne sait pas. Ce n'est pas forcément notre priorité, ce qui est un peu bête en soi même, du strict point de vue totalement sociopathes capitaliste, est ce que je peux faire du pognon, bon, tous les utilisateurs d'Accessibilité, c'est aussi un marché qui a besoin d'utiliser en soi. Juste regardez mieux du point de vue profit, il n'y a pas trop de raison de ne pas faire d'accessibilité sur beaucoup de produits. Dès fois one est un peu surpris des applications que des gens mal voyants utilisent. Ce n'est pas des problématiques ultra connues. Tu me disais "Est-ce qu'on peut utiliser une application" oui mais par qui ?
Fanny:
Je pense qu'aujourd'hui va essayer de se focaliser sur la partie accessibilité visuelle. Je pense qu'on fera une petite ouverture à la fin, mais effectivement, tu vois des personnes comme Manuel qui sont non-voyantes ou des personnes malvoyantes. Essayer de focaliser surtout sur ça pour une personne qui utilise Talkback. Qu'est ce qu'il va faire que l'application ne fonctionnera pas
François:
Si l'application est utilisée par quelqu'un non-voyant...
Fanny:
Par ricoché, c'est pas mal pour les autres catégories.
François:
Ça, a priori, en général, ça doit être utilisable par mal de monde. Et du coup, simplement, c'est donc mon application. Je lance Talkback et je promène mon doigt sur l'écran. Est ce que ce que Talkback va annoncer, est-ce suffisant pour comprendre le contenu de l'écran? Un exemple simple. Super facile à utiliser. C'est tout ce qui est checkbox, radio, switch. Quand on customise ou même parfois, quand on prend le widget Materiql qui est mal fait et quand on a un élément comme ça à l'écran, si on met le doigt dessus et que y'a rien qui nous dit Checked ou not checked. Si je ne peux pas voir l'élément et que je n'ai pas non plus son état qui est énoncé, forcément, c'est pas utilisable. Pas moyen de savoir, par exemple, pas dans une liste d'horaires, lequel est sélectionné.
Fanny:
Et justement, ce cas, en tout cas sur Android. Si on utilise beaucoup de composants custom et qu'on ne fait pas forcément gaffe l'accessibilité et qu'on va étendre de View, par exemple. Mais en fait, on a rien du tout qui est accessible puisqu'on n'hérite pas de l'accessibilité des composants natifs. Et si on veut faire l'effort, tu me corrige, mais si on veut faire l'effort, on va devoir nous mêmes positionner les éléments pour Talkback, puis venir associer les comportements attendus pour que Talkback puisse dire oui, c'est un bouton, son état est checked ou pas checked. Plus tu utilises des composants custom potentiellement, si tu fais pas gaffe, ton app elle est encore moins accessible.
François:
C'est ça? Tout ce qui est, ce qu'Android appel les checkables, au final, c'est pas vraiment l'exemple tarte à la crème, tu ne fait pas attention, tu ne rends pas accessible. C'est aussi l'exemple où, par contre, voilà si tu testes un peu ton l'application, quand tu développes, ça prend vraiment deux secondes à rendre accessible.
Fanny:
L'autre exemple qui prend vraiment deux secondes à rendre accessible et qu'il m'enrage quand je vois que c'est fait sur une app, c'est au niveau des images. En fait, si tu ne mets pas le content description, et que ton image véhicule l'information principale, ton utilisateur peut pas, par exemple Vente Privée, j'en avais parlé avec Céline, si tu testes Ventes Privées avec TalkBack, tu es incapable de savoir quelles sont chacune des ventes parce que c'est que des images et tu sais pas si c'est une vente Adidas ou Nike. Donc, tu utilise pas du tout. Ça sert à rien quand tu passes dans l'app, et ca te dit "sans libellé".
François:
C'est ça, c'est un peu là où on arrive aux solutions qui marchent bien et ce qui fonctionne bien au niveau accessibilité c'est aire des choses systématiques, des solutions et des outils qui sont applicables partout. Par exemple, tout ce qui est images, dans notre API, quand tu récupère un objet image, tu as un champ, qui s'appelle alt, qui va contenir ou non une description, si c'est adapté ou pas. Et derrière quand on appelle imageView.load, on a une extension de méthode pour faire le load pour mettre les drawables et aller lire ce petits champs pour mettre la content description par défaut. C'est ce genre de démarche qui marche bien.
Fanny:
Tu es obligé d'y penser, je trouve que c'est un truc qui est pas mal qui ont été pensé sur Compose. C'est que quand tu fais une image par défaut, tu es obligé de mettre Content Description. Et si tu veux que TalkBack l'ignore, tu mets null. Alors si tu sais pas ce que c'est, une Content Description, tu vas dire ça me fait chier, je met null, mais en fait non. Il faut se dire, bon alors la c'est mon image et puis je vais juste dire à une personne qui est non-voyante si c'est un chien, c'est un produit, un produit A, une vente sur Adidas, etc.
François:
On essai d'être encore plus plus automatisé que vas forcément y penser. C'est que par défaut si tu fais rien sur ton objet image de façon à récupérer la valeur alt et ça va la mettre sur ton image.
Fanny:
Car c'est comme que vous l'avez fait. Ça marche.
François:
Effectivement, sur Compose, c'est pas mal. Je suis en train de bosser pour passer notre application à Compose. Et donc forcément notre propre implémentation de Image pour loader nos objets et ainsi de suite. Je laisse le champ Content Description sans valeur par défaut. Donc, c'est à l'appelant de faire le choix.
Fanny:
Du coup, tant qu'on est sur Compose, qu'est ce que tu penses à l'heure actuelle du niveau d'accessibilité de la version bêta de Compose?
François:
En fait, jusqu'à la première bêta, tu regardais le code Compose, tu cherchais pour TODO, et tu avais un peu partout TODO Accessibilité. Donc là on est à la bêta 7 à l'heure ou on enregistre je crois. Ça avance petit à petit. ils sont en train d'ajouter des choses. Là, ils ont ajouter la possibilité de renseigner le nombre d'items dans une lazy liste, équivalent Compose RecycleView. Ça avance petit à petit. C'est encore les débuts l'accessibilité sur Compose. Normalement, tout ça, j'espère, je ne vois pas sortir une version sans ça, ça devrait être fixé d'ici la 1.0.
Fanny:
J'espère aussi. C'est juste les pré requis. Mais effectivement, il y a encore quelques petites choses qui n'ont pas été pensées. En tout cas, si on peut aussi faire un apparté Compose et SwiftUI, je trouve que par contre, avec Compose, c'est beaucoup plus simple de faire des composants accessibles par rapport à avant en XML, du coup sur un Android, ou on faisait des Custom View et se retrouver facilement dans des cas non accessibles. La avec Compose, c'est beaucoup plus simple. Quand je pense que tu es d'accord. Et sur SwiftUI, c'est assez simple, tu rajoutes juste une propriété et ça prend 2 3 lignes, tu as 4/5 paramètres à connaître. Et voilà.
François:
Oui, c'est vrai que tout ce qui était checkables par exemple, c'est super facile à ajouter. Après ça reste le problème, ça prend 2 secondes, mais il faut penser à passer les deux secondes à ajouter ça.
Fanny:
Moi, je sais que dans mon ancienne équipe, c'était le truc quand je faisais mes revues de code je sais que moi j'y pense, mais mes collègues n'y pensaient pas forcément. Et du coup, quand je faisais les revues de code, je me disais que les autres vont se focus sur sur le reste du code. Et du coup, moi, je vais vraiment avoir un warning dans ma tête. Si je vois une image, je regarde si il y a le Content Description. Si je vois des trucs qui se superposent, je fais gaffe à l'ordre d'affichage, etc. Il faut juste qu'il y ait au moins une personne qui l'ait en tête, que ce soit dans une definition of done pour que ça devienne un peu plus automatique comme réflexe.
François:
C'est ça. Et après? Il y a aussi des choses qui sont gérées par défaut sur Compose. C'est selectable je crois sur Compose.Et du coup, si tu déclare un élément selectable, pour le déclarer ou rajouter un modifier selectable, c'est ce que tu vas vouloir faire pour n'importe quel checkbox juste pour qu'elle fonctionne bien, un peu gratuitement quand tu fais ça de façon bien.
Fanny:
Ça marche donc là, dans les erreurs courantes, on a parlé des descriptions au niveau des images. Ensuite, on a parlé quand tu fais des composants custom type checkbox, switch. De bien penser à overrider le comportement pour que ça fonctionne avec l'assistant. Est-ce qu'il y a d'autres cas comme ça ?
François:
Ça va être un peu plus spécifique, mais tout ce qui est uniquement compréhensible si tu vois l'écran, je vais donner un exemple ça va être plus clair. C'est par exemple qand tu as un prix, ou tu vas avoir des promos, tu auras un prix barré et un prix non barré. Par défaut, quand tu le lis, via TalkBack tu vas avoir un prix après l'autre. Et aucun moyen de savoir lequel, lequel est barré, lequel n'est pas barré. Donc, quel est le vrai prix de l'objet? A une époque, il avait essayé de régler ça au niveau Talkback. Ou tu avais le timbre de la voix qui changé suivant c'était en gras. Oui, je pense qu'ils ont vite abandonné l'idée. ça ne marchait pas si bien que ça pour les utilisateurs.Du coup, c'est un cas tout bête? Au final qui arrive assez souvent? Ça a beau être une TextView, il faut quand mettre une TextView, il faut quand même mettre une Content Description différente du texte de base et avoir encore une fois ça c'est un prix normal, prix actuel...
Fanny:
Sur ce cas là, c'est de se dire quand un élément, que ce soit comme tu dis, textuel ou images, qui a un contexte qui est implicite ou une manière ou un final tu ne lierais à voix haute la même façon que c'est matérialisé à l'écran comme là, tu ne dirai pas prix barré, Totaux 10 euros, et prix réel 5 euros. Et encore que là, tu vois, comme tu dis Talkback n'est même pas capable de véhiculer prix barrés. Et là, du coup, ces cas là il ne faut pas hésiter à se dire je vais donner plus d'infos. Pareil, des fois, tu vois au formatage de prix, faut peut être essayer de bien checker. Ça va bien, ça va bien bien de manière logique ou je sais que sur iOS avec SwiftUI, j'avais du override, on afficher une heure, et avec VoiceOver au lieu le dire 10H40, il disait 10 de points 40. Du coup, c'est un peu dommage et ça prend une ligne de code de dire en fait la mon élément texte pour VoiceOver, tu vas juste le dire de manière plus lisible en disant heure au lieu de deux points.
François:
Malheureusement, il y a des cas particuliers comme ça ou Talkback et Voiceover se prennent les pieds dans le tapis.
François:
Et donc un cas sur lequel il y a quelques années, je sais pas si ils l'ont réglé depuis, mais à l'époque où on avait les actions Material qui étaient tout en majuscules, Talkback va lire ça une lettre à la fois, comme si c'était un acronyme.
Fanny:
Je ne pense pas qu'il fasse ça encore. Il fait encore ça Talkback?
François:
Je ne sais pas du coups. On est passé en Pascal case pour toutes nos actions il y a un moment. Dans tous les cas, on a pas ce problème là. Maisc'est un truc qui est arrivé il y a quelques années, c'est un petit peu ennuyeux. Une fois que tu le vois, soit tu demandes aux traducteurs de faire un autre texte juste pour cela soit tu le fais de manière un peu brutale en repassant automatiquement en small case. Et espérer que ça ne pose pas de problème.
Fanny:
Moi j'ai deux cas encore en tête, j'aimerais bien discuter de toi, voir si toi aussi tu les a rencontrés dans d'autres situations. Il n'y a pas longtemps, j'ai rencontré un cas ou dans une liste, la manière dont ça avait été codé, quand tu as un petit toggle sur une liste pour avoir plus d'informations et quand le toggle était activé, on faisait sur Android, un dataChangeForItem pour que le RecyclerView recycle l'item et le regénère. Et du coup, TalkBack perdait complètement le focus et on se retrouvait en fait nulle part. Est ce que toi, moi j'ai rapidement corrigé ce truc là? On ne va pas recycler, on ne va pas appeler cette méthode là. On a juste fait un beau if/else sur le clic du bouton. Et puis, rien changer à ce moment là. Est ce que tu as déjà vécu ça ou dans un scénario tu as une perte de focus et tu dois soit venir dire à Talkback, en fait, set le focus à tel prochain item, ou alors tu as changé ta façon de coder pour pas avoir ce souci là.
François:
Le focus pour la peine c'est un sujet assez large. Du coup, c'est un concept un peu complexe et un peu artificiel quand on utilise juste l'application avec ses doigts. Quel objet est focus quand de toute façon, je vois l'application peu importe. Par contre, c'est super important quand tu es non voyant. Et ça peut devenir rageant quand tu appuies sur un item de ta liste et hop tu étais à l'item 103 et bim tu te retrouves à l'item 1. Déjà de base, il y a assez peu de cas ou j'aurai meme envie de dire aucun cas ou on a vraiment envie d'appeler notifyDatasetChange. J'ai envie de dire DiffUtil est votre ami. On a un adaptateur qui, par défaut, fait le taf pour nous. On lui soumet une nouvelle liste et il va la soumettre à DiffUtil, de renvoyer les résultats ainsi de suite. Encore une fois, ce qui marche super bien dans tout ce qui est accessibilité, c'est d'avoir les outils qui donc soumet automatiquement derrière et avoir quelque chose qui marche quasiment tout le temps. Et ça va régler pas mal de problèmes niveau list. Du coup, DiffUtil si il est bien setté bien. Tu as une liste dans un premier état, tu envoies une second liste à un RecyclerView, tu l'as passe via DiffUtil, et diffUtil va générer une liste de changement: il y a une liste qui a été insérée ici, il y en a une autre qui a bougé de là à là, ce qui va faire que le ReclyclerView ne va pas perdre le focus et va juste ajouter dynamiquement insérer de nouveaux éléments là ou il faut. Ça marche super bien. Et en plus, juste avoir une expérience un peu raffinée on va dire, juste avoir les items qui s'anime en place au lieu d'avoir un flash, c'est pas mal.
François:
Ça déjà ça règle pas mal de problèmes de focus. Même si ça arrive parfois de devoir un peu corriger des petits bugs RecyclerView quand on a des cas particuliers. Par contre, ce qui est plus complexe, c'est quand on va commencer à avoir des écrans les uns au dessus des autres. Ah ça, ça arrive souvent quand on a des dialogs, surtout les dialog custom, parce que ceux qui sont créés par le système, le système va creer une nouvelle window juste pour cette dialog là. Donc Talkback est assez intelligent pour isoler cette nouvelle window et juste avoir le focus dessus. Tout ce qui est fait à la mano, les gens de le font pas comme ça. La solution simple, c'est juste de générer un dialog pour ça. Dès fois ce n'est pas toujours possible. Si t'as une petite bulle d'explication collée à un élément de on UI, si t'as un dialogue qui apparait en bas qui est swipable, des choses comme ça, c'est un peu plus compliqué. Et là, quand il faut mettre en place des solutions un peu systématique pour gérer le focus. Quand mon dialogue arrive, je vais focus sur le titre du dialogue. Et c'est là où j'ai dû écrire le plus de code custom pour tout ce qui est accessibilité, surtout encore une fois on récupère une codebase qui n'est pas 100% accessible de base. Donc il faut un peu gérer ça, donc il y a des cas où clairement je vais juste parcourir ma liste de vues. Je ne la recommande pas forcement, et faire en sorte que certaines parties de l'arborescence ne sont plus focusables, Tout ce qui est focus, c'est vraiment ce qui est le plus compliqué à gérer.
Fanny:
Je trouve aussi et il est intéressant ton en exemple sur les dialogues, du coup. Effectivement, c'est un cas où, justement, quand vous allez afficher une modale ou une dialogue qui va prendre le dessus sur l'application, veuillez bien vérifier que le focus suive et en même temps que le contenu derrière n'est plus focusable. Quand on va utiliser des choses custom, ça va souvent être une erreur assez classique. C'est que du coup, l'utilisateur avec TalkBack ou VoiceOver, peut être qu'on va bien mettre le focus sur la modale ou sur le type de mémoire comme tu dis, mais potentiellement, en swipant, on va pouvoir accéder à ce qui est affiché dans la vue de derrière. Et là, ça devient très, très compliqué à comprendre ce qui se passe.
François:
Quand tu ne vois pas l'écran, c'est un peu compliqué de voir ça. Tu n'a rien à voir. Et pour la peine, c'est une classe de bugs ou malheureusement on en a régulièrement en audit. Et surtout ce n'est pas des bugs d'accessibilité. Parce que quand tu as ce bug là, tu peux passer ton doigt sur l'écran sans savoir TalkBack activé et déclencher les clics sur les éléments en dessous de ce que tu as au premier plan. Ce qui est, ce qui peut être ennuyeux suivant ce que tu as en dessous. Et pour la peine, ce sont des bugs que nos auditeurs d'accessibilité qui ne remonte ça, et au final c'est des bugs qui qui touchent tout le monde et qu'on veut régler parce que par exemple nous on ne veut pas que les gens retirent des choses de leur panier sans le vouloir ou en général ou commande sans le vouloir ainsi de suite. Tu veux pas que les gens, par erreur, activent des bouts de UI invisibles.
Fanny:
C'est dans le cas où tu es sur une modal, mais je sais qu'il y a pas longtemps, j'ai corrigé un soucis ou on mettait une custom view par dessus une vue et en fait tu ne voyais pas que tu avais ta main view en dessous. Donc, c'était vraiment un problème uniquement pour l'accessibilité puisque de toute façon, elle n'était pas capable, tu avais un fond blanc avec du contenu. Sauf que avec TalkBack, tu accédais avec le contenu derrière. Je pense qu'on a fait quand même pas mal le de gérer l'ordre des éléments. Est-ce que tu as un exemple, un cas concret à expliquer où on doit faire attention à certaines choses,
François:
Ou alors pour la peine. Donc, je disais plutôt que tout ce qui l'accessibilité, c'est un peu subjectif. Et là, pour la peine, quelque chose qui va t'être remonté par les auditeurs de manière, voilà c'est quelque chose sur laquelle on peut discuter, c'est souvent très subjectif. C'est qu'elle doit être l'ordre des éléments à l'écran. Sachant que encore une fois, ceux qui n'ont jamais utilisé TalkBack, ou les services d'accessibilité en général, parce qu'il y a TalkBack et les services où tu vas parcourir ton écran en appuyant sur un bouton pour dire je vais vers l'avant, vers l'avant, ... Et donc, si tu a une UI, je parlais de Panier un peu plus tôt, donc mettons tu as un panier avec ta liste d'achat et que tu as 50 items dans ton panier, tu arrives tu es focus sur le titre du Panier et tu veux aller sur le bouton Commander, voilà qu'elle doit être l'ordre pour aller jusque là. Est ce que tu dois parcourir toute ta liste pour aller sur tous les items? Tu les as ajouté au panier tu sais déjà ce que tu as dedans. Pour arriver tout en bas sur le bouton Commander. Est ce que tu veux au contraire que ce bouton soit accessible de manière un peu plus facile, par exemple? Tu peux un peu truander avec l'ordre des vues. Donc, soit c'est juste après le titre, soit c'est juste avant le titre. Et si les gens fouillent un peu quand ils sont en mode accessibilité, car ils sont un peu débrouillarde, et vont un peu chercher comment sont les choses, vont se rendre en compte qu'ils peuvent aller en arrière et être directement sur cet objet. On peut faire les choses comme ça pour rendre l'application accessible. Et quel est l'ordre parfait? C'est entièrement subjectif.
Fanny:
Ça va dépendre des situations. J'ai le même cas de ce que tu dis. En gros, quand tu es dans une app Android avec un FAB button, le bouton en surposition en Android, comme tu le dis ca pourrait etre ton bouton Valider ta commande, n étant une N'apprends 1 beta sur Android, le coutand en superposition, comme tu dis, ça pourrait être ton bouton valider ta commande, et au final, si tu veux, si, si tu laisses TalkBack ou VoiceOber, il va lire dans l'ordre d'affichage du haut vers le bas, il va le lire en dernier, alors qu'effectivement, peut être rien à foutre de tout entre tous tes items. Je pense qu'ils sont débrouillards les utilisateurs non voyants, mais pas tous, et je pense qu'il y en a aussi qui sont qui ne sont pas très geek et qui sont peut être du coup freiné par des usages aussi complexes de savoir qu'en fait, si tu tombes en arrière dans ta stack, au bout d'un moment, tu vois arriver au dernier élément de ton écran et tu vas pouvoir naviguer de bas en haut. Je trouve ça assez finalement complexe dans la logique. Du coup, ça, c'est un cas super intéressant de se dire est ce que pour quelqu'un qui utilise TalkBack ou Voice Over, je vais inverser l'ordre des éléments. Du coup sur Android c'est simple ou pas?
François:
C'est relativement simple. La qualité de TalkBack a beaucoup augmenté. Au fil du temps, ça reste un des cas sur lequel TalkBack ne veut pas nous aider et il faut un peu changer la définition. C'est des trucs encore un peu buggué parfois. La plupart du temps, ça ne marche pas trop mal.
Fanny:
Oui, ça marche. Ça, c'est un truc que j'ai testé, par contre avec Compose, qui n'a pas encore été prévu de pouvoir influencer l'ordre des éléments.
François:
J'ai l'impression, oui, parce que on a la possibilité de changer le focus sur Compose. Alors je sais pas. C'est moi qui suis mal pris, mais pour le moment je n'ai pas réussi à utiliser ça.
Fanny:
Et effectivement, ils savent pas encore comment le faire. Sur iOS, je trouve que c'est plutôt pas mal fait. Sur Android, la version XML, du coup, sur ton élément que tu voulais changer d'ordre, tu pourrais facilement le faire, en tout cas dans le XML si tu n'avais pas un cas trop complexe, en disant maintenant, tu vas venir le lire avant tel Éléments et après celui là. Sur iOS pour, je pense, éviter que les gens manipulent l'arbre d'ordre des éléments, tu viens affecter un poids sur ton composant. Tu vas dire celui là son sort priority c'est 5. Celui là, c'est 4. Celui là, c'est 3. Puis à mon avis dans la algorithm du coup, quand il va générer l'arbre d'ordre des éléments, il va d'abord faire attention à la priorité et puis trier de haut en bas. Ceux qui ont la priorité 5 pour les dire en premier, puis ensuite ceux qui ont la priorité 4 de haut en bas, etc. Du coup, t'as pas, t'es pas obligé de venir dire ça avant ça ou après ça. Je pense que c'est une sécurité qui ne fait pour pas trop donner la main aux devs. Mais c'est assez simple, même si parfois tu te retrouves dans des cas un peu compliqué où tu aimerais bien pouvoir pouvoir dire lis moi ça après ça et tu galère avec tes différentes couches de vue, de te dire on va faire mieux, mais on verra comment ça sera possible de faire ça sur Compose.
François:
je sui sur qu'ils vont prévoir quelque chose pour qu'on puisse fait ça.
Fanny:
Oui, il faut qu'ils prévoient. C'est vrai que le cas que tu expliquais, tu te retrouves, ça va. C'est le cas entre guillemets positif. Si tu as 5 items dans ton panier, ça va, tu travers tes 5 items et tu arrives sur ton bouton Valider ton Panier, et ça va plutôt bien. Si tu commences à avoir 100 items ou une liste infinie, tu n'arrives jamais au bouton, sauf si tu es un geek et qe tu sais que tu peux revenir en arrière pour y accéder.
François:
C'est ça, c'est la ou il y a des choses un peu plus compliquée. Et après aussi, pour tout ce qui est ordres des vues dans TalkBack. Le second cas, c'est simplement quand tu as une vue, qui est un ViewGroup, qui contient contient plusieurs vues, Est-ce que l'ordre par défaut que TalkBack va utiliser est celui que je veux. Par défaut TalkBack va lire deux en haut à gauche, un en bas, à droite. Ça marche la plupart du temps et de temps en temps, suivant comment tu as architecturer ta vue tout simplement, ça va pas forcément entre ce que tu veux. Ça va. Du coup, ça va donner une vue pas ultra facile à comprendre. Si voilà deux parties d'un texte qui ne sont pas mis dans l'ordre, c'est pas ultra facile. Tu peux le faire avec Accessibility Traversal Before After. Si la vue est vraiment importante pour le business, la vue principale application qu'on retrouve partout où la vue la plus portant ainsi de suite, ça peut voir le coup juste pour cette vue là de construire directement un Content Description de zéro ou on un truc un peu mieux fait, qui ajoute du text si il le faut, qui rajoute du contenu pour la vue.
Fanny:
Tu vois, la dernière fois, j'étais sur un élément, en gros, je suis en train de travailler sur l'accessibilité d'une appli en France qui s'appelle ViteMaDose, pour savoir les centres de vaccination ou trouver une place, tu as du en entendre parler. Et je m'étais dit tiens, sur chaque élément de la liste, t'as une liste et ça dit les créneaux disponibles et je me suis dit ça serait cool sur chaque élément de la liste, je double tape et ça clique sur le bouton "Prendre un rendez vous" qui fait partie de l'item de la liste, tu sais. Et j'aurais bien voulu, c'est la première fois que ça m'arrive, mais j'aurais bien voulu remplacer la phrase par défaut qui dit "double tap to activate" ou "tapez deux fois pour activer" par "taper deux fois pour prendre rendez vous". J'aurais peut être dû faire effectivement un composant custom pour venir ajouter du contexte un petit peu avant ou un peu après. Je n'ai pas trouvé la notion de hint. J'ai l'impression que sur Android, tu peux mettre un content description, ou ton texte par défaut si c'est un texte, et tu peux mettre un hint quand il s'agit d'un edit text. C'est une sorte d'indice qui te dit, c'est ton placeholder quoi. Il me semble que sur iOS, tu peux mettre un hint sur chaque élément, et le hint va s'énoncé à la fin par VoiceOver. J'aurais bien voulu mettre un hint sur un composant sur lequel j'étais pour lui dire bah, en plus de tout ce que tu dis d'habitude. Bah, rajoute un indice entre guillemets pour dire tiens, si tu double tap, ça va prendre rendez vous.
François:
Ça me parle. Je sais que si tu édite directement les noeuds d'accessibilité, je pense que comme ça, je pense qu'il y a un paramètre hint. Par contre, est ce que il va être énoncé pour n'importe quelle vue? Si tu set? Ou est ce qu'il faut en plus que le paramètre labelFor qui soit setté ? Si ce n'est pas le cas c'est peut être juste un Content Description.
Fanny:
Tu viens l'enrichir en fait. En plus tu vois moi je m'étais dit je vais grouper le contenu de toute ma liste et je ne m'étais pas trop embêté. J'avais mis important pour Accessibilité, etc. Et ça, ça regroupé tous les éléments et je pense que du coup, si je veux vraiment aller plus loin, cela dit, comme tu dis construire une Content Description qui va reprendre tous les éléments de ma cellule et qui, en plus, va rajouter à la fin la phrase "tapez deux fois pour prendre rendez vous." ou une information qui va dire quand tu actionnes sur cette cellule, ça va faire cette action là.
François:
Sachant que, il y a tout aussi une info sur lesquels ce que les utilisateurs que moi j'ai et les auditeurs me rapportent, que dans la pratique ça ils ne font pas trop attention, c'est tout ce qui est quand TalkBack va te dire button à la fin de quelque chose, ou Switch, ...
Fanny:
Ils vont prendre la note,
François:
Ils ont le "double tap to activate", ils savent qu'ils ont un button. Ils s'en fichent que TalkBack... ce qui tombe bien parce que Talkback le fait très mal ça.
Fanny:
J'ai l'impression qu'il ne te le dis pas systématiquement en fait, le type.
François:
Dans mes souvenirs comme ça implémenté, il faut que tu renseignes, que tu overrides quelque chose comme classe pour accessibilité où toi tu donnes Android.widget.Button, ... et même comme ça, je ne suis pas sur ce que ça marche tout le temps et du coup je m'étais demandé si cela valait le coup de le fixer. On m'a dit de toute façon, ne t'embete pas avec ce point en particulier.
Fanny:
Ça marche, un autre truc dont je voulais parler. Je pense que c'est le dernier truc qui nous reste à voir en termes pratiques. Tu as parlé tout à l'heure de headings? Voilà ce que tu utilises, c'est un truc qui est déjà arrivé il me semble sur Android que sur iOS donc tu peux activer, il en parlait la dernière fois. Manuel, le rotor qui lui permet de dire là quand je swipe de gauche à droite, ça me permet de passer en heading en heading, ils ont même en plus sur iOS, ce qu'on n'a pas encore sur TalkBack, c'est la notion de container, pour pouvoir passer de groupes de groupe en groupe. Et tu pourrais du coup découper ton écran en plusieurs zones et pouvoir facilement naviguer. Au final, tu vois le cas que tu expliquais tout à l'heure avec ta liste de courses et ton bouton commander, on pourrait les mettre dans des containers différents et pas s'embêter en fait influencer l'ordre de lecture et se dire en fait c'est un autre conteneur. S'il veut, il pourra trouver un geste rapide pour passer à l'autre conteneur. Sur Android, toi, tu commences à utiliser un petit peu ces comportements rapides pour passer de titres en titres ou vous n'avez pas forcément le cas d'usage.
François:
Si, justement, c'est quelque chose que j'ai ajouté il n'y a pas super longtemps. Je suis aussi un des mainteneurs de notre lib de design, ce qui d'ailleurs, au passage pour l'accessibilité, c'est extrêmement utile pour rendre l'application accessible parce que je peux faire en sorte que tous mes widgets soient accessibles, soit par défaut, soit facilement accessibles. Et en autre dans sa bibliothèque de widgets, on a ce qu'on appelle un titre de section, un heading, et du coup, que ce soit sur Compose, sur le framework legacy, déclarer que c'est un heading. Ca prend un ligne.
Fanny:
Du coup, j'imagine, vous avez un design système, les dev qui va venir copier coller, il sait qu'il fait un composant qui ressemble à ç&, c'est heading, il copie/colle c'est ça. Oui, c'est induit d'accessibilité. Parce que toi, tu l'a prévu en amont, dans le design system
François:
C'est ça. Nous derrière on va créer une nouvelle feature. Le designer est fortement encouragé à utiliser le Design Syste, et les élémnts qui viennent du Design System. Du coup, quand le développeur doit récupérer le figma avec la nouvelle feature, il va cliquer sur un élément, voir que c'est un section Title Type A par exemple. Et donc, du coup, il va prendre notre Design System, pour le Section Title Type A. Et ça va faire tout le taf automatiquement, il va être déclaré comme un heading, sans rien à faire. Si on un switch pareil. Ça fait le travail pour déclarer checkable, et reporter l'état. Niveau efficacité, ça aide beaucoup. De pouvoir juste prendre un figma, avoir l'élément du Design System à utiliser, prendre l'élément du Design System, ... c'est à la limite du Drag n Drop.
Fanny:
Une dernière question au sujet des images. Je me pose souvent la question : est ce que cette image je devrais la masquer ou pas? Tu parlais par exemple des animations Lottie. Est ce que je mets un contentDescription ou est ce que je la masque ? Et j'ai l'impression qu'il faut toujours se poser la question. Il n'y a pas une réponse unique.
François:
Oui, c'est un peu pour ça que suis toujours dubitatif par rapport aux solutions qu'on propose par des tests d'accessibilité automatisés parce que oui ton bot d'accessibilité ne va pas comprendre le contexte et du coup pour ce qui est de l'accessibilité et surtout les images, bah oui, c'est le contexte qui va te dire si t'as besoin de contentDescription ou pas. Donc pour les images, tu as de manière générale 3 gros cas : l'image qui va décrire toute chose d'important et qui ne va pas être dans un texte autre part.Je reprend l'exemple des objets achetés. Si tu as une image de bananes et qu'en dessous tu as une TextView qui dis "Bananes", alors pas besoin de contentDescription sur l'image.
Fanny:
Tu vas juste la masquer pour que ça soit ignoré par Talkback.
François:
C'est juste de voir si Talkback, si on met "non important pour l'accessibilité", voilà pour quelqu'un qui ne peut pas voir l'écran, ça fonctionne aussi car le nom est écrit. S'il n'est pas écrit vraiment, il faut une contentDescription. Et le dernier cas, c'est aussi avoir des images simplement décoratives. Si j'ai par exemple, une petite flèche pour dire que si j'appuie ça va aller autre part, ou voilà des choses comme ça vraiment comme un pictogramme qui, au final, n'apporte pas vraiment d'informations par rapport au texte.
Fanny:
Par exemple c'est écrit date de naissance et tu as un pictogramme avec un petit gâteau d'anniversaire à côté ?
François:
Voilà. Ou si tu as option tu as une petite roue dentée à côté, c'est joli, mais niveau accessibilité, ça sert pas beaucoup. Donc non, ça, ça, oui tu peux directement le masque. Par contre la difficulté on en a discuté c'est que effectivement, c'est quand toi tu as implémenté ta vue tu dois te poser la question dans quel cas etc.
Fanny:
Il y a un truc que je fais, que je ne vois pas beaucoup. Et je pense que je ne sais pas si l'usage existe vraiment. Mais quand j'ai une image avec un texte associé dans certaines situations, je vais les grouper plutôt que masquer l'image parce que je me dis que quelqu'un qui est malvoyant, mais qui voit encore mais peut-être qui perd la vue pour quelconque maladie, par exemple, il peut utiliser potentiellement Talkback quand il est fatigué ou quoi. Et il va voir l'image et la tête et peut-être vouloir taper dessus et qu'il utilise Talkback comme une aide. En fait, je me dis ça doit être frustrant de voir quelque chose qui prend beaucoup de place sur l'écran, de taper dessus pour savoir ce que c'est. Et en fait, le focus ne se met pas parce que toi tu as mis dans le code que ça n'était pas important pour l'accessibilité. Donc je sais que les cas où j'ai une image et que dessous j'ai forcément un sous titre, je vais les grouper puisque ça ne prend pas beaucoup de lignes de code. Et alors je gère le corner-case ultime d'une personne qui pourrait utiliser Talkback dans ces cas là. Je ne suis pas persuadé que ce que ça représente vraiment beaucoup d'utilisateurs, c'est surtout de l'UX, c'est pas ça qui va faire que l'application ne sera pas accessible, c'est juste un confort en plus.
François:
Après un petit confort comme ça, ça peut être intéressant pour l'utilisateur aussi. Moi, j'avoue je le ne fais pas.
Fanny:
Ouai mais en fait tu sais je teste des apps, je teste beaucoup d'app pour me dire "Tiens, qu'est ce que font les autres?" Et je le vois très peu, donc je sais pas si c'est moi qui me suis mis cette lubie en tête parce que j'ai travaillé avec une personne qui était ce dans cette situation là? Et du coup, je pense que c'est un petit plus qui va améliorer l'expérience mais qui n'est pas ultime.
François:
C'est un petit plus, mais encore une fois quand on parle d'accessibilité, c'est sûr qu'on voit imagine tout de suite une personne aveugle. Même si dans la réalité, c'est extrêmement large, c'est sûr il y a des cas comme ça qui existe aussi.
Fanny:
Du coup pour revenirsur la partie visuelle. Est ce que tu testes InstaCart avec un niveau de taille de polices différentes, de tailles des éléments ? Je sais qu'il y a justement une distinction sur Android qu'il n'y a pas sur iPhone il me semble où c'est juste un niveau de zoom global.
François:
Oui. Du coup, on a on a deux choses Android. On a le display size. Du coup, ça va changer la densité de l'écran. Dans la pratique, c'est comme si on avait moins de pixels sur l'écran, parce ce qu'il est moins dense. Et du coup, ça va faire que tout est beaucoup plus gros. Et donc, au final, ça teste juste : "Est ce que mon UI elle s'adapte bien quand j'ai un écran plus petit". Donc ça en général, c'est quelque chose si on a suffisamment de ressources c'est quelque chose qu'on va avoir fait dans tous les cas. Donc si quelqu'un utilise ce settings, c'est comme s'il avait un petit téléphone. Du coup, normalement tout va bien se passer et après, il y a tout ce qui est taille de police. D'ailleurs, c'est là où composes est un peu plus pénible. Enfin bon déjà tout ce qui est taille de police c'est ce qui va faire que tout ce qui est texte va devenir plus grand ou petit suivant le choix utilisateur. Dans le framework legacy, c'est super simple à implémenter. Si vous avez une taille de texte qui est juste dans un wrap_content, de tout façon ça sera fonctionnelle. Et si vous avez pour une raison X ou Y, qui dit que cet écran doit faire 80 dp de haut, même si Android va se plaindre il faut mettre 80 sp de haut à la place, parce que sp c'est les scale pixels et c'est ça qui va changer son accessibilité. Donc c'est aussi vous faites que la taille du conteneur change aussi dynamiquement. Même si android le lint va pas être content.
Fanny:
Attend, j'inverse les deux du coup, je m'embrouille : dp C'est ce qu'on utilise en général pour tout ce qui est widget et sp pour les fonts. Et donc ce que tu dis là c'est que si t'as un container avec du texte et que tu veux qu'il scale bien et n qu'il y ait pas ton texte qui déborde en fait tu mets la même unité que ton texte ?
François:
C'est ça, pour la hauteur de ce widget ! Bon pour la largeur à priori y'a pas de soucis quand on match_parent, match_constraint et ainsi de suite. Pour la hauteur par contre, on veut pas arriver au cas où le texte devient beaucoup plus grand mais que le conteneur reste à la même taille et du coup ça tiens pas dedans. Voilà c'est pas esthétique et dans les cas extrême c'est pas lisible. Et juste avoir le conteneur qui, au lieu de faire 80 dp de haut fait 80 sp, bah oui en fait cette notion de sp qui veut dire "scale pixel" c'est comme ça que le framework fait en sorte de changer les tailles de texte. Et du coup, si le conteneur est aussi scale pixel, il va s'agrandir et ça va bien fonctionner. Ca par contre, c'est un truc un peu plus pénible à faire avec Jetpack Compose.
Fanny:
Ah ouai ? Justement tu disais avec Compose c'est pas simple. Pourquoi ?
François:
C'est pas la mort non plus, Compose il va accepter des taille en "dp". Ici dp c'est une inline classe, au final c'est un long derrière. Du coup a la compilation il va pas apprécier qu'on lui envoie une taille en sp. Du coup, il faut passer par une composition locale qui va te fournir la densité. A partir de la densité tu peux prendre ton sp et le transmettre en dp. C'est un peu verbeux.
Fanny:
Ok "Composition locale". Ce genre de chose, sur iOS ça m'est arrivé de le faire. Il me semble qu'au niveau de l'environnement, en tout cas avec SwiftUI, tu peux récupèrer @Environment(\.sizeCategory), et tu peux savoir quel est le niveau de zoom qui est sélectionné dans tes settings. Et tu fais un gros if else "si t'es inférieur à la taille XL alors tu mets autant autant en taille, si t'es supérieur, mais tu changes". Du coup, c'est ce que tu dis qui est faisable en compose c'est ça ?
François:
Heureusement c'est encore plus simple quand même en compose. Tu vas prendre la taille de texte, par exemple 16sp et par exemple tu vas faire, tu vas faire "with(localeDensity.current){" tu prends ta taille et tu fais toDp et il va te transcrire en une taille correspondante en dp dans la densité actuelle. Et ça c'est un objet qui est de type dp et du coup tu peux le passer sans problème.
Fanny:
Ca marche. Et en XML "la vieille façon mais que finalement tout le monde utilise encore hein ! Tu sais si c'est facile de récupérer un peu la densité actuelle de l'écran pour pouvoir faire un comportement custom, par exemple, si tu avais des éléments qui étaient sur un Quatre-Colonnes et que en fait, quand tu zoome, ça casse complètement les et que tu te dis, tiens, je les déplacent sur deux colonnes que je veux mettre à la suite? Tu sais comment faire ça?
François:
Alors du coup, attend du coup déjà le cas donc je je parlais pour la peine en XML, tu mets sp au lieux de dp et c'est bon. Le seul truc, c'est que si tu utilises lint, bon bah c'est un cas ou les lint bon ils sont bien intentionnés, mais qui ne sont pas super utiles. Il va se plaindre. Il va dire "tu as mis sp a quelque chose qui n'est pas un texte". Oui, c'est vrai. Mais voilà, il y a des cas où c'est tout à fait légitime. C'est la même chose le lint parfois il va se plaindre sur un contentDescription que tu as pas mis mais en fait, peut-être que tu veux pas le faire dans l'XML mais dans le code. Donc pour un bot lint c'est difficile de comprendre le contexte. Malheureusement, ça ne marche pas toujours super bien.
Alors pour parler sur des colonnes ?
Fanny:
Oui revenons à ce cas. En fait, en gros j'ai eu ce cas sur iOS, où j'avais des éléments où il était en 3 colonnes. Et en fait, en zoomant, ça a débordé. C'était plus du tout lisible. Il y avait plus de place pour voir les textes et du coup, justement, ce qu'on avait fait, c'était de se dire bien au lieu d'être sur 3 colonnes, si on est au dessus d'un niveau de zoom XXL, par exemple alors on passe sur 2 colonnes. Et quand j'ai fait la même vue sur Android, j'ai l'impression que c'est un problème qu'on a moins puisque au final, on a l'habitude de développer pour une variété d'écran des densités différentes. Et puis les contraint. layout etc. Vont peut-être faire que ça va mieux se comporter ? je ne sais pas, en tout cas, je n'ai pas eu le même soucis. Mais je suis quand même dit "tiens comment j'aurais pu faire si ça avait été le cas?". Et en fait j'ai pas trouvé d'équivalent au code que j'ai pu faire sur iOS.
François:
J'avoue que c'est quelque chose que j'utilise plus du tout maintenant mais qu'on peut faire en Android. Du coup, ça marche. C'est basé sur la taille d'écran. Et c'est "swdp" qui va regarder quelle est la plus petite largeur écran et en fonction cela te permet de détecter grosso modo les tailles d'écran. Et du coup, tu peux dire que l'image de base d'une colonne, par exemple, est si t'es à SW 600 dp ou plus tu peux adapter ton écran et ainsi de suite. Donc, si tu veux faire ça autrement moi j'utiliserai un constraint layout avec un flow qui fait que si ça déborde ça va retourner à la ligne.
Fanny:
Tu vois je pense que c'est pour ça que je n'ai pas trouvé la logique. Je me suis dit "sur iOS Je passais par les services d'accessibilité pour savoir quel étaitent mes réglages d'accessibilité, notamment c'était quoi le niveau de zoom". Tandis que sur Android, en fait, c'est une logique de se dire la densité de ton écran est la même et il suffit de la récupérer.
François:
C'est ça et pour la peine c'est un truc que android fait depuis android 1.0.
Fanny:
Ouai je suis en train de me rendre compte que c'était super simple à gérer.
François:
Par contre c'est vrai que c'est quelque chose où les designers ne sont pas forcément super attentifs. Souvent, ils ont une mentalité prints, où il y a une taille d'écran qui prenne en compte. "Et si j'ai un petit écran, j'ai un grand écran ?" Ça, c'est parfois chose un peu plus complexe à mettre en place.
Fanny:
Ça marche. On va passer à la partie accessibilité après le dev. On a parlé d'audit tout à l'heure mais avant ça est ce que vous automatisé des choses d'un point de vue accessibilité ?
François:
On a testé il y a quelques semaines une solution qui faisait des tests d'accessibilité. Pour nous, c'était dans l'optique de passer par un cabinet d'audit qui aurait mis en place ce type d'outils à notre place. On n'a pas été super convaincus. Donc pour le moment ce qu'on fait c'est des tests manuels et tous les trois mois on fait un audit. C'est un doute déjà élaboré et on s'appuie aussi beaucoup sur les retours utilisateurs.
Fanny:
Je pense que même pour les auditeurs, avant de penser tout de suite à la case audit, testé manuellement soi même, se faire un petit peu une idée de l'expérience, fermer les yeux comme tu disais et voir si ça fonctionne. Avoir des retours utilisateurs, si on en a. Par ce que l'audit, je pense que c'est un peu la case final car en plus tu vas passer par un cabinet extérieur donc ça va couter à l'entreprise, et si t'as pas encore testé ton application manuellement toi même bon...
François:
C'est sûr que si t'as pas l'échelle ou juste, pas encore le besoin d'avoir d'audit, oui, tester toi même. C'est comme ça que l'on remonte pas mal de cas, en plus android y'a un setting pas mal, tu appuies sur volume haut et volume bas et ça déclanche Talkback. Parce que j'ai pas envie de l'utiliser tout le temps, mais juste sur l'appli que je suis en train de tester. Je regarde si ça fonctionne bien sur tel écran, ça prend 3 secondes et hop.
Fanny:
Moi, ça m'arrive aussi quand je dois saisir quelque chose au clavier. Du coup, je fais exactement comme tu dis. Je désactive Talkback en appuyant sur volume haut et volume bas en même temps, je saisis mon truc au clavier, puisque je sais absolument pas bien le faire de cette façon là et après, je le réactive. Ou parfois je vais directement sur le bon écran. Parce que j'ai mes habitudes et je l'active. Sur iOS aussi il me semble qu'il y a aussi un raccourci assez rapide, peut être appuyé trois fois sur le bouton Home en tout cas c'est un raccourcis que l'on peut configurer.
François:
En plus, je sais que sur iOS on peut avoir aussi une petite bulle pour ça présente sur l'écran ?
Fanny:
Oui une petite bulle aussi loin que tu peux placer ou tu veux dans un coin.
Bon après si tu sais pas ça tu fais une recherche, de toute façon, tu va surement te retrouver à faire une recherche sur Google pour découvrir ce raccourci en mode "Comment je désactive Talkback ou voice over ?". Mais ce raccourcis en tout cas ça évite quand même d'aller dans les settings de ton téléphone, de démarrer. Savoir naviguer entre les apps, l'ouvrir. C'est quand même des usages un peu plus complexe que nous en tant que dev, je pense qu'il faut surtout savoir maitriser l'expérience dans l'app. C'est déjà une bonne chose.
François:
C'est ça. Et après? En plus de tester toi même, tout simplement avoir dans l'aide de ton app "problème d'accessibilité, contactez nous", ou accessibilité@taboite.com, c'est super facile à mettre en place également et ça va permettre de faire remonter des choses.
Fanny:
Et s'assurer que l'accès à cette feature soit facile et ne pas mettre un gros envoyer vers une Web view avec un Captcha qui ne sera pas accessible. Je sais que Céline en parlait au premier épisode, de dire "Parfois, il y a un formulaire pour pouvoir contacter, mais il n'est pas accessible". Compliqué de remonter les choses.
François:
Ouai Les captcha c'est compliqué malheureusement.
Fanny:
C'est clair. Ça fait déjà une bonne heure qu'on parle. Du coup, on va essayer de conclure. Et justement j'ai trouvé les retours de Manuel et l'expérience de Manuel est hyper intéressant puisqu'au final, je lui parlais beaucoup d'app :"Qu'est ce que tu utilises comme app?" Et lui a parlé beaucoup d'usages, finalement un peu externe. Tu vois les les innovations qu'il attend c'est surtout autour de la spatialisation, les lunettes, etc. Est ce que ce que toi ça t'as inspiré des choses ? Est ce que ça a révélé des choses ses échanges?
François:
Manuel J'ai trouvé ces remarques super intéressantes. J'ai été surpris car beaucoup de choses qu'il a dite c'est des choses que j'aurais dis également. Par exemple il disait que "l'accessibilité faut le prendre en compte au début du dev." Et oui tout as fait, j'ai trouvé que pour quelqu'un qui n'est pas du tout dans le code soit au courant de ça". J'ai aussi un peu regardé les lunettes dont il parlait. C'est pas mal !
Fanny:
L'application Microsoft : Soundscape. Il y a une petite vidéo super sympa où tu vois effectivement les éléments qui sont décrits. c'est inspirant.
François:
Oui, et je pensais que ces écouteurs, c'était tout ce qui est "transmission du son à travers les os". En fait non c'est encore mieux foutu que ça car c'est un petit haut parleur directionnel qui est pointé vers l'oreille.
Fanny:
D'accord donc ça vient pas perturber autour. Les gens n'entendent pas, en fait.
François:
C'est ça quoi les gens autour l'entende pas. Toi, tu peux quand même entendre ce qu'il y a autour de toi, ce que t'as pas quand tu as un haut parleur collé à l'oreille. Donc c'est vraiment des choses auxquelles on ne pense pas, mais qui sont super utiles pour les non-voyants.
Fanny:
Oui, c'est clair, moi j'ai hâte de voir tous ces gens qui commencent à travailler, qui continuent de travailler sur ces sujets là. Apple fait pas mal de choses. J'ai découvert qu'ils ont un outil sur Mac et il me semble sur iOS est ceci ou ça vient de numéroter chaque élément sur l'écran. Par la voix, tu vas pouvoir contrôler ce qui se passe, donc c'est pour une personne, du coup, qui a peut être plus l'usage des mains. Et du coup, qui va pouvoir dire "cliquer sur l'élément 1". Tu vois sur l'écran, ça ajoute une surcouche. 1, 2, 3, 4, 5, 6, 7, etc pour numéroter chaque élément interactif. Je trouve ça vraiment dingue. Ce niveau d'accessibilité, ce genre de choses que l'on peut fair. J'ai hâte de voir Google. Je pense qu'il y a encore un petit peu de marge.
François:
Oui, c'est ça un peu dingue. Je connais pas bien comment ça s'est goupillé, mais iOS a beaucoup d'avance.
Fanny:
Il me semble que dès le départ, est ce que j'ai entendu, ça a été pris en compte, en fait, les premiers iPhone. Il me semble que l'un des concepteurs devait être malvoyants ou non-voyants ou quelque chose dans le genre.
François:
C'est comme ça que je l'imagine en effet pour être honnête. Un heureux accident. C'est super. C'est dommage pour android. L'avance qu'ils ont depuis la version 1, android cravache un peu pour rattraper depuis.
Fanny:
Même tu vois sur un iOS, je sais que quand je développais, je regardais beaucoup les apps faites par Apple pour voir comment ils font. Quelle est l'expérience qu'il propose? Et c'était des bons modèles. Alors que sur Android, quand je me dis "tiens, je vais aller voir Google Calendar, comment ça fonctionne? ou même rien que les settings d'Android, comment ça fonctionne? Ils doivent utiliser les Headings car il y a plusieurs sections dans la liste" et non... ils sont même pas encore à ce niveau là. C'est rare que je crache sur Google,
François:
Mais parfois je me demande ce qu'il bricole. C'est clair,
Fanny:
Du coup, pour conclure si, si tu avais un conseil à nos auditeurs développeurs mobile Android, iOS doit vous retenir sur comment rendre leur app plus accessible. Ce serait quoi?
François:
Vaste sujet. Si, ils démarrent d'une application qui est déjà en place, et qu'ils veulent la rendre accessible, du coup, c'est un peu plus d'efforts que vous voilà que si ils partaient de zéro, bon là dans ce dernier cas l'app peut être 90% accessible avec très peu d'effort. Si, par contre, l 'app est déjà là où il y a des choix techniques qui ne sont pas toujours des choix techniques pour être efficace, et pas très compatible avec l'accessibilité. Bon là Prendre une demi heure pour lancer Talkback, apprendre à l'utiliser en 5 10 minutes, c'est pas très compliqué en soit. Tu balayes ton doigts sur l'écran pour savoir ce que s'est, tu double tap pour active voilà. Et voilà un peu tester leurs application, et pouvoir arriver à quelque chose d'un peu plus utilisable. Surtout qu'a priori, beaucoup, beaucoup d'applications. Surtout que derrière il y a des communautés et des utilisateurs des services d'accessibilité qui attendent de pouvoir utiliser. Ceux sont des utilisateurs comme les autres, si on regarde que l'aspect pécuniaire, qui on de l'argent, comme tout le monde et qui veulent le dépenser et c'estpeut être un moyen de se différencier facilement.
Fanny:
Ça marche. Super. Merci beaucoup, François. On se retrouve une prochaine fois, peut être dans un meetup ou une conférence. Merci à tout le monde. Aurevoir.
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 advanced search, transcribe multiple languages, upload many different filetypes, generate automated summaries powered by AI, and easily transcribe your Zoom meetings. Try Sonix for free today.