Attribut title dans les liens

Bonjour,

Je souhaiterai savoir si l'attribut title est nécessaire pour l'accessibilité (notamment pour les liens) ?
D'après les premiers retours que j'ai eu il semblerait que oui, mais je ne parviens pas à comprendre pourquoi il serait "obligatoire" pour l'une des 3 validations en accessibilité.

Je peux comprendre que via le title il est possible de donner des indications (comme l'ouverture dans une nouvelle page, un lien d'un site externe, etc.) mais j'imagine que les lecteurs d'écran peuvent détecter cela automatiquement (target="_blank", URL du site externe différente du site consulté, etc.)

Merci à ceux qui prendront le temps de bien vouloir m'éclairer à ce sujet

Bonjour et bienvenue,

Dans la mesure du possible, il faut se passer de l'attribut title dans le maximum de cas, en ayant des intitulés de lien (le texte dans l'élément a, entre les balises <a> et </a>) les plus clairs possibles.
Savoir qu'il s'agit d'un site externe intéresse aussi les voyants, que le PDF pèse 2 Mo intéresse ceux qui surfent via un WiFi public qui rame, que le site cible est en anglais ou chinois intéressera les francophones n'ayant pas fait langues O, etc

Quand on a des contraintes (la maquette à intégrer n'a pas été réalisée en interne et/ou n'a pas eu l'accord du client avec "tous ces trucs qui servent à rien ou pas grand chose", pas la place, etc), on a alors effectivement recours à title si nécessaire.
Les attributs title identiques à l'intitulé de lien sont inutiles, à supprimer puisqu'ils n'apportent rien. C'est bon on a déjà l'intitulé !
Il reste le cas où on veut apporter une information ne figurant pas dans l'intitulé.

En théorie oui, on peut se passer de title si on maîtrise l'intégralité de la chaîne de création d'un site web (décideur, graphiste, ergonome, intégrateur statique et dynamique, rédacteur de contenu). En pratique, on va en avoir besoin dans plus ou moins de cas et là WCAG2, RGAA 2.2 et/ou Accessiweb 1.1 (AW 2.0 en appel à commentaires publics, lien temporaire et critères/tests/glossaire susceptibles de modification d'ici la version finale) sont intéressants en recommandant et proposant des tests à respecter

edit: là je viens de créer un intitulé de lien super long pour rajouter des informations quant à la nature du lien, ça plaît rarement
Modifié par Felipe (11 Nov 2009 - 12:17)

Pour en rester à la problématique strictement "accessibilité":
* D'une manière générale, l'utilisateur doit être prévenu avant tout changement de contexte : nouvelle fenêtre, lancement d'une application autre que le navigateur, changement de focus dans la page. Cet avertissement peut être bien-sûr implicite dans certains cas (libeller un lien mailto avec une adresse mail suffit).
* Non, les aides techniques ne signalent pas automatiquement ce genre de choses, et ne pourraient pas le faire de manière utile : pour l'ouverture d'une nouvelle fenêtre, détecter un script est pour le moins beaucoup plus difficile.
* Les utilisateurs concernés ne sont pas seulement ceux des lecteurs d'écran. Etre averti de l'ouverture d'une nouvelle fenêtre est par exemple tout aussi utile à des utilisateurs mal-voyants qui se servent d'un simple dispositif d'agrandissement. Dans la mesure où les navigateurs ne signalent pas nativement les ouvertures de nouvelles fenêtres, il faut donc un avertissement spécifiquement ajouté au lien.
* TITLE n'est pas le seul moyen et, à vrai dire, les techniques WCAG2.0 ont un discours assez curieux actuellement à ce sujet : TITLE y est déconseillés en raison de défauts effectivement connus (non accessibilité clavier notamment) mais la solution de remplacement préconisée (un texte caché via CSS dans le libellé du lien) a des défauts au moins similaires, sinon pires. Cette pseudo-solution a donc été sagement écartée par les méthodes d'applications RGAA et AW2.0.

Je rappelle à titre d'information que les lecteurs d'écran comme jaws sont généralement configurés pour lirr celui de l'intitulé ou du title qui est le plus long, en écartant complètement l'autre, lorsque les deux sont présents. Si vous utilisez un title, il ne faut donc pas se contenter d'ajouter les informations complémentaires, mais il faut également reprendre à double l'ensemble de ce qui se trouve déjà présent dans l'intitulé.

QuentinC a écrit :
Je rappelle à titre d'information que les lecteurs d'écran comme jaws sont généralement configurés pour lirr celui de l'intitulé ou du title qui est le plus long, en écartant complètement l'autre, lorsque les deux sont présents. Si vous utilisez un title, il ne faut donc pas se contenter d'ajouter les informations complémentaires, mais il faut également reprendre à double l'ensemble de ce qui se trouve déjà présent dans l'intitulé.

Là aussi, c'est assez amusant entre WCAG et les méthodes d'applications (RGAA, AW) : ce comportement est propre à Jaws. Celui de Window Eyes est très différent et n'incite pas du tout à dupliquer dans le TITLE les informations du libellé.

Sur le fond, WCAG est muette à ce sujet : cette pratique est en fait une lecture très "française" des choses. D'autant que cela ne va pas du tout dans le sens donné au TITLE par HTML

Bonjour à tous,

Thierry V. a écrit :
Je souhaiterai savoir si l'attribut title est nécessaire pour l'accessibilité (notamment pour les liens) ?

Laurent Denis a écrit :
libeller un lien mailto avec une adresse mail suffit

Lors d'une évaluation que j'ai faite en début d'année, le rapport de labellisation (évaluation initiale) d'Accessiweb précisait bien, pour une adresse mail, que, je cite :

a écrit :
Le lien de contact n'est pas assez explicite : "contact@nom_du_site.com". Ajouter un attribut title de type "Envoyer un message à contact@nom_du_site.com".

Il a donc fallu ajouter l'attribut title sur chaque mailto afin d'obtenir le précieux macaron Bronze.

Ce sera peut-être différent avec AW 2.0

Une labellisation est une démarche particulière : des exigences et une lecture de WCAG propres au label y sont fréquentes (et tout à fait légitimes).

a écrit :

Le lien de contact n'est pas assez explicite : "contact@nom_du_site.com". Ajouter un attribut title de type "Envoyer un message à contact@nom_du_site.com".

En réalité c'est inutile : le lecteur d'écran annonce le type de lien (par exemple jaws dit : "lien sur la même page" ou "lien envoyer courrier", NVDA dit pratiquement la même chose, et je suis à peu près certain que pour les autres c'est pareil).
A ce propos, c'est bien dommage que les attributs hreflang et type n'ont pas percé autant du côté des webmasters que du côté des aides techniques, ils seraient drôlement utiles parfois (combien de fois je suis déjà tombé sur des pages en espagnol, arabe, japonais ou chinois alors que je ne connais pas ces langues, ou sur des PDF alors que ce n'est pas ce que je voulais... et quand bien même, on apprécie d'être prévenu avant d'arriver sur un site en anglais)
Modifié par QuentinC (12 Nov 2009 - 11:48)

QuentinC a écrit :
En réalité c'est inutile : le lecteur d'écran annonce le type de lien (par exemple jaws dit : "lien sur la même page" ou "lien envoyer courrier"

Oui je veux bien te croire, mais le fait est qu'Accessiweb exige cet attribut pour l'obtention du niveau Bronze (et à fortiori des niveau Argent et Or).
Un retour utilisateur serait sans doute apprécié, tu peux faire part de cette remarque à l'équipe.

Laurent Denis a écrit :
mais la solution de remplacement préconisée (un texte caché via CSS dans le libellé du lien) a des défauts au moins similaires, sinon pires. Cette pseudo-solution a donc été sagement écartée par les méthodes d'applications RGAA et AW2.0.

En quoi est-ce problématique exactement?

QuentinC a écrit :
A ce propos, c'est bien dommage que les attributs hreflang et type n'ont pas percé autant du côté des webmasters que du côté des aides techniques,

Aucun des principaux lecteurs d'écran ne le lisent?
Modifié par Hermann (12 Nov 2009 - 13:49)

a écrit :
Oui je veux bien te croire, mais le fait est qu'Accessiweb exige cet attribut pour l'obtention du niveau Bronze (et à fortiori des niveau Argent et Or).

Bah s'ils le demandent c'est sûr qu'il n'y a rien d'autre à faire que de dire amen.... ja'pportais juste mon point de vue.

a écrit :
Aucun des principaux lecteurs d'écran ne le lisent?

Non, malheureusement. hreflang et type sont deux grands oubliés, de même que le sont les <link> pour définir des relations entre documents (quand je pense aux possibilités que ceux-ci auraient pu apporter...)

QuentinC a écrit :
Bah s'ils le demandent c'est sûr qu'il n'y a rien d'autre à faire que de dire amen....

Dans le cadre d'une démarche de labellisation, il n'y a effectivement rien d'autre à faire que se conformer strictement à ce qui est demandé

QuentinC a écrit :

Non, malheureusement. hreflang et type sont deux grands oubliés, de même que le sont les <link> pour définir des relations entre documents (quand je pense aux possibilités que ceux-ci auraient pu apporter...)

Il en est de même pour longdesc (même si ça change grâce à Opera) ou l'attribut cite...

Gilles a écrit :
Il en est de même pour longdesc (même si ça change grâce à Opera)

Si tu restes dans le domaine des navigateurs graphiques tels qu'utilisés par des utilisateurs valides, oui ; pour le reste, Jaws connaît longdesc depuis un bon bout de temps.

a écrit :
Jaws connaît longdesc depuis un bon bout de temps.

Je confirme. Ca doit être supporté depuis la vversion 6 ou 7 déjà, donc depuis au moins 4 ans. Par contre, honnêtement, je ne l'ai jamais rencontré sur le web hors sites de programmation web.
Modifié par QuentinC (16 Nov 2009 - 06:38)

Longdesc...

Une vieille fausse bonne idée, née de l'échec d'OBJECT, relayée plus récemment par celui d'XHTML2.0. Ce n'est pas le contenu graphique qui doit avoir une description étendue, mais le texte HTML qui devrait avoir alternativement un rendu via un contenu graphique....

Un échec qui entraîne à son tour de fausses bonnes idées, comme celle de Hickson qui partait d'une mesure de l'utilisation de longdesc sur le Web et non d'une mesure de l'utilisation de longdesc sur le Web conforme à WCAG, pour conclure qu'il faut évacuer longdesc....

Un échec qui rebondit avec WCAG2.0 qui dilue le rôle dévolu à longdesc, avec la notion de ALT dont le contenu permet de situer où est la description étendue dans la page...

Bref, au final, personne ne pleurerait sur la disparition de longdesc.

Laurent Denis a écrit :
Longdesc...

Une vieille fausse bonne idée, née de l'échec d'OBJECT, relayée plus récemment par celui d'XHTML2.0. Ce n'est pas le contenu graphique qui doit avoir une description étendue, mais le texte HTML qui devrait avoir alternativement un rendu via un contenu graphique....

Tout à fait d'accord, dans un monde idéal. Mais parfois, la Charte Graphique imposée rend impossible l'explicitation au fil du texte d'un diagramme, et à part un D-link , je ne vois pas comment faire autrement qu'avec un longdesc.

Faire du diagramme un lien qui, via js, affiche le contenu textuel dans une modale, le déplie, etc... Le D-link en version intelligente, disons

Laurent Denis a écrit :
Faire du diagramme un lien qui, via js, affiche le contenu textuel dans une modale, le déplie, etc... Le D-link en version intelligente, disons

J'y avais pensé, mais dans ce cas tu ne peux plus fournir d'alternative courte "résumée" de l'image dans l'attribut alt. Du coup, les utilisateurs qui ne souhaiteraient pas forcément consulter la description détaillée, et se contenteraient de la version abrégée seraient quand même obligés de suivre le lien, puis revenir sur la page de départ (si js est désactivé) pour continuer leur lecture, puisque le alt décrirait le lien ("description détaillée blabla" ou quelque chose de ce genre), à moins d'inclure cette alternative dans le alt, en plus de la description du lien.

Oui, je sais, j'ai le chic pour imaginer des cas utilisateurs tordus

1. bwa si : "La tendance est à la hausse. En savoir plus"
2. bwa non pour le js désactivé: sans js, et js non intrusif, le contenu de la modale ou le contenu est dans la page, à la suite de l'image (c'est le js qui ajoute au alt le "en savoir plus" inutile sans js)

Dans cette perspective, js est utilisé pour simuler l'un des plus grands apports d'XHTML2.0, aujourd'hui aux oubliettes: le contenu d'un paragraphe est textuel à la base, un mécanisme de substitution manipulable par l'UA le remplace par la cible d'un src. Ici, l'image est affichée par défaut, mais le texte est là, tout près, immédiatement.
Modifié par Laurent Denis (19 Nov 2009 - 13:45)