Un formulaire d'inscription

Nous sommes heureux d’annoncer le nouveau livre d’Adam Silver Form Design Patterns . Dans cet extrait du livre, Adam examine les qualités fondamentales d'une forme bien conçue et comment y penser. Vous pouvez aussi obtenir le livre tout de suite →

Commençons par un formulaire d’inscription. La plupart des entreprises veulent des relations à long terme avec leurs utilisateurs. Pour ce faire, ils ont besoin d'utilisateurs pour s'inscrire. Et pour faire que ils doivent donner de la valeur aux utilisateurs en retour. Personne ne souhaite s'inscrire à votre service – il souhaite simplement accéder à tout ce que vous proposez ou à la promesse d'une expérience plus rapide lors de sa prochaine visite.

Malgré l'apparence basique du formulaire d'inscription, vous devez prendre en compte de nombreux éléments: éléments primitifs qui constituent un formulaire (étiquettes, boutons et entrées), moyens de réduire l'effort (même sur de petits formulaires de ce type), tout au long de la validation du formulaire.

En choisissant un formulaire aussi simple, nous pouvons zoomer. sur les qualités fondamentales que l'on trouve dans les formulaires bien conçus.

A quoi ça pourrait ressembler

Le formulaire se compose de quatre champs et d'un bouton de soumission. Chaque zone est composée d’un contrôle (l’entrée) et de son étiquette associée.

Voici le code HTML:

   Prénom 
  
   Nom 
  
   Adresse électronique 
  
   Créer un mot de passe 
  
  

Les étiquettes sont le lieu de notre discussion.

Dans Accessibilité pour tous Laura Kalbag définit quatre paramètres généraux qui améliorent l'expérience utilisateur pour tous:

• Visuel : facilitez la visualisation.
• Auditif : faites en sorte qu'il soit facile d'entendre.
• Moteur : faites en sorte qu'il soit facile d'interagir avec.
• Cognitive : faites-le comprendre facilement.

En examinant les étiquettes de chacun de ces points de vue, nous peut voir à quel point les étiquettes sont importantes. Les utilisateurs voyants peuvent les lire, les utilisateurs malvoyants peuvent les entendre à l’aide d’un lecteur d’écran, tandis que les utilisateurs ayant une déficience motrice peuvent définir plus facilement la mise au point sur le terrain grâce à la zone de frappe plus grande. En effet, le fait de cliquer sur une étiquette met en évidence l'élément de formulaire associé.

Pour ces raisons, tout contrôle qui accepte l'entrée devrait avoir un auxiliaire . Les boutons de soumission n'acceptent pas les entrées, ils n'ont donc pas besoin d'étiquette auxiliaire – l'attribut value qui rend le texte à l'intérieur du bouton, agit comme étiquette accessible.

Pour connecter une entrée à une étiquette, l'attribut id de l'entrée et l'attribut de l'étiquette pour doivent correspondre et être uniques à la page. Dans le cas du champ email, la valeur est "email":

 html
 < label   pour  =  "email" >  Adresse e-mail  </  label > 
 < input   id  =  "email" >   

Ne pas inclure d'étiquette signifie ignorer les besoins de nombreux utilisateurs , y compris ceux ayant des déficiences physiques et cognitives. En nous concentrant sur les obstacles reconnus aux personnes handicapées, nous pouvons rendre nos formulaires plus simples et plus robustes pour tout le monde.

Par exemple, une zone d'impact plus grande est cruciale pour les utilisateurs ayant une déficience motrice, mais elle est plus facile pour ceux qui n'en sont pas affectés.

Placeholders

L'attribut Placeholder est destiné à stocker un indice. Il fournit aux utilisateurs des instructions supplémentaires pour remplir un champ – particulièrement utile pour les champs contenant des règles complexes telles que le champ du mot de passe.

Le texte fictif n'étant pas une valeur réelle, il est estompé pour permettre de le différencier de celui saisi par l'utilisateur. Il est difficile de lire le texte en gris à faible contraste de l'espace réservé. « />

Contrairement aux étiquettes, les astuces sont facultatives et ne doivent pas être utilisées comme bien sûr. Ce n’est pas parce que l’attribut placeholder existe que nous devons l’utiliser. Vous n'avez pas besoin d'espace réservé "Entrez votre prénom" lorsque l'étiquette est "Prénom" – c'est une duplication inutile.

Les espaces réservés séduisent par leur esthétique minimale et peu encombrante. Cela est dû au fait que le texte de substitution est placé à l'intérieur du champ. Mais c’est un moyen problématique de donner un indice aux utilisateurs.

Premièrement, ils disparaissent lorsque l’utilisateur tape. Il est difficile de se souvenir du texte en train de disparaître, ce qui peut provoquer des erreurs si, par exemple, l'utilisateur oublie de satisfaire à l'une des règles de mot de passe. Les utilisateurs confondent souvent le texte d’espace réservé avec une valeur, ce qui provoque l’omission du champ, ce qui, encore une fois, provoquerait des erreurs ultérieurement . Le texte en gris sur blanc manque de contraste, ce qui le rend généralement difficile à lire . Et pour couronner le tout, certains navigateurs ne prennent pas en charge les espaces réservés, certains lecteurs d'écran ne les annoncent pas et le texte d'indice long peut être coupé.

  
   Password 
   Doit contenir au moins 8 caractères, dont au moins 1 chiffre et 1 lettre majuscule 
  
  

L'indice est placé dans l'étiquette et dans un pour qu'il puisse être stylé différemment. En le plaçant à l’intérieur de l’étiquette, il sera lu par les lecteurs d’écran et agrandira davantage la zone d’attaque.

