Boutons désactivés —

Imaginez un monde dans lequel chaque bouton est désactivé par défaut . Habituellement, il est gris, subtil et légèrement flou, souvent avec un faible contraste et une étiquette de texte discrète qui est un peu difficile à déchiffrer. Il n'est cependant pas destiné à rester désactivé pour toujours. Il devient actif éventuellement une fois qu'une entrée bien formée est fournie. Mais avant de pouvoir donner vie à la page avec son extravagance de dégradé de couleurs, il reste là calmement et silencieusement, s'occupant de ses propres affaires. Aimeriez-vous vivre dans ce monde?

Certes, il peut y avoir de très bonnes raisons de désactiver les boutons par défaut. Après tout, en tant que concepteurs et développeurs, nous voulons rendre les erreurs de nos utilisateurs plus difficiles. Nous voulons éviter les allers-retours inutiles entre les messages d'erreur. Nous voulons nous assurer que l'entrée est parfaitement correcte avant que les données ne soient même envoyées au serveur. Et nous voulons indiquer que quelque chose d'important manque avant que les utilisateurs passent à l'étape suivante. fait.

Nous investissons donc du temps et des efforts dans une validation en ligne résiliente et fiable. Et nous faisons de notre mieux pour fournir des commentaires utiles lorsque les utilisateurs passent d'un champ de saisie à un autre. Et, bien sûr, nous désactivons les boutons par défaut pour éviter les clics et les tapotements prématurés qui ne conduiront qu'à la valse avec des messages d'erreur.

Cette approche peut très bien fonctionner pour certains scénarios, mais elle s'avère être un modèle de conception désastreux pour de nombreux scénarios, souvent au point que les clients sont complètement verrouillés, sans une seule chance de transmettre leur intention à l'interface. Dans cet article, nous examinerons les problèmes d'utilisation courants avec les boutons désactivés, comment résoudre ces problèmes et quand la désactivation des boutons est réellement logique. Nous allons commencer par le début, en examinant quand les boutons désactivés causent plus de problèmes que d'aide. quelque chose ne va pas. Cette observation apparemment évidente pourrait ne pas être évidente au premier coup d'œil cependant. Par exemple, que faire si vous souhaitez décocher une case mais que l'interface ne vous le permet pas ? Quel est le problème exactement? Y a-t-il un problème avec votre connexion Internet ? Y a-t-il des problèmes avec les privilèges des utilisateurs ? Faut-il attendre et espérer le meilleur, ou plutôt rafraîchir la page ? Et si vous actualisez la page, toutes les données que vous avez saisies avec tant de soin et de prudence persisteront-elles dans le formulaire, ou disparaîtront-elles pour toujours ?

Lorsque nous rencontrons un bouton désactivéla situation est pas très différent. Nous sommes bloqués, mais nous ne savons pas pourquoi. Il se peut qu'il manque quelque chose d'autre dont nous avons besoin pour aller de l'avant. Ou nous avons négligé quelques petits caractères quelque part. Ou peut-être avons-nous fait une faute de frappe dans l'un des champs de saisie. Ou nous n'avons pas rempli les données de la bonne manière. Ou peut-être qu'il n'y a aucune erreur de notre part, et c'est un bogue système qui est absolument hors de notre contrôle. laissé dans les bois pour trouver quelle est la pièce manquante du puzzle. Dans ces situations, ils présentent généralement deux types de comportements légèrement différentset ces comportements dépendent de ce qui est exactement inaccessible dans l'interface utilisateur.

Lorsque de grandes parties de l'interface sont désactivées

Observation des clients interagir avec l'état désactivé révèle quelques modèles d'utilisation courants. Lorsque de grandes parties de l'interface sont désactivéesla plupart des clients supposeront que le système est occupé et qu'un processus se déroule en arrière-plan sur la page. Et parce qu'il se passe quelque chose, ils font généralement preuve d'une bonne dose de patience en premier. Ils resteront assis là à attendre qu'un spinner apparaisse ou que la page revienne éventuellement. Plus l'entrée est précieuse, plus ils resteront assis là et attendront.

