Bonnes pratiques concernant le formulaire de connexion

Utilisez des fonctionnalités de navigateur multiplates-formes pour créer des formulaires de connexion sécurisés, accessibles et faciles à utiliser.

Si les utilisateurs doivent se connecter à votre site, il est essentiel de bien concevoir votre formulaire de connexion. Cela est particulièrement vrai pour les personnes dont la connexion est mauvaise, qui utilisent un mobile, qui sont pressées ou qui sont stressées. Les formulaires de connexion mal conçus enregistrent des taux de rebond élevés. Chaque rebond peut signifier un utilisateur perdu et mécontent, et pas seulement une occasion de connexion manquée.

Voici un exemple de formulaire de connexion simple illustrant toutes les bonnes pratiques:

Checklist

• Utilisez des éléments HTML pertinents: <form>, <input>, <label> et <button>.
• Ajouter un libellé <label> à chaque entrée.
• Utilisez les attributs d'élément pour accéder aux fonctionnalités intégrées du navigateur: type, name, autocomplete, required.
• Attribuez aux attributs name et id des valeurs stables qui ne changent pas entre les chargements de page ou les déploiements de sites Web.
• Indiquez la connexion dans son propre élément <form>.
• Assurez-vous que le formulaire a bien été envoyé.
• Utilisez autocomplete="new-password" et id="new-password" pour la saisie du mot de passe dans un formulaire d'inscription et pour le nouveau mot de passe dans un formulaire de réinitialisation.
• Utilisez autocomplete="current-password" et id="current-password" pour saisir le mot de passe de connexion.
• Activez la fonctionnalité Afficher le mot de passe.
• Utilisez aria-label et aria-describedby pour les mots de passe.
• Ne doublez pas les entrées.
• Concevez des formulaires de sorte que le clavier mobile ne masque pas les entrées ni les boutons.
• Assurez-vous que les formulaires sont utilisables sur mobile: utilisez du texte lisible et assurez-vous que les entrées et les boutons sont assez grands pour être utilisés comme zones cibles tactiles.
• Conservez votre branding et votre style sur vos pages d'inscription et de connexion.
• Effectuez des tests sur le terrain et lors de l'atelier: intégrez des analyses de page, des analyses des interactions et des mesures de performances axées sur l'utilisateur dans votre flux d'inscription et de connexion.
• Effectuez des tests sur différents navigateurs et appareils: le comportement des formulaires varie considérablement d'une plate-forme à l'autre.

Utilisez un code HTML pertinent

Utilisez des éléments conçus pour la tâche: <form>, <label> et <button>. Ceux-ci activent les fonctionnalités intégrées du navigateur, améliorent l'accessibilité et ajoutent du sens à votre balisage.

Utiliser "<form>"

Vous pourriez être tenté d'encapsuler les entrées dans un <div> et de gérer l'envoi des données d'entrée uniquement avec JavaScript. Il est généralement préférable d'utiliser un ancien élément <form> simple. Cela rend votre site accessible aux lecteurs d'écran et autres appareils d'assistance, offre diverses fonctionnalités intégrées aux navigateurs, facilite la création d'un système de connexion fonctionnel de base pour les navigateurs plus anciens, et peut continuer à fonctionner même en cas d'échec de JavaScript.

Utiliser "<label>"

Pour étiqueter une entrée, utilisez un objet <label>.

<label for="email">Email</label>
<input id="email" …>

Deux raisons:

• Appuyez ou cliquez sur un libellé pour le sélectionner. Associez un libellé à une entrée en utilisant l'attribut for du libellé avec l'élément name ou id de l'entrée.
• Les lecteurs d'écran énoncent le texte du libellé lorsque le libellé ou l'entrée du libellé est sélectionné.