Comme pour la plupart des éléments de conception, ce n’est pas le seul moyen d’obtenir cette fonctionnalité. Nous pourrions utiliser les attributs ARIA pour associer l'indicateur à l'entrée:

   Mot de passe 
  
 Doit contenir au moins 8 caractères, dont au moins un chiffre et une lettre majuscule. 
  

L'attribut aria-décrit par est utilisé pour relier l'allusion par son id – tout comme l'attribut for pour les étiquettes, mais en sens inverse. Il est ajouté à l’étiquette du contrôle et lu après une courte pause. Dans cet exemple, «le mot de passe [pause] doit contenir huit caractères plus avec au moins un chiffre et une lettre majuscule.»

Il existe également d'autres différences. Tout d’abord, un clic sur l’indicateur (un

dans ce cas) ne permet pas de centrer le contrôle, ce qui réduit la zone d’attaque. Deuxièmement, malgré le soutien croissant d’ARIA, il ne sera jamais aussi bien soutenu que les éléments natifs. Dans ce cas particulier, Internet Explorer 11 ne prend pas en charge l’air décrit par . C'est pourquoi la première règle d'ARIA est de ne pas utiliser ARIA :

«Si vous pouvez utiliser un élément ou attribut HTML natif avec la sémantique et le comportement que vous voulez déjà construit en , au lieu de reformuler un élément et d'ajouter un rôle, un état ou une propriété ARIA pour le rendre accessible, puis le faire . »

Étiquettes flottantes

Le modèle d'étiquette flottante de Matt Smith est une technique qui utilise l’étiquette comme marque de réservation. Le libellé commence à l'intérieur du contrôle, mais flotte au-dessus du contrôle lorsque l'utilisateur le tape, d'où son nom. Cette technique est souvent vantée pour ses qualités décalées, minimalistes et peu encombrantes.

Malheureusement, cette approche pose plusieurs problèmes. Premièrement, il n'y a pas de place pour un indice, car l'étiquette et l'indicateur sont identiques. Deuxièmement, ils sont difficiles à lire en raison de leur faible contraste et de la taille réduite de leur texte, comme ils sont généralement conçus. (Un contraste plus faible est nécessaire pour que les utilisateurs aient la possibilité de faire la différence entre une valeur réelle et un espace réservé.) Troisièmement, comme les espaces réservés, ils peuvent être confondus avec une valeur et risquent d'être tronqués.

Et les étiquettes flottantes ne font pas économiser. espace. L'étiquette a besoin d'espace pour commencer. Même s’ils économisaient de l’espace, ce n’était pas une bonne raison pour réduire la facilité d’utilisation des formulaires.

«On dirait que c’est beaucoup d’efforts lorsque vous pouvez simplement placer les étiquettes au-dessus des entrées et obtenir tous les avantages / aucun des problèmes."
– Luke Wroblewski sur les étiquettes flottantes

Les interfaces originales et minimalistes ne rendent pas les utilisateurs géniaux, les interfaces évidentes, inclusives et robustes le sont. Réduire artificiellement la hauteur de tels formulaires est à la fois peu convaincant et problématique.

Vous devez plutôt donner la priorité à la création d'espace pour une étiquette toujours présente et facilement disponible (ainsi que des conseils si nécessaire) au début du processus de conception. De cette façon, vous n'aurez pas besoin de presser le contenu dans un espace restreint.

Nous discuterons bientôt de plusieurs techniques moins artificielles pour réduire la taille des formulaires.

Le protocole de question

Un puissant et ] moyen naturel de réduire la taille d’un formulaire est d’utiliser un protocole de question . Cela vous permet de savoir pourquoi vous posez chaque question ou si vous incluez un champ de formulaire.

Le formulaire d'enregistrement doit-il recueillir les nom, prénom, adresse électronique et mot de passe? Existe-t-il des façons meilleures ou alternatives de demander cette information afin de simplifier l'expérience?

Il est vraisemblable que vous n'avez pas besoin de demander le nom de l'utilisateur et le nom de famille pour qu'il s'enregistre. Si vous avez besoin de ces informations plus tard, pour une raison quelconque, demandez-les ensuite. En supprimant ces champs, nous pouvons réduire de moitié la taille du formulaire. Tout cela sans recourir à des modèles nouveaux et problématiques.

Pas de connexion au mot de passe

Une façon d'éviter de demander un mot de passe aux utilisateurs consiste à utiliser le modèle sans connexion au mot de passe . Cela fonctionne en utilisant la sécurité du courrier électronique (qui nécessite déjà un mot de passe). Les utilisateurs entrent uniquement leur adresse électronique et le service envoie un lien spécial à leur boîte de réception. La suite connecte immédiatement l'utilisateur au service.

Non seulement cela réduit la taille du formulaire à un seul champ, mais également enregistre également les utilisateurs ayant à se rappeler un autre mot de passe. Bien que cela simplifie le formulaire isolément, il ajoute d’une certaine manière une complexité supplémentaire pour l’utilisateur.

Premièrement, les utilisateurs sont peut-être moins familiarisés avec cette approche et de nombreuses personnes s’inquiètent pour la sécurité en ligne. Deuxièmement, le fait de devoir quitter l’application pour accéder à votre compte de messagerie est fastidieux, en particulier pour les utilisateurs qui connaissent leur mot de passe ou utilisent un gestionnaire de mot de passe.

Ce n’est pas qu’une technique soit toujours meilleure que l’autre. C’est une question de protocole qui nous pousse à penser à cela dans le cadre du processus de conception. Sinon, vous ajouterez un champ de mot de passe sur le formulaire sans y penser et en aurez fini avec le mot.

Passphrases

