Transcript du meetup de sensibilisation à l’accessibilité numérique chez ekino le 17 mai 2018

Cet article a d’abord été publié sur le blog d’ekino ; je l’ai en effet écrit dans le cadre de mon travail en tant qu’employée.

Le 17 mai dernier, pour la journée mondiale de sensibilisation à l’accessibilité (GAAD, Global Accessibility Awerness Day), ekino a organisé et hébergé un meetup réunissant trois présentations. Nous nous sommes essayé à l’exercice du transcript en direct, voici – plein d’erreurs encore certainement mais avec la meilleure intention du monde – un copié-collé quasiment pas retouché.

Fait avec Sébastien.

• Aller directement à la présentation Et orange, comme couleur, c’est accessible ?
• Aller directement à la présentation Accessibilité numérique : design et expérience utilisateur
• Aller directement à la présentation CSS Grid : Sémantique et accessibilité

Mot d’accueil

Delphine : Bonsoir à tous, merci d’être venus. Comme vous le savez aujourd’hui, c’est la journée mondiale de sensibilisation à l’accessibilité. Ça fait quelques années qu’on surveille la date, c’est la première fois qu’on organise un meetup à cette occasion.

Il y a des goodies à l’entrée, dont une checklist concernant des petits trucs qu’on peut mettre en place pour l’accessibilité, pour les designers et les dev front. On va commencer avec notre 1re présentation…

On commence avec Stéphane Deschamps.

Et orange, comme couleur, c’est accessible ?, par Stéphane Deschamps

« Et orange, comme couleur, c’est accessible ? » – Diaporama, 668 Ko

Stéphane Deschamps : Bonjour, Rapprochez vous svp, ce n’est pas très intime pour l’instant… 🙂 Y’a de la place devant.

Je m’appelle Stéphane, référent accessibilité chez Orange France. Mon travail est d’intégrer l’accessibilité dans les processus d’Orange.

Qui est designer dans la salle ? Ok, une poignée. Des chefs de projets ? Des intégrateurs / Front end ? Je vais vous parler d’un problème : la couleur. Notamment quand elle est peu contrastée comme chez Orange.

Je vais vous raconter comment on a essayé de le résoudre. Pour remonter à la source : on s’est basé sur les WCAG du W3C. Il y a une définition assez simple pour la couleur : un ratio de 3:1 pour les couleurs. Mais pour plein de raisons, plutôt 4.5:1 : bref c’est la faute des vieux. [calculs compliqués] Cf formule sur le powerpoint pour la formule… W3C a dit : 4.5:1. C’est la que j’espérais avoir des designers qui feraient « Arg, on peut pas faire ça ! ».

Il y a des outils pour surveiller les contrastes, comme Colour Constrast Analyser. C’est un outil tout simple qui s’installe sur les tous les OS. Il y a une pipette pour le arrière plan et le premier plan et il calcule. Par exemple, là je vois que le petit texte n’est pas assez contrasté. Il y a trois gradations pour l’accessibilité :

A: must AA: should AAA : could Si l’outil dit : « ce n’est pas assez », l’outil vous propose aussi des couleurs proches avec le bon ratio. Qui a connu wanadoo ? En 2006, on normalise la marque Wanadoo / France Télécom / Itinéris pour devenir Orange. Au 1er juin : bam. Vous voyez bien là le bouton ? Ben les clients non plus. Les clients se sont plaints par Sur ce bouton là, le contraste était trop faible, les gens ne le voyaient pas. Panique chez la maitrise d’ouvrage : hyperventilation du chargé de la maitrise. Il faut se poser pour redéfinir le problème et trouver des solutions avec l’équipe design.

On a réglé ça en 1 mois, le temps qu’on trouve une solution et qu’on la déploie. On a fait un truc tout bête : noir sur fond blanc. C’était radical, mais ça a permis de sauver les meubles. On a mis des pictos pour faciliter la navigation : première fois qu’on a des pictos chez Orange France.

Du coup c’est intéressant pour l’amélioration progressive : en accessibilité on a jamais tout bon, du coup il faut faire au mieux et améliorer étape par étape. C’est pas bon puis c’est meilleur, et ensuite comment on améliore encore ? Au travers de l’exemple d’Orange, j’ai envie de vous parler de tous ces processus. D’ici six mois, un an vous allez voir des choses sur Orange et vous verrez que ça bouge. À l’époque, il y avait 30 % d’orange sur la page et le reste en N/B. Problème de constraste, comment faire pour faire ressortir la coueur d’Orange sans perdre en lisibilité ?