Vous vous comporterez probablement de la même manière. Pourquoi donc? En fin de compte, nous le faisons uniquement pour éviter toute perturbation ou interruption du processus en cours. Tout comme nous ne savons pas si le chat de Schoredinger est vivant ou non sans regarder dans la boîte, nous ne savons tout simplement pas si la réservation a eu lieu ou non jusqu'à ce que nous examinions le système ou que nous parlions avec quelqu'un qui le fait.

Si quelque chose d'inattendu se produit pendant le processus de réservation, ou si nous appuyons accidentellement sur un mauvais bouton au mauvais moment, nous ne savons pas ce qui s'est réellement passé. Nous serons peut-être plus rassurés une fois que nous aurons reçu un e-mail de confirmation, mais même dans ce cas, nous ne le saurons pas avec certitude à moins que nous ne puissions nous connecter au système et vérifier notre réservation. Et si l'e-mail n'arrive pas, nous ne serons pas beaucoup plus intelligents non plus.

Si nous voulons savoir ce qui s'est passé, nous devons nous lancer dans un long voyage plein de sauts d'un service client à un autre. , et parfois passer des heures dans des widgets de chat à essayer d'être rassurés que la carte ne sera pas débitée deux fois, ou que nous avons effectivement annulé un abonnement.

Interrompre un processus en cours semble risqué et imprévisiblenous préférons donc simplement nous asseoir et attendre devant une interface désactivée – le seuil de patience est suffisamment élevé pour que nous ne nous jetions pas dans tous ces tracas et ennuis pour le découvrir tout de suite.

Cependant, même ce seuil est finalement atteint, et les utilisateurs commenceront prudemment à déplacer le pointeur de leur souris sur l'écran, ou tenteront de commencer à tabuler sur leur clavier, ou essayeront de faire défiler vers le haut et vers le bas sur leurs appareils mobiles. Si cela ne fonctionne pas, ils passeront à l'étape suivante, en essayant de redonner vie à la page avec quelques dizaines de clics de rage tenaces ou de tapotements.

Et si cela ne fonctionne pas. fonctionneront non plus, certains prendront une capture d'écran de l'interface comme preuve ou comme référence, et essaieront peut-être d'ouvrir la même page dans un autre onglet du navigateur. Les utilisateurs avertis iraient jusqu'à ouvrir la page dans un autre navigateur, car certains systèmes déconnectent les utilisateurs essayant de se connecter au même compte à partir de plusieurs onglets. en indiquant que les articles sont en cours de chargement. Exemple : Wise.com.

La raison de tous ces problèmes est que nous, en tant qu'utilisateurs, ne voulons pas perdre l'état et les données de la page désactivée. Nous avons peut-être saisi toutes les bonnes données, choisi tous les bons paramètres, et peut-être même pris la peine de trouver un code de réduction fonctionnel, et même créé un message cadeau parfait. Donc, à tout le moins, nous devrions essayer de capturer tout le travail que nous avons déjà fait et remplir à nouveau ces données dans un autre onglet ou une autre fenêtre, plutôt que de refaire tout le travail difficile.

Quand Seul un seul bouton est désactivé

Le comportement ci-dessus peut sembler attendu pour les pages qui bloquent entièrement la saisie de l'utilisateur, mais il devrait sûrement être différent dans les cas où seule une petite partie de l'interface – disons un humble bouton "Continuer" – n'est pas pas accessible ? Ironiquement, les mêmes problèmes apparaissent également avec les boutons autonomes, bien que dans une moindre mesure. problème directement lié à leur entrée. C'est pourquoi il est rare de voir des gens assis et attendre que le bouton "Continuer" revienne à la vie ou change miraculeusement.

Un problème qui apparaît cependant lorsque les utilisateurs rencontrent un bouton désactivé tard dans le processus, en particulier sur mobile. Beaucoup ne réalisent pas si le bouton a été désactivé dès le débutou il y a quelque chose dans leur entrée qui en fait l'a rendu désactivé en cours de route. Certaines personnes rouvriront même la même page dans un autre onglet pour vérifier quel était l'état initial.

