UX/UI : Documentons l'accessibilité en phase de design

Conférence de Stéphanie Walter.

L’accessibilité ce n’est pas qu’une affaire de développeur. Le must, c’est aussi de la documenter pendant la phase de design ! Ca permettra de gagner du temps en développement, comme les descriptions auront été claires dès le début.

On ne peut aussi que rappeler que mettre l’accessibilité à la fin d’un projet “si on a le temps” est vraiment une mauvaise idée. Et j’ai une remarque pour chiffrer le temps à passer sur un projet : l’accessibilité, ce n’est pas juste mettre un “alt” sur une image. Ca peut être quelque chose de complexe à faire dans le code. Il faut donc le chiffrer en demandant l’avis d’une personne qui connaît ces problématiques. (fin de ma parenthèse ;-) )

Pour documenter l’accessibilité en phase de design, Stéphanie nous montre qu’elle le fait souvent via des annotations sur Sketch, qu’elle utilise pour les maquettes.

Exemple indiqué par Stéphanie : Accessibility Annotation Examples.

Elle dit aussi que la documentation ne fait pas tout et qu’il faut régulièrement organiser des réunions avec les développeurs pour être sûr que les informations soient bien interprétées. Et parfois, c’est plus simple d’expliquer les détails à l’oral.

Pour les annotations qui sont mises dans les maquettes, conseil : il vaut mieux les mettre dans une autre couleur que celles de la charte, sinon les développeurs peuvent penser que ça fait partie des maquettes !

Stéphanie se fait une matrice des couleurs, pour pouvoir établir un bon contraste accessible. (non, on ne met pas du jaune sur du rouge !). Elle utilise Color ratio Matrix tool.

Elle consulte aussi la checklist de WCAG for designers.

Pour bien commencer avec la navigation clavier, on peut proposer des liens d’évitement au début de la page, qui se déclencheront lors de la navigation clavier (lorsqu’on passe de la barre d’URL à la page). Ils évitent de devoir tabuler sur tous les éléments du menu. On peut par exemple proposer : accéder au contenu de la page.

Si la page contient différent menus, sidenav, on peut proposer aussi ces différents liens à l’utilisateur. La navigation clavier doit aussi être bien ordonnée. Du côté de Figma, il existe un plugin pour le prévoir. Il y a aussi le plugin Fluent Accessibility Notation — Figma.

Il ne faut pas non plus utiliser seulement des couleurs pour indiquer une info ou une erreur. Il faut penser aux utilisateurs daltoniens qui ne pourront pas forcément savoir à quoi correspondent les couleurs. Pensez donc aux icônes ! (avec un aria-label=“erreur” sur l’icône ;-) )

Dans les maquettes, lorsqu’on a des choses complexes, il faut penser à détailler les actions. On peut par exemple avoir une série de boutons les uns en dessous des autres. Chacun entraîne une action. Mais où le développeur doit-il rendre la zone cliquable ? Sur le texte ? Sur l’icône ? Sur l’ensemble de la zone ?

Il faut bien documenter les animations en communiquant avec les équipes de développeurs. En CSS on va pouvoir par exemple gérer la vitesse des animations, pour les utilisateurs qui ont configuré leur poste d’une façon spécifique. Vous pourrez trouver de très bonnes pistes sur le site a11y project. La maquette indiquera aussi s’il faut mettre un texte alternatif sur l’image. (sinon, on mettra un alt="").

Pensez également à indiquer l’ordre des titres de la page. Les h1, h2, h3 (etc) sont comme un sommaire de la page, pour un lecteur d’écran.

En bref il faut:

• se tenir à jour avec l’accesibilité
• voir les interactions au délà des pixels “statiques” sur les maquettes.

Je vous invite à aller lire l’article de Stéphanie, où elle a indiqué bien d’autres liens que ceux que j’ai mentionnés.