Pendant plusieurs mois… Il a fallu 6 mois pour trouver la couleur adaptée. Y’a que les designers sur leurs beaux écrans qui voient la différence, mais sur l’exemple : le premier n’est pas bon, le 2e l’est. Définition de guideline : si vous utilisez le orange pour du texte : taille de texte min à 18 px. Cette nuance ne parait pas grand chose, mais en vrai c’est six mois de travail pour trouver un orange qui soit contrasté. Un orange assombri vire vite au orange marron sale. Sinon vous partez vers le rouge d’un concurrent, du coup le service juridique n’était pas content.

Au final, on a le orange du logo qui marche très bien sur la signalétique. Zéro problème de contraste sur fond noir. Pour le texte : un orange spécifique. C’est dans la charte depuis 2007. C’est beaucoup de travail pour arriver à ce résultat. Même quand on a l’impression d’avoir un problème très impactant…

Il y quelques années, un concurrent avec un texte bleu sur fond blanc et ils ont eu le soucis aussi. On se rassure en se disant qu’a coté c’est pire. La clientèle d’orange est assez vieille (client historique etc.), un devoir d’universalité etc. pour la marque, donc dur de passer outre. La charte de Orange (qui n’est pas publique), c’est 120 pages de bonheur. Et une page dit : voici toutes les couleurs possibles. Avec des consignes qui disent : attention cette couleur n’est pas utilisable si c’est sur du fond blanc, etc.

Quelques cadeaux pour finir : Certains de mes collègues trouvaient balo de faire des trucs sans les partager. Par exemple, Confort+ avec plein de trucs, des traductions des règles d’accessibilité plus digeste, mieux expliquée.

Il y a aussi des recommandations mobiles : les WCAG évoluent, vont devenir AG et on parlera de tout ce qui est numérique, plus seulement le web. Dans ces règles d’accessibilité on a fait le tri dans tout ce qui existe IOS et Android expliquant le pourquoi du comment de chaque règle. Dans le wiki du W3C, il y avait une matrice qui trainait : il y avait une vue en colonne triant les critères par métier. Le problème, c’est que ce tableau avait été fait par des gens de bonne volonté mais le travail n’avait pas été fini.. Du coup pour le diffuser en interne j’ai créé un outil pour lister les critères de manière automatique, filtrer les critères par métier etc.

On fera la même chose en octobre à Paris Web pour les WCAG 2.1. Confort+ c’est une extension pour ordinateur. C’est pour adapter l’affichage ou le comportement d’un site web. Par exemple : sur le W3C, j’aime pas le bleu des liens visités / non visités pas assez marqué. Avec confort+ tu peux forcer une couleur. Idem, tu peux changer la typo etc. Bref tu améliores ton usage du site. MDAN : un démonstrateur d’accessibilité pour mobile; ça marche sur iOs et Android. Ça lance talkback et ça montre en temps réel la différence entre accessible et non avec la recommandation de la bonne pratique.

Voila, c’est fini. Merci 🙂 Questions ?

Public : On pourra avoir les slides ? Stéphane : oui je les ferai passer par Delphine M. (Delphine : ça sera sur Twitter)

Public : our la couleur orange finale, vous avez visé du AA ou AAA ? Stéphane : Le critère AAA était impossible, on a fait du AA mais avec une grosse exigence de respect du AA. Tu l’as vu sur la slide là : on a globalement trouvé un truc pile sur du grand texte. En ajoutant une règle dans les guidelines pour imposer une taille de texte minimum.

Public : Ce sont les users mécontents qui ont provoqués ce changement ? Stéphane : Y’a eu un cheminement interne : on est une ancienne entreprise d’état et en tant que tel, on a beaucoup d’employés handicapés. Avant que la loi évolue, pour forcer les choses dans le privé, personne n’employait d’handicapés (car ils sont chiants avec leurs fauteurs, on peut pas faire de jogging avec eux, etc.). L’état n’avait pas de soucis à employer ces gens. Le mec qui portait l’accessibilité chez Orange était malvoyant. Du coup il en avait besoin de ça, donc ça aide à porter.

Pour faire avancer : on choppe un projet qui traine, on pousse l’accessibilité dessus et ensuite on décline sur les autres projets en montrant comment on fait. En 2004 début du projet « accessibilité », 2006 crise de la couleur. Historiquement en 2006 quand on faisait de l’archétype d’utilisateur. Les malvoyants passaient souvent à la trappe. Coup de semonce en 2006, les dirigeants furent bien content de nous avoir sous la patte pour résoudre le problème. 2006 n’a pas déclenché le problème, mais ça a concrétisé le besoin.

Public : Vous avez des tests pour vérifier que l’accessibilité a amélioré la satisfaction client ? Stéphane : On est en cours de mise en place d’une harmonisation du suivi de satisfaction client. J’ai eu une collègue qui évaluait la satisfaction client de cette façon : si y’a moins de gens qui râlent, alors c’est que ça va mieux. On est entrain de former un panel d’utilisateurs handicapés pour suivre l’évolution du sujet.

