#22 – L’accessibilité numérique, un droit pour tous et toutes

Souvenez-vous : dans l’épisode 14, je parlais d’inclusion et de design inclusif avec Gladys Diandoki.

On avait abordé la notion d’accessibilité numérique sans réellement s’y attarder. D’ailleurs, les deux sont bien souvent confondus.

Personnellement, je trouve que l’accessibilité devient un terme un peu galvaudé, utilisé à tort et à travers, sans réellement comprendre ce que cela veut dire. Moi-même, je n’en avais qu’une vague notion avant de m’intéresser à l’UX Writing. Et justement, à ce moment-là, j’ai croisé la route d’Anne-Sophie Tranchet, qui a fait de l’accessibilité son cheval de bataille.

Anne-Sophie est UX/UI designer indépendante. Elle travaille notamment pour BetaGouv, l’incubateur de services de l’État.

Pour elle, l’accessibilité, c’est une évidence. Ça fait partie de son métier de designer. Elle veille à concevoir des produits inclusifs et accessibles à toutes et à tous. Et, l’accessibilité numérique ne signifie pas seulement l’accessibilité d’une interface pour les personnes en situation de handicap.

Mais Anne-Sophie vous en parle bien mieux que moi dans ce nouvel épisode !

Bonne écoute / lecture.

 

 

Notes explicatives

• Open source : le terme fait référence aux logiciels dont le code peut être vu, modifié et distribué par tous.
• Sprint : ou design sprint – processus de création reposant sur une contrainte temporelle, en principe cinq jours, pour résoudre un problème complexe.
• Title : ou balise title – balise HTML qui contient une phrase reprise dans l’onglet du navigateur de l’internaute et le titre qui apparaît dans les résultats de recherche du moteur.

 

Ressources de l’épisode de podcast

• BetaGouv : incubateur de services publics numériques de l’État.
• La DINUM : direction interministérielle du numérique, en charge de la transformation numérique de l’État.
• RGAA : référentiel général d’amélioration de l’accessibilité, qui comporte 106 critères d’évaluation de l’accessibilité numérique.
• W3C : organisme international à but non lucratif dont la mission est de mettre en place les standards du web afin d’en uniformiser le contenu.
• Les notices AcceDe Web : documents pratiques et opérationnels pour la prise en compte de l’accessibilité numérique.
• FALC – Facile à Lire et à Comprendre : ensemble de bonnes pratiques pour simplifier le français, conçu avec des personnes atteintes d’un handicap intellectuel.
• Le blog d’Anne-Sophie Tranchet, une mine d’or de ressources sur l’accessibilité numérique.
• Suivre Anne-Sophie sur Twitter, où elle est très active.

Échanges avec Anne-Sophie Tranchet : L’accessibilité numérique, un droit pour tous

Salut Anne-Sophie, je suis contente de t’accueillir sur le podcast, merci beaucoup d’avoir accepté l’invitation.
Tu es UX/UI designer en freelance, avec une forte appétence pour le contenu. Tu as aussi un sujet de prédilection qui est l’accessibilité et dont on va parler aujourd’hui. Mais, avant de rentrer dans le vif du sujet, j’aimerais qu’on revienne sur ton parcours. Comment es-tu devenue designer freelance ?

À la base, je suis développeuse. Pendant mes études d’ingénieure en informatique, je participais à un projet open source qui s’appelle « Dotclear ». C’est un équivalent français de WordPress. Ce projet m’a permis de tester pas mal de choses différentes. C’est là que j’ai découvert l’ergonomie. J’ai aussi découvert l’accessibilité, c’était une forte composante du projet. Et puis, j’ai également découvert le design.
C’était un terrain de jeu où j’ai fait plein de choses différentes.

Je suis devenue développeuse, mais j’avais toujours été claire avec ma hiérarchie : la partie utilisateur m’intéressait.

Après cinq ans dans mon entreprise, ils m’ont proposé de changer pour un poste dédié à l’UX. J’étais dans une entreprise où il n’y avait personne qui le faisait et où les développeurs et développeuses concevaient les fonctionnalités. Ce n’était pas toujours optimal. Je suis devenue designer un peu sur le tas.

Je suis encore restée trois ans dans cette entreprise avant de me lancer l’année dernière en freelance.

Tu as tout appris sur le tas – l’UX et l’accessibilité ?

Oui, c’est beaucoup d’auto-formation et de veille, avec une forte appétence pour le contenu. Mais j’avais ce syndrome de l’imposteur…

Qu’on connaît tous et toutes (rires).
Tu as l’air d’avoir une forte appétence pour le contenu. Tu t’occupes aussi des contenus quand tu travailles sur des projets ?

Oui, quand je suis devenue UX Designeuse, je me suis un peu renseignée sur ce que j’allais faire. Et j’ai découvert que c’était un métier, UX Writer. J’étais folle de joie. Il y a des gens, c’est leur métier. Ils font ça tous les jours. C’est dingue, quelle chance !

J’aime bien avoir plusieurs casquettes et faire plusieurs choses. Je ne pense pas que ça me plairait de me consacrer exclusivement au contenu.

En tout cas, j’ai tout de suite remarqué que c’était hyper important le choix des mots.

Par exemple, mon premier travail était dans le monde du livre numérique. La plupart des problèmes qu’on rencontrait au SAV, c’étaient des problèmes de compréhension et de wording. « Livre numérique », « e-book », ce sont des termes compliqués. Ou, par exemple, « télécharger », « transférer », « uploader un livre », personne n’utilise les mêmes termes. Les gens ne s’y retrouvaient pas. Une grosse partie des problèmes venait de la manière dont on expliquait ou formalisait les fonctionnalités.