Les mots de passe sont généralement courts, difficiles à mémoriser et faciles à déchiffrer. Les utilisateurs doivent souvent créer un mot de passe de plus de huit caractères, composé d'au moins une lettre majuscule et une lettre minuscule, ainsi que d'un numéro. Cette micro-interaction n’est guère idéale.

"Désolé, mais votre mot de passe doit contenir une lettre majuscule, un chiffre, un haiku, un signe de gang, un hiéroglyphe et le sang d’une vierge."
– meme Internet anonyme

Au lieu d'un mot de passe, nous pourrions demander aux utilisateurs un mot de passe . Une phrase secrète est une série de mots tels que «monkeysinmygarden» (pardon, c’est la première chose qui me vient à l’esprit). Ils sont généralement plus faciles à mémoriser que les mots de passe et ils sont plus sécurisés du fait de leur longueur: les phrases secrètes doivent comporter au moins 16 caractères.

L'inconvénient est que les phrases secrètes sont moins utilisées et donc inconnues. Cela risque d’inquiéter les utilisateurs qui s’inquiètent déjà pour la sécurité en ligne.

Qu'il s'agisse du modèle de connexion sans mot de passe ou des mots de passe, nous ne devrions abandonner la convention que lorsque nous avons effectué des recherches approfondies et variées auprès des utilisateurs. Vous ne voulez pas échanger un ensemble de problèmes contre un autre sans le savoir.

Style de champ

La façon dont vous stylisez vos composants de formulaire dépend, au moins en partie, de la marque de votre produit ou de votre société. Cependant, la position de l'étiquette et les styles de focus sont des considérations importantes. 19659071] "Le fait de placer une étiquette directement sur son champ de saisie permettait aux utilisateurs de capturer les deux éléments d'un seul mouvement de l'œil."

Mais il existe d'autres raisons de placer l'étiquette au-dessus du champ. Dans les petites fenêtres, il n’ya pas de place à côté du contrôle. Et dans les grandes fenêtres, le zoom avant augmente les chances que le texte disparaisse de l'écran .

De plus, certaines étiquettes contiennent beaucoup de texte, ce qui le place sur plusieurs lignes, ce qui perturberait le visuel. rythme si placé à côté du contrôle.

Bien que vous ayez pour objectif de garder les étiquettes sous tension, ce n’est pas toujours possible. L'utilisation d'un modèle prenant en charge des contenus variables – en plaçant les étiquettes au-dessus du contrôle – constitue une bonne stratégie

Aspect, taille et espace

Les champs de formulaire doivent ressembler à des champs de formulaire. Mais qu'est-ce que cela signifie exactement?

Cela signifie qu'une zone de texte doit ressembler à une zone de texte. Les cases vides signifient «remplis-moi» parce que je suis vide, comme un livre à colorier. Cela fait partie de la raison pour laquelle les espaces réservés sont inutiles. Ils suppriment la perception de l'avantage qu'une zone de texte vide fournirait autrement.

Cela signifie également que l'espace vide doit être encadré (encadré). Le fait de supprimer la bordure, ou de n'avoir qu'une bordure inférieure, par exemple, supprime les avantages perçus. Une bordure inférieure peut sembler au début être un séparateur. Même si vous savez que vous devez saisir quelque chose, la valeur va-t-elle au-dessus ou au-dessous de la ligne?

Sur le plan spatial, l’étiquette doit être proche de son contrôle de formulaire et non du contrôle du champ précédent. Les choses qui semblent proches les unes des autres suggèrent qu'elles vont de pair . Un espacement égal peut améliorer l'esthétique, mais cela se ferait au détriment de la facilité d'utilisation.

Enfin, l'étiquette et la zone de texte elle-même devraient être suffisamment grandes pour être lues et exploitées. Cela signifie probablement une taille de police d'au moins 16 pixels et, idéalement, une cible tactile globale d'au moins 44px .

Styles de focus

Les styles de focus sont une perspective plus simple. Par défaut, les navigateurs mettent en évidence les contours de l'élément afin que les utilisateurs, en particulier ceux qui utilisent un clavier, sachent où ils se trouvent. Le problème avec le style par défaut est qu’il est souvent faible, difficile à voir et un peu moche.

Bien que ce soit le cas, ne soyez pas tenté de le supprimer, car cela diminuerait considérablement l’expérience utilisateur de ces utilisateurs. traversant l'écran avec le clavier. Nous pouvons remplacer le style par défaut pour le rendre plus clair et plus esthétique.

 input: focus {
  préciser: 4px solide # ffbf47;
} 

Le champ Email

Malgré son apparence simple, la construction du champ contient des détails importants qui affectent l'expérience.

Comme indiqué. plus tôt, certains champs ont un indice en plus du libellé, raison pour laquelle le libellé se trouve dans une étendue enfant. La classe field-label nous permet de la transformer en CSS.

  
   Adresse e-mail 
  
  

L'étiquette elle-même est “Adresse e-mail” et utilise un casse de phrase. Dans « Arguments pour le cas des lettres », John Saito explique que le cas de phrase (par opposition au titre de titre) est généralement plus facile à lire, plus convivial et facilite le repérage des noms. Que vous teniez compte de ces conseils ou non, mais quel que soit le style que vous choisissez, veillez à les utiliser systématiquement.

L'attribut du type de l'entrée est défini sur qui déclenche une clavier à l'écran spécifique au courrier électronique sur les appareils mobiles. Cela donne aux utilisateurs un accès facile aux @ et . (point) symboles que chaque adresse électronique doit contenir.

Les personnes utilisant un navigateur qui ne supporte pas le système verront une saisie de texte standard ( ). Il s'agit d'une forme d'amélioration progressive, pierre angulaire de la conception d'expériences inclusives.

Amélioration progressive