N'utilisez pas d'espaces réservés comme étiquettes d'entrée. Les utilisateurs sont susceptibles d'oublier à quoi ressemblait l'entrée une fois qu'ils ont commencé à saisir du texte, en particulier s'ils sont distraits ("Ai-je saisi une adresse e-mail, un numéro de téléphone ou un ID de compte ?"). Les espaces réservés présentent de nombreux autres problèmes potentiels. Consultez les sections Ne pas utiliser l'attribut d'espace réservé et Les espaces réservés dans les champs de formulaire sont dangereux si vous n'en êtes pas convaincu.

Il est probablement préférable de placer vos étiquettes au-dessus des entrées. Cela permet une conception cohérente sur mobile et ordinateur, et selon les recherches sur l'IA de Google, l'analyse par les utilisateurs est plus rapide. Vous obtenez les étiquettes et les entrées en pleine largeur, et vous n'avez pas besoin d'ajuster l'étiquette et la largeur de l'entrée pour les adapter au texte du libellé.

Ouvrez le Glitch label-position sur un appareil mobile pour le constater par vous-même.

Utiliser "<button>"

Utilisez <button> pour les boutons. Les éléments de bouton offrent un comportement accessible et une fonctionnalité intégrée d'envoi de formulaires. Ils peuvent être stylisés facilement. Il est inutile d'utiliser un élément <div> ou un autre élément se faisant passer pour un bouton.

Assurez-vous que le bouton "Envoyer" indique sa fonction. (par exemple, Créer un compte ou Se connecter), et non Envoyer ou Commencer.

Vérifier que le formulaire a bien été envoyé

Aider les gestionnaires de mots de passe à comprendre qu’un formulaire a été envoyé. Vous pouvez le faire de deux manières:

• Accédez à une autre page.
• Émulez la navigation avec History.pushState() ou History.replaceState(), puis supprimez le formulaire de mot de passe.

Avec une requête XMLHttpRequest ou fetch, assurez-vous que la réussite de la connexion est signalée dans la réponse et gérée en extrayant le formulaire du DOM et en indiquant la réussite à l'utilisateur.

Envisagez de désactiver le bouton Sign in (Se connecter) une fois que l'utilisateur a appuyé ou cliqué dessus. De nombreux utilisateurs cliquent sur les boutons à plusieurs reprises, même sur des sites rapides et responsifs. Cela ralentit les interactions et augmente la charge du serveur.

À l'inverse, ne désactivez pas l'envoi de formulaire en attente d'une saisie de l'utilisateur. Par exemple, ne désactivez pas le bouton Se connecter si les utilisateurs n'ont pas saisi leur code client. Les utilisateurs risquent de manquer quelque chose du formulaire. Appuyez plusieurs fois sur le bouton Connexion (désactivé) s'ils pensent que cela ne fonctionne pas. Au minimum, si vous devez désactiver l'envoi de formulaire, expliquez à l'utilisateur ce qui manque lorsqu'il clique sur le bouton désactivé.

Ne pas doubler les entrées

Certains sites obligent les utilisateurs à saisir deux fois leur adresse e-mail ou leur mot de passe. Cela peut réduire le nombre d'erreurs pour quelques utilisateurs, mais alourdit le travail de tous les utilisateurs et augmente les taux d'abandon. Par ailleurs, il n'est pas logique de se demander si les navigateurs saisissent automatiquement des adresses e-mail ou suggèrent des mots de passe sécurisés. Il est préférable de permettre aux utilisateurs de confirmer leur adresse e-mail (vous devrez le faire de toute façon) et de leur permettre de réinitialiser facilement leur mot de passe si nécessaire.

Tirer le meilleur parti des attributs d'éléments

C'est là que la magie opère vraiment ! Les navigateurs intègrent plusieurs fonctionnalités pratiques qui utilisent des attributs d'éléments d'entrée.

Ne pas divulguer les mots de passe, mais permettre aux utilisateurs de les voir s'ils le souhaitent

