Title, ce faux ami de l’accessibilité

Le 21 décembre 2013, Romy Duhem-Verdière nous expliquait déjà dans les vingt-quatre jours du web pourquoi il fallait utiliser avec modération l’attribut title - ouvre une nouvelle page.
Près de quinze ans plus tard, le constat reste similaire : l’attribut title continue d’être employé à mauvais escient. À l’occasion des douze ans de publication de cet article, je souhaite revenir sur ce sujet, car en accessibilité il est souvent nécessaire de répéter et de reformuler pour ancrer les bonnes pratiques.

Mais reprenons les choses au début.

L’attribut title, à quoi ça sert ?

Selon la définition de Mozilla Developer Network (MDN), l’attribut universel title contient un texte d’information lié à l’élément auquel il est rattaché1 .

Historiquement, l’attribut title est utilisé pour afficher des infobulles, fournir un nom accessible à un élément, ou les deux.

Afficher une infobulle

Si l’on survole avec une souris un élément avec un attribut title, au bout d’un instant, le contenu de l’attribut title apparaît dans un cadre flottant à proximité de l’élément.

C’est principalement utilisé pour préciser la signification d’une icône ou d’un pictogramme, ou encore pour ajouter des informations complémentaires utiles à la compréhension.

Infobulle générée par un attribut `title` pour expliquer une abréviation (API : Application Programming Interface)
Exemple d’infobulle pour expliquer une abréviation
Infobulle générée par un attribut `title` pour expliquer un pictogramme (Threads - nouvelle fenêtre)
Exemple d’infobulle pour expliquer un lien contenant uniquement un pictogramme

Fournir un nom accessible

L’autre usage courant consiste à fournir un intitulé accessible à un élément interactif (lien, bouton, champ de formulaire, etc.). Cette technique est reconnue comme conforme par le Référentiel général d’amélioration de l’accessibilité (RGAA).
Par exemple, le nom accessible d’un lien est déterminé selon l’ordre suivant :

  • texte associé via aria-labelledby ;
  • sinon, contenu de l’attribut aria-label ;
  • sinon, contenu textuel du lien ;
  • sinon, contenu de l’attribut title.

Source : Intitulé (ou nom accessible) de lien sur le site du RGAA - ouvre une nouvelle page

Exemple d’utilisation de l’attribut title pour donner un nom accessible à un lien contenant uniquement un pictogramme :

<a href="https://exemple.com/espace-personnel" title="Espace Personnel">
    <span aria-hidden="true" class="fa-solid fa-user"></span>
</a>

Exemple d’utilisation de l’attribut title pour donner du contexte supplémentaire à un lien contenant déjà un texte :

<a href="https://exemple.com/mentions-legales" title="Mentions légales - ouvre une nouvelle page">
    Mentions légales
</a>

C’est quoi le problème ?

Limites de l’utilisation de l’attribut title pour afficher une infobulle

L’information est cachée et nécessite de deviner son existence

Si vous utilisez cette technique pour expliciter la signification de votre icône, c’est comme si vous jouez aux devinettes avec vos utilisateurs et vos utilisatrices.

Rien n’indique a priori aux personnes qu’une infobulle est disponible. Elles doivent tester : Tiens, et s’il se passait quelque chose si je survole cette icône avec ma souris ?.

Zone avec six pictogrammes, le cinquième pictogramme est un chat et possède un attribut title « Miaou ! ».

Les textes des attributs title obligent à patienter

Admettons que les personnes qui visitent votre site soient fans d’escape game : elles pourraient tenter l’expérience, mais alors, elles devront attendre… car l’apparition de l’infobulle n’est pas instantanée.

Exemple d’apparition d’une infobulle
Transcription

Présente un extrait de page web. La zone comporte six pictogrammes. Lorsque la souris passe sur le cinquième, qui représente un chat, une infobulle affichant le texte « Miaou ! » apparaît après un court délai.

Sensible au moindre mouvement

Et pour se voir récompensés par l’apparition d’une infobulle, ils devront être adroits : ils vont devoir introduire le curseur de leur souris dans la zone exacte de l’élément qui la porte, et y laisser leur souris sans bouger : l’infobulle n’apparaît que si la souris est parfaitement immobile. Et si vous déplacez votre souris, elle disparaît.