L'amélioration progressive concerne les utilisateurs. Il arrive juste pour faciliter nos vies aussi que les concepteurs et les développeurs. Au lieu de suivre un ensemble de navigateurs et de périphériques (ce qui est impossible!), Nous pouvons simplement nous concentrer sur les fonctionnalités.

Avant tout, l’amélioration progressive consiste à toujours offrir aux utilisateurs une expérience raisonnable, quels que soient leur navigateur, appareil ou qualité de la connexion. Lorsque les choses tournent mal - et ils le feront - les utilisateurs ne souffriront pas car ils pourront toujours faire avancer les choses.

Il existe de nombreuses façons pour une expérience de se tromper. Peut-être que la feuille de style ou le script ne se charge pas. Tout se charge peut-être, mais le navigateur de l'utilisateur ne reconnaît pas certains codes HTML, CSS ou JavaScript. Quoiqu'il en soit, l'utilisation de l'amélioration progressive lors de la conception d'expériences évite aux utilisateurs de passer un mauvais moment.

Cela commence par HTML pour la structure et le contenu. Si le code CSS ou JavaScript ne se charge pas, c’est correct parce que le contenu est là.

Si tout se passe bien, il est possible que divers éléments HTML ne soient pas reconnus. Par exemple, certains navigateurs ne comprennent pas . C’est bien, car les utilisateurs auront plutôt une zone de texte (). Les utilisateurs peuvent toujours entrer une adresse électronique. ils ne disposent tout simplement pas d’un clavier spécifique au courrier électronique sur leur mobile.

Peut-être que le navigateur ne comprend pas les CSS sophistiqués et les ignore. Dans la plupart des cas, ce n’est pas un problème. Supposons que vous ayez un bouton avec border-radius: 10px . Les navigateurs qui ne reconnaissent pas cette règle afficheront un bouton avec des coins inclinés. On peut soutenir que l’affrontement perçu du bouton est réduit, mais les utilisateurs ne sont pas blessés. Dans d'autres cas, il peut être utile d'utiliser les requêtes de fonction .

Ensuite, il y a JavaScript, qui est plus compliqué. Lorsque le navigateur essaie d’analyser des méthodes qu’il ne reconnaît pas, il a tout à fait raison. Cela peut entraîner l'échec de vos autres scripts (valides et pris en charge). Si votre script ne vérifie pas d’abord que les méthodes existent (détection de fonctionnalité) et fonctionnent (test de fonctionnalité) avant de les utiliser, il est possible que les utilisateurs obtiennent une interface endommagée. Par exemple, si le gestionnaire de clic d’un bouton appelle une méthode non reconnue, le bouton ne fonctionnera pas. C’est mauvais.