Cela m’a vraiment éclairée sur le fait que le choix des mots est hyper important, et ça fait partie intégrante de l’expérience utilisateur.

C’est hyper intéressant que tu ais bossé sur les livres numériques. Tu m’avais dit que tu avais testé toutes les liseuses possibles et inimaginables. Est-ce que c’est en lien avec ça ? (Rires)

Oui, à l’époque, j’avais testé les liseuses de la concurrence ainsi que les nôtres. Par exemple, pour voir quels termes les gens emploient dans la vraie vie, chez les concurrents, pour s’aligner. Il y a des choses, il n’y a pas de mots qui les décrivent et c’est compliqué de trouver un mot qui va être compréhensible, qui va décrire clairement, pour que l’utilisateur comprenne ce qu’il peut faire.

Je me souviens qu’on avait beaucoup réfléchi sur un livre numérique audio. Un livre CD, mais en version numérique, mais ce n’est pas du texte, c’est de l’audio. Il y a le terme « e-book » pour le livre numérique qui se lit, mais le livre numérique audio, il n’y a pas un seul terme.

Dans un menu, « afficher mes livres numériques audio » veut dire plein de choses. « Bibliothèque » ça veut aussi dire plein de choses : c’est l’endroit dans lequel tu ranges tes livres, et c’est là où tu les emprunte. Donc, où est-ce que tu affiches les livres que tu as empruntés à ta bibliothèque ? Tu ne peux pas les afficher dans la bibliothèque de ton application parce que l’utilisateur ne comprend pas si « bibliothèque » ça veut dire telle ou telle chose… C’était hyper intéressant de réfléchir aux bons mots.

À l’heure actuelle, en tant qu’indépendante, tu travailles sur quel type de projet ?

Alors aujourd’hui, j’ai plutôt envie de me spécialiser dans le service public, le design public. J’en avais un peu marre de bosser pour des produits où il y avait un enjeu final de vendre et de faire du profit.

C’est un peu bizarre pour beaucoup de gens, mais moi, mon rêve, c’était de designer les interfaces de la CAF ou des impôts. Un truc que tout le monde utilise, qu’on n’a pas envie d’utiliser, mais justement, je veux que l’expérience soit la plus fluide possible.

En ce moment, je travaille beaucoup pour le service public. Pas nécessairement sur des applications qui sont pour les citoyens. Ce sont aussi des applications qui sont pour des agents publics, qui vont aider les citoyens.

C’est hyper important de soigner les mots pour « déjargoniser » tout ça et être clair et compréhensif. Pour que les gens s’y retrouvent sur tout ce qui est légal ou administratif.

Sacré enjeu ! Mais c’est vrai que, de prime abord, ce n’est pas ce qu’il y a de plus sexy. En tout cas, tout le monde les utilise, alors tu dois vraiment te sentir utile.

C’est ça. Quand on fait un service pour les citoyens, a priori, c’est pour tout le monde. C’est ça qui est hyper intéressant dans la réflexion qu’on a sur un design accessible et inclusif pour tout le monde.

Et justement, au niveau des services publics, est-ce que tu trouves qu’en termes de maturité design, ils le sont ? Sont-ils sensibilisés au design ? Où est-ce qu’ils en sont ?

C’est dur d’avoir une réponse globale. J’ai seulement un point de vue sur BetaGouv.
BetaGouv, c’est un incubateur de l’État.

Un incubateur dans le privé, ça va être une structure qui va aider des startups à naître et à se développer. Dans le public, l’incubateur ne va pas aider des startups, mais il va aider des équipes qui vont s’attaquer à un problème donné.

Par exemple, quand une entreprise crée des déchets, elle doit remplir des papiers pour identifier les déchets, les peser et payer certaines taxes, etc. Il y a une application derrière tout ça, il y a une équipe qui travaille sur cette application pour s’assurer qu’elle est à la fois utile pour les utilisateurs professionnels qui génèrent des déchets ou pour la législation, pour que tout puisse être en règle.

BetaGouv, c’est donc un incubateur et, à la différence d’autres parties de la DINUM – le ministère du Numérique – j’ai l’impression qu’on est un peu plus avancé sur la tech’. Ce ne sont pas les mêmes méthodes de travail.

Le but de cet écosystème de l’incubateur, c’est de travailler avec une logique itérative où, comme dans une startup, avec des sprints, des méthodes agiles, tu testes vite, tu t’améliores, pour ne pas rester dans le monde un peu figé de l’administration.

La DINUM a un observatoire des pratiques numériques. Ils ont recensé les 250 démarches les plus faites par les Français. Sur les 250 démarches faites, je crois qu’il y en a encore un tiers qui n’est pas numérisé, donc elles ne peuvent se faire que par papier. Et il y en a 90% qui ne sont pas accessibles aux personnes en situation de handicap. Donc, il y a énormément de travail à faire de ce côté-là. Même si, aux yeux de la loi, le service public enfreint la loi, puisque depuis le 23 septembre de cette année, tous ces sites-là devraient être accessibles à tout le monde.

Chez BetaGouv, tu fais quoi exactement ?

BetaGouv, c’est une centaine d’équipes autonomes qui travaillent sur des projets différents, en partenariat avec un ministère différent.
Je suis dans une équipe transverse. Je ne travaille pas sur un projet en particulier. Je suis plutôt une aide pour toutes les autres équipes.