Démonstration du comportement de l’infobulle lorsque le pointeur de la souris reste instable
Transcription

Présente un extrait de page web contenant une phrase où l’abréviation « API » est soulignée en pointillé.

La souris passe dessus mais reste en mouvement, ce qui n’entraîne aucune action. Lorsqu’elle se stabilise suffisamment longtemps, une infobulle affichant « Application Programming Interface » apparaît. Toutefois, le message disparaît dès que la souris bouge légèrement, même si elle reste dans la zone de l’abréviation.

Cela crée une barrière pour les personnes qui ne peuvent pas manipuler la souris avec précision.

L’infobulle n’est pas adaptable

Certaines personnes ont besoin d’agrandir le texte, d’augmenter le contraste, d’utiliser un thème sombre ou des feuilles de style personnalisées. Or, l’infobulle générée par l’attribut title ne respecte ni le zoom, ni le thème, ni les styles appliqués par les personnes concernées.

Démonstration de l’effet du zoom et du changement de thème sur une infobulle
Transcription

Présente un extrait de page web en mode clair, contenant un lien intitulé « Connexion à l’espace professionnel ».

Lorsque la souris se stabilise, une infobulle affichant le même texte apparaît.

L’écran est ensuite zoomé : la taille du texte double, mais celle de l’infobulle reste inchangée et ne s’adapte pas. Le thème de la page passe ensuite en mode sombre ; l’ensemble de l’interface bascule alors en sombre, sauf l’infobulle qui reste claire.

Les textes des infobulles ne sont pas sélectionnables

Le contenu des infobulles générées par l’attribut title ne peut pas être sélectionné ni copié.

Inaccessible au clavier

Cela exclut également les personnes qui naviguent uniquement au clavier. Les infobulles générées par l’attribut title ne sont pas accessibles via le clavier, même sur un lien ou un élément interactif.

Inutilisable sur tablettes et smartphones

Si la navigation se fait sur une tablette ou un smartphone, il est impossible d’afficher les infobulles générées par l’attribut title.
Cela signifie que toute information uniquement présente dans cette infobulle sera totalement inaccessible sur ces terminaux.

Problèmes liés à l’utilisation de l’attribut title pour donner un nom accessible

L’utilisation de l’attribut title pour fournir un nom accessible vise principalement les personnes naviguant avec un lecteur d’écran. Bien que cette technique soit considérée comme valide par le RGAA, elle présente plusieurs limites et problèmes d’accessibilité.

Lecture aléatoire par les lecteurs d’écran selon le contexte et les réglages

Le principal problème est que l’attribut title n’est pas toujours restitué par les lecteurs d’écran2 .

Par exemple, avec NVDA, le texte des attributs title présents sur un lien ou un bouton est vocalisé lorsque l’on navigue entre les éléments interactifs, mais ne l’est pas lors de la lecture linéaire du contenu de la page :

Exemple de restitution en naviguant entre éléments interactifs, puis de manière linéaire, sur un texte contenant un lien et un bouton
Transcription

Un extrait de page web contient le texte : « Par exemple, avec NVDA, le texte des attributs title présents sur un lien ou un bouton est vocalisé lorsque l’on navigue entre les éléments interactifs, mais ne l’est pas lors de la lecture linéaire du contenu de la page. »

Dans ce texte, « lien » est un lien et « bouton » est un bouton. La navigation commence par un déplacement d’un élément interactif à l’autre : le lecteur vocalise le contenu des éléments et leurs title. Ensuite, la navigation se fait de façon linéaire : seul l’intitulé visible est vocalisé.

Texte prononcé par le lecteur d’écran :

« lien, visité, même page, lien – Ce lien possède un attribut title avec du texte

bouton bouton – Ce bouton possède un attribut title avec du texte

Par exemple, avec NVDA, le texte des attributs title présents sur un visité, même page, lien lien ou un bouton bouton est vocalisé lorsque l’on navigue entre les éléments interactifs, mais ne l’est pas lors de la lecture linéaire du contenu de la page. »

Risque de répétitions

Lorsque vous utilisez un attribut title sur un lien qui contient déjà du texte (par exemple pour ajouter du contexte), il existe un risque de doublon.

Selon la configuration des lecteurs d’écran, le contenu du title et le texte du lien peuvent être vocalisés. Ce n’est pas bloquant, mais cela ralentit la lecture, augmente la charge cognitive et allonge le temps de restitution