Les mots de passe saisis doivent comporter type="password" pour masquer le texte du mot de passe et aider le navigateur à comprendre que l'entrée est destinée aux mots de passe. (Notez que les navigateurs emploient différentes techniques pour comprendre les rôles d'entrée et décider s'ils souhaitent ou non proposer d'enregistrer les mots de passe.)

Nous vous conseillons d'activer l'option Afficher le mot de passe pour permettre aux utilisateurs de vérifier le texte qu'ils ont saisi, sans oublier d'ajouter un lien Mot de passe oublié. Consultez la section Activer l'affichage des mots de passe.

Donner aux utilisateurs de mobiles le clavier approprié

Utilisez <input type="email"> pour fournir aux utilisateurs mobiles un clavier approprié et activer la validation intégrée de base des adresses e-mail par le navigateur... pas besoin de JavaScript !

Si vous devez utiliser un numéro de téléphone au lieu d'une adresse e-mail, <input type="tel"> permet d'utiliser un clavier téléphonique sur les appareils mobiles. Vous pouvez également utiliser l'attribut inputmode si nécessaire: inputmode="numeric" est l'option idéale pour les codes PIN. Tout ce que vous vouliez savoir sur le mode d'entrée contient plus de détails.

Empêcher le clavier mobile d'obstruer le bouton Connexion

Malheureusement, si vous ne faites pas attention, les claviers mobiles peuvent masquer votre formulaire ou, pire, masquer partiellement le bouton Sign in (Connexion). Les utilisateurs peuvent renoncer avant de réaliser ce qui s’est passé.

Dans la mesure du possible, évitez ce problème en n'affichant que l'adresse e-mail/le numéro de téléphone et le mot de passe, ainsi que le bouton Connexion en haut de la page de connexion. Placez les autres contenus ci-dessous.

Effectuer des tests sur plusieurs appareils

Vous devrez effectuer les tests sur toute une gamme d'appareils pour votre audience cible et procéder aux ajustements nécessaires. BrowserStack permet de tester sans frais des projets Open Source sur toute une gamme d'appareils et de navigateurs.

Envisagez d'utiliser deux pages

Certains sites (y compris Amazon et eBay) évitent le problème en demandant l'adresse e-mail/le numéro de téléphone et le mot de passe sur deux pages. Cette approche simplifie également l'expérience: l'utilisateur n'est chargé qu'une seule chose à la fois.

Dans l'idéal, cette opération doit être implémentée avec un seul élément <form>. Utilisez JavaScript pour n'afficher initialement que l'adresse e-mail, puis masquez-la et affichez la saisie du mot de passe. Si vous devez forcer l'utilisateur à accéder à une nouvelle page entre la saisie de son adresse e-mail et de son mot de passe, le formulaire de la deuxième page doit comporter un élément de saisie masqué avec la valeur de l'adresse e-mail, pour permettre aux gestionnaires de mots de passe de stocker la valeur correcte. La section Password Form Styles that Chromium comprend (Styles de formulaire de mots de passe compris par Chromium) fournit un exemple de code.

Aider les utilisateurs à éviter de saisir à nouveau des données

Vous pouvez aider les navigateurs à stocker correctement les données et à saisir automatiquement les données, afin que les utilisateurs n'aient pas à se souvenir de saisir l'adresse e-mail et le mot de passe. Cela est particulièrement important sur mobile et essentiel pour les saisies d'e-mails, qui génèrent des taux d'abandon élevés.

Cette procédure comporte deux parties:

1. Les attributs autocomplete, name, id et type aident les navigateurs à comprendre le rôle des entrées afin de stocker des données pouvant être utilisées ultérieurement pour la saisie automatique. Pour permettre le stockage des données pour la saisie automatique, les navigateurs modernes ont également besoin que les entrées aient une valeur name ou id stable (qui ne soit pas générée de manière aléatoire à chaque chargement de page ou déploiement sur le site), et qu'elles se trouvent dans un <form> avec un bouton submit.