C’est ainsi que vous améliorez. Mais le mieux est de ne pas avoir besoin d’être amélioré. HTML avec un peu de CSS peut donner aux utilisateurs une excellente expérience. C’est le contenu qui compte et vous n’avez pas besoin de JavaScript pour cela. Plus vous pouvez compter sur le contenu (HTML) et le style (CSS), mieux c'est. Je ne saurais trop le souligner: si souvent, l’expérience de base est la meilleure et la plus performante . Il est inutile d'améliorer quelque chose s'il n'apporte pas de valeur ajoutée [voir (voir principe de conception inclusif 7).

Bien sûr, il arrive parfois que l'expérience de base ne soit pas aussi bonne qu'elle pourrait l'être - c'est quand il est temps d'améliorer. Mais si nous suivons l’approche ci-dessus, quand un élément CSS ou JavaScript n’est pas reconnu ou exécuté, les choses continueront de fonctionner.

L’amélioration progressive nous fait penser à ce qui se passe lorsque les choses échouent. Cela nous permet de construire des expériences résilientes avec la résilience. Mais de la même manière, cela nous fait réfléchir à la nécessité d'une amélioration. et, le cas échéant, quelle est la meilleure façon de procéder.

Champ de mot de passe

Nous utilisons le même balisage que le champ de courrier électronique abordé précédemment. Si vous utilisez un langage de modèle, vous pourrez créer un composant qui accepte les deux types de champs. Cela aide à appliquer le principe de conception inclusif 3, à être cohérent .

  
     Choisir le mot de passe 
     Doit contenir plus de 8 caractères avec au moins un chiffre et une lettre majuscule. 
  
  

Le champ du mot de passe contient un indice. Sans cette option, les utilisateurs ne comprendront pas les exigences, ce qui risquerait de provoquer une erreur une fois qu'ils ont essayé de continuer.

L'attribut type = "password" masque la valeur de l'entrée en remplaçant les informations saisies par l'utilisateur. avec de petits points noirs. Il s'agit d'une mesure de sécurité qui empêche les personnes de voir ce que vous avez tapé s'il se trouve à proximité.

A Password Reveal

Le fait de masquer la valeur lorsque l'utilisateur tape rend difficile la correction des fautes de frappe. Ainsi, lorsqu’une tâche est créée, il est souvent plus facile d’effacer toute l’entrée et de recommencer. C’est frustrant, car la plupart des utilisateurs n’utilisent pas d’ordinateur avec une personne regardant par-dessus leur épaule.

En raison du risque accru de fautes de frappe, certains formulaires d’enregistrement comportent un champ supplémentaire «Confirmer le mot de passe». Il s’agit d’une mesure de précaution qui oblige l’utilisateur à taper deux fois le même mot de passe, ce qui double l’effort et dégrade son expérience. Au lieu de cela, il est préférable de laisser les utilisateurs révéler leur mot de passe, qui concerne les principes 4 et 5, donnez le contrôle et le choix offert respectivement. De cette manière, les utilisateurs peuvent choisir de révéler leur mot de passe lorsqu'ils savent que personne ne les regarde, ce qui réduit le risque de fautes de frappe.

Les versions récentes d'Internet Explorer et de Microsoft Edge fournissent ce problème de manière native. Comme nous allons créer notre propre solution, nous devrions supprimer cette fonctionnalité en utilisant CSS comme ceci:

 input [type=password] :: - ms -veve {
  affichage: aucun;
} 

Nous devons tout d'abord insérer un bouton à côté de l'entrée. L'élément devrait être votre élément de référence pour tout changement de code JavaScript, à l'exception du changement de lieu, qui est destiné aux liens. Lorsque vous cliquez dessus, vous devriez basculer l'attribut type entre mot de passe et text ; et l’étiquette du bouton entre “Show” et “Hide”.

 function PasswordReveal (input) {
  // stocke l'entrée en tant que propriété de l'instance
  // pour qu'il puisse être référencé dans les méthodes
  // sur le prototype
  this.input = input;
  this.createButton ();
};

PasswordReveal.prototype.createButton = function () {
  // crée un bouton
  this.button = $ (' Afficher le mot de passe ');
  // bouton d'injection
  $ (this.input) .parent (). append (this.button);
  // écoute l'événement de clic du bouton
  this.button.on ('cliquez', $ .proxy (this, 'onButtonClick'));
};

PasswordReveal.prototype.onButtonClick = function (e) {
  // Basculer le type d'entrée et le texte du bouton
  if (this.input.type === 'mot de passe') {
    this.input.type = 'text';
    this.button.text ( «Masquer le mot de passe);
  } autre {
    this.input.type = 'mot de passe';
    this.button.text ( 'Afficher le mot de passe');
  }
}; 

Notes de syntaxe et d'architecture JavaScript

Comme il existe de nombreux types de JavaScript et différentes manières de concevoir des composants d'architecte, nous allons passer en revue les choix utilisés pour construire le composant de révélation de mot de passe, et tous les composants à venir dans le livre.

Premièrement, nous utilisons un constructeur. Un constructeur est une fonction conventionnellement écrite dans le cas d'un chameau supérieur - PasswordReveal pas passwordReveal . Il a été initialisé à l’aide du mot-clé new ce qui nous permet d’utiliser le même code pour créer plusieurs instances du composant:

 var passwordReveal1 = new PasswordReveal (document.getElementById ('input1'));

var passwordReveal2 = new PasswordReveal (document.getElementById ('input2')); 

Deuxièmement, les méthodes du composant sont définies sur le prototype - par exemple, PasswordReveal.prototype.onButtonClick . Le prototype est le moyen le plus performant de partager des méthodes entre plusieurs instances du même composant.

Troisièmement, jQuery est utilisé pour créer et extraire des éléments et écouter des événements. Bien que jQuery ne soit ni nécessaire ni préférable, son utilisation signifie que ce livre peut se concentrer sur les formulaires et non sur la complexité des composants inter-navigateurs.

Si vous êtes un concepteur qui code un peu, l'ubiquité et la faiblesse de jQuery -La barrière à l'entrée devrait être utile. De même, si vous préférez ne pas utiliser jQuery, vous n'aurez aucun mal à refactoriser les composants selon vos préférences.

Vous avez peut-être également remarqué l'utilisation de la fonction $. Proxy . Ceci est l’implémentation par jQuery de Function.prototype.bind . Si nous n’utilisions pas cette fonction pour écouter des événements, le gestionnaire d’événements serait appelé dans le contexte de l’élément ( this ). Dans l'exemple ci-dessus, this.button serait indéfini. Mais nous voulons que ce soit l’objet de révélation du mot de passe, afin que nous puissions accéder à ses propriétés et à ses méthodes.

Options d’interface alternatives

L’interface de révélation du mot de passe que nous avons construite ci-dessus bascule le libellé du bouton entre “ Afficher le mot de passe ”et“ Masquer le mot de passe ”. Certains utilisateurs de lecteurs d'écran peuvent être désorientés lorsque l'étiquette du bouton est modifiée; Une fois qu'un utilisateur rencontre un bouton, il s'attend à ce qu'il persiste. Même si le bouton est persistant dans le bouton son libellé lui donne l’impression que ce n’est pas le cas.

Si votre recherche montre que cela pose un problème, vous pouvez essayer deux approches alternatives.

D’abord, utilisez un case à cocher avec une étiquette persistante «Afficher le mot de passe». L'état sera signalé par l'attribut vérifié . Les utilisateurs de lecteurs d’écran entendront «Afficher le mot de passe, la case à cocher, la case cochée» (ou similaire). Les utilisateurs voyants verront la case à cocher cocher la case. Le problème avec cette approche est que les cases à cocher servent à saisir des données et non à contrôler l'interface. Certains utilisateurs peuvent penser que leur mot de passe sera révélé au système.

Ou, en second lieu, changer le statut du bouton - et non l’étiquette. Pour transmettre l'état aux utilisateurs de lecteurs d'écran, vous pouvez basculer l'attribut entre true (pressé) et false (non pressé).

  
   Show mot de passe
 

Lors de la mise au point du bouton, les lecteurs d'écran annonceront «Afficher le mot de passe, le bouton bascule, enfoncé» (ou similaire). Pour les utilisateurs voyants, vous pouvez attribuer au bouton l'apparence voulue en utilisant le sélecteur d'attribut comme suit:

 [aria-pressed="true"] {
  box-shadow: encart 0 0 0 0.15rem # 000, encart 0.25em 0.25em 0 #fff;
} 

Assurez-vous simplement que les styles non pressés et pressés sont évidents et différenciés, sinon les utilisateurs malvoyants peuvent avoir du mal à faire la différence.

Microcopy

Le libellé est réglé sur “Choisir un mot de passe” plutôt que sur “Mot de passe”. . ”Ce dernier est quelque peu déroutant et pourrait inciter l’utilisateur à taper un mot de passe qu’il possède déjà, ce qui pourrait poser un problème de sécurité. Plus subtilement, cela pourrait suggérer que l'utilisateur est déjà enregistré, ce qui amène les utilisateurs présentant des déficiences cognitives à penser qu'ils se connectent à la place.

Lorsque «Mot de passe» est ambigu, «Choisir un mot de passe» apporte une clarté.

Styles de boutons

C'est quoi un bouton? Nous référons à différents types de composants sur une page Web en tant que bouton. En fait, j'ai déjà couvert deux types de boutons différents sans les appeler. Faisons-le maintenant.

Les boutons qui soumettent des formulaires sont des «boutons d’envoi» et sont codés de manière caractéristique en ou . L'élément est plus malléable en ce sens que vous pouvez y imbriquer d'autres éléments. Mais il est rarement nécessaire de le faire. La plupart des boutons de soumission ne contiennent que du texte.

Remarque: Dans les versions antérieures d'Internet Explorer, si vous avez plusieurs le formulaire soumettra la valeur de tous les boutons au serveur. , peu importe ce qui a été cliqué. Vous aurez besoin de savoir quel bouton a été cliqué pour pouvoir déterminer la bonne action à prendre, c'est pourquoi cet élément doit être évité.

D'autres boutons sont injectés dans l'interface pour améliorer l'expérience de JavaScript - à peu près comme nous avons fait avec le composant de révélation de mot de passe discuté plus tôt. C'était aussi un mais son type était réglé sur le bouton (pas soumettre ).

Dans les deux cas, la première chose à savoir sur boutons est qu'ils ne sont pas des liens. Les liens sont généralement soulignés (par les styles d'agent utilisateur) ou spécialement placés (dans une barre de navigation) afin de pouvoir être distingués entre du texte normal. En survolant un lien, le curseur se transforme en pointeur. En effet, contrairement aux boutons, les liens ont une faible perception du pouvoir .

