En conception responsable, beaucoup de choses se passent en amont des maquettes : l’analyse du besoin, la stratégie, l’architecture de l’information, les spécifications fonctionnelles.
Beaucoup de choses se passent aussi lors de la définition des parcours utilisateurs et de la conception visuelle des maquettes : les contrastes, la taille du texte, les espacements, les images et autres médias, les animations, etc.
Et enfin, beaucoup de choses se passent lors du passage des maquettes au développement. Là, je suis globalement alignée avec Perrine Croix : la valeur des annotations est largement sous-estimée.
Pourquoi annoter ses maquettes
Le résultat final de la conception UX/UI n’est jamais la maquette, mais bien le service numérique développé. Et celui-ci n’est pas un simple copié-collé des maquettes visuelles.
Soit c’est moi qui développe, et alors j’ai juste besoin de discuter avec moi-même pour traduire mon intention de conception en code fonctionnel. Soit je collabore avec une équipe de développement, des copywriters et autres pros du web, et dans ce cas je dois communiquer mon intention à d’autres humains : c’est à la fois plus délicat et plus enrichissant.
Dans tous les cas, un visuel ne suffit jamais à traduire une intention : la maquette n’est qu’un support de réflexion et de communication. Alors comment communiquer une intention de conception sobre et accessible à partir de maquettes ?
Dans cet article, je vous partage quelques pratiques d’annotation que j’ai adoptées au fil du temps pour mieux communiquer aux équipes de développement mes intentions de designer en termes d’accessibilité et d’écoconception.
Annoter pour l’accessibilité
Il y a certaines choses qui sont évidentes (ou qui devraient l’être) pour les équipes de développement. Et puis il y en a d’autres qui doivent être explicitées systématiquement.
La balise title de chaque page
Chaque page doit avoir un titre précis qui correspond à son contenu : c’est le critère 8.5 du RGAA (Référentiel Général d’Amélioration de l’Accessibilité). Il peut être nécessaire d’y ajouter des éléments de contexte variables, par exemple pour une liste de résultats de recherche : « 13 résultats pour choupisson page 1 sur 5 » plutôt que « Résultats ».
Les éléments à masquer aux technologies d’assistance
Les images décoratives et les icônes redondantes avec le texte doivent être ignorées par les technologies d’assistance (critère 1.2 du RGAA). C’est généralement le designer qui détermine si une image est décorative ou redondante dans chaque contexte.
Les alternatives textuelles
Les images et icônes porteuses d’information doivent porter une alternative textuelle qui sera restituée par les technologies d’assistance. Par exemple, si on ajoute une icône “nouvelle fenêtre” ajoutée en css à la suite d’un lien, il faut donner la même information sous une autre forme aux technologies d’assistance.
L’ordre de déplacement du focus
Parfois, et même si on doit en faire une exception, l’ordre de déplacement du focus ne suit pas l’ordre des éléments dans le code. Par exemple suite à l’insertion d’un nouvel élément dans la page, ou lorsqu’on utilise des liens d’accès rapide. Dans ces cas-là, il est pertinent de le préciser sur les maquettes pour respecter le critère 12.8 du RGAA. Mais comme le dit Eric Bailey (en anglais), il n’est généralement pas pertinent de l’annoter dans les autres cas.
L’ordre des éléments dans le code
Il arrive aussi que l’ordre visuel diffère de l’ordre de lecture logique. Par exemple, lorsqu’on place un badge “catégorie” au-dessus d’un titre. Dans ces cas-là, il est important que le code html suive l’ordre de lecture logique et que l’ordre visuel soit géré avec css pour passer le critère 10.3 du RGAA.
Les interactions attendues pour un composant complexe
De la fenêtre modale au composant composite hautement personnalisé, il peut être nécessaire de préciser les séquences d’interaction attendues : vocalisation du contenu, effets des touches du clavier, etc.
Description de l'image
Le composant contient :
une étiquette “Local tags”
un élément de sélection avec le texte “#department”
un champ de saisie texte contenant le texte “mat”, avec les options d’autocomplétion “maths” et “mathematics”. Une annotation indique “arrow-down focuses the first option and so on”.
un bouton avec le texte “Create”
Annoter pour l’écoconception
Il y a moins de choses à annoter directement sur les maquettes en matière d’écoconception, mais quelques éléments ont leur importance, en lien avec le Référentiel Général d’Écoconception des Services Numériques (RGESN).
Le rappel des contraintes
Il est souvent utile de rappeler les contraintes en contexte : les maquettes peuvent être le bon endroit pour le faire.
Il peut s’agir par exemple de rappeler le nombre limite de requêtes et le poids maximal de transfert pour chaque chemin utilisateur défini comme critique 1 . Cela permettra de suivre et de maintenir l’optimisation des parcours de navigation (critère 4.3 du RGESN).
Pour certains composants, il peut être nécessaire de préciser les conditions de déclenchement d’une interaction. Par exemple, attendre 3 caractères et x ms pour afficher les propositions d’autocomplétion. C’est ce qui est recommandé par le critère 4.9 du RGESN.
Les marges d’optimisation
On peut aussi préciser sur les maquettes les marges d’optimisation laissées par le design. Par exemple :
la possibilité de transiger ou non sur la qualité d’une image en contexte, pour appliquer un taux de compression plus sévère dès que possible (critère 5.2 du RGESN),
les graisses d’une famille typographique qui ne seront jamais utilisées, pour limiter les fichiers de police téléchargés en accord avec le critère 4.8 du RGESN,
les caractères spéciaux qu’on n’utilisera jamais : pour alléger les fichiers de police en éliminant tous les glyphes inutiles,
les différentes tailles et ratios prévus pour une image : pour optimiser au mieux le chargement des images sur les différents écrans.
Annoter ne remplace pas la discussion
Pour finir, en pratique « j’annote » mes maquettes à plusieurs endroits différents :
La documentation des composants ou des design patterns : j’y détaille les points d’attention et prérequis en matière d’accessibilité.
L’utilisation d’un composant dans une page : j’y ajoute des indications contextuelles (sémantique, alternatives textuelles…)
Tout ce travail d’annotation permettra aux équipes de développement et de rédaction de suivre les bonnes pratiques de conception responsable dès le départ, et évitera des corrections longues et coûteuses. Si d’autres designers interviennent sur le produit, ils et elles auront aussi une trace de l’intention initiale.
Les annotations ne peuvent cependant pas remplacer des échanges directs et synchrones, qui permettent de débloquer bien des situations : laissez vos équipes discuter entre elles !
Cet article et tous les articles de ce blog sont sous licence CC-BY-SA.
- Un chemin critique est toujours en lien avec les unités fonctionnelles principales du service, par exemple : acheter une place de spectacle, réserver un livre, payer un impôt, etc. ↑