2. L'attribut autocomplete aide les navigateurs à remplir automatiquement les entrées à l'aide des données stockées.

Pour les adresses e-mail, utilisez autocomplete="username", car username est reconnu par les gestionnaires de mots de passe dans les navigateurs modernes, même si vous devez utiliser type="email" et id="email" et name="email".

Pour saisir des mots de passe, utilisez les valeurs autocomplete et id appropriées afin de permettre aux navigateurs de différencier les nouveaux mots de passe des mots de passe actuels.

Utiliser autocomplete="new-password" et id="new-password" pour créer un nouveau mot de passe

• Utilisez autocomplete="new-password" et id="new-password" pour saisir le mot de passe dans un formulaire d'inscription ou pour le nouveau mot de passe dans un formulaire de modification de mot de passe.

Utiliser autocomplete="current-password" et id="current-password" pour un mot de passe existant

• Utilisez autocomplete="current-password" et id="current-password" pour la saisie du mot de passe dans un formulaire de connexion ou pour la saisie de l'ancien mot de passe de l'utilisateur dans un formulaire de modification de mot de passe. Cela indique au navigateur que vous souhaitez qu'il utilise le mot de passe actuel qu'il a stocké pour le site.

Pour obtenir un formulaire d'inscription:

<input type="password" autocomplete="new-password" id="new-password" …>

Pour se connecter:

<input type="password" autocomplete="current-password" id="current-password" …>

Prendre en charge les gestionnaires de mots de passe

Les différents navigateurs gèrent la saisie automatique des e-mails et la suggestion de mot de passe de manière légèrement différente, mais les effets sont presque les mêmes. Par exemple, dans Safari 11 et versions ultérieures, le gestionnaire de mots de passe s'affiche. L'authentification biométrique (empreinte digitale ou reconnaissance faciale) est utilisée si elle est disponible.

Sur ordinateur, Chrome affiche des suggestions par e-mail, affiche le gestionnaire de mots de passe et saisit automatiquement le mot de passe.

Les systèmes de saisie automatique et de mots de passe du navigateur ne sont pas simples. Les algorithmes permettant de deviner, de stocker et d'afficher les valeurs ne sont pas standardisés et varient d'une plate-forme à l'autre. Par exemple, comme l'a souligné Hidde de Vries : "Le gestionnaire de mots de passe de Firefox complète ses heuristiques avec un système de recettes".

La page Autofill: Ce que les développeurs Web doivent connaître (mais ne le doivent pas) contient beaucoup plus d'informations sur l'utilisation de name et de autocomplete. La spécification HTML répertorie les 59 valeurs possibles.

Activer le navigateur pour suggérer un mot de passe sécurisé

Les navigateurs modernes utilisent des méthodes heuristiques pour décider quand afficher l'interface utilisateur du gestionnaire de mots de passe et suggérer un mot de passe sécurisé.

Voici comment procéder avec Safari sur votre ordinateur de bureau.

(Des suggestions de mots de passe uniques et sécurisés sont disponibles dans Safari depuis la version 12.0.)

Grâce aux générateurs de mots de passe de navigateur intégrés, les utilisateurs et les développeurs n'ont pas besoin de définir un "mot de passe sécurisé". Étant donné que les navigateurs peuvent stocker les mots de passe de manière sécurisée et les saisir automatiquement si nécessaire, les utilisateurs n'ont pas besoin de mémoriser ni de saisir des mots de passe. En encourageant les utilisateurs à tirer parti des générateurs de mots de passe intégrés du navigateur, ils sont également plus susceptibles d'utiliser un mot de passe unique et sécurisé sur votre site, et moins susceptibles d'en réutiliser un qui pourrait être compromis ailleurs.

éviter aux utilisateurs de manquer accidentellement des données ;