On est 6 designers, et on a des compétences assez variées. De mon côté, je vais m’intéresser particulièrement à l’accessibilité. Certains sont plus spécialisés dans tout ce qu’il y a en amont du projet : des ateliers de conception, d’idéation avec les parties prenantes. Certaines personnes sont un peu plus orientées sur tout ce qui est psychologique, biais cognitifs, la dimension UX. On a des formations diverses.

Le but, c’est de pouvoir apporter de l’aide ponctuelle aux équipes parce qu’elles n’ont pas toujours un designer en interne. Il y a des équipes qui sont seulement 2 ou 3. Il y a toujours des développeurs, des développeuses. En revanche, le design, c’est ce qu’on essaie de promouvoir et de pousser. Alors on joue un peu le rôle de l’échantillon gratuit où, pendant un mois ou deux, on accompagne les équipes sur une problématique donnée et on leur dit « regardez comme c’est hyper intéressant d’avoir un designer dans l’équipe pour vous accompagner sur ces choses-là ». Le but, c’est de leur donner envie de recruter en interne.

C’est hyper enrichissant aussi pour toi de travailler sur différents projets !

C’est assez chouette, même si ça vient aussi avec l’inconvénient de ne pas pouvoir s’investir à fond dans un projet. C’est plutôt papillonner d’un projet à l’autre et parfois, on a envie d’aller plus loin, de pousser plus. Mais on essaye justement de bosser avec le plus d’équipes possibles pour avoir le plus d’impact possible et ensuite de confier la relève à des designers qui seront vraiment intégrés dans l’équipe.

D’accord. Si on revient sur le sujet principal de nos échanges, pour toi, c’est quoi l’accessibilité ?

L’accessibilité, pour moi, c’est un droit.
Si on parle d’accessibilité numérique, c’est pour que les personnes puissent accéder à un service numérique, peu importe leur manière d’accéder au web, si elles ont un handicap physique, mental, psychique, temporaire ou permanent.

L’accessibilité pour toi, ça concerne les personnes qui ont un handicap ?

Oui, ce sont les personnes qui ont un handicap temporaire ou permanent.
Je crois qu’une personne sur cinq est concernée en France.

En fait, on a en tête des personnes en fauteuil roulant ou des personnes aveugles, mais il y a des maladies qui peuvent être beaucoup plus court terme, ou on ne voit pas tout de suite le lien de cause à effet entre le handicap et la vie numérique.

Par exemple, la sclérose en plaques, c’est une maladie qui peut causer des troubles de l’attention ou de la mémoire. Ça va être difficile de compléter des démarches sur Internet, surtout si elles sont compliquées et mal conçues.

Tout ce qui va impacter notre corps va impacter comment on utilise des services numériques.

Aujourd’hui, il y a encore une confusion entre le terme d’accessibilité et l’inclusion.

J’ai eu du mal à comprendre la nuance. Il y a des choses qui vont se recouper. Quand on travaille sur un design inclusif, on œuvre pour l’accessibilité et vice versa. Mais ce n’est pas la même chose parce que ce ne sont pas les mêmes enjeux. L’accessibilité, on va penser spécifiquement aux personnes en situation de handicap. Si ton site n’est pas accessible, tu ne pas y accéder, tu es exclu. Alors qu’un design inclusif va faire en sorte de penser à tout le monde, quel que soit le « critère », pas seulement la situation de handicap, mais aussi le lieu de vie, la situation économique, le niveau d’éducation, la barrière de la langue, l’âge…

Ce sont peut-être des généralités, mais l’inclusivité, tu vas éviter d’avoir une expérience trop frustrante. Typiquement, là en signant un formulaire, je ne pouvais pas mettre un tiret dans mon prénom. C’est frustrant. Ce n’est pas inclusif, mais je peux contourner cet obstacle en enlevant le tiret, en mettant un espace. Mais une personne qui est aveugle et qui n’a pas d’alternative à une image textuelle, elle n’aura pas d’alternative. Elle sera bloquée, elle ne pourra pas utiliser le service. Ce n’est pas du tout le même enjeu.

Donc, finalement, est ce qu’on peut dire que l’accessibilité, c’est un pan de l’inclusion ?

J’ai essayé de dessiner un diagramme de Venn pour comprendre. Et je pense qu’ils sont tous les deux profondément imbriqués, mais il y a des démarches que tu vas faire en accessibilité, ça ne va servir qu’à l’accessibilité. Ça ne se recoupe pas entièrement. Ce n’est pas l’un ou l’autre, ce sont des enjeux différents, mais qui sont assez complémentaires. Généralement, quand on est dans la démarche de l’un, de toute façon, on œuvre aussi pour l’autre.

Pourquoi es-tu tombée dans la marmite de l’accessibilité ? Pourquoi tu en as fait son cheval de bataille, ton sujet de prédilection ?

C’est une très bonne question. Je ne saurais pas trop te dire pourquoi fait. Ça me parait normal, parce que pour moi, c’est le prolongement de l’UX.

Il y a des usagers, ils ont besoin de faire quelque chose, ils rencontrent des problèmes. Comment est-ce que je peux les aider à résoudre ce problème ?

Je ne vois pas des tonnes de différences avec d’autres parties de mon métier d’UX designer. Et quand je vois que parfois, on peut passer des heures à pinailler sur des détails de couleurs ou de wording, et après on va dire « ah non, on n’a pas le temps de rendre ce site accessible » … Il y avait ce côté injuste et l’incompréhension. Pourquoi ça ne parait pas important l’accessibilité ? Ça m’a beaucoup interpellée.