Public : – Comment vous assurez que ce design pensé accessible est correctement intégré ? Stéphane : Formation des équipes, même quand le développement est fait en externe. Maintenant les gens savent de quoi on parle, ça facilite le dialogue. Y’a quelques temps, quatre appels d’offres, quatre réponses de grosses boîtes : la première aucune mention de l’accessibilité, et les 3 autres a peine mentionné. Et une a fait tout un paragraphe. Bref on fait de l’accompagnement avec nos prestataires pour s’assurer de la qualité du résultat final.

Et de la recette, avec des audits d’accessibilité (on laisse les juniors faire ça :p ) On fait de moins en moins de recette globale grâce aux relais au sein des équipes, avec des référents etc. qui s’assurent de la qualité le plus tôt possible En France, je suis référent accessibilité chez Orange FR. En Espagne ça se met en place. On met des ressources à tous les niveaux pour détecter les soucis dès que possible.

Public : Vous êtes combien à l’accessibilité chez Orange ? Stéphane :

• Accessibilité et marketing des produits (téléphone etc.) : je ne sais pas.Des équipes en recherches, je ne sais pas.
• Pour le numérique : on est 6 ou 8 personnes pour accompagnement et audit et je ne peux pas compter ceux qui font l’accompagnement sur les projets. Demain je rencontre 7 projets et un designer sera le référent sur ces projets. En gros une dizaine de gens sur l’assurance qualité, avec de plus en plus de relais, d’animateur coté design, code …

Public : Vous avez un portail avec la documentation Orange ? Stéphane : Oui : Règles et accessibilité mobile par exemple, avec toutes les règles qu’on fait appliquer sur les projets. Avec des exemples, des mises en situations etc (texte sur une image, piège au clavier…). C’est en constante évolution, inspiré du modèle du W3C avec publication public. Avant on faisait des PDF, du coup les montées de version étaient pénible à faire. Maintenant c’est versionné sur Github ce qui facilite grandement l’évolution de la matière.

Public : Vous allez faire les intranets, et les documents ? Par exemple, dématérialisation des factures. Stéphane : Intranet : c’est pas mon domaine, mais la maitrise d’ouvrage s’est engagée. C’est pas un engagement financier, ou marketing, on a beaucoup d’employés en situation de handicap, donc a besoin de s’assurer qu’ils puissent bosser tranquillement (plutôt que se tourner les pouces :p ) On a des gens qui font de l’accompagnement, qui suivent les besoins salariés etc. on a une équipe chargée de tout ce qui est interne pour surveiller, corriger etc. On a scripté avec JAWS des pages : JAWS ? Si je suis aveugle, un moyen c’est de me faire lire ce qui est inscrit à l’écran.

Il faut donc que ce qui est l’écran doit être correctement implémenté. Avec Angular par exemple, si j’ai un « bouton » qui n’est qu’une div dans une div dans une div, ce bouton n’existe pas. Si tu as un dev sous la patte tu peux lui faire corriger en mettant un vrai >button<. Si ce n’est pas possible, alors on scripte pour dire à JAWS : « ça c’est un bouton ». Tout ce qui est document, c’est externalisé, mais on surveille. Le prestataire est une entreprise qui doit rendre des comptes, on espère que ça va faciliter tout ça. Merci 🙂 clap clap clap

Accessibilité numérique : design et expérience utilisateur, par David Monnehay

« Accessibilité numérique : design et expérience utilisateur », Diaporama, 16,5 Mo

Je m’appelle David Monnehay, je suis consultant acessibilité chez Atalan. Je fais des audits à longueur de journée, vivement que je ne sois plus junior pour arrêter :p Je vais vour parler de la conception graphique, et passer quelques idées reçues, type : « si c’est accessible, c’est moche ».

Et on va aller plus loin que ça : comment en tant que designer on peut améliorer l’UX de tout le monde en intégrant l’accessibilité dans les process ? Est-ce que l’accessibilité est une grosse contrainte graphique ?

Il y a certains sites qui continuent à penser ça, et on va en reparler. Mais ça date d’une époque où les lecteurs d’écrans étaient récents, pas très performants et ou oui c’était compliqué d’interpréter tout. Dy coup on écrivait gros et sans image. Voici le site de l’UEFA, la capture date d’aujourd’hui. Le site est riche graphiquement et change souvent.

Voici une capture de la page d’accueil de ce matin. Et tout en bas : on a un petit lien. Souvent on est habitué à naviguer au clavier : souris impossible quand on est aveugle ou avec un handicap moteur. Du coup, si je veux accéder à ce petit lien, je dois tout parcourir pour l’atteindre.

