Le sondage accessible : des formulaires que tout le monde peut remplir

Tu peux rédiger des questions claires et perdre quand même la réponse. Si un répondant ne voit pas le label, ou ne sait pas quel bouton radio il vient de sélectionner, il ne t'envoie pas de mauvaises données. Il n'envoie rien. Et il est parti avant que le premier graphique s'affiche. L'accessibilité, c'est la partie de la conception de sondages qui décide qui peut répondre tout court.

Un sondage inaccessible biaise tes résultats

Environ une personne sur six vit avec un handicap. D'autres encore lisent ton formulaire sur un téléphone en plein soleil, ou le remplissent d'une main dans le train. Chacun d'eux est un répondant que tu as invité. Quand le formulaire ne fonctionne qu'avec une souris et une bonne vue, le groupe qui abandonne n'est pas un échantillon aléatoire. Ces personnes diffèrent de celles qui terminent, donc leur absence fausse le résultat dans une direction que tu ne peux ni voir ni corriger après coup. C'est le biais de non-réponse. Il se retrouve juste à côté des réponses de mauvaise qualité que tu filtres déjà : les deux expliquent pourquoi un export qui semble propre peut quand même induire en erreur.

La dimension juridique est là aussi. La directive européenne sur l'accessibilité s'applique depuis le 28 juin 2025 et tire de nombreux services numériques vers un standard technique que le reste du secteur utilise déjà : le WCAG, les Web Content Accessibility Guidelines. La section 508 et l'ADA font de même aux États-Unis. La version actuelle est WCAG 2.2, une recommandation du W3C révisée en décembre 2024. Le niveau AA est ce que presque tout le monde entend par "accessible". Tu n'as pas besoin de le mémoriser. Les vérifications ci-dessous y correspondent.

Donne un vrai label à chaque champ

L'erreur la plus courante dans les formulaires de sondage, c'est d'utiliser le placeholder comme label : un champ avec du texte gris clair "Ton e-mail" et rien au-dessus. C'est épuré. Puis le répondant commence à taper, l'indication disparaît, et quiconque a fait une pause à perdu le seul indice sur ce que le champ voulait. Le gris sur blanc échoue presque toujours au test de contraste. Certains lecteurs d'écran n'annoncent jamais le texte du placeholder. Le champ ressemble alors à "édition, vide".

Un label est un texte visible lié à son champ de saisie. Cliquer dessus met le focus sur le champ, et un lecteur d'écran lit les deux ensemble. Place-le au-dessus du champ. Si tu veux montrer un format ou un exemple, fais-le dans un texte d'aide séparé près du champ. C'est le WCAG 3.3.2, et cela coûte une ligne de balisage.

Les questions matricielles, c'est là que les lecteurs d'écran décrochent

Une grille avec des énoncés sur le côté et une échelle de notation en haut fonctionne bien sur un grand écran et est un cauchemar pour un lecteur d'écran. Les répondants voyants jettent un coup d'oeil aux en-têtes de colonnes une fois, puis descendent les lignes. Un lecteur d'écran ne jette pas de coups d'oeil. Il atterrit sur le troisième bouton radio de la ligne quatre et annonce, sauf si tu as construit la grille avec soin, "bouton radio, non coché" sans aucune indication sur l'énoncé ou le point de l'échelle.

Chaque option de la grille a besoin d'un nom accessible qui porte les deux éléments : la ligne à laquelle elle appartient et la valeur qu'elle représente. "Le tableau de bord est facile à naviguer, tout à fait d'accord" peut recevoir une réponse. Un bouton radio nu, non. Si tu ne peux pas le garantir, divise la matrice en questions séparées, un énoncé par question. C'est aussi plus lisible sur un téléphone, où la grille aurait été écrasée écrasée. Plus de défilement, beaucoup moins d'erreurs. Une formulation claire aide aussi : une matrice construite à partir de questions qui correspondent chacune à une décision est plus courte dès le départ.

Chaque échelle doit fonctionner au clavier

Les évaluations par étoiles et les curseurs emoji sont souvent les éléments les plus attrayants d'un sondage. Ils sont aussi les moins utilisables. Trop souvent, ce sont des images cliquables ou de simples div avec un gestionnaire de clic, donc ils fonctionnent avec une souris et rien d'autre. Un utilisateur de clavier les dépasse en tabbant.

Le WCAG 2.1.1 est clair : tout doit fonctionner au clavier. La façon fiable de construire une question d'évaluation, c'est avec de vrais boutons radio stylés pour ressembler à des étoiles ou des chiffres. Le navigateur te donne alors le focus clavier et la sélection par touches fléchées gratuitement. Les curseurs sont les plus difficiles à réaliser correctement, car la valeur doit être annoncée pendant qu'elle change et etre atteignable par étapes individuelles. Pour un score de recommandation de 0 à 10, de simples boutons radio font mieux à chaque fois. Retire la main de la souris et essaie la question toi-même.

Groupe les options pour que la question voyage avec elles

Les boutons radio et les cases à cocher forment un ensemble, et ils doivent etre annoncés comme tel. Quand un groupe d'options n'est pas lié à sa question dans le balisage, un lecteur d'écran lit chaque choix séparément : "Moins de 18 ans. 18 à 24 ans. 25 à 34 ans." La personne entend une liste d'âges sans savoir ce qui est demandé. Entoure chaque groupe de façon à ce que le texte de la question devienne le nom du groupe et que les options soient à l'interieur. Chaque option est alors lue "Quel est votre âge, 25 à 34 ans" et la question voyage avec la réponse. C'est la mécanique derrière le WCAG 1.3.1 : invisible, jusqu'a ce que quelqu'un ne puisse pas voir la mise en page qui portait le sens.