Mais sinon, j’ai toujours été dans une démarche où j’aime faire les choses bien. J’aime bien les best practices. Et l’accessibilité, ça fait partie du package de choses que je voudrais concevoir.

Tu trouves que ça prend de l’ampleur, ce sujet ? Qu’on a vraiment envie de faire des interfaces accessibles, ou alors c’est juste un effet de mode ?

J’ai un biais. Depuis que je suis à mon compte, je peux vraiment m’y intéresser, ça fait partie de mon métier. Je ne vais pas faire quelque chose de non accessible. En tout cas, j’essaie dans la mesure de mes compétences. Depuis que je suis à mon compte, c’est beaucoup plus présent dans ce que je fais, dans ce que je dis.

Mais depuis septembre, les sites du service public et les sites qui ont un certain chiffre d’affaires annuel ont une obligation d’accessibilité. Forcément, je pense que ça fait qu’on en parle un petit peu plus. J’ai l’impression qu’il faut toujours passer par cette carotte – « attention, vous allez avoir une amende » – pour que ça devienne un sujet. Mais en tout cas, dans le service public, c’est un truc dont on commence à parler.

Pour l’instant, c’est encore en mode « oh mon Dieu, il faut que je fasse quelque chose, mais je ne sais pas quoi faire », mais au moins on en parle. C’est déjà pas mal.

C’est toujours un premier pas, même si oui, il y a la carotte au début.
Est-ce que tu pourrais donner des exemples de non-accessibilité, de barrières rencontrées sur les interfaces, selon différents types de publics ?

Ça va dépendre des types de handicaps.

Par exemple, le podcast est un format audio. Un format audio, ça veut dire que ce n’est pas accessible aux personnes qui ont des problèmes d’audition, qui sont malentendants. Mais, si on parle d’inclusivité, c’est aussi peu accessible pour les personnes dont la langue française n’est pas la langue natale, parce que ça peut être plus difficile de comprendre le texte par écrit, par exemple.

Les barrières, ça peut aussi être, sur les sites ou les applications, la manière dont on navigue et on accède à un service.
Toi, tu utilises surement un clavier et une souris, mais tout le monde n’utilise pas ces supports parce que pour avoir une souris, il faut une main. Il faut une main qui sache avoir une certaine mobilité. Il faut être précis dans ses gestes. Si tu as des troubles moteurs, si tu as un manque de mobilité, si tu as un bras dans le plâtre, tu vas le faire difficilement. Donc, peut-être que tu préfères utiliser un clavier, ou que tu préfères utiliser la reconnaissance vocale pour pouvoir naviguer, ou une plage braille. Il y a énormément de manières de naviguer sur Internet. L’idée, c’est qu’un site soit compatible avec ces choses-là. S’il est bien conçu, il l’est, mais s’il est mal conçu, il ne l’est pas.

Il y a plein de manières de configurer son ordinateur pour qu’il affiche les textes en plus gros, qu’il augmente les contrastes, ce genre de choses. Mais il faut que le site le supporte. Sinon, ça ne marche pas.

Côté contenu, je prends un exemple tout bête. Moi, je bosse beaucoup avec des formulaires parce que je suis sur des applications administratives. Si le formulaire n’a pas des libellés ou si les libellés sont incompréhensibles, ou s’ils ne sont pas rattachés aux champs que tu dois remplir, il y a tout un tas de personnes qui ne vont pas comprendre, qui ne vont pas pouvoir remplir le formulaire parce qu’elles ne sauront pas ce qu’il faut mettre dans tel champ.

Tous les ans, il y a des études qui montrent quelles sont les erreurs d’accessibilité les plus fréquentes sur des sites. C’est souvent les mêmes. Ce sont des erreurs vraiment bateau. Par exemple, les textes ne sont pas assez contrastés, donc pas assez lisibles.

Je vois souvent sur des sites que le texte est en noir. Mais j’avais lu quelque part que ce n’était pas ce qu’il y avait de plus adapté et qu’il valait mieux mettre un gris anthracite, par exemple.

Au contraire. D’ailleurs, on dit en noir sur quelque chose, parce que noir sur noir par exemple ce n’est pas top (rires). Mais non, un noir sur blanc, c’est génial, ça se voit bien.

Sur les couleurs, c’est un peu un piège, parce que tu ne pourras jamais satisfaire tout le monde. Il y a des gens pour qui ça va être trop contrasté, ils vont avoir des migraines. On parle de cas vraiment exceptionnels. Mais pour la plupart des gens, il faut que le texte soit suffisamment contrasté. Noir sur blanc, c’est encore ce qui se fait de mieux.

Après, d’un point de vue interface, graphisme, esthétique, on va plutôt conseiller de prendre un gris foncé dans un ton chaud. Par exemple, si ton site est dans les bleus, tu prends un gris bleu. Esthétiquement, c’est un détail, mais qui fait que visuellement, c’est joli.

En revanche, si tu fais du gris clair sur blanc, ça marchera hyper bien sur ton Mac, mais quelqu’un qui a des troupes de vision, ou quelqu’un qui a un écran mal éclairé, il ne verra rien sur mobile en plein soleil. Il ne verra pas ton texte.

Puisque tu en parlais… Souvent dans un formulaire d’inscription, il y a le champ « mot de passe » et en dessous, le nombre de caractères à renseigner. Parfois il n’y a pas cette indication, et c’est très, très énervant quand tu tapes un mot de passe et qu’on te dit ensuite « il faut tel type caractère ». Sur d’autres sites, c’est une phrase qui précise le type de caractères en dessous d’un champ. Mais mieux vaut le mettre au-dessus, non ? Pour qu’un lecteur d’écran puisse le lire par exemple.