Les dev se sont dits qu’il fallait une version accessible, du coup ils ont fait une version moche : noir sur blanc, sans image, écrit en gros. Du coup si tu as juste oublié ta souris, tu as perdu et tu dois te contenter de ça. Ce site à souvent sa version accessibilité en panne : liens cassé, personne ne s’en rend compte parce que personne ne vérifie. C’est pas le cas sur la version non-accessible, ça remonte en moins de 5 mn. Ce site pourrait être rendu accessible sans trop de changement, peut-être un peu au zoom. Quelques contrastes mais rien d’insurmontable.

Je vais vous montrer quelques sites que je trouve « beaux », c’est pas trop le sujet mais c’est pour avoir des exemple non moches. Un site qu’on a réalisé avec Atalan : on peut avoir des choses animées, des apparitions etc. tout ça est accessible. On propose une expérience, il y a de la couleur, des liens, c’est assez ludique. Si je rentre dans les pages, même avec un sélecteur de ce genre, je peux le gérer au clavier donc je peux aller l’utiliser au clavier.

Exemple de contrôle pour comparer 2 visions pour montrer les différences entre valide et daltonien. Correction possible : en déplaçant les légendes, on ne perd plus d’information (information véhiculée par la couleur et autre chose)

Pour le site de Switch, on peut voir des animations au scroll etc. et tout ça est parfaitement utilisables par tout le monde. La richesse de l’interface n’est pas un problème.

D’autres exemples : Science-po pour parler design institutionnel : La navigation peut se faire au clavier. Le menu est extrêmement complexe MAIS complexe pour tout le monde. Donc ça va, tout le monde peut s’en servir, le principal est respecté. Un exemple plus courant peut-être : pour les motards dans la salle. (assurance des mutuelles des motards). Les choix de design sont personnels, on est juste là pour voir des ex d’interface. Ce site est valide A, pas AA a cause de problème de contraste. C’est un site e-commerce classique aujourd’hui, blog etc. et c’est accessible. Tout le monde peut s’en servir.

Comment quand on est graphiste peut on prendre en compte l’accessibilité ? On va parler de notre notice AcceDe Web. Atalan a décidé d’écrire des règles de basées sur le WCAG etc. mais compréhensibles par des chefs de projets, sans jargon trop technique. Y’a 4 notices existantes, on va parler de la 1re : conception graphique. Il y a 2 autres notice orientées dev, et une dernière : pour les contributeurs. Les notices sont gratuites et open sources.

Conception graphique et fonctionnelle : Vous trouverez des règles de conception classées en 8 thématiques. Quand je design un formulaire, je peux me référer à cette notice pour ne pas laisser à la porte quelqu’un en situation de handicap. On peut aussi construire une checklist adaptée au site, et s’en servir pour la recette. On va pas présenter toute la notice, je veux juste vous montrer qu’elle existe et comment elle fonctionne.

Première règle : avoir un fil d’arianne. Ça permet à tout le monde de se repérer dans le site. Ça permet de remonter dans l’arborescence du site. Toujours situé au même endroit. Et des captures et exemple pour mettre en situation. Des astuces pour différencier la page courante et les autres. Une autre fiche : un intitulé explicite. c’est pour les lecteurs d’écran qui vont naviguer de lien en lien pour éviter « lire la suite, lire la suite, lire la suite… ».

C’est aussi valable pour d’autres handicaps visuels : faciliter la reconnaissance des liens etc. (soulignement par exemple) Exemple sur les formulaires : ne pas gérer de l’espace de ce genre. L’espacement continu pose problème. Des utilisateurs ne voient qu’une partie de l’écran. Ou le lien entre l’étiquette et le champ n’est pas évident (et faire le lien entre 2 éléments distants est alors difficile). Toujours faire en sorte que l’étiquette et le champs soient le plus proches possibles.

Public : Est ce qu’un select c’est très utile pour la civilité ? David : Pas de soucis pour l’accessibilité, c’est plus une question UX/UI, j’ai pas d’avis sur la question. Soit tu parcours une liste, soit tu parcours les boutons radios. Voilà les différentes fiches, il y en a un paquet je vous laisse aller les voir et vous les approprier. C’est open source, faites votre vie.

Souvent on demande au client de nous solliciter autant que possible, et dès le début du projet. C’est plus facile de demander au graphiste de rajouter un bouton qu’au développeur : faut le designer, faire valider etc. le plus tôt, le mieux. Ça évite de laisser les dev seuls face aux problématiques d’accessibilité. Quand les clients nous écoutent, ils nous envoient les maquettes avant de commencer les intégrations. Souvent, on a peu de choses à dire : on ne parle pas du « design », mais de l’ux.

