Recommandations pour améliorer l’accessibilité du vote par Internet

Le saviez-vous ? Il existe à l’heure actuelle 4 façons de voter aux élections françaises :

1. Directement aux urnes, ce qui suppose un déplacement dans votre bureau de vote.
2. Par procuration, dans le cas où une personne de confiance accepte de se rendre à votre place dans un bureau de vote.
3. Par correspondance, mais seulement pour les français de l’étranger et pour certaines élections.
4. En ligne, mais seulement pour les français de l’étranger et pour certaines élections.

La possibilité de voter en ligne, bien qu’ayant un certain nombre de contraintes en terme de sécurité et de confidentialité, est très prometteuse en terme d’accessibilité : elle rend le vote accessible à toutes et tous les citoyen·ne·s majeurs et pour qui les autres modalités de vote seraient trop contraignantes. On pense aux personnes non-motorisés et vivant loin de leur bureau de vote mais aussi aux personnes vivant avec différentes formes de handicap, comme les personnes malvoyantes par exemple. Dans ce cas précis, le vote en ligne donne une autonomie sans précédent aux votants, notamment grâce aux technologies d’assistance dont tous les ordinateurs modernes sont équipés. Mais pour que cela fonctionne, le service doit être conçu et programmé de façon à être compatible avec ces technologies d’assistance. En tant que française vivant en Allemagne et designer spécialisée en accessibilité, j’ai pu tester le dispositif en ligne lors des élections législatives de 2022. Dans cet article, je partage quelques recommandations pour permettre d’améliorer l’accessibilité de ce dispositif pour les prochaines élections. La plupart de ces recommandations peuvent s’appliquer à n’importe quel service digital. Il s’agit de:

• Simplifier la mise en forme des informations
• Utiliser un design system
• Tester avec des technologies d’assistance

À noter qu’un audit d’accessibilité a déjà été publié dans une déclaration d’accessibilité. Je ne m’attarderai pas sur les points déjà mentionnés dans ce document. Mes recommandations s’orientent d’avantage sur mon expérience en terme d’accessibilité et d’utilisabilité que sur les critères établis dans le RGAA.

Mais de quoi parle-t-on exactement ? Je vais maintenant présenter l’expérience utilisateur·rice·s du vote par Internet pour les législatives de 2022.

L’expérience utilisateur·rice·s en bref

Une fois son inscription sur la liste consulaire complétée, on doit suivre les étapes suivantes pour voter en ligne :

1. Se rendre sur la plateforme de vote,
2. S’identifier au moyen de l’identifiant reçu par email et du code secret reçu par SMS,
3. Sélectionner un candidat,
4. Confirmer son choix,
5. Valider son vote en entrant le code confidentiel envoyé par email,
6. Télécharger le récépissé de vote (facultatif),
7. Vérifier que le vote a bien été pris en compte via la réception de l’email de confirmation (30 à 60 min après la validation du vote).

Le processus est aussi expliqué dans la vidéo du Tweet ci-dessous:

Tweet de @FR_Consulaire expliquant en video comment voter par internet au second tour des élections législatives de 2022.

En soi, ce processus est simple et logique. Sa complexité réside surtout dans les différentes parties de son écosystème constitué de :

• la plateforme d’inscription sur la liste consulaire
• la boîte email du votant
• le téléphone du votant
• la plateforme de vote

Cela paraît néanmoins nécessaire afin d’assurer la sécurité du processus. Sur le long terme, on pourrait imaginer que la plateforme de vote serait aussi celle où l’inscription s’effectuerait, ce qui faciliterait la communication et diminuerait la charge cognitive pour les votant·e·s.

Un autre aspect qui mérite une communication accrue de la part de l’État est la temporalité du processus, divisée en différentes phases. Il y a :

• la phase d’inscription sur la liste consulaire, qui n’est pas limitée dans le temps, mais qui doit être faite suffisamment en avance pour permettre le vote par internet.
• les phases de vote du premier et second tours, dont les temporalités diffèrent de plusieurs jours comparées à celles des bureaux de vote.

Cela étant dit, je vais maintenant focaliser mes recommandations sur la plateforme de vote en elle-même.

1. Simplifier la mise en forme des informations

La mise en forme de la plateforme de vote est assez disparate, en particulier au moment de la connexion et du récépissé du vote. Cela peut avoir un impact négatif sur la lisibilité et la compréhension des informations, en particulier pour les personnes avec des troubles intellectuels ou d’apprentissage (ex: dyslexie).

Les pages de connexion et de récépissé de vote sur la plateforme.

Les 2 redesign ci-dessous contiennent exactement les mêmes informations que la page de connexion et de récépissé de vote de l’original.