Ajoutez l'attribut required aux champs d'adresse e-mail et de mot de passe. Les navigateurs récents affichent automatiquement des invites et se concentrent sur les données manquantes. JavaScript n'est pas nécessaire.

Prenez soin de vous avec les doigts et les pouces

La taille par défaut du navigateur pour à peu près tout ce qui concerne les éléments d'entrée et les boutons est trop petite, en particulier sur mobile. Cela peut sembler évident, mais il s'agit d'un problème courant avec les formulaires de connexion sur de nombreux sites.

Assurez-vous que les entrées et les boutons sont suffisamment grands

La taille et la marge intérieure par défaut des entrées et des boutons sont trop petites sur ordinateur et pire encore sur mobile.

D'après les consignes d'accessibilité Android, la taille cible recommandée pour les objets d'écran tactile est comprise entre 7 et 10 mm. Les directives d'interface Apple recommandent de 48 x 48 pixels, et le W3C suggère au moins 44 x 44 pixels CSS. À partir de là, ajoutez (au moins) environ 15 pixels de marge intérieure aux éléments d'entrée et aux boutons pour les mobiles, et environ 10 pixels sur ordinateur. Essayez avec un véritable appareil mobile et un vrai doigt ou un pouce. Vous devriez pouvoir appuyer confortablement sur chacun de vos boutons et entrées.

Les cibles tactiles ne sont pas dimensionnées de manière appropriée. L'audit Lighthouse peut vous aider à automatiser le processus de détection des éléments d'entrée trop petits.

Un design adapté aux pouces

Recherchez une cible tactile. Vous verrez de nombreuses images d'index. Cependant, dans le monde réel, de nombreuses personnes utilisent leur pouce pour interagir avec leur téléphone. Les pouces sont plus gros que les index, et le contrôle est moins précis. C'est une raison de plus de disposer de zones cibles tactiles de taille adéquate.

Agrandissez le texte

Comme pour la taille et la marge intérieure, la taille de police par défaut du navigateur pour les éléments d'entrée et les boutons est trop petite, en particulier sur mobile.

Les navigateurs utilisés sur différentes plates-formes ont une taille de police différente. Il est donc difficile de spécifier une taille de police particulière qui fonctionne bien partout. Une enquête rapide auprès des sites Web populaires montre des tailles de 13 à 16 pixels sur ordinateur: une taille adaptée à cette taille physique est un bon minimum pour le texte sur mobile.

Cela signifie que vous devez utiliser un plus grand nombre de pixels sur mobile: 16px sur Chrome pour ordinateur est assez lisible, mais même avec de bonnes vues, il est difficile de lire du texte 16px sur Chrome pour Android. Vous pouvez définir différentes tailles de pixels de police en fonction de la taille de la fenêtre d'affichage à l'aide de requêtes média. 20px fonctionne parfaitement sur mobile, mais vous devriez le tester avec des amis ou des collègues souffrant d'une déficience visuelle.

L'audit Document n'utilise pas de tailles de police lisibles L'audit Lighthouse peut vous aider à automatiser le processus de détection d'un texte trop petit.

Laissez suffisamment d'espace entre les entrées

Ajoutez une marge suffisante pour que les entrées fonctionnent correctement avec les zones cibles tactiles. En d'autres termes, visez une marge d'environ la largeur d'un doigt.

Assurez-vous que vos entrées sont clairement visibles

Le style de bordure par défaut des entrées les rend difficiles à voir. Ils sont presque invisibles sur certaines plates-formes comme Chrome pour Android.

En plus d'une marge intérieure, ajoutez une bordure: sur un fond blanc, une bonne règle générale consiste à utiliser #ccc ou un format plus foncé.

Utiliser les fonctionnalités intégrées du navigateur pour signaler les valeurs saisies non valides

Les navigateurs disposent de fonctionnalités intégrées permettant d'effectuer une validation de base de formulaire pour les entrées comportant un attribut type. Les navigateurs vous avertissent lorsque vous envoyez un formulaire avec une valeur non valide et se concentrent sur l'entrée problématique.