Dans Resilient Web Design Jeremy Keith discute de l’idée de l’honnêteté matérielle. Il déclare: «Un matériau ne doit pas remplacer un autre. Sinon, le résultat final est trompeur. ”Faire en sorte qu'un lien ressemble à un bouton est malhonnête. Il indique aux utilisateurs que les liens et les boutons sont les mêmes quand ils ne sont pas.

Liens peuvent faire des boutons de choses ne peuvent pas faire. Les liens peuvent être ouverts dans un nouvel onglet ou mis en favori pour plus tard, par exemple. Par conséquent, les boutons ne doivent pas ressembler à des liens ni avoir un curseur de pointeur. Au lieu de cela, nous devrions faire en sorte que les boutons ressemblent à des boutons qui ont naturellement une forte perception de capacité financière. Whether they have rounded corners, drop shadows, and borders is up to you, but they should look like buttons regardless.

Buttons can still give feedback on hover (and on focus) by changing the background colour, for example.

Placement

Submit buttons are typically placed at the bottom of the form: with most forms, users fill out the fields from top to bottom, and then submit. But should the button be aligned left, right or center? To answer this question, we need to think about where users will naturally look for it.

Field labels and form controls are aligned left (in left-to-right reading languages) and run from top to bottom. Users are going to look for the next field below the last one. Naturally, then, the submit button should also be positioned in that location: to the left and directly below the last field. This also helps users who zoom in, as a right-aligned button could more easily disappear off-screen.

Text

The button’s text is just as important as its styling. The text should explicitly describe the action being taken. And because it’s an action, it should be a verb. We should aim to use as few words as possible because it’s quicker to read. But we shouldn’t remove words at the cost of clarity.

The exact words can match your brand’s tone of voice, but don’t exchange clarity for quirkiness.

Simple and plain language is easy for everyone to understand. The exact words will depend on the type of service. For our registration form “Register” is fine, but depending on your service “Join” or “Sign up” might be more appropriate.

Validation

Despite our efforts to create an inclusive, simple, and friction-free registration experience, we can’t eliminate human error. People make mistakes and when they do, we should make fixing them as easy as possible.

When it comes to form validation, there are a number of important details to consider. From choosing when to give feedback, through to how to display that feedback, down to the formulation of a good error message — all of these things need to be taken into account.

HTML5 Validation

HTML5 validation has been around for a while now. By adding just a few HTML attributes, supporting browsers will mark erroneous fields when the form is submitted. Non-supporting browsers fall back to server-side validation.

Normally I would recommend using functionality that the browser provides for free because it’s often more performant, robust, and accessible. Not to mention, it becomes more familiar to users as more sites start to use the standard functionality.

While HTML5 validation support is quite good, it’s not implemented uniformly. For example, the required attribute can mark fields as invalid from the outset, which isn’t desirable. Some browsers, such as Firefox 45.7, will show an error of “Please enter an email address” even if the user entered something in the box, whereas Chrome, for example, says “Please include an ‘@’ in the email address,” which is more helpful.

We also want to give users the same interface whether errors are caught on the server or the client. For these reasons we’ll design our own solution. The first thing to do is turn off HTML5 validation:

Handling Submission

When the user submits the form, we need to check if there are errors. If there are, we need to prevent the form from submitting the details to the server.

function FormValidator(form) {
  form.on('submit', $.proxy(this, 'onSubmit'));
}

FormValidator.prototype.onSubmit = function(e) {
  if(!this.validate()) {
    e.preventDefault();
    // show errors
  }
};

Note that we are listening to the form’s submit event, not the button’s click event. The latter will stop users being able to submit the form by pressing Enter when focus is within one of the fields. This is also known as implicit form submission.

Displaying Feedback