Original et redesign en niveau de gris de la page de connexion.

Original et redesign en niveau de gris de la page “Récépissé de vote”.

Seulement, ils ont été construits avec l’objectif de rester aussi simple que possible, notamment en :

• Conservant la mise en page sur une colonne. De cette façon, les votant·e·s peuvent discerner plus rapidement la structure de chaque page.

La ligne rose restitue le trajet que l’œil doit effectuer pour scanner les informations de la page “Choix du candidat”. Elle met en évidence que l’amplitude des mouvements nécessaires pour une mise en page sur 2 colonnes est bien plus grande que sur une colonne.

• Diminuant le nombre de styles de texte en utilisant des logiques d’usage. Les votant·e·s peuvent ainsi distinguer plus facilement la hiérarchie des informations.

Le récépissé de vote original contient 13 styles de texte différents avec de multiples graisses, tailles de texte, couleurs et du soulignement. Le redesign renforce la hiérarchie en incluant des logiques de style : le soulignement est utilisé uniquement pour les liens et le texte en gras que pour les titres.

• Limitant l’usage des icônes. Ainsi, elles servent de support aux textes d’une certaine importance ou sont utilisées seules pour des actions où leur signification est relativement évidente.

Sur la page de connexion, les icônes “information” au début des champs de saisie et “calendrier” devant les dates d’ouverture et de fermeture de la plateforme sont utilisées uniquement de façon décorative. Elles ont donc été retirées de ma proposition.

• Optimisant le contenu, par exemple en communiquant la durée de la phase de vote directement dans le chapeau de la page.

Les dates d’ouverture et de fermeture de la plateforme ne sont pas des contrôles interactifs. Un simple paragraphe de texte suffit pour donner cette information. L’importance de cette information mérite tout de même de la faire apparaître en premier.

J’ai utilisé les mêmes principes pour recréer le reste de ce processus:

Original et redesign en niveau de gris de la totalité du processus.

Il est commun d’entendre que l’accessibilité est une discipline trop spécifique, car elle ne bénéficierait qu’à 15% de la population en moyenne. Ce que je démontre en simplifiant l’interface de la plateforme de vote, c’est qu’au contraire, l’accessibilité bénéficie à tous : simplifier la mise en page permettrait à tous de comprendre et de compléter le processus plus rapidement. Enlever la complexité de l’interface faciliterait également son implémentation. C’est le fait de ne pas considérer l’accessibilité dès le départ qui introduit de la complexité dans les interfaces et non le contraire.

2. Utiliser un design system

Dans le cadre de la plateforme, utiliser les composants du design system (DS) de l’État améliorerait fortement l’accessibilité de l’interface. On s’en rend compte aisément en comparant les champs de saisie du DS avec ceux de la plateforme de vote en terme de :

1. Consistance du comportement,
2. Perception de l’état d’erreur,
3. L’anatomie des composants.

Consistance du comportement

Les champs de saisie de la plateforme se comportent différemment d’une étape à l’autre ; sur la page de connexion, les labels des champs de saisie sont flottants (ils changent de position et de taille dès qu’ils reçoivent le focus). À l’étape “Vote”, le label disparait complètement au focus, ce qui peut poser un problème pour les personnes ayant des difficultés de mémorisation. Qu’il s’agisse d’une condition médicale ou d’une distraction passagère : mieux vaut que le label soit toujours visible.

En comparant les deux premiers champs, on se rend compte de plusieurs problèmes de consistance : les icônes pour montrer ou cacher les informations ne sont pas les mêmes, l’alignement du lien d’aide est différent et le label disparaît complètement dans le deuxième cas.

En comparaison, le champ de saisie du DS de l’État est pourvu d’un label statique positionné au-dessus du champ et dont la taille ne varie pas au focus. Ce comportement est reconnu comme bien plus accessible, notamment car la lisibilité du label ne diminue pas en fonction de l’état du champ.

Perception de l’état d’erreur

De plus, l’état d’erreur du champ de saisie du DS de l’État est pourvu d’un message qui ne s’appuie pas seulement sur la couleur rouge pour se signaler mais utilise aussi une icône de support : cela explicite la nature du message, en particulier pour les personnes qui vivent avec une forme de daltonisme. Dans certains cas, la couleur rouge peut être difficile voire impossible à distinguer. C’est pourquoi il est préférable d’utiliser une icône de support et de localiser le message d’erreur à proximité du champ de saisie où l’erreur se situe.

Les simulateurs de daltonisme, bien que non représentatif de l’expérience de la totalité des personnes daltoniennes, permet de se faire une idée sur la perception qu’ils peuvent avoir de certaines couleurs.

