L’infobulle à l’ère des WCAG 2.1

28 avril 2020, par Équipe Access42

L’été dernier, nous avions eu un coup de cœur pour l’article Tooltips in the time of WCAG 2.1, écrit par Sarah Higley.

Aujourd’hui, nous avons la joie de partager avec vous sa traduction en français, avec l’aimable permission de l’autrice.

Pas le temps de tout lire ? L’essentiel du billet : adoptez une définition restreinte de l’infobulle, et rendez-vous directement à la section Les bonnes pratiques : on résume.

Depuis que l’infobulle existe, ou en tout cas depuis l’ère des navigateurs web graphiques, elle est à l’origine de bien des tourments sur le plan de l’accessibilité numérique. Aussi appelée « info-ballon », « bulle d’aide », « tooltip », « toggletip » ou encore « infotip » par ses équivalents anglais, on pourrait presque la baptiser « petit encadré de la honte ».

Qu’importe la désignation, les ennuis s’enchaînent, et pas des moindres :

  • Comment les personnes naviguant au clavier peuvent-elles accéder au contenu des infobulles ?
  • Quid des utilisateurs et utilisatrices de pointeurs sans souris qui se servent plutôt d’un écran tactile ou d’un système d’eye tracking par exemple ?
  • Comment les personnes aveugles et malvoyantes peuvent-elles, déjà dans un premier temps, savoir qu’une infobulle existe, et dans un second, la lire ?
  • Si l’infobulle renferme du contenu interactif (au grand dam des grands maîtres de l’Internet), comment y accéder sans faire disparaître l’infobulle involontairement ?
  • Comment une personne utilisant un logiciel d’agrandissement fait-elle pour déplacer son champ visuel de façon à lire l’infobulle tout en évitant de la faire disparaître ?

Mais alors, pourquoi les infobulles posent-elles autant problème ?

La première allusion à une infobulle graphique dans le contexte du web remonte à un brouillon de HTML de 1993 décrivant « title » comme un attribut optionnel pour les liens. Voici le paragraphe en question, initialement rédigé en anglais, mais que l’on peut traduire ainsi :

« Le logiciel de navigation pourra, avant ou pendant l’extraction d’un document, afficher le titre de ce document en annotation de marge ou dans un petit encadré au survol de l’ancre par la souris. »

À l’époque où ces spécifications ont été écrites, les lecteurs d’écran sous environnement graphique existaient déjà depuis plus de quatre ans. Aujourd’hui, soit 26 années plus tard, on note quand même quelques progrès.

Même si l’inaccessibilité causée par le comportement exclusif de l’attribut title vis-à-vis des utilisateurs et utilisatrices de souris persiste, au moins la dernière version de la spécification HTML dénonce de façon explicite les problèmes d’accessibilité et met en garde les développeurs et développeuses quant à l’utilisation de cet attribut.

Précisons aussi que les WCAG, règles pour l’accessibilité des contenus web, ont gagné en autorité. Mais aux prémices du web, il n’y avait absolument aucune incitation à développer des expériences autrement que pour des personnes voyantes qui utilisent une souris.

La balise <img> a été proposée pour la première fois par un représentant du navigateur Mosaic en 1993, qui l’a présentée finalement plus comme un avertissement préalable que comme une suggestion.

Même si en théorie, la spécification img a toujours tenu compte de l’attribut alt, dans la pratique, il a fallu du temps pour qu’elle soit supportée. Pendant des années, les lecteurs d’écran et navigateurs texte n’avaient aucun moyen de restituer un élément graphique.

Si cette référence historique à la balise <img> peut sembler incongrue pour un article sur les infobulles, la pertinence tient de ce qu’il s’est passé par la suite : les navigateurs ont commencé à implémenter l’attribut alt, mais en choisissant un rendu visuel sous forme d’infobulle, à l’instar de l’attribut title pour les liens.

Même si l’attribut alt conservait ainsi une fonction d’alternative textuelle, l’implémentation de l’infobulle a changé les méthodes des éditeurs web en matière de rédaction de texte alternatif. Des articles ont d’ailleurs été publiés sur l’incidence néfaste de l’effet infobulle.