Les cas les plus courants qu’on rencontre c’est les contrastes insuffisants. Saxoprint par exemple : le orange n’est pas assez contrasté. C’est normal, je suis maquettiste je me pose pas forcément la question, j’ai pas forcément le ratio dans l’oeil. Ça aussi c’est assez fréquent : du texte sur des images. Autour de ces lettres, il y a un ombrage, ce qui pourrait peut-être valider le contraste. À un moment donné, on développait que pour desktop, et on a dû changer la façon de concevoir les expériences. Du coup, on peut intégrer ces nouvelles expériences dès la conception, et pas juste se caler sur le législatif : on peut innover, proposer etc.

Les autres points, c’est l’information portée uniquement par la couleur. Ici on a un carousel : je ne sais pas a quoi sert le vert, mais le blanc c’est la slide actuelle. Du coup si je ne vois pas la différence de couleur je ne sais pas où je suis. L’utilisateur peut avoir inversé le contraste (le blanc étant trop fort, gênant). Exemple sur le formulaire : « 2 erreurs sur le formulaire, veuillez corriger les champs en rouge » : si je suis daltonien impossible de savoir de quel champ on parle. Intégrer les messages d’erreur dès les maquettes, ne laissez pas les intégrateurs choisir vite. Deuxième cas de figure : L’onglet est actif, mais si je ne vois pas la couleur je suis perdu.

Autre exemple : un élément qui bouge. Pour certains, ça rend la lecture impossible car leur attention est accaparée par l’élément mouvant. Il faut prévoir un moyen de mettre en pause l’élément. Idéalement, il faut prévoir un bouton qui stoppe tout sur le site. Si le carousel tourne seul, il faut un bouton pause. Si on laisse l’intégrateur seul : il pourrait faire un gros bouton pause au milieu et provoquer un arrêt cardiaque du graphiste. Donc faut le prévoir dès le départ, tout le monde sera content. Ici on a une vidéo qui se lance automatiquement, aucun contrôle (lecture ou son). A minima, fournir un bouton affichant les contrôles si ceux ci ne sont pas visibles par défaut.

Là, on a vu quelques points embêtant qui « cassent » les maquettes. Si vous avez la main, intégrez ces contrôles a l’image de la marque. Puisque je sais qu’on a des utilisateurs avec des outils différents, je peux aller plus loin que respecter la règle : pourquoi ne pas créer une expérience utilisateur spécifique ? Pourquoi innover seulement pour les valides ? Pourquoi fournir un simple fichier texte, pas stylé, pour quiconque ne peut pas lire une vidéo ? Intégrons ces utilisateurs dès le départ. (lecture de la slide)

Exemple : contraste insuffisant. Quelqu’un a décidé que le gris clair c’est design / luxe. Du coup on a une surenchère sur ces contrastes. D’ici quelques temps, on sera en blanc sur blanc à ce rythme. Si à la fin de la journée de votre écran 30″ vous devez plisser les yeux, alors vous avez un problème de constraste. Si problème de constraste : optimiser la maquette. Qu’est-ce que je peux améliorer ? gris plus dense ?

Sinon, fournir un mode de contraste élevée (par exemple si charte techniquement bloquante) via un bouton sur le site affichant un mode alternatif. Et ça ça passe par la phase design graphique, ce n’est pas à l’intégrateur de gérer ça sur le fait. Exemple sur le site de Le Mans : peu de problème de contraste sur la page. Problème de conception : le bouton pour changer les contrastes est caché, pour cause de mauvais contraste. Et si je l’active, c’est subtil. C’est légèrement moins dense, et ça touche tout. En gros, ajout d’un filtre sombre sur les images mais c’est pas une solution satisfaisante.

Exemple : Oui Sncf. Encore du orange, c’est une problématique importante s’il en est. Ce orange n’est pas accessible. Du coup ils ont mis un bouton accessibilité qui vient transformer le orange en orange maronnasse. Du coup le contraste est valide. Mais quitte a faire ça, autant mettre le bon contraste de départ. Et tous les oranges ne sont pas concernés, du coup des problèmes persistent.

Autre exemple : https://ocirp.fr/ Y’a plein de façons de faire, si vous voulez proposer ces modes alternatifs : les boutons veuvage etc. les couleurs ne sont pas possibles pour avoir un ratio suffisant. Du coup mode alternatif : on passe en noir et blanc. Je dis pas que c’est la meilleure solution, mais c’est la solution qui a été retenue. Les webmasters maintenant ne travaillent qu’avec ce mode car ils trouvent le site plus agréable, plus reposant (et repassent de temps en temps en couleur spour vérifier que tout fonctionne). L’idée c’est d’anticiper un problème en phase graphique, de le résoudre et d’apporter les solutions à l’équipe front. C’est pas le boulot du front de redesigner le site pour régler ces problèmes.