L’anatomie des composants

Enfin, le DS de l’État propose une variation du composant avec un texte d’aide, ce qui permet d’apporter des précisions sur les informations que les votant·e·s doivent entrer. Ce texte apparaît directement en dessous du label lorsqu’il est utilisé. Pour ce qui est de la plateforme de vote, un texte d’aide est aussi présent mais dans un tooltip qui s’affiche seulement lorsque les votant·e·s survolent le champ avec leur souris. Par conséquent, les personnes qui s’appuient uniquement sur le clavier pour naviguer n’ont pas accès à cette information.

Comparaison des textes d’aide pour les champs de saisie sur la plateforme de vote et sur le DS de l’État.

Néanmoins, ce DS est une base qui doit s’enrichir avec les besoins des différents services de l’État. Pour finir avec le champ de saisie, il existe des variations incluant un bouton icône, mais celles-ci ne permettent pas d’activer le focus sur cette partie du champ uniquement, ce qui serait souhaitable dans le cas de la plateforme de vote, où les informations du champ doivent pouvoir être dissimulées ou apparaître.

Les variations du champ de saisie du DS de l’État permettent d’avoir une icône à la fin du champ mais elles ne sont pas actionnable individuellement.

Cela tient sûrement à la nouveauté du DS, qui a un peu plus d’un an. L’initiative est encore toute nouvelle, là où certains services de l’État ont déjà plusieurs années à leur actif. L’adoption et la propagation du DS au sein des différents services de l’État est une entreprise titanesque. On peut imaginer que la plateforme de vote n’utilise pas le DS pour l’instant car sa transition n’a pas été mise en priorité.

3. Tester l’interface avec des technologies d’assistance

Pour accéder à Internet, les personnes en situation de handicap peuvent avoir recours à diverses technologies d’assistance. Parmi elles, on peut trouver différents types de logiciels (lecteurs d’écran, logiciels de zoom, reconnaissance vocale, etc…) ou d’outils (claviers, plage braille, switch, etc…). Tester la plateforme avec des personnes utilisant des technologies d’assistance s’impose donc comme une manière de s’assurer que leurs besoins seront pris en compte. Afin d’éviter certaines erreurs basiques, les équipes produit peuvent aussi effectuer certains tests, même lorsqu’elles sont peu familières des technologies d’assistance. Je couvrirais ici :

1. Tester la navigation au clavier,
2. Tester l’adaptabilité du service,
3. Tester les modes de couleurs et les contrastes,
4. Parcourir l’interface avec un lecteur d’écran.

Tester la navigation au clavier

Il s’agit de compléter le processus sans utiliser la souris. Sur la plateforme de vote, on s’aperçoit que le focus n’est pas déplacé dans la modale de déconnexion lorsque cette commande est activée.

Dans cette vidéo, le focus reste sur le champ de saisie à l’arrière plan après l’ouverture d’une modale. Le focus devrait être déplacé et demeurer dans la modale une fois celle-ci ouverte.

Avec ce test, on peut donc s’assurer que le focus est bien visible et qu’il passe d’un élément à l’autre de façon prévisible (de haut en bas et de gauche à droite pour les langages qui se lisent dans cette direction). C’est important pour les personnes qui dépendent du clavier pour naviguer.

Tester l’adaptabilité du service

Il s’agit de compléter le processus sur différents supports (par exemple avec un smartphone) et en zoomant l’interface à 200%. Sur la plateforme, on découvre qu’une fois zoomé à 200%, la durée d’ouverture de la plateforme passe en dessous du bouton de validation du formulaire, ce qui diminue singulièrement les chances que cette information soit vue ou lue par les personnes sur mobile ou utilisant des logiciels de zoom. On s’aperçoit aussi que la mise en page s’adapte mal sur smartphone, ce qui peut compliquer l’usage des champs de saisie.

Comparaison de la page de connexion à 100% et 200% sur ordinateur et à 100% sur mobile.

Avec ce test, on peut aussi vérifier que le service est programmé pour éviter un scroll latéral lorsqu’on agrandi la page via les fonctions de zoom du navigateur.

Tester les modes de couleurs et les contrastes

Il s’agit de compléter le processus en activant le mode contraste élevé de Windows ainsi que les thèmes présents sur l’interface. Sur la plateforme, on constate qu’un certain nombre d’informations sont manquantes en mode contraste élevé. Parmi elles, les labels des champs de saisie, les actions pour changer ou entendre le CAPCHA et l’interrupteur entre les modes clair et sombre. On note aussi que le contraste des liens est insuffisant au survol et au focus en mode sombre.