Et si vous voulez rire, jetez un œil à ces exemples bien réels d’alternatives textuelles croisées dans des attributs alt de l’époque. Petit avant-goût : des « Cliquez ici ! » qui apparaissent pour chaque image. [Note d’Access42 : le site d’Alan Flavell est indisponible à l’heure où nous publions cette traduction.]

Bien que l’attribut alt ne subisse plus le « traitement infobulle » dans les navigateurs modernes, il suffit de voyager dans le temps pour y voir un vrai problème de conception. Depuis le tout début, le comportement des infobulles natives n’a fait qu’encourager la création de contenu exclusivement adapté aux personnes voyantes utilisant une souris, laissant les autres sur le banc de touche.

L’infobulle pour texte alternatif a démontré tout de suite à quel point cette conception contribuait à dégrader l’expérience de toutes les personnes qui n’utilisent pas de souris ou qui ont recours aux technologies d’assistance.

Nombreuses sont les publications dénonçant les problèmes qui persistent à cause du manque d’inclusivité des infobulles générées par l’attribut title ; cet article exhaustif de Scott O’Hara pour 24a11y est un bon point de départ pour comprendre le problème.

Au-delà de l’attribut title, qu’en est-il des infobulles aujourd’hui ?

Les professionnel·les de l’accessibilité n’ont de cesse de répéter qu’il faut « utiliser les éléments d’interface natifs ». Ce qui pose la question suivante : si l’infobulle native pose problème déjà sur le plan conceptuel, que peuvent faire les professionnel·les du design et du développement pour s’adapter ? En bref : pas grand-chose.

Avant de s’intéresser en détail aux techniques d’implémentation d’une infobulle sur mesure, prenons le temps de définir ce qu’est réellement une infobulle. L’infobulle est traditionnellement associée à un traitement purement visuel : du texte qui s’affiche dans un petit encadré par-dessus le contenu principal, à la demande de l’utilisateur ou de l’utilisatrice généralement au survol du composant décrit par ce texte.

Cette interprétation pose problème lorsqu’il s’agit de définir une spécification destinée à fournir une expérience cohérente et accessible. Et pour cause : à un motif de conception visuelle ne correspond pas forcément un seul motif d’interaction.

(C’est-à-dire ?)

Considérer le web design uniquement comme un média visuel présente le risque de confondre motifs visuels et motifs fonctionnels ou d’interaction.

Un exemple classique : sur le web, le terme « menu » présent sur une interface utilisateur web revêt une signification tant large et générique que spécifique et technique.

Dans une conversation courante entre professionnel·les du web, « menu » pourrait désigner autant une série de liens qui servent à naviguer dans un site web, qu’une barre d’outils (Fichier, Modifier, etc.) située généralement en haut de l’interface des applications.

Cela pourrait aussi, bien sûr, désigner une liste de mets proposés par un restaurant, que l’on consulte sur un support papier.

Laissant de côté cette troisième éventualité, considérons les deux autres. Les personnes naviguant au clavier ou à l’aide de technologies d’assistance ont des attentes différentes vis-à-vis d’un menu de navigation et d’un menu d’application traditionnel ; le premier étant une liste de liens accessibles par tabulation et le second une série d’actions accessibles au moyen des touches de direction et souvent de raccourcis.

Conclusion : un motif de conception visuelle, plusieurs motifs d’interaction.

Pour aller plus loin, on vous recommande en entrée : inclusive-components.design/menus-menu-buttons, et en plat : github.com/w3c/aria-practices/issues/353.

(Fin de la parenthèse ; retournons à nos infobulles.)

À l’instar de « menu », le terme « infobulle » est venu à désigner quasiment toute petite fenêtre non modale s’affichant au-dessus d’un contenu.

Si l’infobulle sert traditionnellement d’aide à la saisie sur des éléments d’interface utilisateur (d’où, d’ailleurs, la désignation anglaise de l’infobulle : « tooltip » qui signifie littéralement « conseil pour l’outil »), ce même motif de conception visuelle peut être utilisé pour afficher autant l’alternative textuelle d’un bouton-image, un message d’erreur dans un formulaire, du contenu en texte enrichi (texte en gras, liste, etc.), que du contenu interactif.

L’implémentation de base pourrait être la même pour tous ces cas d’utilisation si la présentation visuelle et les interactions à la souris étaient les seules choses qui comptaient.

