Paris Web 2021, l’édition en ligne
Nous étions à la 16e édition de Paris Web ! Crise sanitaire oblige, les conférences avaient lieu en ligne. Un Slack était accessible à tous pour discuter et poser des questions en direct aux conférenciers. Une organisation adaptée au thème de cette année : “Le Web en mouvement”. Retour sur les conférences qui nous ont marquées.
Section intitulée temoignagesTémoignages
Par Emmanuelle Aboaf, Raphaël Marcimain, Aurélie Renard-Vignelles et Céline Bœuf
La journée s’ouvre sur quatre témoignages de personnes en situation de handicap. Ces témoignages concernent les difficultés qu’elles rencontrent au quotidien sur le Web. Comme toujours à Paris Web, l’accessibilité est à l’honneur.
Aurélie est multi-DYS et TDAH, comme 7 millions de personnes en France. De ces handicaps, le plus connu est la dyslexie. Il touche Aurélie, ainsi que la dyspraxie, qui lui pose problème pour situer les choses dans l’espace d’une page Web. Par exemple, la présence de plusieurs colonnes posera problème, elle ne saura pas où poser les yeux. Idem lorsqu’un menu contient un sous-menu.
Elle encourage les développeurs de sites Web à abandonner l’utilisation de polices avec sérif (ex : Times New Roman) dans les textes et propose de privilégier des polices d’écriture sans serif, ainsi qu’un alignement à gauche plutôt que justifié.
Raphaël est malvoyant et autiste : les pubs, remplir un questionnaire, ou un texte écrit trop petit, sont autant d’obstacles pour sa navigation sur le Web. Il soulève également le problème des sites qui obligent l’utilisation d’un smartphone pour l’utilisation de leur service, comme WhatsApp sur navigateur. Cela ferme l’accès de leur plateforme aux gens qui n’ont pas de téléphone.
Pour en revenir aux menus, il encourage à utiliser un surlignage clair des menus actifs ou survolés, car il ne voit souvent pas le pointeur de la souris.
Emmanuelle est sourde et son principal souci se situe au niveau de l’accès aux ressources audio : notamment le sous titrage et les transcriptions écrites. Lorsque ceux-ci sont présents, encore faut-il qu’ils soient lisibles, elle s’est parfois retrouvée face à des sous-titres blancs sur fond blanc ! Le cas de l’écriture inclusive dans les sous-titres est problématique car compliquée à déchiffrer pour les dyslexiques, et longue à lire.
Il faut simplement utiliser un sous-titrage standard : blanc avec contour foncé, dans une police de taille confortable. Les sous titres automatiques quant à eux ne sont pas fiables, mais ils peuvent être utilisés comme point de départ puisqu’ils font la synchronisation et le gros du travail. Ensuite il n’y a plus qu’à corriger.
C’est bien de penser à sous-titrer ses médias, mais il s’agit aussi d’informer ! Parfois, on ne sait juste pas qu’il existe des sous-titres.
L’autre problème majeur soulevé par Emmanuelle concerne le téléphone : elle encourage à proposer un service client écrit et pas systématiquement téléphonique. De même, dans un formulaire, ne pas rendre les champs téléphone obligatoires puisque si on vient à l’appeler, elle ne pourra probablement pas répondre.
Elle nous fait également part d’un handicap provisoire qui l’atteint actuellement : la photophobie. Les thèmes sombres ne sont pas toujours bien pensés, un texte écrit en noir est souvent oublié, il devient donc illisible par manque de contraste. En revanche, un bouton blanc dans un thème sombre sera vécu comme très aggresif, car trop contrasté.
Céline est aveugle et bien souvent, des informations sont écrites sous format image et elle ne peut donc pas les lire. Elle est amenée à jongler entre les navigateurs pour faire fonctionner les différentes parties d’un site, et ça c’est quand tout le site est accessible ! Car parfois, certaines parties sont accessibles mais pas d’autres : création de compte, connexion, ajout panier, paiement. Les informations importantes ne doivent pas être définies uniquement par une couleur. Par exemple “Corriger les infos encadrées en rouge” devrait être remplacé par un message indiquant le nom du champ. Idem lorsqu’on indique de cliquer à un endroit en particulier.
On retiendra notamment ces deux phrases :
“Une bonne expérience sur le web est une expérience où j’arrive au résultat escompté en y passant autant de temps et d’énergie qu’une personne valide.”
"L’accessibilité n’est pas juste un truc théorique qui fait plaisir aux experts mais un vrai problème concret qui concerne des vrais gens.”
Section intitulée petit-guide-pratique-pour-commencer-un-design-systemPetit guide pratique pour commencer un design system
Par Cécile Freyd-Foucault
Un Design System, c’est un écosystème, un ensemble d’outils ou de composants à destination des développeurs et des designers pour concevoir des interfaces homogènes et cohérentes. C’est une sorte d’encyclopédie de votre application finalement.
Basée sur son expérience, Cécile nous donne quelques conseils pour en créer un.
Tout d’abord, un Design System s’utilise en équipe, il est donc indispensable que tous les collègues amenés à l’utiliser se sentent impliqués. Et chaque membre de l’équipe devra en avoir la même définition !
Il faut également se poser les bonnes questions, notamment “Pourquoi on en fait un ?” S’il n’a pas de réel intérêt, autant ne pas en faire du tout !
Ensuite on va identifier les composants, en commençant par identifier les parcours utilisateurs et les différents écrans du produit, sur tous les types d’appareils devant être pris en charge par l’application. On va pouvoir identifier les problèmes de ces composants et la criticité de ces problèmes.
À partir de là, on peut mettre en place une stratégie visant à résoudre ces problèmes en fonction de la difficulté à les résoudre indépendamment d’une part, et de leur complexité d’autre part.
Une partie qu’on adore : la documentation ! 🤓 Elle décrit les composants, les styles, les parcours, ce qui est mis en place pour l’accessibilité, et j’en passe. Elle contient même de la documentation de documentation : c’est-à-dire comment rédiger cette documentation, ainsi que les conventions de nommage choisies par l’équipe. La documentation décrit aussi quand, comment et pourquoi changer un composant.
Enfin, Cécile nous rappelle qu’un Design System doit répondre au besoin des utilisateurs et à rien d’autre. Il ne faut pas prendre de l’avance sur ce qui existe déjà au risque de perdre du temps sur des points qui n’ont pas de cas d’utilisation immédiats et ne sont pas encore utilisés.
Section intitulée wordpress-et-l-ecriture-inclusive-accompagner-le-changement-au-sein-d-une-communaute-open-sourceWordPress et l’écriture inclusive. Accompagner le changement au sein d’une communauté open-source
Par Jean-Baptiste Audras
Jean-Baptiste est un des développeurs Core de Wordpress. Lui et le reste de l’équipe ont récemment revu l’interface pour la rendre plus inclusive, « démasculiniser » la version française du CMS.
Il s’agit dans un premier temps de choisir les traductions qui conviennent, mais aussi d’accompagner les utilisateurs et utilisatrices du CMS dans cette transition. Les éditeurs de plugins sont également encouragés à en faire autant.
Mais comment fonctionne-t-elle, cette transition ? D’abord, des utilisateurs lambda proposent une traduction. Environ une fois par mois, l’équipe qui maintient le CMS va se réunir et débattre de cette proposition de changement. Si l’équipe ne parvient pas à prendre de décision, alors un sondage aura lieu au sein de la communauté.
Pour traduire, plusieurs techniques sont possibles :
- La combinaison consiste à utiliser les deux genres : L’onglet “Utilisateurs” devient “Utilisateurs et utilisatrices”. Cette solution présente l’inconvénient de prendre beaucoup de place.
- Le point médian se met au niveau de la terminaison du mot : “Utilisateurs” devient “Utilisateur·ice·s”. Cette solution prend en effet moins de place, mais elle est aussi moins lisible et présente des inconvénients d’accessibilité.
- Le neutre et les formulations épicènes seront la solution la plus souvent choisie. Dans ce cas, “Utilisateurs” devient “Comptes”.
Ces changements ont été globalement bien acceptés par la communauté. Face aux avis négatifs, il faut savoir faire preuve de pédagogie et inviter la communauté à participer en amont s’ils ne sont pas en accord avec les choix qui ont été faits.
Lors de changements de ce type, on note l’apparition de forks du projet, des gens proposent leur propre traduction. Et c’est encouragé ! Si beaucoup apparaissent, ou si les autres forks sont très clonés, ça permet de se rendre compte que la communauté préfère autre chose, et qu’il faut potentiellement repenser le projet. Mais là ça n’était pas le cas, une belle réussite donc !
Section intitulée reseaux-sociaux-gafam-et-vie-privee-chez-les-ados-vu-par-une-adoRéseaux sociaux, GAFAM et vie privée chez les ados (vu par une ado)
Par Camille Deschamps
Camille entre dans le vif du sujet en nous parlant de Mastodon, et de Signal, concurrents Open Sources respectifs de Twitter et WhatsApp. Elle cite également PeerTube (YouTube), Diaspora (Facebook), PixelFed (Instagram), et d’autres, qui sont autant d’alternatives aux réseaux sociaux que nous connaissons actuellement.
Malgré la multitude d’alternatives qui existent, et qui respectent réellement notre vie privée, elle note un refus d’en discuter de la part des autres adolescents.
Comment ça “réellement” ? Eh bien, elle nous explique que Snapchat récolte toutes les informations de votre appareil : le modèle, la version, le navigateur utilisé, mais aussi les identifiants et même les logiciels installés, ainsi que le niveau de batterie ou encore le fuseau horaire. Instagram récupère les mêmes informations en poussant encore plus loin : sur PC, il identifie la fenêtre active ainsi que les mouvements de la souris. Et Tik Tok est encore plus avancé dans ce domaine puisqu’il peut regarder les applications installées et celles désinstallées, l’adresse IP de l’appareil, le nom du réseau wifi utilisé, ou encore la localisation. Il utilise également un algorithme (similaire à celui de Facebook / Instagram) visant à faire passer le plus de temps possible à chaque utilisateur spécifique sur l’application en fonction de ses intérêts.
Camille s’interroge sur ce qu’elle peut faire à son échelle et à son âge, et la réponse est d’informer le plus possible ! Qu’il s’agisse de l’entourage, ou même des professeurs pour les inviter à utiliser des outils tels que la suite Framasoft qui fait concurrence à la suite d’outils Google, et qui peuvent à leur tour partager à la nouvelle génération.
Section intitulée tous-sur-ecran-quels-enjeux-ethiquesTous sur écran, quels enjeux éthiques ?
Par Amélie Boucher
On passe en moyenne 6h55 par jour, soit la moitié de notre temps éveillé, sur les écrans. Dans ce contexte, des problématiques d’éthique finissent forcément par intervenir. Quand Amazon, à l’aide de ses fameux dark patterns, fait tout pour empêcher ses utilisateurs de se désinscrire, quand Netflix lit automatiquement l’épisode suivant ou encore quand LinkedIn nous invite à souhaiter un joyeux anniversaire, est-ce innocent ? Y a-t-il une réelle intention de nuire ?
Amélie souligne la différence entre éthique de responsabilité et éthique de conviction. L’éthique de conviction place principes et valeurs au dessus de tout, tandis que l’éthique de responsabilité s’intéresse aux effets de ses actes. C’est cette dernière qui prime.
Notre problème est que la performance-business – faire des ventes, récupérer des inscriptions, etc – passe aujourd’hui avant les soucis d’éthique. Sauf que, sur le long terme, les gens remarquent les dark patterns mis en place, et la courbe de fidélisation redescend.
Alors comment agir en tant que développeur ? On peut déjà repérer des signaux. Par exemple, quand on commence à trouver des ressources expliquant comment ne pas se faire avoir par une certaine fonctionnalité de notre site, c’est signe qu’elle est largement indésirable et considérée comme un dark pattern. On peut aussi aller chercher l’efficacité : effectuer une certaine action avec le moins de clics possibles, ou rendre plus claires les étapes à effectuer pour faire cette action. Cela réduira à peu près toujours les comportements à éthique faible.
Pour revenir à l’accessibilité, des participants à Paris Web ont souligné le fait que l’absence d’accessibilité de certains sites pousse des personnes en situation de handicap à accepter des choses malgré elles.
Section intitulée palmares-2021-des-idees-fausses-sur-l-accessibilite-numeriquePalmarès 2021 des idées fausses sur l’accessibilité numérique
Par Agnès Haasser
Il semblerait que la certification Opquast connaisse une certaine notoriété en ce qui concerne l’accessibilité. Et pourtant, elle ne vérifie qu’une petite portion des (critères RGAA)[https://www.numerique.gouv.fr/publications/rgaa-accessibilite/methode-rgaa/criteres/] ! Pour ne plus nous faire avoir par ce genre de préjugé, Agnès nous propose de vérifier ensemble quelques idées reçues sur l’accessibilité :
❌ “Un HTML non standard va pourrir l’accessibilité” Un HTML standard est une bonne base mais c’est insuffisant pour rendre un site accessible. L’ajout d’attributs par des librairies Js par exemple, ne pose pas de problèmes. L’inaccessibilité peut avoir une multitude d’autres origines. D’où le fait que l’absence de Js sur un site n’est pas non plus signe d’une bonne accessibilité. 3 Il existe une documentation expliquant comment faire des interfaces riches : (l’Aria Authoring Practice)[https://www.w3.org/TR/wai-aria-practices-1.1/]. Cette documentation est bourrée de design patterns pour faire des éléments accessibles, les comportements standards attendus pour ces composants, etc.
❌ “L’accessibilité c’est galère à mettre en place”
Sur certains composants, peut être, mais pour ce qu’on fait au quotidien, c’est très simple ! Par exemple, un simple attribut label pour chaque élément input, un attribut legend pour chaque fieldset, etc.
❌ “Du coup je vais mettre des aria-label PARTOUT” Abuser de cet attribut fait office de pelleteuse et occulte l’accessibilité qui était disponible dans l’élément que vous essayez de décrire. Mieux vaut pas d’Aria qu’un mauvais Aria.
Section intitulée le-jargon-web-avant-le-webLe jargon web, avant le web
Par Gaël Poupard
Gaël a effectué pour nous une chouette recherche étymologique et a pris le temps de décortiquer les anglicismes nichés dans notre vocabulaire quotidien. 🔎
World Wide Web signifie “toile d’ampleur mondiale” et le mot Web utilisé tel quel en Français perd la notion de réseau organique minutieusement orchestré, puisqu’en anglais il définit une toile d’araignée.
Radio button, littéralement bouton de radio : lorsque l’un est activé, les autres ne le sont plus car on ne peut sélectionner qu’une station à la fois !
Scroll veut dire rouleau, ou parchemin : on enroule ce qu’on a déjà lu, on déroule ce qu’on n’a pas encore lu. Le terme français “barre de défilement” est bien moins parlant.
Bug : l’insecte présent dans le PC et qui provoque un bogue est un mythe ! L’anecdote de l’insecte trouvé dans un PC de Grace Hopper est le “first actual bug found in a computer” (“premier véritable insecte trouvé dans un ordinateur") mais le terme était déjà présent depuis longtemps.
Spam vient d’une marque de porc en conserve devenue populaire lors de la seconde guerre mondiale. Un sketch des Monthy Python y fait référence et se moque du fait qu’on en trouve absolument partout, il est à l’origine de l’utilisation de Spam.
Framework => cadre, charpente, ou encore coffrage en Français. Ce mot définit l’outil qui va supporter un ouvrage construit. Il peut être totalement retiré une fois le chantier terminé. Ce sens est également perdu !
La liste est encore plus longue et contient une pléthore de métaphores. Car finalement, peu de termes ont été créés pour le Web. D’ailleurs on peut citer à nouveau Opquast qui fournit un glossaire pour les Français qui travaillent dans le milieu du Web.
Section intitulée de-restaurateur-de-vitraux-a-developpeur-petit-guide-pour-personnes-en-reconversionDe restaurateur (de vitraux) à développeur : petit guide pour personnes en reconversion
Par Rémi Mercier
Rémi nous parle de sa reconversion en développeur : L’avant reconversion. C’est une période bien plus compliquée que ce que l’on croit, qui demande du temps – plusieurs années -, de l’organisation, mais aussi du soutien à la fois de l’entourage personnel et professionnel. Une fois que la décision est prise de se réorienter, faire des projets personnels pour tester son envie est un bon premier pas.
Mettre un premier pied dans à l’étrier en trouvant son premier job de dev. Eh oui, il existe une grosse différence entre la formation et un vrai boulot. Faire la jointure est possible de plein de manières (projets, exercices, ressources en ligne etc).
Avant les entretiens, c’est utile, et rassurant, de travailler son pitch pour raconter son parcours de manière linéaire, même si votre parcours ne l’est en réalité pas du tout !
Puis repérer une équipe adaptée : est-ce que j’aurai le niveau ? Est-ce que la culture de cette entreprise me convient ? Est-ce que je veux bosser avec ce type de personnes ? Ces gens vont aussi vous aider à monter en compétences, vous soutenir, faire des projets à vos côtés.
Célébrer ses spécificités, par exemple : lister ses expériences professionnelles et ce qu’on a appris dans chacune d’entre elles. “Si j’ai pu apprendre ça avant, je peux intégrer une équipe de développeurs”. Et ça nous prouve qu’on a de la valeur, ses années d’expérience ont de la valeur même s’il s’agit d’une expérience qui n’a rien à voir avec le développement. Donc on aura beau être junior, bah finalement pas tant que ça.
L’après, c’est le second poste, l’aisance, la confiance en soi, un meilleur salaire etc. Et en fait ça commence à l’étape d’avant : en progressant pendant son premier boulot. Le sujet de la veille est un sujet important, surtout dans l’informatique. Si elle est relative aux compétences utiles dans son travail, elle peut être effectuée au travail. (En tout cas, chez JoliCode, elle est fortement encouragée !) Il ne faut pas oublier de se poser, et regarder ce qu’on a appris, avec des méthodes comme « 3 things a day », ou en écrivant des articles par exemple.
Booster son Klout (ça aussi on aime chez Joli) : présence sur Twitter, articles etc.
Quel que soit votre parcours, vous apportez de la valeur à votre équipe tech. Et souvenez-vous, si vous travaillez comme développeur, vous êtes un vrai développeur.
Section intitulée a-l-annee-prochaineÀ l’année prochaine ! 👋
Cette année, les conférences ont eu lieu en ligne : l’enregistrement des vidéos s’est fait cet été chez les conférenciers, puis les vidéos ont été diffusées dans un live YouTube (et pourquoi pas PeerTube alors ? 😜). Les spectateurs se sont retrouvés sur un Slack dédié qui ne manquait pas d’humour et de bonne humeur ! Cela a permis aux spectateurs de poser leurs questions directement à l’écrit et aux conférenciers de pouvoir y répondre directement. Nous avons beaucoup aimé cette approche qui permet aux plus timides de poser leurs questions plus facilement, mais aussi d’échanger des liens, d’épingler les messages d’annonces, etc.
Nous avons aussi découvert une communauté très impliquée dans l’accessibilité. Les gens ont posé des questions très pertinentes, qui faisaient souvent écho avec les sujets des autres conférences.
Nous espérons avoir le plaisir de croiser ce beau monde, en chair et en os cette fois, l’année prochaine !
Cet article porte sur la conférence Paris Web 2021.