Comparaison de la page de connexion en mode clair, sombre et contraste élevé.

Ce test est important pour les personnes malvoyantes et/ou qui customisent leur interfaces avec leur propre thème pour plus de confort.

Parcourir l’interface avec un lecteur d’écran

Il s’agit de naviguer de façon linéaire avec un lecteur d’écran. On découvre ainsi que l’option “Vote blanc” n’est pas correctement annoncée sur la plateforme.

Parmi les options de vote, les noms des deux candidats sont clairement retransmis aux utilisateur·rice·s de lecteur d’écran mais l’option “Vote blanc” n’est pas correctement annoncée.

Utiliser un lecteur d’écran peut être intimidant au début, mais à partir du moment où l’on connaît les combinaisons navigateur-lecteur d’écran ainsi que les commandes de base (allumer et éteindre le lecteur + aller d’un élément à un autre), ce test est simple à effectuer. Il permet de s’assurer que les utilisateur·rice·s de lecteur d’écran ont accès à toutes les informations et peuvent compléter le processus sans encombre.

Tous les problèmes d’accessibilité soulignés dans cette partie auraient pu être détectés avant le déploiement du site si ces tests étaient incorporés aux procédures de validation des services de l’État. Ces tests seraient d’autant plus rapides à effectuer si les designers étaient formés à ces problématiques : nombre d’erreurs seraient tout simplement évitées.

Conclusion

Améliorer l’accessibilité des services numérique est un voyage et non une destination. J’ai exposé trois recommandations pour faciliter ce voyage:

1. Conserver une mise en forme simple de l’information afin d’améliorer l’intuitivité et la lisibilité de l’interface. Cela va de la mise en page aux styles de textes en passant par l’usage des visuels et du contenu en lui-même.
2. Utiliser un design system. Une partie non-négligeable des problèmes d’accessibilité peuvent être adressés au niveau des composants, ce qui peut alléger significativement le travail de documentation et de test de l’accessibilité.
3. Mettre en place un protocole de test avec des technologies d’assistance. Cela peut avoir lieu à différents moments et de différentes façons. Ce protocole devrait être effectué régulièrement par l’équipe produit (en mixant les compétences de préférence), mais ne peut en aucun cas suppléer à l’expertise des utilisateur·rice·s régulier·ère·s de technologies d’assistance.

Au travers de ces recommandations transparaît l’opportunité d’améliorer un service public qui, bien que limité aux français de l’étranger aujourd’hui, pourrait s’il est adopté à l’échelle de la France, réellement démocratiser l’accès au vote en le rendant plus accessible à toutes et à tous.

Au-delà de ce service public, j’espère avoir attisé la curiosité des personnes travaillant dans la tech au sujet des multiples modalités d’usage d’une interface (en dehors de la souris). Car c’est en en apprenant plus sur ces technologies d’assistance et les personnes qui les utilisent qu’on peut créer des interfaces bien meilleures car plus inclusives.

Pour aller plus loin (en anglais)

Les sujets évoqués ici vous ont intéressés ? Voici quelques ressources qui vous permettront d’en apprendre plus :

Sur l’accessibilité du vote:

• Whitney Quesenberry, une designer et chercheuse américaine a fondé le “Center for Civic Design” pour lequel elle a publié une série de “Fieldguides” avec des recommandations concrètes pour améliorer l’accessibilité des bureaux de votes.
• Cette étude de la Research Alliance for Accessible Voting qui analyse les résultats de 2 enquêtes à l’échelle des États-Unis sur les problèmes d’accessibilité du vote. On y apprends notamment que les personnes avec un handicap ayant répondu aux enquêtes préfèrent voter par correspondances, car ils n’ont pas accès à Internet chez eux (ce qui fait écho au lien de causalité entre handicap, accès à l’emploi et pauvreté).

Sur les technologies d’assistance:

• Cet article pour concevoir des produits compatibles avec le mode de contraste élevé de Windows. Les conseils sont surtout adressés aux personnes ayant des connaissances en HTML et CSS.
• Cette conférence sur les usages des personnes utilisant des fonctionnalités ou des outils pour zoomer dans les interfaces.
• Cette vidéo où Léonie Watson explique comment elle utilise son lecteur d’écran.

Pour intégrer l’accessibilité à votre processus de design:

• Just Ask: Integrating Accessibility Throughout Design est un livre gratuit (en ligne) avec de nombreux conseils pour conduire des tests d’utilisabilité avec des personnes en situation de handicap.

Un grand “Merci” à Étienne Ndiaye et à Catherine Mathias pour leurs relectures attentives.