Des formulaires accessibles : étiquettes, erreurs, clavier

Une organisation d’aide et de soins à domicile (Spitex) du Gros-de-Vaud reçoit les demandes par un formulaire en ligne : nom, adresse, prestations souhaitées, un champ pour les remarques. Un jour, la fille d’une cliente appelle. Sa mère voit mal et a essayé de remplir le formulaire avec la loupe de l’écran. Après l’envoi, la page était rouge, mais elle n’a pas trouvé ce qui n’allait pas — le message se trouvait en haut, loin de la partie agrandie.

Pour une Spitex dont la clientèle est souvent âgée, ce n’est pas un cas marginal. Beaucoup de ces obstacles s’évitent avec quelques principes que décrit le W3C.

Qui utilise les formulaires autrement

Tout le monde ne remplit pas un formulaire avec la souris et le regard. Certaines personnes écoutent l’écran avec un lecteur d’écran, d’autres font tout au clavier, agrandissent fortement l’affichage ou ont besoin de plus de temps pour comprendre des instructions. S’y ajoutent des situations qui peuvent toucher chacun : un bras cassé, un téléphone en plein soleil, une langue que l’on connaît mal.

Les Règles pour l’accessibilité des contenus web (WCAG) du W3C sont la référence internationale en la matière. La version 2.2 a été publiée le 5 octobre 2023. Le W3C a aussi publié un guide consacré aux formulaires, mis à jour pour la dernière fois en mars 2026.

Les étiquettes

Le guide du W3C commence par le principe d’identifier chaque champ de formulaire par une étiquette, en général avec l’élément HTML label. L’étiquette est reliée au champ — un lecteur d’écran la lit dès que le champ est atteint, et un clic sur l’étiquette place le curseur dans le champ. Les WCAG demandent des étiquettes ou des instructions lorsqu’une saisie est attendue (critère 3.3.2).

Un texte indicatif gris dans le champ, qui disparaît à la saisie, ne remplace pas une étiquette : dès que quelqu’un commence à écrire, on ne voit plus à quoi servait le champ.

Le remplissage automatique

Les navigateurs peuvent insérer un nom, une adresse ou une adresse e-mail à partir de données enregistrées si le formulaire indique à quoi sert un champ. Les WCAG demandent que la finalité des champs portant sur la personne elle-même puisse être déterminée par programmation (critère 1.3.5). Pour les personnes qui ont du mal à taper, cela épargne beaucoup de travail — et les fautes de frappe dans l’adresse par la même occasion.

Les groupes

Certains champs vont ensemble, par exemple le choix des prestations — Soins de base, Aide au ménage, Service de repas — ou la question « Qui remplit ce formulaire ? ». Le guide du W3C recommande de les regrouper avec les éléments fieldset et legend. Une personne qui utilise un lecteur d’écran n’entend alors pas seulement « Aide au ménage, case à cocher », mais aussi à quelle question la case se rapporte.

Des instructions au bon endroit

Le guide du W3C recommande de donner des indications qui aident à remplir le formulaire — pour l’ensemble du formulaire et pour chaque champ. L’emplacement est décisif : une indication sur le format d’une date se place avant le champ, pas seulement dans le message d’erreur. Et les champs obligatoires sont signalés d’une manière reconnaissable sans la couleur, par exemple avec le mot « obligatoire ».

Des messages d’erreur qui aident

La mère de l’appelante a buté sur un point typique. Les WCAG demandent qu’une erreur de saisie détectée soit signalée et décrite sous forme de texte (critère 3.3.1), et que, si possible, une suggestion de correction soit proposée (critère 3.3.3). De plus, une information ne doit pas être transmise uniquement par la couleur (critère 1.4.1).

Pour la Spitex, cela signifie concrètement :

• Le message se trouve à côté du champ concerné, pas seulement en haut de la page.
• Il dit ce qui manque ou ce qui est faux — « Veuillez saisir un NPA à quatre chiffres » au lieu de « Saisie non valable ».
• Les champs déjà remplis le restent.
• Un cadre rouge seul ne suffit pas ; un texte, ou un symbole accompagné d’un texte, en fait partie.

Clavier et focus

Un formulaire doit pouvoir être entièrement utilisé au clavier (critère 2.1.1) : d’un champ à l’autre avec la touche de tabulation, les choix avec les touches fléchées, l’envoi avec la touche Entrée. L’endroit où se trouve le focus doit être visible (critère 2.4.7).

Les WCAG 2.2 y ajoutent un nouveau critère : lorsqu’un élément reçoit le focus clavier, il doit être au moins partiellement visible et ne pas être masqué par d’autres contenus (critère 2.4.11) — par exemple par un bandeau sur les cookies ou un en-tête fixe.

Assez de place pour toucher

La taille des éléments de commande compte aussi. Avec le nouveau critère 2.5.8, les WCAG 2.2 demandent que les cibles aient une taille minimale — 24 × 24 pixels CSS — ou un espacement suffisant par rapport aux autres cibles. De petites cases à cocher serrées les unes sous les autres sont difficiles à atteindre pour les personnes dont les mains tremblent ou sur un petit écran.

Ne pas demander deux fois

Un autre nouveau critère des WCAG 2.2 concerne directement les formulaires : les informations qu’une personne a déjà saisies au cours du même processus ne doivent pas être redemandées (critère 3.3.7). Qui a déjà indiqué l’adresse de la cliente ne doit pas la retaper pour l’adresse de facturation — un « identique à ci-dessus » suffit.

Et lors de la connexion, personne ne doit avoir à résoudre une énigme, retenir quelque chose ou recopier quelque chose (critère 3.3.8). L’article Le spam dans les formulaires de contact décrit comment protéger des formulaires contre le spam sans de tels obstacles.

Les formulaires longs

Pour les formulaires longs, le guide du W3C recommande de les découper en plusieurs étapes plus courtes et d’indiquer la progression — « Étape 2 sur 4 ». Cela aide tout le monde, mais surtout les personnes qui ont besoin de plus de temps ou qui doivent s’interrompre en cours de route.

Ce qui s’applique en Suisse

La loi sur l’égalité pour les handicapés exige des autorités que leurs prestations sur internet soient accessibles aux personnes malvoyantes sans difficultés excessives (art. 14, al. 2, LHand), et interdit aux particuliers qui fournissent des prestations au public de traiter une personne handicapée de façon discriminatoire du fait de son handicap (art. 6 LHand). Dans sa version 3.0, le standard de cyberadministration eCH-0059 s’appuie sur les WCAG 2.1 et s’applique en premier lieu aux collectivités publiques et aux entreprises concessionnaires. Les obligations qui s’appliquent à une organisation donnée dépendent de son rôle.

Pour la Spitex du Gros-de-Vaud

La Spitex fait retravailler son formulaire : chaque champ a une étiquette visible, les prestations sont regroupées, les messages d’erreur se trouvent à côté du champ et disent quoi faire. Le formulaire se remplit au clavier, le focus est bien visible, et l’adresse de facturation se reprend d’une simple coche. La fille de la cliente l’a réessayé avec sa mère.

Dans l’app Formulaires que nous développons, les réponses seront chiffrées dans le navigateur de la personne qui répond et ne redeviendront lisibles que chez la destinataire. Les critères d’accessibilité que rempliront les formulaires de l’app, nous les décrirons sur sa page dès qu’elle sera lancée.