Ainsi, une fois que le formulaire sur une page semble être rempli, les utilisateurs se dirigent immédiatement vers le bouton « Continuer » presque en mode pilote automatique. Si ce bouton est désactivé, la toute première chose que l'on peut presque ressentir en regardant les mouvements des utilisateurs est un ralentissement massif de l'interaction. C'est littéralement comme si les utilisateurs heurtaient un mur. Certaines personnes voudront vérifier que le bouton est bien désactivé, en le survolant, en essayant de cliquer/taper dessus, ou de tabuler dessus avec le clavier – souvent en cliquant plusieurs fois pour voir s'il va réellement répondre après tout. Cependant, la plupart du temps, il ne se passera pas grand-chose.

Si le bouton ne répond pas, les utilisateurs recherchent d'abord les suspects habituels – une mauvaise mise en forme, une ponctuation manquante ou des caractères accentués qui ont causé le problème. Si cela n'aide pas, la plupart des utilisateurs parcourront l'intégralité du formulaire souvent champ par champ, de haut en bas et en arrière, et essaieront d'éliminer tous les problèmes potentiels qui pourraient être à l'origine de l'état désactivé.

Par exemple, il est courant de voir des personnes ressaisir le numéro de téléphone, avec et sans +avec et sans zéro non significatif, avec et sans espaces vides. Parfois, ils retapent même toutes les saisies à nouveau champ par champ, car ils supposent que le navigateur a peut-être reçu des données « incorrectes » avec le remplissage automatique du navigateur qui a été utilisé pour certains champs de saisie.

En fait, ils essaient toutes les combinaisons possibles de formatage de rue, de références de numéros de commande, de dates et d'heures, de noms de famille et de salutations et tout le reste — ce qui à bien des égards n'est rien de plus qu'une conjecture car nous ne savons jamais comment fonctionne l'application et quels changements d'entrée affecteront son comportement.

Voilà un bel exemple d'expérience vraiment frustrante. Et bien sûr, nous supposons généralement que tous ces tracas sont facilement évitables avec une validation en ligne à la pointe de la technologie qui détectera les erreurs tôt. Il s'avère que ce n'est souvent pas si simple.

La validation en ligne n'est jamais à l'épreuve des balles

En théorie, tout ce que nous avons couvert dans les sections précédentes ne devrait jamais arriver. Après tout, n'est-ce pas ce que la validation en ligne est censée corriger en premier lieu ? Plutôt que d'afficher des messages d'erreur une fois toutes les saisies effectuées, nous les montrons un par un au fur et à mesure que les utilisateurs font leurs erreurs, généralement après avoir quitté le champ de saisie. Mais combien de fois cela a-t-il échoué sur vous ?

Est-il déjà arrivé que votre adresse de livraison n'ait pas été acceptée par un validateur d'adresses — peut-être parce que le bâtiment vient d'être construit récemment ? Ou peut-être avez-vous utilisé une syntaxe parfaitement valide mais légèrement alambiquée pour éviter le spam, par ex. k.giraudel+smashing@bmx.de, pourtant le validateur d'e-mail a supposé que le caractère + ne peut pas faire partie de l'e-mail ?

Et si vous ne le faites pas ? Vous n'avez pas encore d'e-mail professionnel, mais le service n'accepte pas d'adresse Gmail ? Ou peut-être y a-t-il des données que vous ne vouliez pas fournir, par ex. l'âge, le sexe, l'anniversaire ou un numéro de téléphone – et bien qu'ils soient mis en évidence comme facultatifs, l'interface ne laisse pas passer une valeur vide ?

Bien qu'il existe de nombreux scénarios où la validation en ligne fonctionne bien, il existe tout autant d'exceptions et cas extrêmes lorsque la validation en ligne ne fonctionne pas du tout :