En fait, tu peux. C’est important de penser le contenu de manière linéaire parce que nous, on a une vision très linéaire de la page. Quelqu’un qui lit avec une plage braille ou qui utilise la synthèse vocale pour entendre la page, elle n’a pas cet aperçu global. Si tu lui donnes les instructions après lui avoir demandé son mot de passe, ça ne va pas lui servir. Après, selon la manière dont tu codes ton application, tu peux quand même le mettre après, et via des balises dédiées, tu fais le lien entre la consigne et le champ.

J’en profite pour glaner des petites infos, des conseils (rires).
Si on revient sur les erreurs, as-tu d’autres erreurs fréquentes qui sont relatives au contenu ?

Il y a tout un ensemble de textes cachés qu’on ne voit pas sur un site. Tout ce qui est texte alternatif des images par exemple. Ou le title d’une page, ce que tu vois en haut dans ton onglet, c’est la première chose qu’une personne qui utilise un lecteur d’écran va entendre, ou c’est la chose qui va s’afficher quand tu bookmark une page, ou c’est la chose qui va s’afficher quand tu fais une recherche Google. Donc, ce truc-là, il est hyper important et ce n’est pas quelque chose qu’on pense souvent à designer, qu’on pense souvent à expliciter.

Le problème, c’est que si on le laisse aux développeurs et développeuses, ça ne veut pas nécessairement dire que ça va être mal fait, mais peut-être qu’on ne va pas y porter autant de soin et autant de réflexion que si on le prend comme partie intégrante de ce qu’on veut livrer.

Pareil pour les liens, les boutons… Si tu as plein de « lire ici » ou « lire la suite » sur une page, ce n’est pas optimal pour plein de raisons. Pour des raisons d’accessibilité, notamment.

Ça m’est déjà arrivé de faire des liens sur des images, par exemple dans une newsletter. Et puis, je me suis dit qu’il faudrait peut-être que je rajoute en plus un petit texte au-dessus pour avoir une alternative et mettre le lien là-dessus.

Oui, pour tous les gens qui vont seulement avoir le texte de ton email, c’est utile.

Il y a d’autres erreurs fréquentes dont tu voulais parler ?

Le top 5 des erreurs fréquentes, ce sont les textes pas contrastés, le manque d’alternatives aux images, les liens vides. Et puis le dernier, ça doit être les labels dans les formulaires.

Après, tu as deux moyens pour savoir si un site est accessible. Tu as le moyen légal. En France, c’est le RGAA. Tu as 106 critères. Ce sont des choses à vérifier sur ton site.

Est-ce que mes images ont une alternative textuelle ? Est-ce que le titre de ma page est clair et cohérent ?

Tu as 106 questions à te poser. C’est long et fastidieux de les vérifier. Certaines ne sont pas à la portée de tous. Pour certaines, il faut des compétences techniques pour les vérifier, mais il y en a beaucoup qui sont relatives au contenu. Et donc, si tu suis tout ça techniquement, légalement, ton site est accessible.

Mais, dans la pratique, c’est comme te demander si ton site à une bonne UX. Tu fais des tests utilisateurs, tu te rends compte qu’il y a des choses qui ne sont pas idéales.

Un site peut être accessible, mais avoir une super mauvaise UX pour quelqu’un qui navigue au clavier, parce qu’il va devoir tabuler pendant des heures et des heures avant d’arriver à la bonne page. Ce n’est pas parce qu’un site est accessible légalement qu’il est facilement utilisable et vice-versa. Parfois, il ne faut pas se concentrer sur avoir un bon score RGAA, mais penser concrètement à ce dont les utilisateurs ont besoin pour utiliser le service.

Une question un peu large, tu y réponds comme tu veux. Comment on fait pour rendre une interface accessible ?

Il y a plein de manières d’y répondre.

Au début, je trouve que ce qui fait peur dans l’accessibilité, c’est qu’on a envie de bien faire. On veut rendre une interface accessible. Mais en fait, on ne sait pas ce que ça veut dire, l’accessibilité. Et l’accessibilité, ça veut dire plein de choses parce que ça s’adresse à plein de personnes différentes qui ont plein de besoins différents. Pour moi, la première phase, c’est de sensibiliser et de comprendre vraiment : c’est quoi les types de handicaps ? Pour un type de handicap visuel, quelle barrière tu rencontres ? Quand le handicap est auditif, quelles barrières tu rencontres ? Quand ce sont des troubles de l’apprentissage, quels vont être les problèmes ? Et une fois que tu comprends un peu mieux ces enjeux-là, tu peux réfléchir à ton interface en cohérence avec tout ça.

La deuxième chose aussi importante, à mon avis, c’est de voir dans une équipe quel rôle tu peux jouer et quelle responsabilité tu peux avoir. Parce que l’accessibilité, c’est un peu le rôle de tout le monde et donc personne ne le fait.
C’est une question que je me pose souvent parce que j’ai des casquettes différentes, en tant que designeuse ou en tant que rédactrice de contenu. Et puis, comme ça, je vais lancer la discussion. Quand ça va passer en développement local, si je parle ouvertement aux développeurs des efforts que j’ai fait en accessibilité, ils vont plus se l’approprier et ils vont continuer ces efforts là quand ils vont coder l’application.