Or, il est important d’opérer des distinctions pour les raisons suivantes (par ordre d’importance) :

  1. Une aide à la saisie ne sert qu’à clarifier le nom accessible d’un élément d’interface ; elle ne doit pas s’y substituer.
  2. L’alternative textuelle d’un bouton-image constitue son nom accessible et doit donc être correctement associée au bouton.
  3. La technique courante qui consiste à associer du texte à un élément d’interface à l’aide de l’attribut aria-describedby ne permet pas de restituer le formatage riche du texte.
  4. Tout contenu interactif inclus dans l’infobulle implique de satisfaire à un nombre de critères : le contenu doit être facilement identifiable par les personnes utilisant un lecteur d’écran, suivre un ordre de tabulation logique, être facilement accessible sans faire disparaître l’infobulle et ne pas exiger une gestuelle fine.

Il n’existe pas de structure DOM ou d’implémentation en JavaScript capable à elle seule de répondre à toutes ces exigences, ne serait-ce qu’à celles des quelques cas utilisateurs déjà mentionnés.

Pour élaborer la recommandation la plus concrète qui soit, il faut partir du principe que les fenêtres non modales remplies de contenu riche ou interactif ne sont pas des infobulles.

Ces éléments-là gagneraient à intégrer le motif de conception « disclosure ».

De même, une fenêtre non modale de type infobulle qui n’est pas reliée à un élément d’interface interactif en bénéficierait aussi. Cela éviterait de créer un bouton inutile simplement pour introduire une tabulation pour les personnes naviguant au clavier.

Tentons à présent d’établir une spécification pour les infobulles qui soit totalement décorrélée de l’aspect visuel. La suite de cet article, en particulier les recommandations en matière d’accessibilité, partira du principe qu’une infobulle correspond à la définition suivante :

« Une infobulle est une fenêtre non modale (ou non bloquante) qui apparaît par-dessus un contenu et qui apporte des informations complémentaires à propos d’un composant d’interface existant, sous forme de texte. L’infobulle est masquée par défaut et s’affiche au survol ou à la prise de focus sur cet élément. »

On pourrait restreindre davantage cette définition en précisant que les infobulles ne doivent contenir que du texte descriptif, ce qui reviendrait à définir l’infobulle comme une version sur mesure et accessible de l’attribut title.

Cela dit, les mêmes exigences d’interaction s’appliquent, que la fonction de l’infobulle soit d’afficher un nom accessible, une description ou un message d’erreur, et ce même avec de légères variations sémantiques.

Infobulles et exigences d’accessibilité

Les infobulles doivent pouvoir être identifiées et lues aussi bien avec une souris, tout autre dispositif de pointage, avec un clavier, un lecteur d’écran, un logiciel d’agrandissement qu’avec toute autre technologie d’assistance.

Les infobulles se doivent aussi de fournir une information utile à l’apprentissage de l’interface utilisateur, mais qui ne soit pas indispensable à son utilisation.

Enfin, les infobulles ne devraient pas empêcher l’utilisateur ou l’utilisatrice de réaliser une autre tâche à l’écran.

Simple, non ? Regardons tout cela de plus près. Et pour ce faire, considérons trois aspects : la sémantique, l’interaction et le contenu.

Sémantique

Une sémantique pertinente est le fondement même de toute bonne structure HTML.

Elle permet aux lecteurs d’écran et aux autres technologies d’assistance de proposer de nombreux raccourcis pratiques pour naviguer dans une interface. Les titres sont bien des titres, les liens sont bien des liens, les accordéons précisent leur état développé/réduit, et les infobulles sont… quoi, déjà ?

On l’a expliqué tout à l’heure : les infobulles peuvent avoir plusieurs fonctions. Même selon notre définition restrictive, elles peuvent indiquer un nom accessible ou une description ; en fonction de ce rôle, la sémantique sera différente.

Ainsi, la clé est d’identifier au préalable le but du texte de l’infobulle et de ne lui attribuer la sémantique correspondante qu’ensuite.

Quelle sémantique pour une infobulle descriptive ?

En ce qui concerne la fonction la plus orthodoxe de l’infobulle, c’est-à-dire le rôle d’aide à la saisie, les deux seuls ajouts sémantiques consistent à :

  1. associer le déclencheur de l’infobulle à l’infobulle elle-même en utilisant les attributs aria-describedby et id ;
  2. faire en sorte que l’infobulle soit inatteignable dès lors qu’elle est masquée, en utilisant l’attribut aria-hidden.