Exemple de double vocalisation de liens par un lecteur d’écran
Transcription

Un extrait de page web présente un titre intitulé « Informations légales », suivi d’une liste de liens :

  • Charte avis en ligne
  • Données personnelles
  • Informations sur les cookies
  • Conditions générales de réparation du service après-vente en magasins
  • Rappel produits
  • Notifier un contenu illicite / sécurité
  • Accessibilité : non conforme
  • Digital Service Act

Lors de la navigation avec un lecteur d’écran, chaque lien est annoncé deux fois : la seconde occurrence comporte le suffixe « nouvelle fenêtre ». La souris survole ensuite deux liens pour montrer que ces secondes occurrences correspondent au contenu du title associé à ces liens.

Texte annoncé par le lecteur d’écran :

« liste de 9 éléments
Charte avis en ligne, lien
Charte avis en ligne (nouvelle fenêtre)

Données personnelles, lien
Données personnelles (nouvelle fenêtre)

Informations sur les cookies, lien
Informations sur les cookies (nouvelle fenêtre)

Conditions générales de réparation du service après-vente en magasins, lien
Conditions générales de réparation du service après-vente en magasins (nouvelle fenêtre) »

Le pire, c’est lorsque l’attribut title reprend exactement la même information que celle déjà présente dans le lien.

Problèmes de traduction et de prononciation

Certains navigateurs proposent une fonctionnalité de traduction qui ne fonctionne pas sur le contenu des attributs title.

Certains lecteurs d’écran ne respectent pas la langue définie dans la page et lisent le texte du title avec la voix par défaut du système.

Exemple d’une page en anglais contenant des attributs title pour un bouton et un lien, affichée sur un poste configuré en français
Transcription

Extrait d’une page web : cette page est en anglais et contient un bouton ainsi qu’un lien.

La navigation commence par un survol des éléments interactifs pour afficher des infobulles :

  • « Text explaining the button’s role placed in a title attribute » pour le bouton ;
  • « Text explaining the link’s role placed in a title attribute » pour le lien.

Ensuite, le lecteur d’écran lit le texte avec une voix anglaise et un accent impeccable.

Puis, lors de la navigation entre les éléments interactifs, la voix passe en français avec un accent français, ce qui rend la compréhension difficile.

Texte prononcé par le lecteur d’écran :

Voix anglaise : Example of a page in English (the HTML tag includes a lang="en" attribute). The screen reader pronounces the technical elements in the user’s language (French in this example) and reads the text using the language defined by the page (English). If an element contains a title attribute, like this

Voix française : bouton

Voix anglaise : button

Voix française : bouton Text explaining the button’s role placed in a title attribute

Voix anglaise : link

Voix française : visité même page lien Text explaining the button’s role placed in a title attribute. visité même page lien

Voix anglaise : link. it is pronounced with a French accent

Risque d’inaccessibilité avec les logiciels de commande vocale

Une des techniques principales pour activer un lien via un logiciel de commande vocale est de prononcer le texte du lien, par exemple : « cliquer sur François-Xavier Lair ».
Si le contenu de l’attribut title ne reprend pas ce texte, il existe un risque que le lien ne puisse pas être activé par commande vocale, ce qui rend la navigation impossible pour les personnes utilisant ces assistances.

Exemple avec un lien de connexion ayant un title « Espace personnel » et un texte visible « François-Xavier Lair » :

Lien de connexion contenant un pictogramme et le texte François-Xavier Lair
<a href="https://exemple.com/espace-personnel" title="Espace Personnel">
    <span aria-hidden="true" class="fa-solid fa-user"></span>
    François-Xavier Lair
</a>

En résumé, l’attribut title est non seulement totalement inaccessible pour toutes les personnes qui naviguent au clavier, sur tablette ou sur smartphone, mais il présente également des difficultés pour de nombreux usages et profils.

Quelles solutions pour remplacer l’attribut title ?

Après avoir passé en revue l’ensemble des limites et des risques liés à l’attribut title, une question se pose naturellement : par quoi le remplacer ?

Dans cette deuxième partie, nous allons présenter les principales solutions, leurs avantages, ainsi que les points de vigilance à garder en tête pour garantir une accessibilité optimale.

Fournir un texte accessible