Si on est force de proposition en amont et si on en parle vraiment en disant les mots « accessibilité » sans que ce soient des gros mots, on lance des discussions. Et puis on intègre ça de manière plus naturelle et fluide au projet.

De manière plus concrète, quand je bosse sur les interfaces l’aspect visuel, le premier truc que je vais faire, c’est de trouver la palette de combinaisons accessibles, les couleurs que je peux utiliser ou pas.

Un exemple fictif, mais qui revient souvent, c’est l’entreprise Orange. Leur couleur principale, c’est l’orange. Et l’orange, c’est une couleur horrible en accessibilité parce qu’elle n’est pas assez lisible sur fond blanc et n’est pas assez lisible sur fond noir. C’est la galère. Du coup, qu’est-ce que tu fais quand tu as une couleur métier comme ça qui n’est pas compatible ? Il y a plein de manières de gérer la solution.
Orange ont fait des articles assez chouettes là-dessus.

En tant que designeuse, la première chose qui m’intéresse, c’est le design des couleurs. Mais maintenant, je réfléchis aussi beaucoup, côtés contenus, à tous les livrables que je peux fournir en plus, pour vraiment axer la discussion sur l’accessibilité. Tous ces contenus cachés, les titres des pages, bien insister sur les formulaires… La hiérarchie du contenu aussi, c’est hyper important, parce que les personnes qui sont aveugles et qui lisent avec un lecteur d’écran, ça peut être hyper long pour elles d’entendre toute la page. Elles vont plutôt lire les titres et puis aller directement vers la section qui les intéresse. Exactement comme nous, quand on arrive sur une page Internet, on ne va pas tout lire mot à mot. On regarde vite fait et on s’arrête là où on voit un gros titre. Et si ta hiérarchie du contenu est mauvaise, ça va être hyper dur pour eux de s’y retrouver. Et ça, c’est purement du contenu, de réfléchir à ton plan, à tes titres et ce sont des choses intéressantes.

Nous, quand on lit une page, on scrolle et on tombe sur un titre. Un lecteur d’écran, ça fonctionne comment ? Il y a cette possibilité d’aller de section à section ?

Alors je ne suis pas pro des lecteurs d’écran, parce que ce sont des logiciels complexes à utiliser. Et même les personnes qui les utilisent tous les jours, elles ne sont pas nécessairement pro. De même que tous les gens qui utilisent un navigateur ne connaissent pas toutes les subtilités d’un navigateur. Mais j’essaye parfois d’utiliser le mien sur mon téléphone parce que je trouve le logiciel un peu plus facile d’accès que sur ordinateur. Ça me permet de tester facilement.

Tu as plusieurs modes de navigation. Tu peux naviguer par titre, tu peux naviguer par lien. Par exemple, tu vas dire « suivant, suivant, suivant », et ça va te lire tous les titres des liens. Tu vas avoir « lire la suite, lire la suite, lire la suite – ah zut lequel je veux », par exemple. Tu peux lire par titre, mais si tu as un trou dans la hiérarchie – un titre de niveau 1 et directement en-dessous un titre de niveau 3 – je ne vais pas pouvoir y accéder parce qu’il manque le titre de niveau 2. Donc, je ne vais pas facilement accéder à quelque chose.

Tu peux naviguer par phrase. C’est l’équivalent de lire phrase par phrase.

Et puis tu peux naviguer par section. Je ne sais pas si tu connais le HTML. En HTML 5, tu peux découper ta page en sections. Tu as la navigation, la sidebar, les sections, les articles… Comme ça, tu peux te retrouver un peu dans la page, en sachant que si tu veux aller dans un autre menu, tu vas chercher « Nav » ou « Menu » par exemple.
Et là encore, c’est du contenu caché.

Admettons, tu as la barre de menu pour aller sur les pages de ton site, et puis tu as la barre de menu des réseaux sociaux qui est dans ton footer, et puis tu as encore une barre de navigation qui va présenter les sites partenaires… Dans ton code, tu vas avoir 3 navigations. Ton lecteur d’écran, il va dire les 3, mais s’ils n’ont pas de titre, la personne qui utilise le lecteur d’écran ne saura pas dans laquelle il faut aller. Elle va commencer à les écouter, elle ne trouve pas ce qu’elle cherche, alors elle va à la suivante. Ça c’est un exemple de contenu qu’on peut proposer aux développeurs et développeuses, ce sont des titres pour ces sections-là.

D’accord.
Le métier de designer se spécialise de plus en plus. Maintenant, on retrouve un UX designer, un UI designer, un UX Writer… Est-ce que tu penses qu’il y a un métier qui se développe sur l’accessibilité ? Un designer qui est focus sur l’accessibilité ?

C’est une bonne question. Quand je vois les intitulés de postes autour de l’accessibilité, je vois assez peu de postes qui seraient orientés accessibilité et design. Tu vas avoir des « advocates of accessibility » qui vont évangéliser l’accessibilité. Tu vas avoir beaucoup de métiers sur l’aspect technique de l’accessibilité, parce qu’il y a une grosse part qui revient sur le code.

Tu as beau penser le truc en amont, derrière si le code ne suit pas, ça ne va pas être accessible.

