Introduction

Pour commencer, je vous informe que la transcription de cette conférence ainsi que le support de présentation sont disponibles sur le web à l’adresse http://a42.fr/blend2017, pour vous permettre de la suivre plus facilement si besoin.

Je m’appelle Marie Guillaumet, et je suis consultante en accessibilité numérique pour la société Access42.

Je suis toujours un peu surprise quand j’entends mes confrères insister sur le fait que l’accessibilité numérique ne serait « pas que » pour les personnes en situation de handicap. Cela m’interpelle.

En tout honnêteté, je trouve cette tournure de phrase assez péjorative. Elle peut laisser penser que les besoins et les attentes des personnes en situation de handicap, dont les personnes qui vivent avec des déficiences permanentes, ne seraient « pas suffisants » pour que nous daignons nous préoccuper d’accessibilité.

Pourtant, concrètement, l’accessibilité du web signifie que les personnes en situation de handicap peuvent utiliser le Web. Elle bénéficie aussi à d'autres, notamment les personnes âgées dont les capacités changent avec l'âge. En tout cas, c’est la définition officielle de l’accessibilité donnée par la WAI (Web Accessibility Iniative) du W3C.

Il est donc plus que temps que nous autres, designers et concepteurs, nous nous penchions sur les besoins et les attentes des personnes en situation de handicap.

Si vous vous intéressez à l’UX (expérience utilisateur), alors vous avez à cœur de répondre aux besoins des personnes qui utilisent les interfaces que vous concevez. Dans ce cas, l’accessibilité va enrichir votre approche et votre pratique du design, en vous aidant à prendre compte des besoins utilisateurs que vous ne soupçonniez peut-être pas.

Je constate qu’on limite souvent les bienfaits de l’accessibilité aux utilisateurs aveugles. Mais en réalité, l’accessibilité concerne tous les handicaps qui affectent l’accès au web, que ce soit les handicaps visuels, les handicaps auditifs, les handicaps moteurs, ou bien les très nombreux handicaps cognitifs, mentaux et psychiques. Sans oublier les polyhandicaps (handicap moteur ou sensoriel + handicap mental) et les troubles de santé invalidants.

En France, d’après l’INSEE, on compte environ 12 à 15 millions de personnes en situation de handicap en France. Cela représente environ 21 % de la population française. Ces chiffres nous prouvent que ceux qui considèrent les utilisateurs handicapés comme « des cas isolés » se trompent.

Maintenant, ce n’est pas inné de connaître la grande diversité des situations individuelles qui existent en matière de handicap.

C’est pourquoi je vous conseille une très bonne lecture pour vous familiariser avec les besoins et les attentes des utilisateurs en situation de handicap en matière de web : c’est le guide Défauts d’accessibilité : impacts sur les utilisateurs. Il explique bien les conséquences provoquées par les défauts d’accessibilité sur les utilisateurs.