aria-label ?

L’attribut aria-label - ouvre une nouvelle page peut remplacer title, mais il présente aussi plusieurs limites :

  • problèmes de traduction : comme pour title, certains navigateurs ne traduisent pas le contenu de l’attribut aria-label.
  • remplacement du texte visible : aria-label substitue le texte affiché, ce qui peut entraîner les mêmes risques que title (nom accessible différent du texte visible).
  • problèmes de maintenance : intégré directement dans le HTML, aria-label peut être oublié lors des mises à jour. De plus, toutes les personnes impliquées dans la production ne maîtrisent pas les mécanismes de génération du nom accessible.

Il est également important de rappeler un principe clé d’ARIA : il est recommandé de privilégier les solutions natives en HTML plutôt que d’ajouter des attributs ARIA lorsqu’ils ne sont pas nécessaires3 .

Pour approfondir le sujet, Eric Bailey l’explique en détail dans son article intitulé aria-label is a code smell - ouvre une nouvelle page.

Utiliser du texte masqué visuellement

C’est la solution la plus fiable. Elle consiste à ajouter un texte caché visuellement, mais correctement restitué par les lecteurs d’écran.
Pour cela, on utilise une classe de masquage accessible — souvent nommée visually-hidden ou sr-only — comme celles proposées par Bootstrap4 ou ffoodd5 .

<a href="https://exemple.com" class="icon-link">
    <span class="visually-hidden">Accéder à la page d’exemple</span>
    <svg aria-hidden="true" focusable="false" width="24" height="24">
        <!-- Icone SVG -->
    </svg>
</a>

Ainsi, le texte est intégré directement au contenu de l’élément HTML qu’il complète, garantissant une sémantique claire et évitant les problèmes liés à l’utilisation de title ou aria-label.

Infobulles

Passons maintenant aux méthodes permettant de remplacer l’utilisation de l’attribut title pour créer des infobulles.

Rendre l’information visible d’emblée

La solution la plus simple et la plus efficace consiste à ne pas utiliser d’infobulles : affichez l’information directement.

Souvent, l’infobulle n’est qu’une tentative de rattrapage d’un pictogramme ambigu.

Si vous pensez devoir préciser le rôle d’un pictogramme ou d’une icône via un attribut title, pourquoi ne pas l’afficher clairement ?

Combien de fois vous êtes-vous demandé : « Quel est le rôle de ce bouton ? » Combien de fois avez-vous cliqué sur un bouton composé uniquement d’un pictogramme, pour constater que l’action n’était pas celle attendue ?

Par exemple, savez-vous à quelles actions correspondent les deux icônes ci-dessous ?

Deux icônes pas forcément explicites pour tout le monde&nbsp;: la première est un symbole de ’dossiers’, l’autre pour ’Sauvegarder’
Réponse

Selon l’article de LogRocket – Which icons to NOT use in 2025 - ouvre une nouvelle page :

  • le premier symbole représente des dossiers ;
  • le second indique l’action de synchroniser les données entre les appareils et le cloud, sauvegarder.

Si vous connaissiez la réponse, pensez-vous que votre mère l’aurait su ? Et votre grand-mère ?

Un pictogramme peut sembler évident… mais pas pour tout le monde. Parfois, c’est culturel6 .

S’il vous plaît, mettez des labels à vos icônes.

Dans le même ordre d’idée, si vous utilisez des infobulles pour fournir un contexte supplémentaire, demandez-vous si cette information ne devrait pas être affichée directement, sans passer par un mécanisme caché.

Popover

Si l’usage d’une infobulle est vraiment nécessaire, autant le faire avec les éléments HTML dédiés.
L’API Popover est un nouveau standard qui permet d’afficher du contenu en superposition par rapport au reste de la page. Ce contenu peut être contrôlé à l’aide d’attributs HTML ou via JavaScript.

Implémentation de base

Placez le texte à afficher dans un élément avec l’attribut popover et un identifiant unique pour pouvoir le cibler :

<div popover id="toggletip">
    A11y est un acronyme numérique pour <span lang="en">Accessibility</span> (accessibilité en anglais)
</div>

Ensuite, utilisez un élément <button> relié à ce premier élément grâce au nouvel attribut popovertarget. Cet attribut doit contenir l’id de l’élément cible :