Mais non, à ma connaissance, il n’y a rien et c’est pour ça que j’ai commencé à faire une veille sur l’accessibilité orientée pour les designers. C’est parce que j’avais besoin de comprendre quelle était vraiment ma responsabilité et pas simplement dire « non, ça, c’est pour le chef de projet ou ça, c’est pour le développeur ». Et je pense qu’il y a encore du travail à faire pour justement proposer des outils, des checklists. Je ne veux pas dire que rien n’est fait, au contraire, mais je pense qu’il y a encore plein de choses à faire pour montrer que les designers et les créateurs de contenu ont une grosse place à prendre là-dessus. Et justement, ce que j’essaie de faire, c’est de l’intégrer au métier qu’on connait.

Je n’ai pas envie d’être UX designer spécialisée en accessibilité. Je suis UX designer et dans mon métier, l’accessibilité fait partie de ce que je veux faire. Ça en fait partie comme plein d’autres choses.

Est-ce que c’est possible d’être entièrement accessible, de concevoir une interface qui est entièrement accessible ?

D’un point de vue légal, tu peux être entièrement conforme. Si tu respectes 100% des critères du RGAA. Par exemple, « Mon parcours handicap » est un site du service public pour aider les personnes en situation de handicap à faire des études ou des formations. Il est entièrement accessible, mais l’accessibilité de manière notée et graduée est en constante évolution. Il y a un groupe de travail qui travaille depuis que le Web existe sur ces sujets-là, et ils sont continuellement en train de travailler sur comment est-ce qu’on évalue l’accessibilité ? Comment est-ce qu’on la mesure ? C’est toujours en évolution.

Pour donner un exemple, aujourd’hui, quand on mesure l’accessibilité, on vérifie des critères, on vérifie qu’ils sont présents sur tous les sites.

Par exemple, si sur ta page d’accueil, il n’y a pas une alternative à une image, mais que tu peux quand même remplir le formulaire pour faire une demande de déménagement et prévenir la CAF, ton site ne sera pas 100% accessible parce qu’il y a un problème, mais en fait, ce problème n’est pas limitant pour suivre un parcours. Et, a contrario, tu pourrais être à 99% accessible, mais avoir un problème d’accessibilité sur la dernière étape du parcours, ce qui fait qu’un utilisateur aveugle ou qui a des troubles moteurs ne pourra jamais finaliser le parcours. Mais sur ton site, tu as le droit d’afficher « accessible » parce que tu es à 99% accessible. Les gens te diront « ah oui, c’est bien, 99% c’est bien ».

La manière de noter aujourd’hui n’est pas optimale, elle ne prend pas en compte la notion de parcours utilisateur. C’est une méthode qui a été inventée depuis que le Web existe. Il y a des réflexions là-dessus au W3C pour imaginer d’autres manières de réfléchir à ça, pour que ce soit plus en accord avec comment on réfléchit aujourd’hui en termes de parcours plutôt qu’en termes de pages.

Aujourd’hui, la notion de page n’est pas évidente. Typiquement, Deezer, tu es toujours sur la même page, et ça se recharge, ta playlist change. Mais ton URL n’a pas changé. Donc, ce n’est pas évident aujourd’hui, avec les applications complexes, de mesurer avec le système qu’on a aujourd’hui.

Quels sont tes conseils pour rendre une interface accessible ?

C’est facile à dire pour moi qui suis dans le service public. C’est peut-être plus délicat dans des services qui visent à se démarquer, parce qu’on va vouloir essayer de faire différent, de faire original. Tout l’enjeu pour moi, c’est de réussir à être quand même compréhensible pour tout le monde et d’être clair, d’être cohérent. Ce n’est pas évident de trouver le juste milieu, entre faire simple, que ça soit inaperçu, qu’il n’y ait pas de difficultés, et se démarquer. Mais côté contenu, il y a beaucoup de choses à faire sur la hiérarchie, sur tout simplement mettre du contenu. Sur les formulaires, sur les intitulés de lien, d’images, de champs, tout ce qui est caché.

Sur le W3C, il y a 10 choses faciles à vérifier pour qu’un site soit accessible.

Par exemple, un test facile à faire est de zoomer à fond à 200% sur ton site et tu regardes s’il est lisible. Il y a certaines personnes qui ont besoin de beaucoup zoomer pour lire le texte. En faisant ce test-là, tu vas vérifier que ton site est bien codé et que le texte peut être adapté selon les besoins des gens.
S’il est adaptable en zoomant à fond, il est aussi adaptable en étant tout petit. Il y a de fortes chances que les personnes vont pouvoir mettre une police qu’elles arrivent à lire. Si elles sont dyslexiques, elles ont besoin d’une police particulière, par exemple.

Parfois, il y a des tests faciles à faire, qui vont permettre de vérifier un ensemble de choses.

C’est une ressource hyper intéressante.
Si on s’intéresse au sujet de l’accessibilité, si on a envie de monter en compétence là-dessus, est-ce que tu as des ressources, que ce soit livres, blogs, podcasts ou autres ? Quelles sont-elles ?

Alors j’aime bien les notices AcceDe Web. Il y en a 4. Elles sont orientées pour différents types de métiers. Tu en as une notamment pour les rédacteurs de contenu et une pour ceux qui font des interfaces graphiques.
C’est un ensemble de checklist sur les bonnes pratiques à respecter. Et j’aime bien le côté très concret qui s’adresse à un métier.

Après, je fais une veille sur l’accessibilité, orientée design. Parce que, justement, il manquait ce côté « qu’est-ce qu’un UX Writer peut faire ? Qu’est-ce qu’un UX designer peut faire quand il est en phase de recherche, quand il est en phase de conception ? »