Vous pouvez utiliser le sélecteur CSS :invalid pour mettre en surbrillance les données non valides. Utilisez :not(:placeholder-shown) pour éviter de sélectionner des entrées sans contenu.

input[type=email]:not(:placeholder-shown):invalid {
  color: red;
  outline-color: red;
}

Essayez différentes méthodes pour mettre en surbrillance des entrées dont les valeurs ne sont pas valides.

Utiliser JavaScript si nécessaire

Activer/Désactiver l'affichage du mot de passe

Vous devez ajouter le bouton Afficher le mot de passe pour permettre aux utilisateurs de vérifier le texte qu'ils ont saisi. La convivialité est moindre lorsque les utilisateurs ne peuvent pas voir le texte qu'ils ont saisi. Il n'existe actuellement aucune méthode intégrée pour le faire, mais il existe des plans de mise en œuvre. Vous devez utiliser JavaScript à la place.

Le code suivant utilise un bouton textuel pour ajouter la fonctionnalité Afficher le mot de passe.

HTML :

<section>
  <label for="password">Password</label>
  <button id="toggle-password" type="button" aria-label="Show password as plain text. Warning: this will display your password on the screen.">Show password</button>
  <input id="password" name="password" type="password" autocomplete="current-password" required>
</section>

Voici le code CSS permettant de donner l'impression que le bouton est en texte brut:

button#toggle-password {
  background: none;
  border: none;
  cursor: pointer;
  /* Media query isn't shown here. */
  font-size: var(--mobile-font-size);
  font-weight: 300;
  padding: 0;
  /* Display at the top right of the container */
  position: absolute;
  top: 0;
  right: 0;
}

Et le code JavaScript permettant d'afficher le mot de passe:

const passwordInput = document.getElementById('password');
const togglePasswordButton = document.getElementById('toggle-password');

togglePasswordButton.addEventListener('click', togglePassword);

function togglePassword() {
  if (passwordInput.type === 'password') {
    passwordInput.type = 'text';
    togglePasswordButton.textContent = 'Hide password';
    togglePasswordButton.setAttribute('aria-label',
      'Hide password.');
  } else {
    passwordInput.type = 'password';
    togglePasswordButton.textContent = 'Show password';
    togglePasswordButton.setAttribute('aria-label',
      'Show password as plain text. ' +
      'Warning: this will display your password on the screen.');
  }
}

Voici le résultat final:

Rendre les entrées de mots de passe accessibles

Utilisez aria-describedby pour décrire les règles de mot de passe en lui donnant l'ID de l'élément qui décrit les contraintes. Les lecteurs d'écran fournissent le texte du libellé, le type de saisie (mot de passe), puis la description.

<input type="password" aria-describedby="password-constraints" …>
<div id="password-constraints">Eight or more characters with a mix of letters, numbers and symbols.</div>

Lorsque vous ajoutez la fonctionnalité Show password (Afficher le mot de passe), veillez à inclure aria-label pour avertir que le mot de passe sera affiché. Sinon, les utilisateurs risquent de révéler par inadvertance des mots de passe.

<button id="toggle-password"
        aria-label="Show password as plain text.
                    Warning: this will display your password on the screen.">
  Show password
</button>

Vous pouvez voir les deux fonctionnalités ARIA en action dans le Glitch suivant:

Vous trouverez d'autres conseils pour rendre les formulaires accessibles sur la page Créer des formulaires accessibles.

Valider en temps réel et avant l'envoi

Les éléments et les attributs du formulaire HTML disposent de fonctionnalités intégrées pour la validation de base, mais vous devez également utiliser JavaScript pour effectuer une validation plus robuste lorsque les utilisateurs saisissent des données et tentent d'envoyer le formulaire.