Autre problème courant : justification du texte (exemple issu de Le Monde.fr) C’est pénible à lire, et pour certains c’est impossible à lire (exemple : celles et ceux qui lisent avec leurs doigts). Pas de solution à ça : ne justifiez pas vos textes. Déjà sur papier c’est pas terrible mais vous avez la main sur la mise en page. Sur le web c’est juste infaisable, ça change trop souvent.

On a souvent cette remarque : « ces points peuvent être traités en phase technique ». Ça ne veut pas dire : laisser les dev se débrouiller avec les maquettes finies. Exemple : les liens d’évitement : le principe c’est d’accéder directement du contenu et passer outre le menu (utile quand on ne peut pas utiliser de souris). Dans ce cas, il a été prévu. Il est pas élégant, mais il existe. En gros, rien n’a été prévu coté design, les intégrateurs ont ajouté un lien parce qu’il fallait ajouter un lien.

On peut aussi se dire qu’en phase de conception on peut proposer aux utilisateurs clavier une expérience personnalisée : HSBC propose des raccourcis pour atteindre certaines sections etc. Bref : ça propose une expérience différente. Si je suis à la souris je ne vois pas ces éléments, donc ça ne me gêne pas. Evidemment, on ne met pas 25 liens dans les liens d’évitement.

Puisque je sais que j’ai des users au clavier, pourquoi est-ce que ne je proposerais pas seulement des liens d’évitements qui s’affichent au focus … (?) Je peux avoir une autre réflexion : celui-là est persistant : quand j’ai tabulé il reste visible. Celui-là est différent, il indique la cible de l’ancre au focus du lien d’évitement. C’est une expérience différente, adapté à un public particulier, qui précise visuellement où vous allez atterrir.

Prévoir la visibilité de la prise de focus. Souvent en maquette on va avoir un effet de hover (survol) et ça sera pareil pour le focus. Mais des fois c’est pas si simple. Et il ne faut pas laisser l’intégrateur décidé seul : exemple du pointillé qui tache sur un site luxe. L’intégrateur a choisi seul, sans validation graphique. Il faut réfléchir aux différents états dès les maquettes (focus, survol…). Exemple : survol de lien, au hover le soulignement disparait. A la souris c’est gênant, mais au clavier il manque une information, c’est pas idéal.

Ici la prise de focus = conteneur encadré en bleu. Et ce n’est pas une expérience qu’on propose aux utilisateurs à la souris. C’est bien que ça soit visible, mais ça pourrait être bien que ce soit joli aussi pour les utilisateurs au clavier. Je vais terminer sur les transcriptions : Par défaut vous avez une transcription textuelle, et on vous propose d’utiliser la fonction native du lecteur. J’ai une heure de vidéo et un fichier texte sans formatage. C’est dommage. Alors qu’on pourrait proposer … Ici on a la vidéo, et parce que ça a été conçu dès les maquettes : on a un bouton qui vient afficher la transcription, avec une mise en page. Si c’est prévu, c’est facile à faire puisque l’UX a été pensée. Les intégrateurs savent quoi en faire. C’est sympa aussi de formater le texte, c’est plus agréable à lire.

Sur un lien, il faut annoncer une ouverture d’onglet. Il faut aussi annoncer l’extension (le type) du fichier : si je n’ai pas de lecteur PDF je ne vais pas télécharger un fichier PDF. Souvent ces fichiers ne sont pas accessibles, inutile pour l’utilisateur d’aller cliquer. On peut ajouter un icône par exemple. Ou un système d’infobulle, comme ça tout le monde a l’information concernant le lien / son comportement / sa cible. En gros :

• Réfléchissez à ces nouveaux profils utilisateurs. Se dire qu’on est passé des utilisateurs purement PC à des gens qui utilisent des iPhone. Mais on a aussi s gens qui n’ont pas le son, ne perçoivent pas les couleurs etc. Si on a proposé autre chose sur mobile, pourquoi pas pour les autres profils ?
• Intégrez les différents profils dans vos personas etc.
• Identifiez les problèmes dans vos maquettes (s’il y en a). Pensez les alternatives, et des fois l’alternative est plus pratique pour tout le monde.
• Challengez les équipes et travaillez tous ensemble : coordination équipe design / tech.

Voila, merci beaucoup 🙂 clap clap clap

– Session rapide de question, puis dernière présentation, puis manger / boire.

Public : Tu as montré pas mal d’exemples, sans préciser ce qui est bien / pas bien. David : J’ai l’impression que tu veux qu’en tant que designer, tu veux qu’on pense un design universel, sans version alternative. Une version alternative ça te va, ou tu es contre et et tu veux de l’universel ?