Typiquement, en phase de conception, il y a des questions qu’on peut se poser tout de suite. Par exemple, si on est sur un outil de cartographie, quelque chose d’hyper visuel : comment on va pouvoir implémenter des fonctionnalités qui vont permettre aux gens qui n’ont pas ces compétences visuelles de s’y retrouver pour savoir si leur département est confiné ou pas ?

Il y a plein d’exemples dans la vie courante. Je m’intéresse vraiment à ces questions. Selon les phases de conception, qu’est-ce qu’on peut faire ou pas ?

Il y a aussi des sites de référence, justement. L’accessibilité, quand on commence à mettre le nez dedans, on peut vite se perdre, parce qu’il y a beaucoup de choses à faire. Déjà tout ce qui est de mettre en place une démarche, convaincre les gens, c’est quelque chose qui revient souvent. Et puis, concrètement, selon le métier, selon ce que tu es en train de faire, ce sur quoi tu travailles, qu’est-ce que tu peux faire à ton niveau ?

Il y a plein de manières de répondre à plein de questions différentes. Il y a des sites qui recensent tous ces outils-là.

Ce sont des supers ressources pour avancer. Effectivement, je me retrouve dans ce que tu dis, on peut se perdre. Je lis énormément sur l’UX Writing, le Content Design, toutes ces choses-là, et dès que je lis un article, je vois qu’il y a un lien avec une ressource intéressante, donc je clique dessus, j’enregistre, parfois je ne m’en sors pas (rires).

Je trouve que c’est intéressant de savoir que ça existe et de s’y pencher quand on sent qu’il y a un projet.

Ça me fait penser à un sujet sur lequel j’ai encore peu bossé, mais qui est dans le contenu : c’est le français simplifié ou le français facile à lire et à comprendre (FALC). J’ai commencé à me former pour comprendre vraiment ce que c’est et comment est-ce que ça peut être une ressource pour moi en tant que designer.

Le français simplifié, c’est un ensemble de bonnes pratiques pour pouvoir écrire en français simplifié, comme son nom l’indique (rires). Un français facile à lire et à comprendre. Et pour vraiment mériter l’attribut « facile à lire et à comprendre », les documents doivent être rédigés avec des personnes qui ont des troubles mentaux. Les utilisateurs concernés sont impliqués.

C’est quand même une écriture qui est hyper spécifique. Tu ne peux pas faire du français simplifié dans toute ton interface, parce que, par exemple, tu dois mettre une phrase par ligne, faire des gros sauts de lignes… C’est assez particulier, mais il y a énormément de bonnes pratiques : éviter le jargon, éviter les formes passives, utiliser des termes simples… Il y a plein de choses, si seulement tout le monde le faisait, ce serait dingue.

Il suffit de montrer l’exemple que tout le monde connait, c’est l’attestation de dérogation. Tu montres une attestation de dérogation en français jargonneux – « je fais une sortie dans le cadre de l’exercice physique de ma personne » – et en français simplifié, c’est « prendre l’air et se promener dehors ». C’est beaucoup plus clair. Tu coches la case « je vais chez le médecin, je fais mes courses ou je prends l’air » plutôt que des phrases de 4 lignes, tu ne sais jamais laquelle choisir.

C’est peut-être issu de notre culture littéraire, mais je ne sais pas pourquoi en français, on s’obstine à faire des phrases longues. Je le vois chaque jour, à partir du moment où quelqu’un écrit, il prend un ton complètement différent et tu as l’impression qu’il va commencer à faire un roman ou une dissertation. Ce sont tout de suite des lignes et des lignes, alors que, oralement, il n’aurait jamais dit des choses comme ça.

En m’intéressant à l’écriture inclusive, dans le sens compréhensible par tout le monde, je me suis rendu compte qu’il y avait pas mal de règles qu’on a appris en cours de français qu’il fallait que je désapprenne : il faut éviter les répétitions, il faut mettre des mots de liaison… Je trouve que pour le Web, il faut écrire de manière simple, il faut mettre des phrases courtes, il faut répéter les mêmes mots parce que les gens vont scanner. On n’a pas la même manière de lire sur le web et donc on ne devrait pas avoir la même manière d’écrire.

Mais comme on est dans des métiers où on a fait des études et on a appris, on est intelligent, il faut qu’on le montre en utilisant des mots compliqués. On a tendance à l’oublier, peut-être. Mais moi, mes premiers jets dans toutes mes interfaces sont immondes, ils sont hyper compliqués. Je fais des phrases à rallonge parce que mon cerveau pense à 4 trucs en même temps. Ok, bon, j’ai écrit ça maintenant, on va le retravailler et on va le simplifier.

L’étape de concision (rires).
Dernière question : si on veut échanger avec toi sur le sujet de l’accessibilité, ou autre, ou si on veut te suivre, où est-ce qu’on peut te contacter ?

Sur Twitter : @anneso_

Oui, tu es très active sur Twitter.
Merci beaucoup, c’était hyper intéressant !

UX Content Craft, la newsletter

Deux fois par mois, directement dans votre boîte e-mails :

• Bénéficiez d’un condensé de ressources pour progresser en UX writing
• Soyez au courant des actualités liées à l’UX writing & au Content design, notamment en francophonie – jobs, événements, etc.

S’inscrire à la newsletter 

 

On garde le contact ?

Vous avez aimé l’épisode ? Dites-le moi en laissant un commentaire, un like ou une note sur la plateforme sur laquelle vous l’écoutez.
N’hésitez à me faire des feedbacks sur l’épisode, pour prolonger le débat, ou sur le podcast en général. Cela m’aidera à l’améliorer, pour qu’il réponde à vos besoins.