• quand une adresse postale ne peut pas être confirmée par un validateur d'adresse légèrement obsolète ou des autosuggestions,
• quand un numéro fiscal non conforme (TIN/TVA) ne valide pas bien qu'il soit parfaitement valide mais n'est pas encore standardisé entre les pays,
• quand une sorte de protection anti-spam est utilisée dans le formulaire, mais elle est bloquée par un bloqueur de publicités agressif,
• lorsque l'utilisateur bloque le suivi mais que l'entrée de l'emplacement veut désespérément détecter l'emplacement et les pauses de l'utilisateur,
• lorsque des extensions de navigateur tiers remplissent des données (par exemple des codes de coupon) , mais sont finalement bloqués par le système, sans aucun moyen de con tinue,
• lorsque l'utilisateur enregistre sa saisie sous une forme complexe un jour, revient finalement, mais le bouton "Continuer" est désactivé car les documents soumis sont en cours de traitement.
• quand une saisie est basée sur un groupe particulier de clients fréquents, et une entrée parfaitement valide ne correspond pas aux exigences qui leur sont adaptées,
• quand un e-mail a des préfixes ou des caractères parfaitement valides, mais la validation en ligne n'est pas tout à fait précise et ne reconnaît pas certains caractères.[19659049]En pratique, même la validation en ligne la plus sophistiquée sera parfois défaillante. Et quand ça échoue, ça échoue énormément. Un utilisateur bloqué par un validateur en ligne n'a absolument aucune chance de soumettre le formulaire avec succès car le bouton de soumission sera toujours inaccessible. Cette situation garantit un taux d'abandon de 100 % pour ces clients.

  Bien sûr, il peut n'y avoir qu'une poignée de personnes ayant cette expérience, ou quelques milliers un jour donné. Le suivi du nombre de personnes qui se retrouvent dans cette situation est un bon début pour comprendre à quel point les boutons désactivés sont graves pour votre entreprise.

  Ce n'est pas seulement le coût, cependant. De par sa nature, la validation en ligne est une limite stricte avec des exigences très spécifiques et strictes. Pourtant, très souvent, les utilisateurs se retrouvent dans des situations complexes qui ne peuvent être prédites à l'avance. Peut-être la plupart des détails sont-ils connus, et les échéances se profilent, mais certains documents sont manquants, et donc la totalité de la saisie doit être abandonnée.

  Cela se traduit généralement par un ]augmentation du nombre d'appels et de demandes d'assistance à la clientèleou simplement des clients mécontents qui annulent leur compte et ne regardent jamais en arrière.

  À bien des égards, gérer les boutons désactivés peut donner l'impression de lancer un dé. Les utilisateurs peuvent avoir de la chance et des champs de saisie erronés seront mis en évidence, ou ils pourraient être moins chanceux et l'interface ne fournira aucun indice significatif. Ils devront ensuite trouver et résoudre ces problèmes, passer par la validation, puis enfin déverrouiller le bouton tout-puissant pour continuer. C'est frustrant sur le bureau, mais devient encore plus frustrant sur mobile lorsque le bouton n'est souvent pas visible car il est hors écran en bas de la page.

  Comme le note Matthew Standage « quand nous un bouton sur un formulaire, nous désactivons souvent l'appel à l'action – cette chose sur la page sur laquelle nous essayons d'encourager les utilisateurs à cliquer pour continuer leur voyage. ] entreprise, car nous ne savons jamais avec une certitude absolue à quel point notre code est à l'épreuve des balles, même s'il peut être fortement testé.

  Les inconvénients des boutons désactivés

  Les exemples ci-dessus indiquent un problème très courant qui réside dans la nature même de de nombreuses implémentations. Les boutons désactivés n'expliquent pas ce qui ne va pas . Ils communiquent que quelque chose ne va pas, mais très souvent, ce n'est tout simplement pas assez bon. En conséquence, trop souvent, les utilisateurs se demandent ce qui manque réellement et, par conséquent, sont complètement bloqués.

  Sans parler des nombreux cauchemars d'accessibilité qui se présentent. Comme le note Adam Silver dans son excellent livre "Form Design Patterns", les boutons généralement désactivés ne sont pas focalisables et les utilisateurs ne peuvent donc pas les atteindre avec un clavier. La raison pour laquelle nous ignorons généralement la mise au point sur ces boutons est qu'ils ne peuvent pas vraiment être utilisés avec eux. (Nous verrons ci-dessous qu'il y a place à l'amélioration, comme nous le ferons cependant).

  De par leur nature, les boutons désactivés souffrent également d'un contraste insuffisant car ils devraient avoir un aspect différent des boutons normaux. En tant que tels, ils sont également difficiles à lire car ils sont généralement grisés. Ils s'appuient sur JavaScript et la validation en ligne, et sur le fait que les utilisateurs peuvent repérer et corriger facilement les erreurs, ce qui peut être difficile à faire sous une forme complexe sur un écran étroit, par exemple.

  

  Et puis il y a une question de timing. À quel moment devons-nous activer un bouton désactivé ? La plupart des implémentations n'activent le bouton que si toutes les entrées requises semblent être bien formées, ou/et ont été vérifiées par un validateur en ligne. C'est certainement le dernier moment pour basculer le commutateur, mais qu'en est-il des situations où cela pourrait se produire plus tôt ?

  Et si un client ouvre son compte bancaire et qu'il doit vérifier son lieu de résidence fiscale , avec quelques autres documents ? Ou peut-être que se passe-t-il si certaines entrées ne peuvent pas être vérifiées immédiatement, mais doivent être transmises via un autre service, alors que ce service n'arrête pas de expirer ? Ou peut-être que certains fournisseurs n'ont pas encore soumis leurs devis définitifs, mais que le projet doit être ajouté au système de toute urgence ?

  Dans tous ces scénarios, les utilisateurs n'ont pas tous les documents requis à main au moment où ils remplissent le formulaire. Imaginez maintenant que tous ces services offrent une fenêtre de 14 jours après l'ouverture du compte lorsque les documents manquants pourraient être soumis. Techniquement, les clients devraient toujours pouvoir continuer sans ces documents, mais pour cela, ils devraient choisir « Envoyer plus tard » pour chaque document manquant pendant qu'ils remplissent le formulaire.

  

  Alors, quand devons-nous activer le bouton désactivé ? Devrions-nous changer l'état uniquement lorsque l'utilisateur a demandé de soumettre les documents plus tard pour chacun d'eux, ou devrions-nous les laisser passer même s'ils ne se sont pas inscrits (et leur rappeler que nous devons les télécharger dans les 14 jours) ? La plupart d'entre nous conviendront que la première option est probablement plus évidente, mais seulement si l'utilisateur peut repérer l'option de soumettre des documents plus tard. La deuxième option va probablement augmenter la conversion et apporter plus de prospects cependant. dans les grandes entreprises et les formulaires B2B – plus nous devons être prudents lorsque nous actionnons ce commutateur.

  Tout cela pour ne pas dire que les boutons désactivés doivent toujours être évités à tout prix. Ils fonctionnent bien lorsqu'ils servent un objectif très petit et très spécifique. L'interface vous indique qu'il reste exactement un article, si plein d'espoir que vous vous précipitez sur la page du produit, choisissez rapidement votre taille, ajoutez l'article au panier – juste pour vous rendre compte que l'article n'est plus disponible. Ce n'est pas l'expérience utilisateur la plus édifiante. Ici, désactiver le bouton "Ajouter au panier" lorsqu'une option n'est pas disponible n'est raisonnable que pour éviter toute confusion et frustration.

  Ou peut-être êtes-vous sur le point de transférer des fonds importants d'un compte bancaire à un autre. Vous avez revérifié tous les champs de saisie, le montant, le destinataire, l'IBAN et SWIFT, et passé en revue tous les frais, et vous êtes prêt à continuer. Heureusement, un bouton vert brillant vous attend pour continuer. Et juste à ce moment, plein de concentration et d'excitation, votre souris glisse ou votre doigt saute sur l'écran tactile – et vous appuyez deux fois sur ce bouton vert brillant.

  

  Que va-t-il se passer ? Vous ne voulez probablement pas envoyer les fonds deux fois. Et vous n'appréciez pas particulièrement les allers-retours entre votre application d'authentification à 2 facteurs et l'interface bancaire – cependant, le système vous a envoyé deux codes de confirmation, et il n'est pas évident lequel vous devez utiliser pour confirmer le paiement .

  Donc, avoir un bouton désactivé une fois que vous l'avez appuyé une fois est un bon indicateur que l'état a changé et que quelque chose se passe, et que rien d'autre ne doit être fait pour que l'opération se poursuive , et que vous devez simplement vous asseoir et attendre que l'interface revienne. C'est là que les boutons désactivés sont utiles.

  

  Lorsqu'une option ou une fonctionnalité n'est pas disponible ou que quelque chose se passe en arrière-plan, nous devons le communiquer tôt et clairement. Un changement visible du bouton y aide, mais nous pouvons également expliquer pourquoi le bouton est désactivé, et ce qui se passe exactement. Par exemple, nous pourrions modifier l'étiquette du bouton pour dire « Ajout au panier… » avec un indicateur de chargement en boucle pour rendre plus évident ce qui se passe exactement.

  Communiquer que quelque chose n'est pas possible est aussi important que d'empêcher les utilisateurs de commettre des erreurs coûteuses. Voici quelques scénarios où cela peut s'avérer utile :

  • pour éviter les mauvais achats : si le prix dépend de certains attributs, il est raisonnable de désactiver le bouton et d'ajuster son étiquette pendant que le prix est ajusté ,
  • pour éviter les doubles réservations : une fois qu'un bouton est cliqué, il est raisonnable de désactiver le bouton et de remplacer un CTA par une flèche de progression ou de changer le libellé en « En attente… ». Un indice pourrait fournir plus d'aide et un aperçu de ce qui se passe. Nous pourrions alors changer à nouveau l'étiquette si cela prend trop de temps pour obtenir une réponse du serveur. Bien sûr, nous voulons également arrêter d'écouter le clic/tapotement après le premier clic/tapotement (les exceptions sont les boutons Annuler et les steppers où vous vous attendez à ce que les clients appuient sur le même bouton plusieurs fois — là avoir un bouton désactivé n'est probablement pas une très bonne idée).
  • pour valider la connexion magique/le code SMS ou pour valider un nombre de caractères : est complet peut être raisonnable. Cependant, c'est une bonne idée de tester si un bouton "Valider" actif fonctionnerait moins bien. Il y a de fortes chances que ce ne soit pas le cas.

  La désactivation des boutons peut être une bonne idée dans certains scénarios après tout. Mais on peut sans doute faire mieux qu'un bouton grisé avec un contraste insuffisant. Jetons un coup d'œil à quelques techniques pour rendre les boutons désactivés légèrement plus inclusifs. loin d'eux ? Dans son excellent article sur Rendre les boutons désactivés plus inclusifsSandrina Pereira met en évidence quelques excellentes techniques (et extraits de code) pour améliorer les boutons désactivés si vous devez les utiliser.

  En voici quelques-unes. stratégies utiles suggérées par Sandrina :

  • modifiez le curseur sur un bouton désactivé pour indiquer que les utilisateurs ne peuvent pas interagir avec lui (cursor : not-allowed),
  • afficher une info-bulle ou un indice expliquant pourquoi le bouton est désactivé ; si un client utilise une souris/touche, nous pouvons afficher une info-bulle en survolant, en cliquant ou en appuyant, et lorsqu'un utilisateur accède au bouton via la touche "Tab", nous pouvons également déclencher l'info-bulle (cependant, le bouton doit être focalisable),
  • empêcher le clic par programmation via JavaScript en utilisant l'attribut aria-disabledet ainsi éviter la perte temporaire du focus clavier pendant la soumission du formulaire (ce qui être le cas avec l'attribut disabled seul),
  • aria-disabled focalisera toujours le bouton et annoncera qu'il existe, mais qu'il n'est pas encore activé ; de la même manière que vous pourriez le percevoir visuellement,
  • utiliser les régions en direct ARIA pour annoncer le contenu dynamique,
  • éviter pointer-events : none dans CSS ; il empêche en effet un clic de souris, mais il n'empêchera pas le focus et la navigation au clavier.

  Sandrina fournit également un extrait de code complet sur CodePen que vous pouvez également intégrer dans vos projets. Dans l'ensemble, un ensemble fantastique de techniques et de petites aides qui ont été testées avec des lecteurs d'écran et VoiceOver, ainsi que des améliorations générales de convivialité telles que l'annonce de la façon de rendre le bouton accessible lorsque le bouton désactivé est mis au point.

  

  Alternativement à l'info-bulle ou à l'astuce, nous pourrions guider l'utilisateur vers les erreurs dans le formulaire, soit avec un lien vers le résumé des erreurs en haut de la page, soit avec des liens vers des champs de saisie qui semblent contenir des erreurs. Et nous pourrions simplement inclure un indice à côté du bouton désactivé pour expliquer pourquoi il est désactivé (comme indiqué ci-dessous).

  

  

  Avec toutes ces petites aides en place, nous pouvons expliquer beaucoup mieux ce qui ne va pas et comment y remédier. Mais si nous voulons réduire les taux d'impasses et d'abandons de manière plus agressive, nous pouvons aller un peu plus loin.

  Toujours fournir une issue

  Comme la réalité est complexe, il est parfois incroyablement difficile pour une interface de prévoyez toutes les options que les clients pourraient vouloir choisir à l'avance. Souvent, le contexte de l'utilisateur est tout simplement imprévisible et est influencé par des choses qui sont hors de notre portée. Ainsi, dans le cas d'une entrée mal formée ou d'une erreur, nous devrions donner à nos clients le bénéfice du doute et fournir une solution pour remplir le formulaire, même s'il ne répond pas entièrement à nos exigences ou attentes.

  Une technique utile que nous avons découverte lors des tests utilisateurs consiste non seulement à ajouter un indice à côté d'un bouton désactivé qui explique ce qui ne va pas, mais également à ajouter un lien de sortie sous celui-ci. Le lien invite les clients à contacter le service client au cas où ils ne pourraient pas continuer.

  

  Le bouton dit littéralement : « Vous ne pouvez pas continuer ? Faites-le nous savoir et nous vous répondrons. En cliquant sur le lien, les utilisateurs peuvent laisser leur e-mail ou leur numéro de téléphone et choisir d'être contacté par le service client. Ou nous pouvons aller encore plus loin en envoyant automatiquement un e-mail au support client avec tous les détails saisis dans le formulaire au nom du client, avec la possibilité de rappeler ou de répondre par e-mail.

  

  

  Une autre option consiste à permettre aux clients de continuer malgré les erreurs,par ex. même si l'adresse postale ne semble pas être la bonne, ou un numéro de téléphone semble être éteint. Bien sûr, nous devons les informer que quelque chose ne va pas, leur demander d'examiner et de vérifier leur entrée, et demander la permission de les contacter au cas où des problèmes se présenteraient. Nous pourrions cependant vouloir faire référence aux erreurs une fois de plus avant qu'elles n'appuient sur le bouton "Acheter maintenant". case they can't proceed, and get their business by resolving technical difficulties for them, rather than offloading these issues on them.

  Do We Need Inline Validation?

  With these enhancement in place, it might be a good idea to revisit the role of inline validation. There are so many questions that need a discussion — when should we start validating, when do we trigger a validator if a user is editing a valid or invalid field, when do we show error messages or confirmation that the input is correct. All these questions deserve a separate article, but in general, keeping inline validation while providing a way out is reasonable, yet it doesn’t need to go hand in hand with disabled buttons.

  In fact, inline validation is likely to be more helpful without a disabled button as users might get a better overview of the correct and incorrect input by having erroneous input fields highlight on submit. That, of course, requires buttons to be accessible at all times. In fact, it’s not such a bad idea at all.

  An Alternative To Disabled Buttons

  To avoid all the hassle customers have to endure with disabled buttons, we could make the experience much more straightforward by keeping the “Continue” button accessible at all times, and using the click to communicate to the user what’s actually wrong.

  Below is a good overall strategy that always proves to be working without any usability issues:

  • validate the input on submit,
  • on submit, explain that there are errors and show how many errors there are (as a tooltip or an error message),
  • if there is only 1 error, point users directly to the input fields that contains the error (with a simple text link),
  • if there are more errors, show an error summary on the top of the page and show a link to the error summary on submit.

  

  Simple, straightforward, accessible, easy to implement, and without any reliance on code to be working flawlessly to bring a disabled button back to life.

  If, however, user’s selection needs to done, perhaps we could get away by relying on frequently used default values instead of asking the user to make a selection explicitly. For example, Blue Apron provides a default selection for its number of recipes delivered per week, and so the “Select” button is active because it always indicates the next step.

  

  And sometimes disabled buttons could be replaced with something slightly more actionable. In the case when an item is no longer available, for example, we could include the number of available items in the size selector. If an option is unavailable, we could show that the option isn’t available rather than hiding it altogether.

  

  Alternatively, we could add a hint above the button explaining that the item is out of stock, or even allow users to get notified once it’s back in stock again. Below is an example of this pattern on Zalando.

  

  Whenever dealing with disabled buttons, we might want to ask ourselves if there is any better way to communicate the options that the user has, and think about the ways connect with them despite the errors — with a default selection, tooltips and hints, as well as actionable calls to action (e.g. be notified about updates).

  Wrapping Up

  You can’t know what you can’t measure. If you already have an implementation with a disabled button, study how many people actually end up in locked-out situations and can’t proceed. That will give you a good start to understand how severe disabled buttons are for your business.

  If you need to use disabled buttons, consider ways to make them focusable and useful by also making them more inclusive and providing a way out for customers to send all the details to the customer support. If you don’t need to make the buttons disabled, validate on submit and guide users directly to errors with sensible error messages. Either way, inline validation can be helpful in giving users a sense of progress as they are making their way through the form, but make sure that users can proceed even if inline validation fails.

  That should be enough to avoid frustration and hassle when dealing with disabled buttons, and hopefully will clear a path towards an accessible and simple form that has fewer abandonments and faster completion.

  Disabled Buttons Checklist

  As usual, here’s a checklist with pretty much everything to ask and double check when designing or building an interface with disabled buttons:

  1. Do we need the button to be disabled by default (e.g. item is unavailable)?
  2. If not, can we keep it enabled and validate user input on submit?
  3. If not, can we rely on default values to keep the button enabled by default?
  4. When should the button become disabled (e.g. prevent double bookings)?
  5. Do we want to grey out any part of the interface along with the disabled button?
  6. Do we want to use a skeleton screen animation along with the disabled button?
  7. Do we want to use a loading spinner for the UI to indicate that the system is busy?
  8. Do we want to use a progress indicator on the button to indicate progress?
  9. Should the wording on the button be different when it’s disabled?
  10. Does it have sufficient color contrast in the disabled state?
  11. Do we want to add a note under the button explaining why it is disabled?
  12. Do we keep the disabled button focusable?
  13. What happens when a user hovers or taps on the disabled button?
  14. What happens when a user tries to activate or focus on the disabled button?
  15. Do we change the cursor to not-allowed to indicate that the action isn’t allowed?
  16. Do we want to use a tooltip explaining why the button is disabled?
  17. Do we prevent the click via JavaScript by using aria-disabled?
  18. Do we use ARIA live regions to announce dynamic content?
  19. Do we avoid pointer-events: none as it doesn’t prevent focus/keyboard navigation?
  20. Do we guide users towards errors when they tap/click/tab to the disabled button?
  21. When do we enable a disabled button?
  22. Can we add a link that sends all user’s input to support if they are locked out?
  23. In that case, do we ask users for their consent to be contacted?
  24. Do we use inline validation (positive or negative)?
  25. When and how do we show error messages?
  26. Do we include an option to continue even if inline validation fails?
  27. Do we need to update the state of the button after every user input?
  28. How will the button change while updating its state?
  29. Do we change the label of the button (“Updating…”) while it’s updating?
  30. Do we change the colors of the button while it’s updating?
  31. Do we want to add a loading spinner while the button is updating?
  32. Should we stop listening to click/tap after the first click/tap?
  33. Do we not stop listening to click/tap for Undo buttons and steppers?
  34. Can we make the disabled button sticky on narrow screens?
  35. Do we track how many people can’t proceed and abandon the flow altogether?
  36. If applicable, can we test if a design without disabled buttons performs better?

  Further Resources

  (il)