It’s all very well detecting the presence of errors, but at this point users are none the wiser. There are three disparate parts of the interface that need to be updated. We’ll talk about each of those now.

Document Title

The document’s is the first part of a web page to be read out by screen readers. As such, we can use it to quickly inform users that something has gone wrong with their submission. This is especially useful when the page reloads after a server request.

Even though we’re enhancing the user experience by catching errors on the client with JavaScript, not all errors can be caught this way. For example, checking that an email address hasn’t already been taken can only be checked on the server. And in any case, JavaScript is prone to failure so we can’t solely rely on its availability.

Where the original page title might read “Register for [service],” on error it should read “(2 errors) Register for [service]” (or similar). The exact wording is somewhat down to opinion.

The following JavaScript updates the title:

document.title = "(" + this.errors.length + ")" + document.title;

As noted above, this is primarily for screen reader users, but as is often the case with inclusive design, what helps one set of users helps everyone else too. This time, the updated title acts as a notification in the tab.

Error Summary

In comparison with the title element, the error summary is more prominent, which tells sighted users that something has gone wrong. But it’s also responsible for letting users understand what’s gone wrong and how to fix it.

It’s positioned at the top of the page so users don’t have to scroll down to see it after a page refresh (should an error get caught on the server). Conventionally, errors are colored red. However, relying on color alone could exclude colorblind users. To draw attention to the summary, consider also using position, size, text, and iconography.

The panel includes a heading, “There’s a problem,” to indicate the issue. Notice it doesn’t say the word “Error,” which isn’t very friendly. Imagine you were filling out your details to purchase a car in a showroom and made a mistake. The salesperson wouldn’t say “Error” — in fact it would be odd if they did say that.

  
There’s a problem
  

    
Enter an email address
    
The password must contain an uppercase letter
  

The container has a role of groupwhich is used to group a set of interface elements: in this case, the heading and the error links. The tabindex attribute is set to -1so it can be focused programmatically with JavaScript (when the form is submitted with mistakes). This ensures the error summary panel is scrolled into view. Otherwise, the interface would appear unresponsive and broken when submitted.

Note: Using tabindex="0" means it will be permanently focusable by way of the Tab key, which is a 2.4.3 Focus Order WCAG fail. If users can tab to something, they expect it will actually do something.

FormValidator.prototype.showSummary = function () {
  // ...
  this.summary.focus();
};

Underneath, there’s a list of error links. Clicking a link will set focus to the erroneous field, which lets users jump into the form quickly. The link’s href attribute is set to the control’s id, which in some browsers is enough to set focus to it. However, in other browsers, clicking the link will just scroll the input into view, without focusing it. To fix this we can focus the input explicitly.

FormValidator.prototype.onErrorClick = function(e) {
  e.preventDefault();
  var href = e.target.href;
  var id = href.substring(href.indexOf("#"), href.length);
  $(id).focus();
};

When there aren’t any errors, the summary panel should be hidden. This ensures that there is only ever one summary panel on the page, and that it appears consistently in the same location whether errors are rendered by the client or the server. To hide the panel we need to add a class of hidden.

.hidden {
  display: none;
}

Note: You could use the hidden attribute/property to toggle an element’s visibility, but there’s less support for it. Inclusive design is about making decisions that you know are unlikely to exclude people. Using a class aligns with this philosophy.

Inline Errors

We need to put the relevant error message just above the field. This saves users scrolling up and down the page to check the error message, and keeps them moving down the form. If the message was placed below the field, we’d increase the chance of it being obscured by the browser autocomplete panel or by the onscreen keyboard.

  
    
    
    Enter your email address.
    
    Enter an email address
  

Like the hint pattern mentioned earlier, the error message is injected inside the label. When the field is focused, screen reader users will hear the message in context, so they can freely move through the form without having to refer to the summary.

The error message is red and uses an SVG warning icon to draw users’ attention. If we’d used only a color change to denote an error, this would exclude color-blind users. So this works really well for sighted users — but what about screen reader users?

To give both sighted and non-sighted users an equivalent experience, we can use the well-supported aria-invalid attribute. When the user focuses the input, it will now announce “Invalid” (or similar) in screen readers.

Note: The registration form only consists of text inputs. In chapter 3, “A Flight Booking Form,” we’ll look at how to inject errors accessibly for groups of fields such as radio buttons.

Submitting the Form Again

When submitting the form for a second time, we need to clear the existing errors from view. Otherwise, users may see duplicate errors.

FormValidator.prototype.onSubmit = function(e) {
  this.resetPageTitle();
  this.resetSummaryPanel();
  this.removeInlineErrors();
  if(!this.validate()) {
    e.preventDefault();
    this.updatePageTitle();
    this.showSummaryPanel();
    this.showInlineErrors();
  }
};

Initialization

Having finished defining the FormValidator component, we’re now ready to initialize it. To create an instance of FormValidatoryou need to pass the form element as the first parameter.

var validator = new FormValidator(document.getElementById('registration'));

To validate the email field, for example, call the addValidator() method:

validator.addValidator('email', [{
  method: function(field) {
    return field.value.trim().length > 0;
  },
  message: 'Enter your email address.'
},{
  method: function(field) {
    return (field.value.indexOf('@') > -1);
  },
  message: 'Enter the ‘at’ symbol in the email address.'
}]);

The first parameter is the control’s nameand the second is an array of rule objects. Each rule contains two properties: method and message. The method is a function that tests various conditions to return either true or false. False puts the field into an error state, which is used to populate the interface with errors as discussed earlier.

Forgiving Trivial Mistakes

In The Design of Everyday ThingsDon Norman talks about designing for error. He talks about the way people converse:

“If a person says something that we believe to be false, we question and debate. We don’t issue a warning signal. We don’t beep. We don’t give error messages. […] In normal conversations between two friends, misstatements are taken as normal, as approximations to what was really meant.”

