8. Documenter les interfaces ou développer
Selon que vous transmettez vos interfaces à une développeuse ou un développeur ou que vous fassiez le développement vous-mêmes, les éléments suivants doivent être pensés et définis à ce stade.
a. Alternatives textuelles
En code HTML, on peut facilement afficher une chose mais en faire lire une autre par les lecteurs d'écran ! C'est très pratique pour donner plus de contexte aux personnes non-voyantes.
Nom des liens
Soit vos liens sont explicites et c'est l'idéal. ex : "Mentions légales" ou "Décret n° 2009-1393 du 11 novembre 2009".
Soit vos liens ne sont pas explicites et il faut préciser un titre alternatif plus précis en HTML pour les personnes naviguant de lien en lien, par exemple avec un aria-label.
Pourquoi est-ce important ?
Sur une page de blog où chaque article est une carte cliquable avec un "Lire l'article", tous les liens de la page ont le même nom si on navigue de lien en lien, ne permettant pas de les distinguer. Il faut donc pour chaque article mettre un aria explicite ou bien mettre le lien sur le titre de l'article lui-même.

Aria label explicite
Dans l'infolettre du portail de l'audiodescription, les liens ont un aria label afin que les noms des plateformes soient lus correctement. Par exemple "arte.tv" serait sinon lu comme "art" et non "arté".
Critères du 6.1 et 7.4 du RGAA
Si le lien est un lien externe qui s'ouvre dans un nouvel onglet, on précise "nouvel onglet" dans l'aria du lien car tout lien doit être explicite et il faut avertir l'utilisateur de tout changement de contexte.
Voir le référentiel
Textes alternatifs aux images
Si l'image est décorative : renseigner un alt " " (c'est un alt présent mais vide).
Si l'image est utile à la compréhension de la page, renseigner un alt descriptif à fournir au développeur / à la développeuse. Par exemple "Logo du Ministère de la culture".
« Le text alt est clair dans l’ensemble. Ça aide à comprendre le contexte. »
Qu'est ce qu'une image utile ?
Sur le site de Rennes Métropole, des utilisateurs aveugles ont trouvé utile d'avoir une alternative à l'image d'en-tête de la page. Ici "Immeubles de 6 étages à loyer modéré près d'un clocher en ville".

L'utilité d'une image est à aviser en fonction de son contexte.
Quid des textes alternatifs générés par IA ?
« Les IA génèrent des textes. Je préfère pas de description du tout ! L’IA m’est utile sur un site marchand : ça me donne un début d’information. Mais pour une affiche de film, non. Il faut un vrai travail d’écriture. »
Les intelligences artificielles peuvent décrire qu'on est en train de regarder un aspirateur rouge et non un filtre d'aspirateur, ce qui peut être une information très utile dans certains contextes. Dans le contexte ci-dessus cependant, elles n'auraient pas su que les immeubles sont à loyer modéré et que c'est bien pour cela qu'on les a choisis pour la page "Demander un logement social". Souvent, mieux vaut ne pas avoir de texte alternatif sur des photos que d'en avoir un qui fait perdre du temps inutilement.
Pour aller plus loin :
- Un arbre décisionnel pour l'attribut alt - W3C WAI
- Alt-texts: The Ultimate Guide (en anglais) - Axesslab
b. Indications sur les composants
Certains composants peuvent être intégrés de différentes manières côté développement. En donnant des indications précises, on garantit l’accessibilité du produit.
Listes
Les listes (ordonnées <ol> ou non ordonnées <ul>) sont extrêmement pratiques à naviguer pour les personnes habituées à la navigation clavier. En effet, elles présentent plusieurs avantages :
- Elles annoncent que c'est une liste.
- On peut sauter la liste en entier si elle ne nous intéresse pas.
- On sait à l'avance combien la liste a d'éléments.
« Sinon vous faites juste une liste à puces de liens. L’avantage sur une liste à puces c’est qu’on peut sauter la liste avec un raccourci clavier. »
Que ce soit des listes à puce ou des listes structurées différemment visuellement (groupe de cartes par exemple), il peut être judicieux d'indiquer lorsqu'on aimerait qu'une liste d'éléments soit effectivement une liste en code, et non seulement un groupe d'éléments.

Penser notamment à mettre en "liste" les ensembles de choix se trouvant dans un filtre par exemple.
« Les cases à cocher, ça m’indique pas que c’est dans une liste. Savoir que j’ai 5 ou 15 genres, c’est plus facile. »
Cartes
Spécifier à côté des cartes si la lecture par la synthèse vocale doit se faire dans un autre ordre que celui d'affichage par défaut (de haut en bas). En développement, on peut faire en sorte que le badge et autres détails (date, etc.) soient affichés au-dessus du titre mais lus après le titre.
Ordre différent de l'affichage
Dans le Système de Design de l'Etat, le composant carte détaille : "Les éléments média, description, badges, tags, détails, boutons sont situés après le titre dans le code HTML."

Pour aller plus loin :
- Define the content order (en anglais) - BBC Screen Reader UX guide
c. Interactions
Sous-menu
Ne pas faire apparaître les sous-menus au survol mais bien au clic.

« C’est bien les sous-menus ne s’affichent pas que 10 secondes quand on passe la souris dessus ! »
« Vous appelez ça un accordéon ? Moi j’appelle ça les menus casse-**** parce qu’il y a plein de sites où ça ne marche pas, ça se referme tout de suite. »
Éviter d'avoir plus de 2 niveaux de profondeur car trop complexe pour la motricité et cognitivement.
Recherche
Permettre de lancer la recherche en appuyant sur la touche "entrée".
« J’utilise un clavier bluetooth et sur certains sites quand on appuie sur Entrée ça recherche pas. »
A noter que beaucoup d’utilisateurs déficients visuels utilisent la dictée vocale dans le moteur de recherche.
Pour aller plus loin :
- Documenter l’accessibilité en phase de design ! - Stéphanie Walter