L’attribut title : à consommer avec modération
Recommandation du référenceur, vieille habitude d’intégration des dinocodeurs, insertion automatique du CMS trop bienveillant, poudre de perlimpinpin du dev padawan… l’attribut title est largement utilisé sur nos pages web. Mais rarement à bon escient.
Mais kezako ?
À ne pas confondre avec la balise <title>, l’attribut HTML title s’utilise sur certains éléments, typiquement sur les liens et les abréviations, pour fournir une information complémentaire, relative à cet élément. Voici un exemple de balisage d’une abréviation :
<abbr title="HyperText Markup Language" lang="en">HTML</abbr>L’attribut title est ici porté par l’élément abbr et a pour valeur « HyperText Markup Language ». Mais comment cela est-il rendu dans nos navigateurs ?
Une expérience utilisateur limitée
Il était autrefois utilisé par les référenceurs pour y cacher des mots-clefs à l’intention des moteurs de recherche. Si l’on sait depuis longtemps que cela n’apporte rien en terme de référencement (blog AxeNet, 2008), on lit encore dans certains forums que l’attribut title aide à « avoir un site plus accessible et ergonomique ». C’est une idée fausse.
En réalité, bien que cet attribut soit supporté depuis plus de dix ans, quasiment aucun navigateur ne permet de le consulter sans souris. Il est habituellement rendu, dans les navigateurs graphiques des postes de bureaux, sous la forme d’une infobulle, qui apparaît lors du survol par la souris. Mais il reste inaccessible aux utilisateurs qui naviguent par exemple au clavier. Parmi les autres utilisateurs, ceux ayant des déficiences cognitives ou motrices peuvent avoir des difficultés à prendre connaissance d’une infobulle. Ce n’est donc pas aussi idéal que ce que l’on souhaiterait.
On le pense magique pour l’accessibilité, mais en réalité l’attribut title n’est pas restitué de façon uniforme par les lecteurs d’écran. En particulier, ceux-ci ne transcrivent pas le contenu des liens de la même manière : si certains favorisent l’attribut title, d’autres choisissent de lire le contenu le plus long, tantôt l’intitulé, tantôt le titre du lien, et aucune action n’est possible de la part du développeur ou du rédacteur pour privilégier l’un ou l’autre. Par exemple, la synthèse vocale Jaws ne lit pas, par défaut, l’attribut title, ce qui ne permet pas à l’utilisateur non-voyant de comprendre un lien non explicite si Jaws n’a pas été paramètré. Cela reste donc très compliqué pour les utilisateurs de lecteur d’écran.
Enfin, l’essor de la consultation web en situation de mobilité remet fortement en question l’usage de cet attribut. Il n’est en effet pas interprété sur les terminaux tactiles. Son contenu reste donc inaccessible aux utilisateurs de tablettes et smartphones, qui constituent aujourd’hui la majorité des internautes et sont en constante augmentation.
Contrairement à ce que l’on aimerait croire, l’attribut title n’améliore pas franchement l’expérience utilisateur. En fin de compte, au lieu d’apporter une information complémentaire, cet attribut la cache à de nombreux internautes, comme le rappelle Steve Faulkner. Mieux vaut donc apprendre à l’éviter, pour ne plus faire des cachoteries aux internautes. C’est en raison de ce mauvais support par les navigateurs que la spécification HTML5.1 n’encourage pas son usage.
À consommer avec modération !
La bonne pratique est donc de ne pas utiliser l’attribut title. Plus précisément, si une information est importante, ce n’est pas dans l’attribut title qu’il faut la placer, mais bien dans la page, sinon elle échappera à la plupart.
Expliciter les liens
C’est le cas des liens : si l’information portée dans l’attribut title est une chose que l’utilisateur doit savoir avant de cliquer le lien, comme le téléchargement d’un fichier ou l’ouverture d’une nouvelle fenêtre, alors cette mention devrait figurer dans l’intitulé plutôt que dans l’attribut. Par exemple :
<a href="…" title=”Télécharger (PDF - 42 Ko)”>Notre catalogue de jouets</a>devrait être remplacé par :
<a href="…">Télécharger notre catalogue de jouets (PDF - 42 Ko)</a>Poids et format de fichier doivent être mentionnés textuellement, dans l’intitulé du lien. Imaginons que ce catalogue soit en anglais et que sa consultation force l’ouverture d’une nouvelle fenêtre : l’internaute doit être prévenu de ce comportement. Si cette solution vous semble trop verbeuse :
<a href="…" target="_blank">Consulter notre catalogue de jouets (PDF - 42 Ko - en anglais - nouvelle fenêtre)</a>utilisez l’attribut title, en y répétant l’intitulé du lien, complété des informations à cacher — en gardant à l’esprit que de nombreux internautes ne pourront alors les voir :
<a href="…" target="_blank" title=”Consulter notre catalogue de jouets (PDF - 42 Ko - en anglais - nouvelle fenêtre) ”>Consulter notre catalogue de jouets (PDF - 42 Ko)</a>Notez que cette autre solution, sans attribut title, conviendra au plus grand nombre :
<a href="…" target="_blank">Consulter notre catalogue de jouets [en] (PDF - 42 Ko) <img src="external.gif" alt="Nouvelle fenêtre"></a>Contrairement à ce qu’on pourrait penser, l’attribut title n’est pas davantage utile sur les liens images, où l’alternative textuelle portée par l’attribut alt, obligatoire, vaut pour libellé. Point trop n’en faut ! Voici qui suffit :
<a href="…"><img src="print.gif" alt="Imprimer cette page"></a>Les liens images (pictos, etc.) constituent une exception. Dans le cas où l’attribut title est présent, il doit être strictement identique au contenu de l’attribut alt, afin de garantir un rendu homogène par les synthèses vocales (cf. : Image alternative tests, by Karl Groves) :
<a href="…"><img src="print.gif" alt="Imprimer cette page" title="Imprimer cette page"></a>Autant charger un script de cette répétition à l’identique, et en profiter pour étendre la portabilité de l’infobulle, via JavaScript, aux terminaux tactiles.
Attention à ne pas en abuser !
L’usage excessif d’attributs title, par exemple sur les abréviations, peut constituer une gêne : dans le cas où l’attribut est lu par la synthèse vocale, l’explicitation à chaque occurrence est trop verbeuse. C’est gênant aussi sur terminaux tactiles, comme en témoignent ces échanges sur l’utilisabilité des <abbr>.
Pour les sigles et abréviations, la règle a toujours été d’expliciter le terme au fil du texte, à la première occurrence. On préférera écrire « Ouvroir de Littérature Potentielle (OuLiPo) » plutôt que <abbr title=« Ouvroir de Littérature Potentielle »>OuLiPo</abbr>. Tout simplement ! Autrement dit, l’exemple de balisage donné au début de cet article est inutile. Faites simple, limitez les usages de abbr ! comme le recommande cet article. Le seul cas où la balise <abbr> semble indispensable est l’entête de tableau dont l’étroitesse impose des titres abrégés.
Pour résumer, on n’utilisera l’attribut title qu’en dernier recours, dans les cas extrêmes, où certains intitulés ne peuvent pas être explicités autrement, souvent par manque de place. Pour l’implémenter correctement, voir aussi la notice AcceDe Web.
Dites-le dans le texte !
On aimerait qu’il rende mieux service, mais l’attribut title souffre d’un trop mauvais support. La bonne pratique est donc de ne pas l’utiliser, ou alors avec prudence, en gardant bien à l’esprit que l’utilisation de l’attribut title pour expliciter un intitulé sera toujours moins accessible que la mention textuelle directe dans la page. Quand une information est importante, on la donne en toutes lettres dans le texte.
6 commentaires sur cet article
JPV, le samedi 21 décembre 2013 à 11:03
Article très intéressant en ce qu’il résume un débat de fond important.
En préalable petite correction : title ne s’utilise pas sur « certains éléments », c’est un attribut universel qui peut s’utiliser sur tous les éléments. Lorsque l’élément est un élément interactif il participe du calcul de « l’accessible name » et est remonté par les Apis en cas de défaillance des attributs ou propriété natives (comme un alt pour une image) et en cas d’absence d’une surcharge ARIA qui remplace toute autre valeur (comme un aria-label par exemple)
Oui le title pose des problèmes de restitution dans les lecteurs d’écrans mais en revanche tous les lecteurs d’écrans peuvent le restituer. Oui le title pose des problèmes de restitution au clavier mais, en revanche, tous les navigateurs devraient le restituer sur les éléments interactifs au moins.
Enfin, oui le title pose des problèmes de restitution sur les périphérique tactiles mais, en revanche, la solution est connue et parfaitement utilisable si les éditeurs de technologies le souhaitent.
WCAG en conclus qu’on ne devrais pas l’utiliser mais, dans le même temps, en fait une technique acceptable pour produire des liens explicites hors contexte en AAA. Terrible paradoxe.
Le seul problème de title est que l’immense confusion sur son rôle et son comportement a tué son appropriation par le développement : personne ne sait quoi en faire au juste.
Et la question de fond est la suivante : devons-nous, oui ou non, prendre en charge au niveau du développement le manque d’implémentation par les fournisseurs de technologie qui, en l’espèce, ne font simplement pas le travail qu’ils sont censés faire ?
En faisant une différence très claire entre la prise en charge de dispositif en cours d’implémentation comme HTML5/ARIA et la prise en charge d’un élément de langage pour lequel nous connaissons parfaitement ce qu’il faudrait faire.
L’histoire nous offre un formidable cas similaire : celui du longdesc, nous avons décidé de prendre en charge le manque de restitution pour les keyboard user de longdesc en imposant l’usage d’un lien adjacent « de préférence » au longdesc via un « D Link » ou un lien adjacent explicite.
Nous avons donc, sciemment, tué nous-même londesc en supprimant la pression utilisateur au niveau des éditeurs des navigateurs.
A force de dire qu’il ne faut pas utiliser title nous sommes en train de tuer la baguette magique de l’accessibilité pour la remplacer, immense paradoxe, par des dispositifs de surcharge accessibles uniquement pour les lecteurs d’écran ou, pire, par des exigences irréalistes (lien explicite hors contexte sans title) par rapport à l’état de l’art.
Je conçois que c’est un problème très délicat, très compliqué mais n’oublions jamais de dire que ce n’est pas à nous de faire ce boulot mais aux éditeurs de navigateurs qui eux, alors qu’ils en auraient les moyens et la vocation, ne le font pas.
Sinon l’article est très bien fait notamment sur ce point capital : un bon title doit reprendre l’intitulé du lien.…
JPV
Anonyme, le samedi 21 décembre 2013 à 14:00
IL est tout de même à noter que title peut avantageusement remplacer un label dans certains cas spécifiques, par exemple dans les formulaires agencés en tableaux.
Exemple rapide d’un cas où les labels peuvent être problématiques et où title arrange bien :
[code=html]
NuméroNomPrénom
1
2
…
[/code]
D’ailleurs vous verrez que si par hasard vous essayer de caser des labels dans l’exemple ci-dessus, qu’ils soient effectivement visibles ou non, dans des cellules différentes des champs ou non, vous constaterez que jaws aurait tendance à ne pas disposer les choses correctement dans sa vue virtuelle ou alors dans un ordre plus ou moins illogique (essayez en lisant ligne par ligne avec haut/bas, ou avec les raccourcis propres à la navigation dans les tableaux Ctrl+Alt+Flèches ; effets surprenants garantis).
Par ailleurs, une petite remarque rien à voir :
[quote]
Imaginons que ce catalogue soit en anglais et que sa consultation
force l’ouverture d’une nouvelle fenêtre : l’internaute doit être prévenu de ce comportement.
[/quote]
Non, le mieux c’est de ne jamais forcer l’ouverture d’une nouvelle fenêtre. Jamais au grand jamais. Ca a toujours été antiaccessible et mauvais comme pratique, c’est frustrant pour celui qui ne souhaite pas ouvrir de nouvelle fenêtre. Ce n’est pas au développeur du site web de choisir, mais à l’utilisateur. Bref je m’égare, c’est un autre sujet.
Anonyme, le samedi 21 décembre 2013 à 14:07
Zut, mon code a été complètement saccagé par un processus visiblement aléatoire.
Voici le code que je voulais donner en exemple ci-dessus, en espérant qu’il passe cette fois.
<table>
<thead>
<tr><th>Numéro</th><th>Nom</th><th>Prénom</th></tr>
</thead><tbody>
<tr>
<th>1</th>
<td><input type=« text » title=« Nom de la personne n°1 » /></td>
<td><input type=« text » title=« Prénom de la personne n°1 » /></td>
</tr><tr>
<th>2</th>
<td><input type=« text » title=« Nom de la personne n°2 » /></td>
<td><input type=« text » title=« Prénom de la personne n°2 » /></td>
</tr>
…
</tbody></table>
Marie, le lundi 23 décembre 2013 à 14:12
Merci pour ton article, Romy ! C’est typiquement le genre d’attribut avec lequel on a tendance à faire du zèle, pensant bien faire, alors qu’en fait, on ne fait pas bien du tout…
Cas typique : souvent, quand un intégrateur intègre une maquette qui contient des abréviations non explicites, il enrichit spontanément ce texte avec des abréviations HTML et leurs attributs title respectifs, tout convaincu qu’il est de pallier ainsi un certain manque d’accessibilité de l’information.
Maintenant que l’on sait que ce n’est pas un si bon réflexe que ça, reste la question de l’accessibilité des textes contribués. Car, finalement, ce qu’on maquette, ce qu’on intègre est statique. Nous créons des modèles pour tester les styles du site, et, si nous garantissons l’accessibilité des zones « statiques » du site (header, footer, par exemple), la responsabilité de l’accessibilité des contenus du site revient aux contributeurs.
Le soin apporté par un intégrateur à la sémantique des éléments d’un article, par exemple (je pense au caption d’un tableau, ou à la légende d’une image) ne sera pas forcément répercuté, sinon en dév (certains CMS ne permettent pas de saisir un caption aux tableaux contribués, par exemple), du moins en production : les contributeurs ne sont pas toujours formés à l’accessibilité.
On n’a donc aucun moyen de vérifier si leurs textes respectent les bonnes pratiques ou pas.
Je me demande comment on pourrait sensibiliser les contributeurs à ces enjeux.
Steve Mayenobe, le lundi 9 juin 2014 à 20:58
Moi qui suis un militant anti-title (si des choses sont à dire, autant le dire dans son contenu) j’ai rarement vu un article aborder avec autant de précisions un sujet qui me paraissait si simple à la base ! Beau boulot !
Keobiz, le mardi 21 février 2017 à 12:52
Merci pour l’article !