Unlike humans, machines are not intelligent enough to determine the meaning of most actions, but they are often far less forgiving of mistakes than they need to be. Jared Spool makes a joke about this in “Is Design Metrically Opposed?” (about 42 minutes in):

“It takes one line of code to take a phone number and strip out all the dashes and parentheses and spaces, and it takes ten lines of code to write an error message that you left them in.”

The addValidator method (shown above) demonstrates how to design validation rules so they forgive trivial mistakes. The first rule, for example, trims the value before checking its length, reducing the burden on the user.

Live Inline Validation

Live inline validation gives users feedback as they type or when they leave the field (onblur). There’s some evidence to show that live inline validation improves accuracy and decreases completion times in long forms. This is partially to do with giving users feedback when the field’s requirements are fresh in users’ minds. But live inline validation (or live validation for short) poses several problems.

For entries that require a certain number of characters, the first keystroke will always constitute an invalid entry. This means users will be interrupted early, which can cause them to switch mental contexts, from entering information to fixing it.

Alternatively, we could wait until the user enters enough characters before showing an error. But this means users only get feedback after they have entered a correct value, which is somewhat pointless.

We could wait until the user leaves the field (onblur), but this is too late as the user has mentally prepared for (and often started to type in) the next field. Moreover, some users switch windows or use a password manager when using a form. Doing so will trigger the blur event, causing an error to show before the user is finished. All very frustrating.

Remember, there’s no problem with giving users feedback without a page refresh. Nor is there a problem with putting the error messages inline (next to fields) — we’ve done this already. The problem with live feedback is that it interrupts users either too early or too late, which often results in a jarring experience.

If users are seeing errors often, there’s probably something wrong elsewhere. Focus on shortening your form and providing better guidance (good labeling and hint text). This way users shouldn’t see more than the odd error. We’ll look at longer forms in the next chapter.

Checklist Affirmation Pattern

A variation of live validation involves ticking off rules (marking them as complete) as the user types. This is less invasive than live validation but isn’t suited to every type of field. Here’s an example of MailChimp’s sign-up form, which employs this technique for the password field.

You should put the rules above the field. Otherwise the onscreen keyboard could obscure the feedback. As a result, users may stop typing and hide the keyboard to then check the feedback.

A Note on Disabling Submit Buttons

Some forms are designed to disable the submit button until all the fields become valid. There are several problems with this.

First, users are left wondering what’s actually wrong with their entries. Second, disabled buttons are not focusable, which makes it hard for the button to be discovered by blind users navigating using the Tab key. Third, disabled buttons are hard to read as they are grayed out.

As we’re providing users with clear feedback, when the user expects it, there’s no good reason to take control away from the user by disabling the button anyway.

Crafting a Good Error Message

There’s nothing more important than content. Users don’t come to your website to enjoy the design. They come to enjoy the content or the outcome of using a service.

Even the most thought out, inclusive and beautifully designed experience counts for nothing if we ignore the words used to craft error messages. One study showed that showing custom error messages increased conversions by 0.5% which equated to more than £250,000 in yearly revenue.

“Content is the user experience.”
— Ginny Redish

Like labels, hints, and any other content, a good error message provides clarity in as few words as possible. Normally, we should drive the design of an interface based on the content — not the other way around. But in this case, understanding how and why you show error messages influences the design of the words. This is why Jared Spool says “content and design are inseparable work partners.”

We’re showing messages in the summary at the top of the screen and next to the fields. Maintaining two versions of the same message is a hard sell for an unconvincing gain. Instead, design an error message that works in both places. “Enter an ‘at’ symbol” needs context from the field label to make sense. “Your email address needs an ‘at’ symbol” works well in both places.

Avoid pleasantries, like starting each error message with “Please.” On the one hand, this seems polite; on the other, it gets in the way and implies a choice.

Whatever approach you take, there’s going to be some repetition due to the nature of the content. And testing usually involves submitting the form without entering any information at all. This makes the repetition glaringly obvious, which may cause us to flip out. But how often is this the case? Most users aren’t trying to break the interface.

Different errors require different formatting. Instructions like “Enter your first name” are natural. But “Enter a first name that is 35 characters or less” is longer, wordier, and less natural than a description like “First name must be 35 characters or less.”

Here’s a checklist:

• Be concise. Don’t use more words than are necessary, but don’t omit words at the cost of clarity.
• Be consistent. Use the same tone, the same words, and the same punctuation throughout.
• Be specific. If you know why something has gone wrong, say so. “The email is invalid.” is ambiguous and puts the burden on the user. “The email needs an ‘at’ symbol” is clear.
• Be human, avoid jargon. Don’t use words like invalid, forbidden, and mandatory.
• Use plain language. Error messages are not an opportunity to promote your brand’s humorous tone of voice.
• Use the active voice. When an error is an instruction and you tell the user what to do. For example, “Enter your name,” not “First name must be entered.”
• Don’t blame the user. Let them know what’s gone wrong and how to fix it.

Summary

In this chapter we solved several fundamental form design challenges that are applicable well beyond a simple registration form. In many respects, this chapter has been as much about what not to do, as it has about what we should. By avoiding novel and artificial space-saving patterns to focus on reducing the number of fields we include, we avoid several usability failures while simultaneously making forms more pleasant.

Things to Avoid

• Using the placeholder attribute as a mechanism for storing label and hint text.
• Using incorrect input types.
• Styling buttons and links the same.
• Validating fields as users type.
• Disabling submit buttons.
• Using complex jargon and brand-influenced microcopy.

And that’s it. If you liked this first chapter of the Form Design Patternsyou can get the book right away. Happy reading!

(cm)