ETQ Usager, je veux les champs générique aient un exemple en placeholder

[LeSim]

concernés :

• texte
• textearea

[colinux]

Cette issue fait suite à https://github.com/betagouv/demarches-simplifiees.fr/issues/7428

Etant donné qu'il s'agit de champs génériques, quel placeholder utiliser ? Ou est-ce aux administrateurs d'en saisir un lors de la création de la démarche pour ces 2 champs en particulier ? cc @Olivier-Marcellin

[Olivier-Marcellin]

hello, pour ce ticket, il n'y pas de consensus après avoir discuté avec une ergonome dans les équipes du Ministère de la Culture, pas plus du côté des designers de Design.Gouv (chargés de la conception du Système de design de l'État) dont les composants pour les champs de saisie n'ont pas cette configuration avec une mention dans le placeholder, seule la saisie du texte : selon l'ergonomie, il est préférable de placer l'exemple en dehors du placeholder pour une question de lisibilité. Il faut au contraire que le placeholder soit vide (ce n'est pas le cas actuellement, il y a répétition du label ce qui est inutile). Je propose au contraire de ne pas autoriser l'affichage de mentions dans les placeholder, l'exemple est à positionner dans la description.

[colinux]

@Olivier-Marcellin Depuis cette PR il n'y a plus la reprise du libellé qui faisait doublon https://github.com/betagouv/demarches-simplifiees.fr/pull/7532

J'y ai implémenté la possibilité aux administrateurs de saisir leur propre exemple pour les champs libres textes & zone de texte.

Pour être sûr de bien comprendre, pour ces champs libres, il faudrait que l'exemple configuré par les administrateurs (Spécimen de saisie) soit affiché comme l'est la description, au-dessus du champ, plutôt que comme un placeholder dans l'input. (Et sans fallback s'ils n'en configurent pas.)

Si on s'en réfère au dernier screenshot que j'ai fait de cette même PR, ça voudrait dire que pour le champ Votre âge en chiffres romains on mettrait quelque chose comme : Exemple : XXXIX juste au-dessus de l'input, et dans la continuité de la description le cas échéant.

Décline-t'on aussi ce même design sur l'ensemble des champs, pour lesquels on a un placeholder à nous non-configurable (email, iban, tel, siret, nombre…), et ainsi toujours laisser l'input vide et l'exemple visible au-dessus ?

Dernière question : as-tu connaissance d'exemples html/css fournis par le système design de ce mode d'implémentation visuelle tout en conservant l'attribut placeholder ? Ou est-ce qu'on s'en affranchit, au risque de perdre en accessibilité pour les plages tactiles / braille et synthèses vocales ? Ou est-ce qu'on doit manipuler le DOM en JS pour satisfaire tout le monde ? ;)

[Olivier-Marcellin]

@colinux en effet oui, selon les recommandations de l'ergonome l'admin configure le specimen de saisie dans la description, donc au dessus du champs, plutôt que dans le placeholder, avec un exemple.

À décliner sur l'ensemble des champs et plutôt que laisser la main à l'admin pour remplir la description avec un exemple, je conseille de pré-remplir la description.

Oui, l'ergonome a proposé des maquettes.

Mais nous n'avons pas d'exemple du côté des équipes du design système e l'État (acronyme DSFR), j'ai demandé confirmation ce jour.

Nous avons un gros sujet sur l'accessibilité, donc ce dernier doit primer sur les recommandations de l'ergonome.

Si on perd en accessibilité parce que l'information n'est pas présente dans le placeholder, alors au contraire, nous devons conserver l'attribut à l'intérieur.

La justification de l'ergonome est que lorsque l'usager sélectionne le placeholder, l'attribut (qui peut être un exemple) est supprimer lors du remplissage, il n'est donc plus guidé si il n'a pas mémorisé auparavant ce qui est attendu.

Ci-joint des captures écrans des maquettes de l'ergonome.

[colinux]

OK, donc j'attends ton retour via le DSFR sur ce sujet.

Cependant l'ergonome justifie de ne pas utiliser de placeholder car il disparaît au début de la saisie, or sur sa seconde maquette tout en bas à droite il précise justement "cette indication disparaît lorsque l'usager commerce à saisir le champ", ce qui reviendrait donc au même ? 🤔 Ou bien il y a une erreur dans la maquette…

[Olivier-Marcellin]

c'est sa ponctuation (le tiret) qui n'est pas claire, elle dit "et non à l'intérieur du champ (comprendre = parce que dans le cas contraire si à l'intérieur… cette indication disparait lorsque l'usager commence à saisir le champ.

[colinux]

OK compris, merci !