Des équipes en recherches, je ne sais pas. Pour le numérique : on est 6 ou 8 personnes pour accompagnement et audit et je ne peux pas compter ceux qui font l’accompagnement sur les projets. Demain je rencontre 7 projets et un designer sera le référent sur ces projets. En gros une dizaine de gens sur l’assurance qualité, avec de plus en plus de relais, d’animateur coté design, code …Pour ce qui est de la couleur : l’alternative c’est mieux de s’en passer. Pour le reste, c’est à voir : par exemple mes parents sont contents de voir le A+/A- car ils ne connaissent pas la fonctionnalité du navigateur. Pour ce qui est des switch, faites-le à fond. Si on peut se passer de l’alternatif tant mieux, et sinon alors aller aussi loin que possible avec une UX sur mesure.

Public : Les utilisateurs en situation de handicap utilisent déjà des outils, donc soit tu vas vraiment plus loin avec une UX sur mesure, soit tu fais de l’universel. Tous les utilisateurs ne sont pas des geeks, ces solutions alternatives peuvent s’adresser à ces gens-là (qui n’ont pas connaissances des outils type lecteur d’écran etc.).

Merci (intervention du time keeper :p )

CSS Grid : sémantique et accessibilité, par Fabien Zibi

CSS Grid : sémantiques et accessibilité, Diaporama (en), 1,2 Mo

Bonjour, je m’appelle Fabien, je ne suis pas expert accessibilité, je suis dev front, intégrateur, et je vais vous parler de CSS grid et de ce que ça engendre en termes d’accessibilité. Je travaille chez Sfeir, si vous voulez me contacter après, vous passer par mon compte Twitter (@_faz). Au quotidien, en tant que développeur, j’ai la responsabilité d’écrire des pages web, HTML, CSS, sans connaissance préalable d’accessibilité, et sans avoir eu la chance d’être poussé par quelqu’un qui m’ait accompagné sur la production des pages. Je me suis posé la queston en préparant cette présentation : qu’est-ce que j’ai pu faire comme bêtises en accessibilité ?

J’avais lu un article que le fait que les navigateurs mettent des styles sur les boutons, on peut mette une div et on règle les problèmes de CSS. ‘text-decoration: none’ permet de ne pas faire des liens moches ‘outline: none’, au sens plus large, permet de gérer le focus. en tant que dev front on a tendance à oublier cette étape, c’est très problématique quand on navigue au clavier. Je vais beaucoup parler de navigation au clavier.

Le texte justifié, je n’y reviens pas. Les div un peu à tort et à travers. Voici la liste des tags HTML, il y en a une grande quantité, je reviens souvent la regarder chez MDN. Le ‘display: none’ permet de ne pas faire lire l’élément par un lecteur d’écran. Le CSS grid, qu’est-ce que ça cache en termes d’accessibilité ? Les designers voient une grille comme une manière harmonieuse de répartir les éléments sur la page. Sur n’importe quelle page web, on trouve toujours une structure de ce type-là. Comment faire ça en CSS, sachant que la boite n’aura jamais la même taille d’un navigateur à l’autre. Historique pour régler le problème :

• Tables : mais notre page n’est pas une table, c’est une page.
• Float : c’est une autre technique, pas prévue pour ça, c’est pour que le texte habille l’image. On l’a détourné, ça se comportait mal, et donc les développeurs ont pris l’habitude d’un hack (clear) en détournant l’utilisation.
• Inline-block : permet d’aligner les éléments, passons.
• Bootstrap : 3 c’est du float, 4 c’est du flexbox.
• Flexbox c’est récent, ça commence à être pas mal, mais ça ne marche que sur une dimension, soit ligne, soit colonne.

Les CSS grid, c’est l’évolution du flexbox en deux dimensions. On crée un quadrillage qu’on numérote, et on va pouvoir placer des éléments sur cette grille. Plutôt que de vous dire « quelque chose se met en haut, en dessous, à côté », maintenant on se dit « sur quelle case je pose mon élément ». La syntaxe est assez basique : on donne une grille, un nom de ligne et de colonne, et ensuite, pour placer un élément, on lui donne les coordonnées du point de départ et du point d’arrivée.

Une des raisons pour lesquelles j’ai voulu faire cette présentation c’est parce que c’est une solution un peu miracle pour les développeurs et les chefs de projet commencent à se demander si ça ne vaut pas le coup de passer aux grids, le support navigateur reste assez bon. Je vais vous montrer une petite grille.

Disons que je crée un grand élément, c’est le conteneur global de la page. (il tape – codepen) J’ai créé une case, je définis une grille : ‘display: grid’ Ça ne change rien pour l’instant. Maintenant je dis combien de colonnes et de lignes je veux. Je vous passe la syntaxe, c’est une méthode ‘repeat()’ ‘fr’ c’est une nouvelle unité de mesure amenée par les grids : quelle fraction d’espace disponible j’alloue à chaque ligne. Si je mets(trop vite pardon) Je fais la même chose pour créer des colonnes ‘grid-template-columns’ Pour l’instant, on ne voit rien, c’est une nouveauté par rapport aux CSS d’avant : on définit tout les conteneurs et ensuite on va les remplir et la magie opère. Ici, j’insère une div.cell, je vais faire un carré de 16 cases (4×4) Ma grille se remplit, je mets un petit écart entre les cellules (‘grid-gap’) pour qu’on les voie.