<button type="button" popovertarget="toggletip">
    A11y
</button>

Le popover s’affiche lorsque vous actionnez le bouton.
La touche Échap est même prise en charge pour fermer le popover.

Tester l’implémentation de base sur CodePen - ouvre une nouvelle page.

Gestion de la sémantique

L’attribut popover n’a pas de rôle intégré. Après tout, ce n’est pas un élément. Son objectif est uniquement d’ajouter un comportement de popover et peut être appliqué sur différents types d’éléments (menu, dialogue, notifications de type toast, etc.).
Il est donc nécessaire de lui attribuer un rôle. Le rôle le plus approprié est tooltip.

Cependant, ce rôle n’est pas encore pris en charge par les lecteurs d’écran. Il est donc nécessaire d’ajouter un attribut aria-describedby pour que le contenu du popover soit correctement restitué.

<button type="button" aria-describedby="toggletip" popovertarget="toggletip">
    A11y
</button>
<div popover role="tooltip" id="toggletip">
    A11y est un acronyme numérique pour <span lang="en">Accessibility</span> (accessibilité en anglais)
</div>

Tester sur CodePen l’exemple de popin avec une structure sémantique de base. - ouvre une nouvelle page.

Gestion de la souris et du clavier

Pour reproduire le comportement attendu d’une infobulle, il est nécessaire d’ajouter un peu de JavaScript afin de gérer son affichage au survol de la souris.

const trigger = document.querySelector(’[popovertarget]’);
const tooltip = document.querySelector(’[popover]’);

// Gestion souris
trigger.addEventListener(’mouseover’, tooltip.showPopover());
trigger.addEventListener(’mouseout’, tooltip.hidePopover());

// Gestion clavier
trigger.addEventListener(’focusin’, tooltip.showPopover());
trigger.addEventListener(’focusout’, tooltip.hidePopover());           

Cela permet également de corriger l’un des problèmes des infobulles générées via l’attribut title : l’absence d’affichage lors de la navigation au clavier.
L’API Popover met à disposition les méthodes showPopover et hidePopover pour cela.

Tester sur CodePen l’exemple de popin avec un JavaScript de base - ouvre une nouvelle page.

Personnalisation des styles et du comportement

Par défaut, le popover s’affiche centré dans la fenêtre.
Pour reproduire le comportement classique des infobulles — affichage à proximité de l’élément déclencheur —, il faut ajouter un peu de CSS.

Ce type de placement a longtemps été complexe à gérer (superpositions, zoom, ajustement selon la taille de la fenêtre), mais le nouveau module CSS Anchor Positioning - ouvre une nouvelle page simplifie désormais grandement cette tâche.

Il permet de positionner un élément par rapport à un autre en définissant une ancre avec la propriété anchor-name et de placer un élément en s’y référant via position-anchor.
La propriété position-area détermine comment l’élément se positionne par rapport à son ancre (au-dessus, en dessous, à gauche, etc.), et il est même possible de définir des positionnements de secours si l’espace initial n’est pas disponible, grâce à la propriété position-try-fallbacks.

[popovertarget] {
  anchor-name: --triger-tooltip;
}
[popover] {
  overflow: visible;
  position-anchor: --triger-tooltip;
  position-area: top;
  position-try-fallbacks: flip-inline, bottom, top;
}

Tester sur CodePen l’exemple de popin avec personnalisation des styles - ouvre une nouvelle page.

Ressource : tutoriel alsacréations Le positionnement par ancre : anchor positioning - ouvre une nouvelle page

Limitation actuelle : CSS Anchor Positioning n’est pas encore largement pris en charge en dehors de Chrome et Safari.
Il est donc nécessaire de prévoir une solution de secours en JavaScript pour gérer le positionnement.
La solution la plus simple consiste à utiliser une bibliothèque comme Floating UI - ouvre une nouvelle page.

Tester sur CodePen un exemple plus complet avec une solution de secours pour les navigateurs ne supportant pas CSS Anchor Positioning - ouvre une nouvelle page.

Support

Le support de l’API Popover est désormais excellent. Elle est largement prise en charge par les principaux navigateurs d’après Can I Use - ouvre une nouvelle page.

Limites de la solution