L'étape 5 de l'atelier de programmation sur les formulaires de connexion utilise l'API Constraint Validation (largement compatible) pour ajouter une validation personnalisée à l'aide de l'interface utilisateur du navigateur intégrée afin de définir le focus et d'afficher des invites.

En savoir plus: Utilisez JavaScript pour des validations en temps réel plus complexes.

Analyses et RUM

"Ce que vous ne pouvez pas mesurer, vous ne pouvez pas améliorer" est particulièrement vrai pour les formulaires d'inscription et de connexion. Vous devez définir des objectifs, mesurer vos performances, améliorer votre site et répéter le processus.

Les tests d'utilisabilité des remises peuvent être utiles pour tester des modifications, mais vous aurez besoin de données réelles pour vraiment comprendre comment vos utilisateurs vivent vos formulaires d'inscription et de connexion:

• Analyse de page: pages d'inscription et de connexion vues, taux de rebond et sorties.
• Analyse des interactions: entonnoirs de conversion vers l'objectif (où les utilisateurs abandonnent-ils votre flux de connexion ou de connexion ?) et événements (quelles actions les utilisateurs effectuent-ils lorsqu'ils interagissent avec vos formulaires ?)
• Performances du site Web: métriques axées sur les utilisateurs (si vos formulaires d'inscription et de connexion prennent du temps pour une raison quelconque et, le cas échéant, quelle en est la cause ?).

Vous pouvez également envisager d'implémenter des tests A/B afin de tester différentes approches d'inscription et de connexion, et des déploiements par étapes pour valider les modifications sur un sous-ensemble d'utilisateurs avant de les déployer auprès de tous les utilisateurs.

Consignes générales

Une interface utilisateur et une expérience utilisateur bien conçues peuvent réduire le nombre d'abandons de formulaires de connexion:

• N'obligez pas les utilisateurs à rechercher des informations de connexion. Placez un lien vers le formulaire de connexion en haut de la page, en utilisant une formulation bien comprise, telle que Se connecter, Créer un compte ou S'inscrire.
• Restez concentré ! Les formulaires d'inscription ne servent pas à distraire les utilisateurs avec des offres et d'autres fonctionnalités du site.
• Simplifiez l'inscription. Ne collectez d'autres données utilisateur (telles que les adresses ou les informations de carte de crédit) que lorsque les utilisateurs voient un avantage clair à fournir ces données.
• Avant que les utilisateurs ne remplissent votre formulaire d'inscription, expliquez clairement quelle est votre proposition de valeur. Quel est l'intérêt de se connecter ? Donnez aux utilisateurs des incitations concrètes pour les inciter à s'inscrire.
• Si possible, permettez aux utilisateurs de s'identifier à l'aide d'un numéro de téléphone mobile au lieu d'une adresse e-mail, car certains n'utilisent pas nécessairement l'adresse e-mail.
• Faites en sorte que les utilisateurs puissent facilement réinitialiser leur mot de passe en faisant en sorte que le lien Mot de passe oublié ? soit bien visible.
• Lien vers vos conditions d'utilisation et vos règles de confidentialité: expliquez clairement aux utilisateurs comment vous protégez leurs données dès le départ.
• Incluez le logo et le nom de votre entreprise ou organisation sur vos pages d'inscription et de connexion, et assurez-vous que la langue, les polices et les styles correspondent au reste de votre site. Certains formulaires n'ont pas l'impression d'appartenir au même site qu'un autre contenu, en particulier s'ils ont une URL très différente.

Poursuivre votre apprentissage

• Créer des formulaires incroyables
• Bonnes pratiques en matière de conception de formulaires mobiles
• Des fonctionnalités de contrôle des formulaires améliorées
• Créer des formulaires accessibles
• Simplifier le flux de connexion à l'aide de l'API Credential Management
• Valider des numéros de téléphone sur le Web avec l'API WebOTP

Photo de Meghan Schiereck sur Unsplash.