Voici un extrait de HTML d’un modèle de champ « nom » avec une infobulle qui sert d’aide à la saisie. Le code HTML part du principe que l’infobulle est ouverte :

<label for="name">Votre nom en entier</label>
<input id="name" type="text" aria-describedby="name-hint">
<div id="name-hint" aria-hidden="false">
 Renseignez votre prénom suivi de votre nom de famille.
</div>

Quelle sémantique pour une infobulle-étiquette ?

Il en va presque de même pour la sémantique d’une infobulle utilisée pour indiquer le nom accessible du composant de l’interface : au lieu d’utiliser l’attribut aria-describedby, l’association se fera avec l’attribut aria-labelledby, et le contenant de l’infobulle n’aura pas forcément besoin de l’attribut aria-hidden.

Il est aussi possible de carrément laisser tomber l’attribut aria-labelledby de façon à ce que le texte de l’infobulle devienne enfant de l’élément d’interface (du moins pour les éléments pouvant contenir des nœuds enfants).

Un avertissement toutefois pour ce cas d’utilisation : les éléments d’interface devraient toujours posséder une étiquette visible, sous quelque forme que ce soit.

Cette technique ne remplace donc pas la nécessité de positionner une étiquette visible, par exemple à côté de l’élément.

Une bonne pratique dans ce contexte consisterait à prévoir une alternative textuelle pour les boutons-images.

Sémantique : ce qu’il faut éviter

Si vous avez déjà l’habitude d’utiliser ARIA, alors vous aurez sûrement remarqué que certains attributs ne figurent pas dans la description ci-dessus.

Les attributs suivants sont en effet liés à l’accessibilité et peuvent sembler pertinents. Pourtant, ils ne sont, pour l’heure, pas recommandés (dans aucun ordre spécial) :

  • role="tooltip" : les attributs role, enfants mal-aimés. Vous vous dites peut-être que c’est un peu paradoxal pour un billet sur les « tooltips » d’inclure cet attribut dans la liste des choses à éviter, non ? S’il n’est pas catastrophique de l’ajouter à l’infobulle, il n’apporte rien de positif non plus. Il semblerait que le rôle tooltip n’ait aucun effet pertinent sur les annonces faites par les lecteurs d’écran ; ce sont plutôt aria-describedby et aria-labelledby qui font tout le travail. Si vous décidez de l’ajouter quand même, utilisez-le uniquement pour les infobulles descriptives, avec l’attribut aria-describedby. Pour plus de contexte, rendez-vous sur ce fil GitHub : github.com/w3c/aria/issues/979.
  • aria-haspopup : les infobulles ont beau ressembler à des fenêtres non modales, l’attribut aria-haspopup est destiné aux fenêtres non modales plus interactives. Plus précisément, seuls les menus (menu), listes déroulantes (listbox), listes arborescentes (tree), grilles (grid) et fenêtres de dialogue (dialog) peuvent être utilisés avec aria-haspopup. L’utilisation d’une valeur par défaut pour aria-haspopup="true" sera interprétée comme aria-haspopup="menu". Étant donné que le but d’une infobulle n’est ni d’interagir avec elle ni de naviguer jusqu’à elle, aria-haspopup ne doit pas être utilisé pour indiquer une infobulle.
  • aria-live : solution de repli ultime pour notifier un changement dynamique de contenu dans la page à l’utilisateur ou à l’utilisatrice, il peut être tentant d’utiliser l’attribut aria-live comme solution pour que les lecteurs d’écran restituent le texte des infobulles. Toutefois, les « zones live » présentent des inconvénients considérables lorsqu’elles sont utilisées pour les infobulles. En effet, dans cette hypothèse, les personnes utilisant un lecteur d’écran ne seraient pas toujours en mesure de consulter à nouveau le contenu de l’infobulle. De plus, les zones live peuvent interrompre la restitution d’autres contenus, comme l’intitulé d’un élément d’interface recevant le focus. Enfin, les utilisateurs et utilisatrices de lecteurs d’écran n’ont aucun moyen de désactiver la restitution du contenu des zones live. Certes, s’il est vrai que aria-describedby pourra être restitué ou non, en fonction de facteurs tels que la configuration des paramètres de verbosité par l’utilisateur ou l’utilisatrice, c’est néanmoins le comportement souhaité pour les aides à la saisie.