L’objectif de cet article n’est pas de fournir une implémentation générique et totalement accessible d’infobulles, mais d’alerter sur les risques liés à l’attribut title.
Les extraits de code présentés ne doivent pas être utilisés tels quels en production : ils servent uniquement de base de réflexion.

Un point de vigilance concerne la manière dont l’information est restituée aux lecteurs d’écran. Grâce à l’attribut aria-describedby, la personne qui utilise un lecteur d’écran aura bien accès au contenu de l’infobulle. Cependant, cette information sera annoncée systématiquement, alors que le reste du public peut choisir d’afficher ou non l’infobulle.

Autre limite : le lecteur d’écran restitue cet élément comme un motif plié/déplié, en annonçant « développé » ou « réduit » lorsque le bouton est activé, alors même que le contenu associé n’est pas forcément contigu.

Exceptions

Il reste trois situations où l’attribut title demeure nécessaire.

Donner du contexte pour les étiquettes de formulaires dont le contenu n’est pas visible

Pour les champs de formulaire dont l’étiquette n’est pas visible ou n’est pas placée à proximité, le test 11.1.3 du RGAA - ouvre une nouvelle page recommande d’utiliser un attribut title afin de préciser la nature de la saisie attendue.

Exemple :

<label for="search-input-md" class="visually-hidden">Rechercher dans le site…</label>
<input placeholder="Rechercher dans le site…" title="Rechercher dans le site…" id="search-input-md" type="search" name="texte">
<button title="Rechercher" type="submit"><span class="fr-sr-only">Rechercher</span></button>

Nommer les iframes

L’attribut title reste aujourd’hui la méthode recommandée pour donner un nom à une iframe.
C’est une exigence de conformité du RGAA, le critère 2.1, qui impose que chaque iframe (balise <iframe> ou <frame>) ait un attribut title.

Dans ce cas précis, l’usage de title ne pose pas les mêmes problèmes, car :

  • il sert uniquement de nom accessible pour les technologies d’assistance ;
  • il n’est pas utilisé pour afficher une infobulle ;
  • il ne génère pas d’ambiguïté avec un contenu visible.

Exemple :

<iframe title="Contenu publicitaire tiers" src="https://bb99d6a.safeframe.googlesyndication.com/" id="google_ads_iframe"></iframe>

C’est donc l’un des rares contextes où title reste une bonne pratique et une exigence de conformité.

Nommer les vidéos

Lors de la relecture de cet article par un collègue aveugle, il m’a remonté que lorsque l’on arrivait sur une vidéo, il y avait un bouton lecture mais aucune indication du contenu de la vidéo : cela manquait de contexte.

Pourtant, chaque vidéo disposait d’une légende placée sous le lecteur par l’outil de gestion du site, ce qui répond au critère 4.7 du RGAA. Cette situation illustre parfaitement que la conformité ne garantit pas automatiquement l’accessibilité.

Dans un premier temps, un attribut aria-labelledby a été ajouté pour référencer le titre de la vidéo, mais ce mécanisme est mal pris en charge par les lecteurs d’écran dans ce cas. Ironiquement, la solution a finalement consisté à ajouter un attribut title sur la balise video.

Cet exemple rappelle une règle essentielle : en accessibilité, rien ne remplace les tests avec de vrais usages et de vrais outils.

Conclusion

L’attribut title peut sembler pratique pour afficher des infobulles ou fournir un nom accessible, mais, sauf rares exceptions, il reste un faux ami de l’accessibilité.

  • Il n’est pas fiable pour les lecteurs d’écran.
  • Sa fonctionnalité d’infobulle ne fonctionne ni sur mobile ni sur tablette, et elle n’est pas accessible au clavier.
  • Il pose des difficultés aux personnes naviguant sur votre site, qu’elles soient en situation de handicap ou non.

Privilégiez des solutions inclusives :

  • Affichez l’information directement lorsque c’est possible.
  • Sinon, utilisez des solutions basées sur les standards HTML.

Une infobulle ne doit jamais être indispensable pour comprendre ou utiliser une interface. L’accessibilité repose sur la clarté, la visibilité et la compatibilité avec toutes les technologies d’assistance.

Pour l’année 2026 qui commence bientôt, prenez une bonne résolution : laissez l’attribut title derrière vous et adoptez des alternatives réellement accessibles pour toutes et tous.

Il n’est plus possible de laisser un commentaire sur les articles mais la discussion continue :