J’ai créé ma grille en quelques lignes de code. Là où ça devient intéressant, c’est qu’on peut – je vais mettre un footer, il va se positionner sur la 3e ligne, 1ere colonne, et finir 3e ligne, 5e colonne, et je lui mets un background vert J’insère mon footer.footer, et là je peux redimensionner l’écran, il sera toujours en bas et fera toujours la taille de tout le contenu.

Cependant si je ne fais pas attention à ce que je fais, là où j’importe des fichiers, je n’ai pas tout le HTML sous les yeux, mon footer peut se retrouver perdu au milieu du code, ça ne pose pas de problème en design mais le screen reader va potentiellement voir le footer au milieu du contenu avant des contenus utiles pour le lecteur dans la page. Imaginons mettre une liste d’éléments : vous voyez que si mes 4 cellules (par exemple 4 orateurs l’un à côté de l’autre), chaque orateur serait un élément de la liste. Un < ul > prend une place dans la grille, et les 4 orateurs sont dans une seule case de la grille. On est tenté de mettre le code « à plat », et on va pas s’embêter avec le code HTML ; on perd alors toute notion de sémantique HTML. Il y a des solutions pour pallier à ce problème.

En résumé : la définition sortie de ma tête, c’est donner la meilleure expérience utilisateur à tout le monde. Je me suis concentré sur la navigation au clavier. Vous avez vu, mon footer est en haut dans le code mais en bas visuellement, il n’est plus à sa place. La sémantique veut donner du sens à ce qui est dans le navigateur pour le retranscrire à l’utilisateur.

Avec la grid, on ne donne aucune information sur la relation entre les éléments. Le conseil que j’ai vu, c’est d’écrire notre page en se concentrant sur l’accessibilité et la sémantique, et ensuite appliquer la grille. Si on a un problème de présentation, c’est soit qu’on a mal conçu sa page, soit qu’on doit revenir sur son code.

Une nouvelle propriété qui arrive, c’est ‘display: contents’. Aux yeux du navigateur, vous faites disparaître l’élément mais aux yeux du lecteur d’écran il est encore là. Si j’ai une grille, h1, etc, ul, deviennent des cellules de la grille avec ‘display: contents’. Suivez Rachel Andrew (@rachelandrew), sur twitter, elle a proposé les subgrids, qui permettent de définir des sous-grilles qui se caleraient sur la grille supérieure pour régler le problème.

Le mot de la fin c’est « Verschlimmbesserung », un mot allemand intraduisible en français : c’est une action pour améliorer les choses qui a un effet pour améliorer les choses mais peut avoir l’effet inverse. On croit faire bien, plus joli etc, plus simple, et on crée des problèmes dont on n’est pas conscient.

Public : En réalité il n’y a pas d’incompatibilité entre cssgrid et l’accessibilité dès lors qu’on est rigoureux ? Fabien : Non il faut juste faire attention et compartimenter sémantique et style

Public : le ‘display: content’ pour l’instant ça pose un GROS PROBLÈME, pas reconnu par les screen readers. Il ne fonctionne pas dans les lecteurs d’écrans. Allez-y mollo. Il fait sauter tous les rôles, y compris les rôles ARIA.

Public : pourquoi as-tu fait 100% pour la largeur et un 100 vh (hauteur du navigateur) pour la hauteur ? Fabien : C’est la même chose en fait. Pendant que j’y suis, dans Chrome devtools il y a un outil qui permet de vérifier directement les contrastes. Il y a aussi Lighthouse, qui fait un audit automatique d’accessibilité (incomplet). Vous pouvez l’intégrer à votre usine logicielle, et à chaque build faire tourner un audit d’accessibilité qui fait un compte-rendu, et casser le build s’il ne respecte pas les règles d’accessibilité. (il montre le projet lighthouse ) C’est dans le devtools, il y a un onglet audit : tu choisis l’audit, il te demande ce que tu veux faire, performance, progressive web application, best practices, accessibilité. Tu peux aussi l’invoquer en ligne de commande pendant le build. Public: il se base sur quelle référence ? — le cerveau des gens qui sont chez Google ? 😉 Public : outil open source appelé aXe-core.

(fin des questions, applaudissements)

Phrase de conclusion

Delphine : Merci beaucoup, merci à nos orateurs, et maintenant on va boire un verre ensemble (et des pizzas et des cocas) et prenez des goodies !