Ce guide est un guide d’accompagnement à la prise en main du RGAA (Référentiel Général d'Accessibilité pour les Administrations). C’est la référence légale en France en matière d’accessibilité numérique.

Je précise que le RGAA est basé sur WCAG (Web Content Accessibility Guidelines), les critères d’accessibilité émis par le W3C.

Pas de panique ! Je sais que dès qu’on évoque les standards et les normes, on a tendance à prendre peur.

Et puis ce n’est pas toujours facile de s’y retrouver parmi toutes les ressources et les discours qui existent à propos de l’accessibilité aujourd’hui.

C’est pourquoi je vous propose de rentrer dans le vif du sujet, et vous présenter rapidement deux problématiques d’accessibilité et les solutions concrètes qui existent pour y répondre. Ces solutions sont simples à comprendre, faciles à prévoir dès la phase de conception de vos projets, et amélioreront beaucoup l’expérience utilisateur des personnes en situation de handicap qui utiliseront vos interfaces.

Exemples concrets

Lisibilité : laisser l’utilisateur personnaliser l’interface

La première problématique concerne la lisibilité de l’interface.

Quand vous créez une interface de zéro, vous avez en général le champ libre pour faire vos propres choix de présentation, par exemple en ce qui concerne les couleurs. Vous pouvez donc vous assurer qu’elles respectent les ratios de contrastes exigés par WCAG et le RGAA, qui dépendent de la taille de votre texte mais aussi de sa graisse (pour en savoir plus, lire la fiche Contraste dans le Guide du concepteur RGAA 3).

En revanche, quand vous récupérez la charte graphique d’un gros client, que vous devez la décliner pour le web mais que les contrastes sont insuffisants, vous ne pouvez pas toujours la modifier pour la rendre accessible.

Admettons que vous travailliez pour un client dont la couleur emblématique est le orange : le orange, comme le jaune, est une couleur qui, de base, n'est pas assez contrastée lorsqu'elle est utilisée avec un arrière-plan blanc. Or, à moins de créer un site entièrement sur fond noir, ce qui ne collerait pas forcément à la charte de votre client et poserait sans doute d’autres soucis, il est souvent impossible de proposer une autre nuance d’orange :

  1. d’une part parce qu’une telle couleur ne se modifie pas, même pour le web, car c’est trop stratégique en terme d’identitié de marque ;
  2. d’autre part parce que vous aurez beau triturer le code hexadécimal de votre orange dans tous les sens, vous ne réussirez jamais à le rendre accessible. Au mieux vous obtiendrez un marron pas terrible, bref c’est impensable.

Alors comment rendre ce contraste accessible ? La solution consiste à prévoir sur vos maquettes un « style switcher », c’est-à-dire un petit bouton à activer qui va permettre aux personnes qui en ont besoin, c’est-à-dire les personnes déficientes visuelles, les séniors et les personnes ayant des difficultés de lecture, de renforcer les contrastes du site concerné.

Vous pouvez voir un exemple sur la présentation que Thomas Villain a donnée au WordCamp Marseille 2017. Il y a un bouton intitulé « Fort contraste » sur ce site, qui permet de renforcer les contrastes, et de faciliter ainsi la lecture pour les personnes qui n’ont qu’une vision partielle ou dégradée des couleurs.

Contraste insuffisant
Contraste insuffisant du bleu clair des titres sur fond blanc.
Contraste renforcé
Contraste renforcé sur l’interface : le bleu clair a été remplacé par du noir.

C’est un petit mécanisme qui requiert quelques lignes de CSS et de JavaScript. C’est relativement facile à mettre en place, et ça apporte un gain utilisateur très important. La seule difficulté, c’est de ne pas l’oublier dans vos maquettes et dans vos spécifications !

Pour aller plus loin

Un style switcher accessible peut également permettre d’augmenter l’interlignage sur tous les textes et de supprimer la justification de ceux-ci pour améliorer le confort de lecture.

C’est le cas sur le site du groupe Accor Hotels (leur style switcher est accessible en activant le bouton « Accessibilité », représenté par une roue crantée).

Une option intéressante concerne la police d’écriture. En effet, en activant l’option « Police (dyslexie »), les textes du site sont affichés à l’aide d’une police adaptée à la dyslexie :

Police par défaut
Police par défaut du site, qui peut poser des problèmes de lisibilité aux personnes dyslexiques.
Police adaptée à la dyslexie
Police adaptée à la dyslexie, améliorant la lisibilité du site pour les personnes dyslexiques.

Voilà, l’épineuse question du texte orange sur fond blanc n’a plus de secret pour vous !

Formulaires : faciliter la saisie

La seconde problématique dont je voudrais vous parler pour terminer concerne l’accessibilité des formulaires.

La problématique des formulaires accessibles est particulièrement complexe : l’aborder de manière exhaustive en quelques minutes est impossible. Mais je peux quand même vous donner deux astuces pour rendre vos formulaires plus accessibles.

Les personnes présentant une déficience mentale, cognitive ou psychique peuvent avoir des difficultés à comprendre le contenu d’un formulaire. Elles ont besoin de savoir quels champs sont obligatoires, ce qu’on leur demande de saisir exactement et sous quelle forme.

Aussi, prenez l'habitude d’indiquer le format attendu dans l’étiquette du champ.

Par exemple, si vous avez un champ de formulaire intitulé « Date de l’aller », il faut ajouter le format attendu après l’intitulé, comme « Date de l’aller (JJ/MM/AAAA) ».

Sans cette explication préalable, certains utilisateurs présentant un handicap mental ou cognitif pourraient être dans l’incapacité de remplir ce champ de formulaire sans se tromper.

Même si vous avez prévu d’ajouter un datepicker (sélecteur de dates), prévoyez que le champ de saisie puisse être éditable, et non pas désactivé : en effet, la plupart des datepickers ne sont pas accessibles, et pour bien des utilisateurs, notamment les personnes aveugles ayant recours à un lecteur d’écran, ce sera plus simple de saisir la date eux-mêmes directement.

Si malgré tout, l’utilisateur se trompe dans sa saisie, donnez un exemple de saisie réelle dans le message d’erreur pour l’aider à corriger sa saisie. Par exemple : « Erreur sur la date. Exemple de date : 01/12/2017 ».

Conclusion

15 minutes c’est vraiment trop court, il est évident que cette présentation ne présente qu’une infime partie de ce qu’il est possible de faire en phase de conception pour rendre un site accessible.

Si tout cela vous a mis en appétit, précipitez-vous sur le Guide du concepteur RGAA 3 qui contient plein d’autres exemples de ce genre, et vous aidera à vous familiariser avec les critères d’accessibilité web et à améliorer l’UX pour les personnes en situation de handicap.

Je suis à votre disposition pour toute question, là maintenant tout de suite, après la conférence, et encore demain.

Merci !

La vidéo

Remerciements

Merci au staff de BlendWebMix et de Alsacréations, ainsi qu’à Stéphanie Walter pour la maquette des formulaires.

Icônes créées par mikicon, Jordan Delcros, Hadi Davodpour et Saeful Muslim pour The Noun Project.