La couleur ne peut jamais être le seul signal

La couleur est un complément au message, et pour beaucoup de personnes, elle disparaît. Un champ obligatoire marqué seulement par un astérisque rouge n'existe pas pour un répondant daltonien. Une erreur signalée uniquement par un encadre rouge non plus. Le daltonisme rouge-vert touche à lui seul environ un homme sur douze. Mets un mot a côté de la couleur : écris "obligatoire" et marque une option sélectionnée avec une coche en plus du changement de couleur. Vérifie aussi le contraste. Le texte courant a besoin d'un rapport d'au moins 4,5 pour 1 par rapport au fond selon le WCAG 1.4.3, et ce gris clair de placeholder n'y arrive presque jamais.

Rédige des messages d'erreur qui expliquent quoi corriger

Le pire moment dans un formulaire inaccessible : tu ne peux pas continuer et tu ne sais pas pourquoi. Une question obligatoire a été omise, tu appuies sur suivant, et la page reste là, ou elle défile quelque part où tu ne regardes pas. Pour un utilisateur de lecteur d'écran qui n'a entendu aucune annonce, le sondage est maintenant cassé, sans explication.

Déplace le focus sur le premier champ qui a échoué. Un utilisateur de clavier atterrit alors sur le problème plutôt que de devoir le chercher. Nomme le champ et la solution dans le message d'erreur lui-même : "La question 4 doit être répondue avant de pouvoir continuer" bat "saisie invalide" à chaque fois. C'est ce que demandent le WCAG 3.3.1 et 3.3.3 : identifier l'erreur, proposer la correction.

Donne une voix aux questions révèlees

La logique conditionnelle est bonne pour la qualité des réponses et facile a rendre inaccessible. Quand une réponse révèle une question de suivi, un répondant voyant la voit glisser dans la page. Un utilisateur de lecteur d'écran ne la voit pas par defaut : le focus reste ou il était, rien n'est annonce, et une question entiere peut passer sans etre entendue. Si tu branches un sondage, fais en sorte que la nouvelle question s'annonce elle-même et déplace le focus vers elle. Garde les questions cachées hors de l'ordre de tabulation jusqu'a ce qu'elles s'appliquent, pour que personne ne tabbe dans un champ hors écran. La même logique conditionnelle et les retours qui améliorent la qualité des réponses bloquent les gens quand la révélation est silencieuse.

Garde le focus visible et dans le bon ordre

L'ordre de tabulation doit suivre l'ordre de lecture, pour que le focus parcourt le formulaire comme l'oeil le fait, pas vers un bouton isole quelque part. Et l'élément focalisé a besoin d'un contour visible. Les navigateurs en fournissent un par defaut, et trop de designs le suppriment, laissant un utilisateur de clavier sans curseur. Le WCAG 2.2 a ajouté la règle 2.4.11 : quoi que tu focalisés, cela ne doit pas être caché derrière un en-tête fixe ou une bannière de cookies. Ton sondage a une barre fixe en haut ? Assure-toi qu'un champ focalisé défile librement au-dessus d'elle.

Respecte le temps et les pouces des gens

Certains panels de sondages placent un minuteur sur une page ou font expirer la session apres un certain temps. Un delai strict pénalise les personnes qui ont besoin de plus de temps : quelqu'un qui utilise un dispositif de commutation, ou quelqu'un qui lit chaque ligne via un lecteur d'écran. Le WCAG 2.2.1 demande d'avertir avant que le temps ne soit écoulé et de laisser les gens le prolonger. Sur les téléphones, il y a aussi un problème physique. Une grille dense de petits boutons radio est une cible qu'aucun pouce ne peut atteindre proprement. Le WCAG 2.2 a fixe un plancher de 24 par 24 pixels CSS pour une cible interactive dans le critère 2.5.8. Donne de l'espace aux options. Si tu utilises une question glisser-classer, ajouté une façon de réordonner sans glisser, car un geste de glissement est lui-même un obstacle.

Laisse le navigateur remplir les champs ennuyeux

Les questions démographiques demandent les mêmes choses que chaque formulaire : nom, e-mail, code postal, pays. Le WCAG 1.3.5 dit de baliser ces champs avec leur objectif, pour que le navigateur et tout outil d'assistance puissent les remplir automatiquement et economiser une vraie frappe pour quelqu'un qui a du mal. Le WCAG 2.2 a ajouté la règle 3.3.7, contre la ressaisie d'informations que tu as déjà collectées dans le même processus. Si ton sondage a récupéré un e-mail à la page un, ne le demande pas à nouveau à la page quatre. Chaque champ que tu peux préremplir ou supprimer est une chose de moins à surmonter.

Teste-le comme un répondant le ferait

Cela ne fonctionne que si tu l'essaies vraiment.

• Débranche la souris et atteins chaque question, chaque option et le bouton d'envoi avec Tab et les touches fléchées.
• Active VoiceOver sur un Mac ou NVDA sous Windows et effectue un parcours complet avec l'écran éteint.
• Zoome la page a 200 % et regarde ce qui deborde ou disparaît.
• Lance axe ou Lighthouse pour les vérifications mécaniques, puis fais davantage confiance au passage manuel qu'au score automatisé.

Les outils automatisés détectent peut-etre un tiers des problèmes. Le reste a besoin d'une personne au clavier. Fais cela avant le lancement, car une fois qu'un sondage est en ligne, sa formulation et sa structure sont figées, et une correction en cours de route divise tes données.