Le mot qui manquait
Huit mots manquaient sur elchi.dev, et sans JavaScript, nos formulaires mettaient des données personnelles dans l'URL. Le build refuse désormais les deux.
À huit endroits, elchi.dev n'affichait rien là où devait figurer un mot. La ligne sous notre nom, dans le pied de chaque page, en faisait partie. La page de contact n'avait pas de libellé pour sa liste de sujets. Personne ne l'a remarqué, parce qu'un élément vide n'a pas l'air cassé. Il n'a l'air de rien.
Le build refuse désormais de produire une page qui demande un texte inexistant. Et les deux formulaires du site qui envoient quelque chose fonctionnent sans JavaScript, ce qui n'était pas le cas.
Comment un mot disparaît
Les textes d'elchi.dev vivent dans un catalogue, un par langue, que nous éditons dans notre tableau de bord. Une page demande un texte par sa clé, par exemple contact.topic_label, et le build y insère les mots. Quand une clé n'existait pas, le template rendait sans bruit une chaîne vide. Pas d'erreur, pas d'avertissement.
Nous avions bien une vérification. Elle comparait le catalogue allemand au catalogue anglais et faisait échouer le build quand une clé existait dans l'un et pas dans l'autre. Elle attrape une traduction oubliée. Elle ne peut pas attraper une clé absente des deux, et c'est ce qui s'était passé : six clés utilisées par les pages n'avaient jamais été écrites, dans aucune des deux langues. Deux autres étaient des fautes de frappe pour des clés existantes.
Un paragraphe vide ne fait de mal à personne à l'œil. Un legend vide n'est pas anodin pour quelqu'un qui utilise un lecteur d'écran : c'est le nom d'un groupe de choix, et sans lui, les sujets du formulaire de contact formaient un groupe de choix sans nom.
Ce que fait le build maintenant
Les pages lisent le catalogue par une recherche stricte. Demander une clé qui n'existe pas arrête le build, nomme la clé et indique où l'ajouter. Dès sa première exécution, elle en a trouvé une de plus : la page 404 demandait un texte de lien qui n'avait jamais existé et masquait le problème avec une valeur de repli écrite en dur dans le template.
Le script de déploiement vérifie aussi le résultat. Il refusait déjà une page avec un titre vide. Il refuse maintenant aussi un build qui contient un paragraphe, un libellé, une légende, un élément de liste, une entrée de liste de définitions, un lien, un bouton ou une emphase vides, ainsi qu'un span vide, sauf s'il se déclare décoratif. La recherche stricte attrape une clé manquante ; ce contrôle attrape tout le reste de ce qui n'affiche rien.
Les formulaires, sans JavaScript
Le formulaire de contact et le configurateur sont envoyés par un script, qui répond à côté de chaque champ et ne quitte jamais la page. Cette partie fonctionnait. Le problème, c'était ce qui se passait sans le script.
Aucun des deux formulaires n'indiquait comment il devait être envoyé, et un formulaire qui ne dit rien est envoyé en GET. Un navigateur sans JavaScript mettait donc le nom, l'adresse e-mail et le message entier dans la barre d'adresse. De là, ils partent dans l'historique du navigateur, dans les logs des serveurs et dans tout ce qui enregistre des adresses. JavaScript est rarement désactivé, mais quand il l'est, ce sont précisément ces données-là qui ne devraient pas s'y retrouver.
Les deux formulaires indiquent maintenant method="post" et pointent vers le même endpoint que le script. Sans script, le navigateur vérifie lui-même les champs obligatoires, et le serveur répond par une page : un remerciement, ou une page qui dit ce qu'il manque au formulaire et propose le chemin du retour, avec notre adresse e-mail et notre numéro de téléphone.
Une chose ne suit pas. Avec un script, le formulaire enregistre le moment où il est apparu à l'écran, et une demande envoyée moins de deux secondes plus tard est traitée comme venant d'un bot. Sans script, cet horodatage n'existe pas, et ce contrôle ne s'applique donc pas. Le champ caché que seuls les bots remplissent s'applique toujours, tout comme la règle qui classe en spam un message de plus de quatre liens.
Ce qu'il faut en retenir
Un site statique est rapide parce qu'il est fait de fichiers simples. Des fichiers simples font aussi exactement ce qu'ils disent, y compris rien, sans se plaindre. Les contrôles sont là pour que ce « rien » fasse du bruit.
Sources
- HTML Standard: form submission attributes, WHATWG, consulté le
- Understanding Success Criterion 1.3.1: Info and Relationships, W3C, consulté le
Écrit par Samuel Krauss, Founder. Classé sous website, accessibility, forms.
Traduit de l’anglais. Lire l’original anglais