Interaction

La méthode d’interaction pour afficher, masquer et lire le contenu de l’infobulle est la même, quelle que soit la fonction de l’infobulle : étiquette ou description de l’élément d’interface.

Focus et survol

La première étape consiste à s’assurer que l’affichage de l’élément d’interface puisse être contrôlé autant au clavier qu’à la souris.

Pour ce faire, l’infobulle doit s’ouvrir à la prise de focus ou au survol de la souris, et se fermer à la perte du focus (blur) ou lorsque la souris s’en va (mouseout).

Combiner des événements de clavier et des événements de pointeur ne devrait pas créer plusieurs infobulles ni engendrer d’autres comportements dysfonctionnels.

Étant donné que l’élément d’interface associé à l’infobulle génère vraisemblablement une action par défaut, activable par clic/Entrée ou Espace/saisie, on ne pourra pas utiliser ces mêmes interactions pour afficher ou masquer l’infobulle.

Si l’élément d’interface ne génère aucune action et n’admet pas de saisie, alors est-ce qu’une infobulle est vraiment utile ? On se tournera plutôt vers le motif de conception «  disclosure ».

L’accès (ou manque d’accès !) au moyen du pointeur

Avec l’explosion de la navigation mobile, l’accès tactile est aujourd’hui primordial. Cette évolution bénéficie notamment aux personnes qui utilisent des dispositifs de pointage sans souris tels que les systèmes d’eye tracking.

Mais hélas, l’un des principaux désavantages de l’infobulle associée à un bouton ou à un lien est que l’on ne peut pas y accéder à partir d’appareils tactiles.

Et pour cause : le survol n’existe pas sur les périphériques tactiles et il n’est pas possible de placer le focus sur un bouton ou sur un lien sans l’activer.

Il en va de même pour d’autres technologies d’assistance contrôlées par un système de pointage, dont les dispositifs de contrôle oculaire.

Pour l’instant, il n’existe aucune solution de contournement, même si les infobulles sur les champs de saisie de formulaires continuent de fonctionner comme prévu.

Les exigences WCAG 2.1 : une infobulle persistante, que l’on peut masquer et survoler

La version 2.1 des Règles pour l’accessibilité des contenus web (WCAG) prévoit de nouveaux critères applicables en ce qui concerne le contenu au survol et au focus. On les retrouve dans le critère de succès 1.4.13 : Content on Hover or Focus.

Si cette nouvelle règle multiplie les efforts à fournir pour proposer une infobulle conforme, elle a le mérite d’encourager la conception de fenêtres modales ou non modales plus accessibles et moins perturbatrices.

Les WCAG 2.1 exigent que tout contenu apparaissant au survol ou au focus puisse être « masqué » (dismissible) et « survolé » (hoverable), et qu’il soit « persistant » (persistent).

Pour y arriver, une infobulle doit :

  • être masquée dès lors qu’une personne naviguant au clavier appuie sur la touche Echap (sauf s’il n’y a aucun risque que l’infobulle se superpose à un autre contenu) ;
  • permettre à une personne utilisant un dispositif de pointage (souris ou autre) de masquer l’infobulle, idéalement à l’aide d’un bouton Fermer (sauf s’il n’y a aucun risque que l’infobulle se superpose à un autre contenu). L’infobulle ne doit alors pas réapparaître au prochain survol. Mettez-vous dans la peau d’une personne utilisant le zoom qui essaie de centrer son champ visuel sur une zone précise sans déclencher l’infobulle et ainsi cacher un autre contenu* ;
  • permettre à une personne utilisant une souris de déplacer le curseur sur le contenu de l’infobulle sans qu’elle disparaisse, et dans l’idéal, sans exiger une concentration intense ou une maîtrise excessivement précise de la souris ;
  • rester visible jusqu’à ce que l’utilisateur ou l’utilisatrice la fasse disparaître volontairement ou jusqu’à ce qu’elle ne soit plus valide (ce qui pourrait être le cas par exemple d’une infobulle indiquant un processus de chargement : l’infobulle pourra disparaître une fois le contenu chargé).

Une remarque supplémentaire pour les plus fervents lecteurs et lectrices des WCAG : la condition « sauf s’il n’y a aucun risque que l’infobulle se superpose à un autre contenu » (without moving pointer hover or keyboard focus) n’est finalement pas tant une exception qu’elle n’en a l’air.

