Cet article est une traduction dont l'original est Tooltip should not exist par Dominik Dorfmeister TkDodo

Pourquoi les composants Tooltip peuvent nuire à l'expérience utilisateur

J'ai une confession à faire : les mauvais tooltips dans les applications web sont l'une de mes bêtes noires. Et pour être juste, il est assez facile de se tromper avec les tooltips. De nombreuses préoccupations doivent être prises en compte :

  • Accessibilité
  • Interactivité au clavier
  • Moins de surprises pour tous les utilisateurs
  • Ne pas cacher d'informations critiques derrière eux

Au fil des ans, j'ai vu de nombreux systèmes de design essayer d'implémenter un composant `<Tooltip>` pour les utilisateurs, et à mon avis, la chose qui les caractérise tous est qu'ils ne seront pas utilisés comme prévu. D'un point de vue de conception d'API, cela signifie probablement que le composant `<Tooltip>` est une abstraction trop basse, ce qui me conduit à ma déclaration du jour 🌶 : les composants Tooltip ne devraient pas exister.

Je ne dis pas que les tooltips eux-mêmes ne devraient pas exister. Ils sont un outil précieux lorsqu'ils sont appliqués "correctement" - quelle que soit la signification de cela pour vos cas d'utilisation. Certes, vous pourriez y parvenir avec de l'éducation, mais soyons honnêtes : très peu de gens lisent la documentation et l'IA ne fait que reproduire ce qu'elle voit déjà, donc il y a de fortes chances qu'elle amplifie les anti-modèles que nous avons dans notre code.

Les problèmes potentiels des tooltips mal utilisés

Interactivité au clavier

Cela devrait être évident : nous devons construire des applications web pour tout le monde, ce qui signifie que nous devons être conscients que tous les utilisateurs n'utiliseront pas une souris. Néanmoins, j'ai souvent rencontré des implémentations qui n'affichent les tooltips que sur hover dans des situations où l'élément qui déclenche le tooltip n'est pas interactif.

Prenons l'exemple de Material UI, l'une des bibliothèques de composants les plus populaires. Leur exemple de tooltip de base dans la documentation ressemble à ceci :

<Tooltip title="Supprimer">
  <IconButton>
    <DeleteIcon />
  </IconButton>
</Tooltip>

C'est simple et cela fonctionne, mais que se passe-t-il si nous ajoutons seulement un `<Tooltip>` autour d'une icône, ou autour d'un autre élément non interactif comme un Badge :

<Tooltip title="Accueil">
  <IconHome />
</Tooltip>

<Tooltip title="Mails non lus">
  <Badge badgeContent={4} color="primary">
    <IconMail color="action" />
  </Badge>
</Tooltip>

C'est exact - le tooltip s'affichera toujours au survol, mais pas au focus car le tabbing le sautera. L'élément n'est pas interactif au clavier, donc il ne reçoit jamais le focus, ce qui signifie que le tooltip n'apparaît jamais lors de la navigation uniquement au clavier.

Moins de surprises pour tous les utilisateurs

Si un `<Tooltip>` peut être ajouté à n'importe quel élément, quelqu'un essaiera. J'ai vu des tooltips dans les endroits les plus étranges, comme sur un certain texte au milieu d'une phrase - sans aucune indication qu'il y a des informations supplémentaires derrière cela.

Mais j'ai également vu l'inverse. C'est extrêmement ennuyeux de voir un bouton qui consiste uniquement en une icône que je ne comprends pas, mais je ne reçois aucune information sur ce qui va se passer lorsque je clique sur ce bouton.

Vous êtes à peu près garanti d'avoir ces incohérences dans votre application dès que vous avez une masse critique de développeurs et de designers travaillant dessus.

Alternatives à un composant Tooltip autonome

Alors, si un composant `<Tooltip>` n'est pas idéal, quelles autres approches un système de design peut-il utiliser pour exposer le comportement du tooltip ? Voici mon avis :

  • Fournir uniquement des composants de patterns de niveau supérieur qui imposent une utilisation cohérente et accessible des tooltips.

Quelques éléments qui ont bien fonctionné dans le passé sont :

  • Les composants interactifs comme `<Button>` ou `<Link>` obtiennent une prop `title` optionnelle. Cela nous permet de montrer des informations supplémentaires si nous le souhaitons. Les éléments interactifs sont généralement facilement découvrables dans l'interface, et ils seront également trouvés avec le tabbing au clavier.
  • `<IconButton>` obtient une prop `title` requise. Cela garantit que les icônes sont expliquées aux utilisateurs et nous donne en plus un moyen de bien étiqueter le bouton pour l'accessibilité.
  • Exposer un composant `<InfoIcon>` pour rendre une icône d'information ou un point d'interrogation + un tooltip. Cela garantit que les utilisateurs savent où trouver des informations supplémentaires, et nous pouvons garantir que c'est focalisable.
  • Créer un `<InfoText>` pour donner plus de contexte au texte. Ce composant devrait être visuellement distinct des autres textes, par exemple avec un soulignement en pointillé, et bien sûr aussi interactif au clavier.

Je suis sûr qu'il y a d'autres choses que je pourrais manquer, mais si c'est le cas, ajouter un autre composant de pattern est mieux que de donner à tout le monde accès au bas niveau `<Tooltip>`. Ne vous méprenez pas, la flexibilité est excellente pour de nombreux cas, comme par exemple la mise en page, mais fournir une expérience utilisateur cohérente et inclusive est bien plus important pour les tooltips, c'est pourquoi être restrictif est préférable.

La restriction engendre également la créativité, donc si nous ne pouvons pas simplement cacher des informations derrière un tooltip juste parce que nous n'avons pas assez d'espace sur notre écran, cela nous aide peut-être à repenser certaines idées de fond en comble.

Alors, si vous construisez un système de design pour votre organisation, essayez de résister à l'envie d'ajouter un composant `<Tooltip>` à votre interface publique.

C'est tout pour aujourd'hui. N'hésitez pas à me contacter si vous avez des questions, ou laissez simplement un commentaire ci-dessous. ⬇️