L’accessibilité permet aux personnes handicapées de voir, comprendre, naviguer, interagir avec, et de contribuer au Web. Imaginez un monde où les développeurs sauraient tout ce qu’il y a à savoir sur l'accessibilité. Vous concevez et ils le construisent... parfaitement. Dans ce monde-là, seul le design lui-même peut causer de la difficulté d’utilisation par des personnes handicapées.
Ce mode d’emploi couvre les principales choses que vous devez savoir pour que vos produits soient “design-ready” et satisfassent un minimum de normes de la section 508 et Web Content Accessibility Guidelines 2.0. Le reste dépendra du développement et des tests d’utilisation.
1. L’accessibilité n’est pas un obstacle à l’innovation
L’accessibilité ne vous forcera pas à faire un produit laid, ennuyeux ou encombré. Elle présentera un ensemble de contraintes à intégrer pendant que vous concevez votre outil. Ces contraintes vous donneront de nouvelles idées à explorer, des idées qui mèneront vers des meilleurs produits pour tous vos utilisateurs.
Pendant que vous lisez ces conseils, gardez en tête que nous ne voulons pas concevoir des services pour d’autres designers.
Concevez vos services pour l’ensemble varié des utilisateurs qui vont interagir avec vos produits.
Cela peut inclure des personnes aveugles, daltoniennes, qui ont une mauvaise vision, celles qui sont sourdes ou ont des difficultés d’audition, les personnes à mobilité réduite temporairement ou non, ou des personnes ayant des déficiences cognitives. Concevez pour les jeunes, les vieux, les utilisateurs aguerris, les utilisateurs occasionnels, et ceux qui aiment simplement une expérience de qualité.
Adoptez ces directives d’accessibilité comme vous le feriez pour toute contrainte de conception. Elles font partie du défi qu’est de créer des produits étonnants.
2. N’utilisez pas la couleur comme seul moyen de faire comprendre une information
Pensez aux utilisateurs qui ont du mal ou ne peuvent pas distinguer les couleurs. Ceci inclut les daltoniens (1 homme sur 12, une femme sur 200), les malvoyants (1 personne sur 30) et les aveugles (1 personne sur 188).
Utilisez la couleur pour souligner ou compléter ce qui est déjà visible.
Dans cet exemple montré en niveaux de gris, combien de champs présentent réellement une erreur d’après vous ?
La plupart des gens qui voient cette image en noir et blanc disent que la réponse se trouve dans le captcha. C’est parce que le triangle avec le point d'exclamation à l'intérieur indique que quelque chose cloche.
Maintenant, regardez ce même écran en couleur. Combien de ces champs sont invalides ?
Avec la couleur, la réponse devient “tous les quatre”.
Il existe bien des façons de rendre ce formulaire accessible à tous. Vous pouvez mettre l’icône triangulaire rouge dans tous les champs contenant une erreur. Vous pouvez utiliser du texte pour expliquer pourquoi il y a une erreur. Vous pouvez utiliser une bulle flottante, des grosses bordures, un texte en gras, un soulignage, des italiques… Les choix sont infinis, la seule règle étant de ne pas utiliser que la couleur.
Comment changeriez-vous ce formulaire pour que la couleur ne soit pas la seule façon de voir qu’il y a une erreur ?
Note : En fait, ce problème d’accessibilité décrit dans l’exemple de PayPal est dû au plugin LastPass de mon navigateur. Merci à Tony Amidei (@subface), de Paypal, qui me l’a fait remarquer. Normalement, l’icône d’avertissement triangulaire apparaît dans tous les champs invalides.
3. Mettez assez de contraste entre le texte et son fond
D’après le WCAG, le contraste entre un texte et son fond doit être d’au moins 4.5 à 1. Si votre police fait au moins 24px ou 19px d’épaisseur, le minimum descend à 3 pour 1.
Cette ligne de conduite aide les utilisateurs malvoyants, daltoniens ou qui ont la vue qui baisse à voir et à lire le texte sur leur écran. Cela signifie que quand le texte fait 24px, 19px d’épaisseur, ou plus, le gris le plus clair que vous puissiez utiliser sur fond blanc est #959595.
Pour du texte plus petit, le gris le plus clair que vous puissiez utiliser sur fond blanc est #767676. Si votre fond est gris, il faut un texte plus sombre.
Il existe des super outils qui vous permettent de trouver une palette de couleurs accessibles, incluant Color Safe. Il y a aussi WebAIM’s Color Contrast Checker, qui vous laissera tester des couleurs que vous avez déjà choisies.
Les logos et autres éléments qu’on ne voit pas sont exemptés de ces normes : ceci inclut des éléments de menus ou des boutons inactifs. Les textes alt ou les textes “fantômes” pour des formulaires n’en sont pas dispensés.
Voici un exemple d’un célèbre site de blogging avec un contraste de texte qui n’est pas suffisant. Seul le contraste du M géant respecte les normes.
Cet exemple de la BBC montre une interface utilisateur qui réussit le test haut la main : leur gris le plus clair est #767676.
J’ai la chance de travailler avec l’équipe de design de Salesforce, qui a suivi les normes de contraste pour son application mobile Salesforce1.
Réfléchissez à l’utilisation des combinaisons de couleurs très contrastées. Les designers qui ont fait cet exercice sont souvent surpris de voir à quel point ils préfèrent les hauts contrastes. Je suis sûr que vous trouverez aussi que l’utilisation des standards de contraste ne gâchent pas l’utilisation de vos produits.
Pour en savoir plus sur le contraste, regardez Projectors Don’t Lie et Accessible Interface Design.
4. Donnez des indications visuelles sur le focus du clavier
Prenons une minute pour nous dire que la feuille de style de base a été très utile aux webdesigners modernes. Sans elle, il serait bien plus difficile de créer une expérience cohérente entre différents supports et navigateurs.
Maintenant, prenons une minute pour haïr la feuille de style de base, qui a joué un rôle dans un des plus grands obstacles à l’accessibilité de l’histoire d’Internet.
:focus {outline: 0;}
Cette simple ligne de CSS rend presque impossible aux personnes voyantes d’utiliser un site Internet sans souris. Heureusement, depuis la sortie des CSS initiaux, bien des feuilles populaires comme celle d’Eric Meyer ont été mises à jour pour annuler la disparition de la pseudo-classe :focus.
L’idée de ce focus disparu était noble : on enlevait le style de base dans l’intention de la remplacer par quelque chose de visible, mais aussi d’esthétiquement adapté à son site. On peut facilement se mettre à détester la bordure grise d’Internet Explorer et Firefox ou le halo bleu de Chrome.
Le problème, c’est que la plupart des sites Internet ne recrée pas son propre focus. Ces indicateurs, fondamentaux dans l’expérience des utilisateurs de claviers, ont presque disparu du Web.
Faisons un exercice rapide : ouvrez un onglet qui donne sur le site de l’entreprise qui fabrique votre téléphone. Appuyez sur Tab plusieurs fois pour naviguer sur le site. Voyez-vous un focus quand vous passez d’un lien à l’autre ? Peut-être sur certains liens, mais pas tous ? Prenez une minute pour réfléchir à l’effet de ceci sur les personnes qui n’utilisent pas de souris pour aller sur le Web.
Si vous êtes sur un Mac, il faudra peut-être d’abord activer Full Keyboard Access dans System Preferences > Keyboard > Shortcuts. C’est en bas.
Si vous enlevez le focus par défaut, remplacez-le par quelque chose de mieux que ce que votre navigateur propose.
Dans l’exemple ci-dessous, la BBC utilise une barre de couleur pour montrer quel onglet est sélectionné.
Twitter utilise à la fois le focus par défaut et une bulle pour montrer le focus. L’icône passe aussi du gris au vert. Ce sont trois moyens visuels différents de montrer aux utilisateurs de clavier que le focus est sur cette icône.
Quand vous créez vos propres focus, pensez quand même à enlever l’état par défaut, sinon, vous verrez quelque chose comme ci-dessous, où le rectangle bleu de Chrome passe par-dessus le fond bleu du menu.
5. Faites attention avec les formulaires
Ces dernières années, nous avons vécu une dé-évolution des formulaires. Les designs modernes ont adopté une approche plus minimaliste. Les formulaires d’aujourd’hui manquent de deux choses nécessaires à l’accessibilité : des limites définies et des étiquettes lisibles.
Formulaires Sans Frontières
Ci-dessous, vous verrez un exemple de formulaire basique. C’est un rectangle avec une limite définie. Il peut être coloré, mais ce n’est pas obligatoire. Il y a aussi une étiquette visible, à gauche dans cet exemple.
Il est important de donner des limites clairement définies aux formulaires, pour les utilisateurs à handicap moteur et à handicap cognitif. Connaître l’endroit et la taille de la cible sur laquelle cliquer est important pour les personnes utilisant une souris standard ou adaptative. Les utilisateurs à handicap cognitif peuvent avoir une difficulté à trouver et interagir avec des espaces sans indices précis.
Vous trouverez ci-dessous une image du champ de recherche d’une application populaire de prise de notes.
Il n’y a pas d’indice sur cet écran. Pouvez-vous deviner les frontières du formulaire ? Il faut cliquer quelque part sur les mots “search notes” pour pouvoir ensuite taper.
Voici un autre exemple de formulaire sans limites précises, d’une plate-forme populaire de blogging. Ci-dessous, vous trouverez deux champs de texte. Où dois-je cliquer pour “raconter mon histoire” ?
Voici le même screenshot avec un rectangle bleu ajouté pour montrer les limites de la zone de texte. Si vous cliquez en-dessous, il ne se passe rien.
Ci-dessous, vous trouverez un autre exemple de design pour la prise de notes. Ceci n’utilise pas non plus les visuels traditionnels, mais les utilisateurs handicapés ont plus d’informations. Le titre de la note va entre les deux lignes horizontales, et l’utilisateur peut cliquer n’importe où entre les deux lignes du bas pour commencer à écrire sa note.
Pouvez-vous penser à d’autres options pour ces designers ? Comment créeriez-vous une application de prise de notes ou de blogging ?
Formulaires Sans Etiquette
Les étiquettes expliquent le but du champ aux utilisateurs, restent utiles quand le curseur pointe dans le champ, et restent visibles quand le champ est rempli. Le texte “placeholder” remplace mal une étiquette.
En plus, le contraste y est typiquement bas. Sur les sept exemples ci-dessous, seul un a assez de contraste pour respecter le ratio de 4.5:1.
Le texte “placeholder” disparaît. Dans les exemples ci-dessous, que suis-je censé taper dans la zone de texte ? Pour l’exemple JetBlue, dois-je taper mon identifiant, mon adresse mail ou mon numéro TrueBlue ? Pour l’exemple Caviar, devrais-je “Get Started” en tapant mon plat préféré, mon restaurant préféré ou mon adresse ? Le prix est-il un minimum et un maximum, ou ce que vous voulez éviter ?
Voici un design plus accessible pour le champ de prix ci-dessus. On voit les labels “min” et “max” même une fois les champs remplis.
6. Evitez les crises identitaires des composants
Q: Quand un menu cesse-t-il d’être un menu ?
A: Quand il est un dialogue non-modal.
Cette question est au coeur d’un des plus grands problèmes d’accessibilité de nos jours. Pour bien comprendre ceci, lisez les Pratiques de design de W3C. C’est un guide qui vous montre comment construire une version accessible de la plupart des designs classiques d’aujourd’hui, incluant des menus, des modaux, de l’autocomplétion, les plans de site, onglets, etc.
Chacun de ces designs a des standards HTML spécifiques. Les attributs ARIA qui leur sont attribués montrent aux utilisateurs d’écrans comment interagir avec un élément en utilisant le clavier. Ils proposent aussi des mises à jour de statut quand l’utilisateur interagit avec un élément. Par exemple, ils montrent à quelqu’un en train d’utiliser le menu qu’il faut qu’il utilise les flèches du clavier pour monter ou descendre dans la liste.
Voici l’autocomplete “de base”.
Voici le même autocomplete, avec des icônes dans les propositions.
C’est exactement le même type d’interface. L’utilisateur tape dans un champ de texte. Une boîte de résultats apparaît en-dessous, et l’utilisateur peut utiliser son clavier pour trouver et sélectionner l’objet qui l’intéresse.
L’exemple ci-dessous est un autocomplete en pleine crise existentielle. Non seulement l’utilisateur peut filtrer et sélectionner un objet dans la liste, il peut aussi éditer ou supprimer chaque objet de la liste en cliquant sur le crayon ou sur la poubelle. L’ajout de ces deux boutons est ce qui rend la liste impraticable.
Ceci crée des problèmes d’accessibilité, en partie parce que le système rompt la norme d’interaction standard avec un clavier. La technologie d’assistance ne peut pas toujours s’adapter aux éléments hors-norme, puisque le WAI de W3C n’a pas défini de spécification propre à ce type d’interface utilisateur.
La même règle s’applique pour les menus. Dans les exemples ci-dessous de Virgin America, si les deux menus sont très similaires visuellement, seul le menu de droite est un vrai “menu”. Celui de gauche est un dialogue non-modal.
Un menu est un widget qui offre une liste de choix aux utilisateurs. Dès qu’on propose plusieurs choix par ligne, comme dans l’exemple de gauche, on n’a plus de menu. Ceci change l’interaction clavier : on n’utilisera plus les flèches, mais la touche Tab.
Contrairement à l’exemple ci-dessus, les dialogues non-modaux peuvent heureusement être rendus accessibles. Connaissez la différence entre un menu et ceux-ci et sachez quel effet cela a sur l’expérience utilisateur. Comprenez comment des petits changements de design peuvent mener à des modifications du modèle d’interaction d’un utilisateur. Ceci vous permettra d’utiliser le bon design pour votre produit.
7. Ne forcez pas les gens à survoler la page pour y trouver des choses
Ce principe est surtout utile aux personnes qui ont des handicaps moteurs. Il inclut les utilisateurs qui n’utilisent qu’un clavier, et ceux qui utilisent des outils de reconnaissance vocale comme Dragon NaturallySpeaking pour interagir avec les sites Internet. Les utilisateurs de clavier et les technologies comme Dragon s’appuient sur des systèmes actionnables visibles à l’écran. Si un lien ou un bouton ne peut pas être vu par Dragon, il ne peut pas être “cliqué” verbalement. Si un utilisateur de clavier ne peut pas voir qu’un bouton existe sur la page, comment peut-on s’attendre à ce qu’il y navigue pour qu’il apparaisse ?
Vous verrez ci-dessous un screenshot de Gmail avec Dragon Naturally Speaking, montrant les hyperliens identifiés par des ombres. L’utilisateur peut dire un nombre à voix haute et activer un lien. Que se passe-t-il si un lien n’est pas visible tant qu’on ne l’a pas survolé ? On aurait des nombres au-dessus d’espaces vides.
Je comprends la popularité de cette idée qu’est de cacher les actions derrière des hover. C’est une solution à l’heuristique célèbre de l’informaticien Alan Kay.
“Ce qui est simple devrait être simple, ce qui est complexe devrait être possible.” -Alan Kay
Je crois fermement à cette heuristique, mais elle devrait rendre le complexe possible pour tous les utilisateurs, incluant ceux qui ont des handicaps. Malheureusement, bien des designers ont cru que la phrase originale signifiait ceci, qui n’est pas une citation d’Alan Kay :
“Les choses importantes devraient être visibles, le reste devrait apparaître quand on le survole.”
Plutôt que de cacher les actions et l’information derrière le survol de la page, explorez des alternatives plus complètes.
- Mettez des actions secondaires dans des menus (ou des dialogues non modaux) sans utiliser le survol pour cacher l’option
- Mettez moins de contraste sur les icônes secondaires, et rendez-les plus sombres une fois survolés
- Utilisez des éléments alternatifs pour remplacer le survol. Une icône d’information est mieux qu’un espace blanc pour cacher du contenu qui n’apparaît que quand on le survol.
Voici un exemple de LinkedIn. Ceci est ma page de profil.
Voilà ce qu’il se passe si je promène ma souris au-dessus de mon profil.
Soudain, je découvre que je peux éditer beaucoup de champs de cette page, par exemple mon nom, mon titre, mes anciennes expériences, ma formation et même ma photo de profil. Etape suivante : quand je survole spécifiquement mon titre, le texte devient bleu, m’indiquant que je peux cliquer.
Ci-dessous, je propose une solution aux problèmes d’accessibilité de ce design. J’ai des petits crayons à côté de chaque champ concerné. Ils sont toujours visibles.
Quand je survole un champ, il devient bleu.
En général, quand on leur en parle, les designers répondent quelque chose du genre :
“C’est un peu encombrant, non ?”
Peut-être que c’est encombrant, mais ce n’est qu’une solution possible au problème. De plus, ça n’apparaît que sur mon propre profil. Combien de temps passe-t-on sur son profil perso ? Quelles sont les alternatives à l’icône du crayon ?
Voici un autre exemple d’Evernote. Ceci est une liste de notes. Quand on passe sur une bande en particulier, quatre icônes d’action apparaissent.
Dans ce cas, je demanderais au designer de considérer l’idée de toujours montrer ces quatre icônes. Une solution possible serait de mettre les icônes en vert sur fond blanc, et en blanc sur fond vert.
Cette solution pourrait aussi être qualifiée d’encombrante, mais souvenez-vous que vous ne faites pas ce design pour des designers. Vous concevez un site pour des utilisateurs variés aux besoins divers, et avec différents outils pour y accéder.
***
On dirait peut-être, au premier abord, que ces contraintes limitent votre créativité. Si elles ont le moindre impact dessus, c’est bien dans le fait qu’elles vous poussent à oublier les limites de votre créativité, alors que vous trouvez des designs visuellement agréables qui permettent à plus d’utilisateurs de trouver leur bonheur.
Avec quelques efforts, vous découvrirez que n’importe quel challenge de conception peut être résolu en plaisant à vos cadres, à votre équipe marketing, à vos investisseurs et à tous vos utilisateurs, y compris ceux qui ont des handicaps.
Jesse Hauler est un vétéran du domaine de l’accessibilité et y travaille depuis 12 ans. Il est actuellement le Spécialiste Principal de l’Accessibilité chez Salesforce, où il a travaillé pendant 4 ans.
Mes remerciements à Cordelia McGee-Tubb pour les super illustrations de cet article.
Suivez Salesforce UX pour plus de posts sur le design tourné vers l’accessibilité.