En effet, même si une infobulle ne semble pas se superposer à un autre contenu dans une certaine résolution d’écran, il est possible que ce soit le cas dans une autre résolution d’écran ou à un autre niveau de zoom.

(*) Une remarque peut-être un peu tatillonne à ce propos : le critère de succès 1.4.13 des WCAG 2.1 précise que l’on doit pouvoir faire disparaître une infobulle sans qu’il ne soit nécessaire de déplacer le pointeur au survol ou le focus clavier. Et le critère précise que la touche Echap peut être amenée à remplir ce rôle.

Mais cette option convient seulement aux personnes naviguant au clavier, pas aux utilisateurs et utilisatrices de souris.

En matière d’utilisabilité, les personnes qui s’appuient principalement sur un dispositif de pointage (souris ou autre) sont moins susceptibles de connaître les raccourcis clavier, voire peuvent ne pas du tout savoir s’en servir.

D’un point de vue technique, il est impossible de détecter l’activation de la touche Echap sur un élément d’interface qui est bien survolé mais qui n’a pas le focus. En détectant l’utilisation de la touche Echap, on serait incapable de distinguer une personne souhaitant faire disparaître une infobulle d’une personne souhaitant fermer une fenêtre de dialogue (dans le cas où l’une et l’autre seraient présentes).

En résumé, la seule solution envisageable est de proposer une méthode qui permette à la fois aux claviers et aux pointeurs de faire disparaître l’infobulle.

Contenu

Une infobulle devrait contenir uniquement des informations non essentielles. La meilleure façon de rédiger ce type de contenu est de se dire qu’il ne sera probablement jamais lu.

On l’a mentionné tout à l’heure : les périphériques tactiles et les pointeurs autres que la souris ne peuvent pas atteindre les infobulles associées à des boutons ou à des liens.

Quant aux lecteurs d’écran, le fonctionnement par défaut consiste parfois à ignorer certains textes de nature descriptive. On doit pouvoir déduire comment utiliser l’interface utilisateur sans devoir lire une seule infobulle.

Si ce n’est pas le cas, il est recommandé de retirer le contenu essentiel des infobulles pour le positionner là où il sera plus accessible et plus identifiable.

En plus de remplir vos infobulles exclusivement de contenu non essentiel, tenez également compte des recommandations suivantes :

  • Assurez-vous que le texte de l’infobulle reste concis. Mettez-vous à la place d’une personne qui utilise un écran de petite taille ou un fort niveau de zoom et qui a besoin de parcourir l’écran pour lire le contenu de l’infobulle.
  • Évitez le contenu riche. Les éléments de mise en forme comme la graisse, l’italique, les titres, les icônes, etc. ne seront pas restitués avec aria-describedby ou aria-labelledby.
  • N’utilisez pas de contenu interactif. Tout contenu interactif, tel que les liens ou les boutons, n’a pas sa place dans une infobulle.

Les bonnes pratiques : on résume

  • Une infobulle ne doit être déclenchée que par des éléments d’interface interactifs.
  • Une infobulle doit décrire directement l’élément d’interface qui la déclenche (ne créez pas de contrôle dans le but simplement de déclencher une infobulle).
  • Utilisez aria-describedby ou aria-labelledby pour associer l’élément d’interface à l’infobulle. Évitez aria-haspopup et aria-live.
  • N’utilisez pas l’attribut title pour créer une infobulle.
  • Ne mettez aucune information essentielle dans une infobulle.
  • Proposez une solution pour masquer une infobulle à la fois avec un clavier et avec un pointeur.
  • Assurez vous que la souris puisse survoler l’infobulle sans la faire disparaître.
  • N’implémentez pas de compte à rebours pour masquer l’infobulle.

Si la lecture de ce billet vous a donné une envie irrépressible d’en savoir plus sur l’énigme de l’infobulle, vous pouvez approfondir votre maîtrise du sujet en parcourant les liens présentés ci-dessous.

Enfin, n’hésitez pas à commenter ce fil W3C dédié à l’infobulle : posez vos questions et partagez vos idées sur ce que l’on devrait attendre du futur comportement par défaut des infobulles.

Traduction : Eleanor Hac.