La 19ème édition de Paris Web a eu lieu du 26 au 28 septembre 2024 ! Qu'est-ce que c'est ? Un événement composé de deux jours de conférences et une journée d'ateliers sur les thématiques de l'accessibilité et de la qualité du web. Il s'adresse aux développeurs et développeuses, mais aussi aux designers, experts et expertes accessibilité et performance, chef et cheffe de projet... c'est pour tous les métiers du web. On ne pouvait pas manquer ça !
C'est donc à l'institut Pasteur que nous nous sommes rendus pendant deux jours. Dès la conférence d'ouverture nous avons pu nous rendre compte des moyens mis en oeuvre pour accueillir le plus de personnes possibles : les conférences étaient toutes interprétées en LSF (langue des signes française) et une retranscription en direct par vélotypie, à la vitesse de la parole, était affichée de chaque côté de la présentation centrale. Le lieu était évidemment accessible PMR (personnes à mobilité réduite). Les conférences se sont déroulées les unes à la suite des autres, pas besoin donc de faire de choix, nous avons pu toutes les suivre ! Voici ce que nous en avons retenu.
Magali commence la conférence avec une citation de Roland Barthes de 1977 pour sa leçon inaugurale au Collège de France :
Mais la langue, comme performance de tout langage, n'est ni réactionnaire ni progressiste ; elle est tout simplement : fasciste ; car le fascisme, ce n'est pas d'empêcher de dire, c'est d'obliger à dire. Les mots ne seraient donc pas source d'expression et de liberté, mais de contrainte et de souffrance.
Un peu plus tard Magali nous dit : "Je suis grosse." Elle note des regards gênés dans le public : ce mot a un sens différent que "ronde" ou "forte". Pourtant elle explique préférer le mot "grosse", qui correspond à la réalité et lui permet d'évoquer que le fait d’être grosse impacte sa vie au quotidien ; c’est un handicap. Alors que de dire qu'elle est "forte" ne lui correspond pas : elle explique ne pas pouvoir soulever 5kg. Et dire qu'elle est "forte", c'est ne pas voir la réalité de son handicap.
Le choix des mots, c’est important. On ne dit pas la même chose de soi si on dit qu’on est "gros" ou qu’on est "fort".
Nous adaptons le langage aux changements de société, mais est-ce qu’on peut pousser des changements de société en changeant notre langage ?
Magali explique comment des mots sont vidés de leur sens avec cet extrait du roman dystopique "1984" écrit par George Orwell, slogan du régime fasciste de l'histoire :
La guerre, c’est la paix. La liberté, c’est l’esclavage. L’ignorance, c’est la force.
En juxtaposant deux mots au sens contraire, ils se vident de leur sens.
Pour l’orateurice (mot créé pour la conférence pour désigner les orateurs et les oratrices), le langage inclusif, c’est tout ce qu’on peut mobiliser au niveau de notre communication, orale ou écrite, pour éviter d’exclure, opprimer ou invisibiliser une partie de la population. Le point médian ou l'écriture inclusive se présentent alors comme des solutions, bien que non exemptes de défauts : on leur reproche notamment de complexifier la lecture. Le français est une langue genrée, cela demande donc plus d'efforts par rapport à d'autres langues moins genrées pour mettre en place des changements liés au genre.
Pourquoi vouloir changer nos règles de grammaire et féminiser plus le français ? En réalité, la masculinisation du français vient de réformes de la langue française datant du 17ème siècle. La règle du "masculin qui l’emporte sur le féminin" aujourd'hui apprise à l'école avait alors été exprimée plus clairement : "le genre le plus noble l’emporte". C'est à la même époque que les noms de nombreux métiers se sont masculinisés. Est-ce qu'on veut vraiment continuer à utiliser des règles grammaticales mises en place selon une idée si misogyne et dépassée ?
Magali se demande : pourquoi dans une industrie si habituée au changement technique comme la tech, on reste autant frileux face au progrès social ?
Pourquoi sommes-nous aussi conservateurs et conservatrices ?
Magali n'est pas défaitiste pour autant : on peut déconstruire un langage oppressif et reconstruire un langage à l’image de ce qu’on veut dans notre société.
Il y a quelques années on désignait les personnes handicapées comme "personnes handicapées". Maintenant, on dit "personnes en situation de handicap". Magali explique ne pas du tout aimer cette expression : c'est comme si ces personnes rencontraient de temps en temps des situations où leur handicap est gênant. En réalité c'est une suite continue de situations où le monde est inadapté.
Cette expression de "personnes en situation de handicap" est une régression qui invisibilise les personnes handicapées.
En conclusion : il faut faire attention à utiliser les bons mots ! Le langage a le pouvoir d'aider à changer la société.
Simon et ses collègues se sont retrouvés avec cette problématique : comment mettre en place un gestionnaire de cookies accessible, conforme au RGAA ?
Ils sont partis des constats suivants :
Ils ont donc décidé de participer à un projet open source non accessible correspondant à leurs compétences pour le rendre accessible. Ils ont choisi le projet Klaro! (et pas tarteaucitron pour des raisons de connaissances techniques, l'équipe connaît JS/React).
Ils implémentent donc des améliorations pour rendre le gestionnaire de cookies accessible, mais se rendent compte que petit à petit leurs modifications sont remplacées par celles d'autres personnes qui ne tiennent pas compte de l'accessibilité. Ils décident donc de faire un fork du projet et lancent leur propre projet : Orejime.
Aujourd'hui après plusieurs années de participation à Orejime, Simon nous montre les quelques surprises de l'équipe :
Ils prévoient des évolutions futures du projet, comme intégrer la notion de thème dont le premier sera celui correspondant au Design System de l’État Français !
La leçon que Simon tire tout de même de cette aventure est qu'il aurait fallu communiquer directement avec les mainteneurs du projet Klaro! sur lequel ils avaient commencé à travailler pour leur expliquer la démarche d’accessibilité qui motivait leurs modifications.
Le terme “Gaslight” vient du film du même nom de 1944 et se traduit plus ou moins par “se faire enfumer”. C’est un sentiment ressenti par Anthony pendant les dernières décennies dans le web à l'égard des SPA qui sont toujours partout, et sont le choix par défaut.
Pourtant la base de la création de projet c’est faire les choix les plus adaptés à des problématiques rencontrées. Anthony nous présente les inconvénients des SPAs :
Antony nous explique ensuite les avantages des MPA (Multi Page Apps, ce qu'on pourrait appeler plutôt des sites “classiques”) et comment faire des MPA robustes et agréables.
<img loading=lazy>, la création d'accordéon avec <details>, en CSS scroll-behavior, et scroll-snap pour la création de sliders, le sélecteur :has()…Il existe de nouveaux outils très intéressants : HTMX, Hotwire Turbo et Unpoly, les CustomElements, Hotwire Stimulus. Pour entrer plus dans les détails de Hotwire Stimulus :
Antony nous donne aussi quelques exemples de sites "MPA" : https://www.hey.com/, https://www.contexte.com/
En conclusion les SPAs ne devraient pas être le choix par défaut. On devrait plus souvent se demander si une MPA pourrait convenir en fonction du besoin, car aujourd'hui les technologies se sont développées et permettent d'avoir une bonne expérience dev et des bonnes performances.
Le sujet de cette conférence, présentée par les joviales Tamara et Nora, est de montrer qu'on peut utiliser des méthodes de travail UX pour aider à avancer sur des problématiques d’accessibilité.
Lorsqu'on arrive sur un projet avec peu ou pas de notions d'accessibilité, il faut se poser différentes question :
Un des premiers conseils, c'est d'être empathique avec les gens qui résistent pour trouver des arguments qui correspondent à leurs problèmes. Cela permet de trouver un passage au travers de la résistance au changement.
Il faut répandre l’idée : “Ça peut être moi ou quelqu’un que je connais”.
Il peut y avoir une problématique de responsabilité floue : qui fait quoi et comment ? On peut utiliser l'ARRM pour s’aider à définir les rôles au sein de la structure : https://www.w3.org/WAI/planning/arrm/.
On peut utiliser l’Accessibility Maturity Model pour mesurer le niveau de maturité du projet : https://www.w3.org/TR/maturity-model/#description-maturity-stages.
Objectivement, on peut rencontrer des difficultés à intégrer plus d’accessibilité parce que l’accessibilité est vraiment un sujet compliqué. Et c’est d'autant plus compliqué de travailler avec des grosses équipes car il faut trouver des solutions pour motiver encore plus de personnes.
Pour tout ce qui concerne le Design on peut mettre systématiquement des annotations sur les maquettes pour que les devs sachent comment intégrer les composants au niveau de l’accessibilité. Ça devient la responsabilité des designers de faire ces choix.
Il est intéressant de faire passer un questionnaire pour les employés pour mesurer les connaissances et les lacunes des équipes. Ça permet aussi de s'assurer que malgré les potentiels turnovers on garde toujours une connaissance stable.
En conclusion, la prise en compte de l'accessibilité sur un projet est un succès quand c’est le collectif qui s’en empare et pas juste quelques personnes.
Le duo de Flora et Esther nous présente une conférence à la fois théorique et pratique autour du design et du temps.
Chaque individu ressent le temps qui passe différemment selon le moment, selon si on s'amuse ou si on s'ennuie par exemple. Le temps se découpe en trois "moments" : le passé, le présent et le futur. Traditionnellement le passé était le plus important, aujourd’hui c’est le présent qui prend plus d’importance.
Cela se reflète dans nos interfaces : le scroll infini est un exemple de présent qui s'étire sans fin. Flora nous donne aussi l'exemple de Google Maps qui est centré sur notre position actuelle plutôt que sur le parcours global, l’avant et l’après.
Esther nous recommande une conférence TED sur la psychologie du temps par Philip Zimbardo : https://www.ted.com/talks/philip_zimbardo_the_psychology_of_time?subtitle=en&geo=fr Elle nous parle aussi de Fabien Fenouillet qui effectue des études en psychologie cognitive sur la motivation, le choix, et liée à l'école, l'enseignement, les enfants.
Esther nous raconte l'expérience du marshmallow : un enfant reçoit un marshmallow par un adulte, l’adulte lui dit que s’il ne mange pas le marshmallow il en aura un second lorsque l’adulte reviendra dans la pièce. L'étude montre que les enfants qui attendent réussissent globalement tout mieux dans la vie : santé, bonheur, finances... Le fait d’attendre pour le second marshmallow démontre une capacité d'inhibition de la part de l'enfant : "si je me retiens maintenant alors je sais que dans le futur j’aurais quelque chose de bien".
La cohérence du temps se construit pendant l’enfance. Même s’il manque des études, on pense que plus les jeunes enfants sont mis devant les écrans, moins ils ont de capacité d'inhibition. Ils sont trop plongés dans un présent qui dure.
Pour les personnes atteintes de schizophrénie, la perception du temps est déformée. Comment les aider à surmonter ce trouble cognitif ? On peut mettre en place des notifications par exemple, pour rappeler quand ont lieu les évènements.
Le temps a une valeur monétaire. Grâce aux technologies, on devrait aller plus vite. En réalité, le temps est le même mais la quantité de travail est plus élevée.
On a eu besoin d’un temps collectif pour le transport et la communication, c’est pour ça qu’on a commencé à le mesurer.
En général les designers s’inspirent beaucoup de ce que font les GAFA, sauf que ce ne sont pas des boîtes particulièrement reconnues pour leur éthique. Flora nous parle de son association dont le but est de créer des composants éthiques : https://beta.designersethiques.org/fr
En conclusion le temps est une notion importante et présente dans nos interfaces. Il faut laisser le contrôle du temps à l’utilisateur car cela l'impacte directement.
L’idée de la conférence de Sébastien est de générer des noms de conférences avec un outil de génération aléatoire, et de voir si on peut en ressortir des sujets intéressants.
Sébastien explique qu'il entend de plus en plus parler de l’accessibilité mais pas toujours de la bonne façon. En fait, il entend surtout des questions sur le taux de non conformité et comment l'atteindre le plus vite possible, avec le moins de modifications.
Mais comment est-ce qu’on calcule ce taux de non conformité ? C’est un pourcentage sur un échantillon, donc ça ne correspond pas au parcours complet de la plateforme. Ça permet de donner une idée de l'accessibilité d'une plateforme mais ce n'est pas représentatif de sa réelle accessibilité.
Le taux est un outil de mesure mais il est loin d'être parfait. Il sert à donner une note mais il ne faut pas s’en satisfaire ni chercher à tout prix à “gagner des points” au détriment de la logique : un site de vidéo peut avoir un score de 98, s’il ne propose pas de transcription il reste inaccessible.
Il faut arrêter de se focaliser uniquement sur le taux. Le mieux est de se demander comment empêcher les erreurs d'accessibilité avant qu'elles ne se fassent et deviennent de plus en plus nombreuses.
Installer un outil de surcouche n’est pas la solution. C’est une aide qu’on peut mettre en place dans un second temps, après avoir résolu les problèmes d’accessibilité propres à la plateforme. Ce sont des outils d’assistance plutôt que d’accessibilité.
Une dernière source sur le sujet : le site du Forum Européen de l’Accessibilité : https://www.edf-feph.org/
Lors de cette conférence Thomas se pose la question : Qu’est-ce qu’il se passe quand on envoie un mail ?
Aujourd’hui les mails sont devenus complètement anodins. Pourtant il se passe beaucoup de choses derrière l’envoi d’un email. Le contenu de ce qui est envoyé c’est uniquement du texte, exactement comme un courrier.
Tous les langages utilisés dans les mails sont standardisés et open source. C’est une différence et un atout par rapport aux logiciels de communication d’aujourd’hui.
On a une image des mails comme étant légers, s'envolant dans les airs pour arriver à leur destinataire. En réalité ils passent par un réseau bien physique de câbles sous-marins.
Les données présentées par Thomas sur les câbles sous-marins proviennent de https://www2.telegeography.com/. On peut utiliser le site iana.org pour connaître l’adresse du domaine mail (ou foyer numérique)
Lison, qui est docteure en psychologie et développeuse web, nous parle ici des handicaps cognitifs et donne des pistes pour permettre aux personnes avec ces handicaps de mieux utiliser le web.
Un handicap cognitif, c'est une altération des processus qui permettent d’acquérir et utiliser nos connaissances. On peut penser que "ça ne concerne que des personnes handicapées" mais n'importe qui peut rencontrer à un moment ces problématiques, par une grande fatigue, lorsqu'on ne maîtrise pas une langue, ou simplement par la vieillesse.
Les derniers ajouts dans les WCAG liés aux troubles cognitifs datent de 2018. On a actuellement les points :
Sont attendus dans la prochaine version les points suivants :
Lison nous présente ensuite différents types de handicaps cognitif et comment aider les personnes qui ont ces handicaps.
Damien se présente et explique qu'il fait partie du studio Monotype, qui propose une collection de typographies et crée un rapport sur la typographie tous les ans, ainsi qu’un podcast.
Parmi les sujets auxquels ils s'intéressent on retrouve :
Aujourd'hui il existe peu de typographies qui se disent "accessibles", mais il y a l'exemple de Lexend
Les typographies évoluent avec le temps, depuis l'imprimante et la machine à écrire à nos jours. Dans les années 90, une technologie appelée MultipleMaster arrive. C’est l’ancêtre des polices variables, mais à cause de sa complexité cette technologie ne parvient pas à se faire une place dans les usages.
En 2016 c’est la renaissance des polices variables. L’idée, c’est d’avoir plusieurs styles dans un seul fichier.
Les “masters” sont les extrémités et les points d’ancrage importants. Ils permettent d’avoir le même nombre de points entre les différents “moments” de la typographie pour ne pas avoir de déformation. Les “instances” sont les graisses, et pas forcément multiples de 100 comme on a l'habitude de le voir sur le web. Les “axes” sont des jeux de styles uniques.
On se déplace entre les instances et les axes pour créer des rendus fluctuants. Les polices variables permettent de l’agilité, de l’expérimentation. On peut travailler sur des impressions d’optique. Aujourd'hui la prise en charge des polices variables n’est pas uniforme mais s'étend.
Quels sont les outils utilisés pour créer des typographies ? Glyphs, Robofonts, Fontlabs...
Comme exemples de polices variables on peut citer HelveticaNow, Walbaum et FruityGear.
Aujourd’hui l’IA n’est pas capable de créer des polices variables mais ça serait pratique car leur création est très compliquée et cela prend du temps.
Nous enchaînons ensuite par la seule conférence en anglais de cette édition de Paris Web. Cette conférence est traduite en simultanée sur une application mobile.
Lainey, qui est avocate aux Etats-Unis, nous présente comment négocier pour mettre en place l’accessibilité dans son entreprise. Elle présente son site internet qui contient de nombreux articles et ressources sur le sujet.
La première idée évoquée c'est : “Accessibility is beautiful” ou "L'accessibilité est magnifique". Il faut mettre en avant la beauté de l’inclusivité. pour aider à sa mise en place.
Lainey nous parle de sa carrière : avocate, elle travaille sur le cas des ATMs impossibles à utiliser par les aveugles ou malvoyants car ils ne possèdent pas encore de braille ou de casque. Avant de faire un procès aux banques, Lainey leur écrit pour tenter de régler le problème à l’amiable. Les banques acceptent de travailler pour aller dans le sens de l’inclusivité et au bout de 4 ans les ATMs avec braille et casque arrivent dans les rues. Par la suite les banques en ligne aux Etats-Unis deviennent aussi accessibles.
La question qu'elle se pose alors est : est-ce qu’il est possible de mettre en place la même chose, mais dans d’autres secteurs ? Comment négocier et collaborer avant de passer à la menace juridique et éviter les procès ? Lainey va travailler dans plusieurs secteurs et très souvent réussir à mettre en place l'accessibilité là où elle est nécessaire : la santé avec les pharmacies, les aéroports, la sécurité, le secteur public (passage piéton…), les prisons, et même le sport avec le baseball.
En 2016 Lainey écrit son livre “Structured Negotiation: A Winning Alternative to Lawsuits.” dont le tout dernier chapitre est consacré à la négociation.
Une seconde idée est “Show don’t tell”, "Montre au lieu de dire" : il faut mettre les handicapés, les personnes qu'on veut défendre au centre de la négociation. Il faut montrer les personnes et les problèmes qu’elles rencontrent, et les effets réels de la non accessibilité sur ces personnes. Il faut montrer qu’aider à résoudre ces problèmes fait du bien, “It feels good”. “Accessibility is delicious”, "L'accessibilité est délicieuse" et fait du bien comme une pâtisserie. Car quand il y a des retours positifs des utilisateurs cela change les mentalités.
Il faut être un dauphin et pas un requin. Ce terme de requin vient d'un livre pour former les avocats qui s’appelle “Teaching baby shark to swim”, "Apprendre à nager au bébé requin". Mais tous les attributs du requins n’aident pas avec l’accessibilité. Il ne faut pas faire peur, il faut collaborer et se montrer empathique, d'où l'idée du gentil dauphin qui s'occupe du méchant requin. Pour négocier il faut mettre à profit ses soft skills : écoute, éthique et confiance, empathie, patience et persistance, et pas de jugement. Il faut aussi être patient malgré les difficultés et penser au long terme pour trouver le courage de continuer.
L'accessibilité est à mettre en place au plus tôt, sinon il devient très très difficile de le faire.
Et parfois si on est comme un poisson entouré par des requins qui ne veulent pas écouter et que ça devient trop difficile il vaut mieux laisser tomber et partir plutôt que de se sacrifier pour rien. Parfois les négociations structurées échouent. On ne peut négocier qu'avec des personnes en qui on peut avoir confiance.
Sofia commence par nous poser la question : à quoi servent les tests ? Elle nous explique :
Mais tout ça est souvent perturbé par des tests flaky. Ce sont des tests qui parfois passent, parfois cassent. Les causes des flaky peuvent être variées :
Comment résoudre ces problèmes ? Il s’agit de problèmes humains ou techniques.
Pour redonner de l'importance aux tests au sein des équipes il faut leur en faire comprendre l'intérêt, pourquoi les tests sont importants et pourquoi il faut y allouer du temps. Il faut également faire comprendre le problème que représentent des tests flaky non corrigés aux équipes.
La première étape est de quantifier les problèmes, former et informer sur les erreurs rencontrées.
Sofia nous donne une liste d'outils pour nous aider avec les tests : Cercle CI, Datadog, Allure, ou utiliser un analyseur statique comme PhpStan.
Il faut mettre en place un processus que tout le monde suit. Tout le monde ne suivra pas, alors il faudra donner l’exemple. On peut utiliser l’humour pour continuer à faire passer les messages en limitant la frustration de nos collègues. On peut valoriser le travail de ceux qui prennent du temps pour corriger des tests flaky.
Il faut prendre le problème des tests au plus tôt pour éviter d'être débordés.
Et parfois la meilleure solution c’est simplement de supprimer le test s'il n'est pas utile.
Thomas va nous parler des leviers (particulièrement du design) pour limiter l’empreinte écologique du numérique. Ces travaux sont disponibles sur le site de l'association qu'il co-dirige, Limites Numériques.
Ce sont des inspirations et des idées.
Il faudrait faire de la pédagogie par le langage. Rendre visible le poids des choses que l’on regarde ou télécharge par exemple. Montrer honnêtement le numérique tel qu’il est. Un des exemples les plus parlant c'est la symbolisation et la représentation du cloud comme étant un petit nuage léger et mignon alors qu'il s'agit de gros serveurs bien physiques et avec une vraie consommation énergétique.
On n'y pense pas vraiment en tant que consommateur, mais un data center a besoin de plus d'énergie pour se refroidir en été qu’en hiver. Aujourd’hui on attend du numérique qu’il soit disponible tout le temps, mais cela a un coût qui n’est pas visible par l’utilisateur.
C’est d'ores et déjà une bonne pratique mais il faudrait trouver de nouvelles choses pour continuer à aller dans ce sens. On pourrait mettre une date de péremption aux contenus, par exemple supprimer des contenus concernant des événements passés et qui n'ont plus d'intérêt à exister. Il fait laisser l’utilisateur choisir les médias qu’il souhaite ou non télécharger, en lui indiquant clairement ce qu'il est en train de télécharger.
Est-ce qu’on a besoin de tout, tout le temps ? Nos smartphones sont très puissants, peut-être même trop pour nos usages. On pourrait utiliser des matériels et outils limitants. Thomas nous donne l'exemple de la vieille machine à écrire utilisée par le scénariste du film Dune, qui ne permet d'écrire qu’un nombre limité de pages et donc l'oblige à se concentrer sur l'essentiel. Cela permettrait aussi au plus de monde possible d’accéder aux services. Les notions liées sont le "permacomputing" et les "vernacular technologies". On devrait pouvoir répondre aux besoins avec des savoir locaux, mis simplement à disposition de chacun.
Thomas et d'autres membres de l'association ont réalisé une enquête sur la paramétrisation des apps sur mobile. Il en ressort les points suivants : il n'y a pas de notion d'écologie, c’est parfois difficile de trouver un paramètre car il est caché dans des menus pas forcément logiques, les effets des paramètres sont peu expliqués, et les choix par défaut sont polémiques car ils ne sont pas les plus sobres.
Thomas nous a présenté des outils et ressources Green IT :
Dans l'idée des réseaux sociaux et services plus éthiques, on retrouve :
Après le repas nous enchaînons avec une conférence de la rigolote et déjantée Agnès, qui commence sa présentation par la conclusion pour que le public puisse s'endormir tranquillement pour digérer. Malin !
Agnès nous indique des références cruciales pour la sécurité : le guide de l’ANSSI et WebAuthn.
La base, c'est : pas de mot de passe seul dès qu’on gère des informations personnelles. Il peut s'agit de données sensibles : sexe, bord politique, adresse... Il faut toujours imposer une authentification multi-facteurs aux admins dans ces cas-là puisqu’ils ont un accès facilité aux données, et proposer l'authentification multi-facteurs aux utilisateurs.
Il faut bien faire la distinction : une authentification forte n'est pas la même chose qu'une authentification multi-facteurs.
L'authentification sert à prouver notre identité. C'est pourquoi normalement une méthode d'authentification ne devrait concerner qu'une personne, et pas un foyer par exemple. Il existe 3 facteurs qui permettent de s’identifier :
L'authentification par mail ou avec 6 chiffres c’est bien, mais recevoir un code par SMS n'est pas recommandé car peu sécurisé !
La double authentification, c'est lorsqu'on utilise deux des facteurs cités au-dessus. Une authentification forte, c'est quand les processus de cryptographie sont robustes.
Il y a 2 techniques d’authentification :
En symétrique on retrouve les TOTP : des applications avec des codes à entrer dans le temps imparti. Ils peuvent fonctionner sans internet. Une clé va être partagée entre le serveur et le téléphone mais ensuite les deux n'auront plus besoin d'être directement liés. La clé va ensuite être mélangée au timestamp actuel puis convertie en code, qui sera partagé par le téléphone et le serveur.
En exemple de TOTP on retrouve Github ou Facebook, dont l'UX n'est d'ailleurs pas la plus claire. Agnès nous parle aussi des cartes Aidant Connect qui est un exemple de bonne UX : le message est plus clair pour l'utilisateur, il est plus facile de comprendre ce qu'il doit faire.
En asymétrique on utilise une clé privée et une clé publique. Ce qui est crypté avec la clé publique est décrypté avec la clé privée et réciproquement. C'est le client qui contient la clé privée et le serveur qui contient la clé publique.
Si on veut mettre en place une double authentification sur un projet, il vaut vraiment mieux passer par une librairie déjà existante qui connaît et gère déjà les problématiques de sécurité. Il ne faut pas refaire la roue, c'est trop dangereux.
Christophe nous avoue que certaines des présentations montrées en conférence plus tôt lui ont donné la nausée.
Il est atteint de cybercinétose. Cette condition fait que lorsqu’on regarde un support numérique on peut ressentir un malaise, une envie de vomir. C’est un malaise créé par la contradiction entre le vestibule (une partie de l'oreille) et la vision. C’est le même phénomène que le mal des transports.
Christophe va ensuite nous montrer différents cas qui vont lui poser des problèmes : Gifs, mouvements avant et arrière, rotations... sur Slack, sur des sites très sérieux ou sur des présentations, avec des vidéos qui se lancent seules et en boucle... les exemples sont nombreux et variés.
Une solution à mettre en place, c'est utiliser en CSS prefers-reduced-motion et donner la possibilité à l’utilisateur de couper les animations et vidéos.
Pendant cette conférence, Emmanuel (ou Manu de son petit nom) va nous expliquer pourquoi il est important de toujours tester son projet avec un lecteur d'écran.
Son site, c'est https://manu.habite.la/
On teste son code sur plusieurs navigateurs, il ne nous viendrait pas à l'esprit de développer en utilisant uniquement les spécifications techniques, sans vérifier le rendu sur navigateur. Alors pourquoi est-ce qu'on le fait pour les lecteurs d'écran ? On implémente des features pour lecteur d'écran sans vraiment les tester alors qu'il faudrait que ce soit de l'ordre du réflexe.
On peut trouver plusieurs problématiques qui sont propres à certains lecteurs d'écran.
Arrêt involontaire de vocalisation
Ce problème est causé par exemple par un <br> qui coupe un texte. On peut utiliser un role=presentation sur le <br> pour le camoufler. Donc il faut faire attention aux balises car selon le lecteur d'écran elles peuvent être prises en compte différemment. Ces derniers analysent même le CSS.
Un title qui n'est pas lu
Un title n’est pas toujours lu, encore une fois ça dépend de l’usage et du lecteur d'écran. Les spécificités sont à vérifier sur https://a11ysupport.io/
Design Pattern ARIA En voulant bien faire, on ajoute beaucoup de aria qui peuvent ne servir à rien ou casser l’expérience de l'utilisateur. Il faut toujours penser à tester dans des cas concrets parce que nos ajouts peuvent être trop techniques pour aucun bénéfice. React-aria est un exemple de librairie qui est bien faite.
Majuscules pas lues La lecture des majuscules pose des problèmes par exemple pour les mots de passe ou code à entrer. Il existe une solution simple : ne pas utiliser de majuscules.
Enfin il faut penser à tester tout le parcours utilisateur, même les e-mails envoyés !
C'est Olivier qui va conclure cette journée et l'évènement en nous parlant des zones blanches et des méthodes pour permettre aux utilisateurs de ces zones d'accéder malgré tout à des services.
C’est fréquent qu’on perde du réseau, en passant sous un tunnel, ou simplement dans un endroit un peu isolé. Les zones blanches sont des zones sans internet. Il y a d’après les données des millions de personnes déconnectées.
Des solutions existent : utiliser des sms, passer par un réseau maillé, passer par des faisceaux de lumière comme dans le projet TAARA.
Pour aider l'utilisateur à patienter on peut gérer le temps d’attente et mettre en place des petits jeux ou des messages empathiques qui vont rendre l'attente plus facile. Il est très important d'informer l’utilisateur quand la connexion est rétablie.
Il faut être transparent sur les données nécessaires pour permettre à l'utilisateur de décider si "ça vaut le coup". On peut proposer des options flexibles à l’utilisateur pour qu’il utilise moins de données.
D'autres pistes de solutions peuvent être :
Finalement les zones blanches provoquent des problèmes mais sont aussi des opportunités pour innover et profiter à tous. C’est aussi un enjeu éthique pour permettre à des communauté entières d’accéder aux ressources du web.
Ces deux journées ont été pleines de découvertes. Elles nous ont permis de repartir plus confiants et assurés sur l'importance de créer un web inclusif, accessible, performant, éthique, écologique... en somme, un web respectueux de tous ses utilisateurs. Ce sont des changements qui sont compliqués à mettre en place, mais en sortant de Paris Web nous en sommes convaincus : nous ne sommes pas seuls avec ces objectifs, et malgré les difficultés c'est bien sur ce chemin que nous voulons nous engager. Nous espérons pouvoir y retourner l'année prochaine !
Auteur(s)
Stéphane Einhorn
Développeur front-end @ Eleven Labs, and SEO lover...
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
L'Anchor positioning API est arrivée en CSS depuis quelques mois. Expérimentale et uniquement disponible à ce jour pour les navigateurs basés sur Chromium, elle est tout de même très intéressante pour lier des éléments entre eux et répondre en CSS à des problématiques qui ne pouvaient se résoudre qu'en JavaScript.
Retour sur l'édition 2018 de dotCSS, la plus grande conférence au monde sur le CSS.
Mission Paris Web 2018 : compte-rendu de trois astronautes