bonjour,
je fais afficher une image avec un balise alt dont les infos sont récuperées de ma BDD.

mon image s'affiche, mais lors du passe de ma souris sur cette image je n'ai qu'un seul mot qui s'affiche. Ce mot correspond au premier mot du contenu de mon alt. par exemple si j'ai "les photos du chalet" je n'aurai que "les"

mon code pour afficher est le suivant :

	<?PHP 
	echo"<a href=\"clics.php?id=".$data['id']."\" target='_blank'><img src=\"../images/partenaire/".$data['logo']."\" alt=".$data['alt']."></a>";
	?>

si vous avez une idée je suis ouvert car je rame....

Les valeurs des attributs d'une balise html doivent (ou du moins devraient toujours) être placés entre guillemets. Si tu n'en met pas, le navigateur va considérer que la valeur associé s'arrête au premier espace qu'il rencontre : Va uniquement te donner pour alt la valeur "un", tandis que te donnera bien "un texte alternatif"


Pour rendre ton code plus lisible et mieux voir ce genre de chose, je te recommande de délimiter tes chaines php contenant du html avec des apostrophes plutôt que des guillemets. (Faire attention, il faut dans ce cas absolument sortir les variables de la chaine, mais comme tu le fais déjà).

echo '<a href="clics.php?id='.$data['id'].'" target="_blank"><img src="../images/partenaire/'.$data['logo'].'" alt="'.$data['alt'].'"></a>'; 

L'intérêt est surtout de ne pas avoir à protéger les guillemets du code html et ainsi conserver sa lisibilité... après, c'est question de goût

merci j'avais aussi trouvé une autre solution mais la tienne est bien plus simple. j'opte donc pour ta solution.

celle que j'avai trouvé :

echo"<a href=\"clics.php?id=".$data['id']."\" target='_blank'><img src=\"../images/partenaire/".$data['logo']."\" alt=\"".$data['alt']."\" width=\"130\" height=\"130\" border=\"0\"></br>".$data['titre']."</a> 
";

Attention, le tag alt est l'affichage du texte alternatif à la place de l'image. IE l'utilise également pour faire l'affichage de l'infobulle, mais ce n'est pas son utilisation première.

Si tu veux afficher une infobulle avec Firefox il fauut utiliser le tag title Et pour faire simple, je te propose de mettre le même texte dans les deux.

Enfin, pour améliorer la lisibilité de ton code, tu n'es pas obligé d'utiliser la double-quote en PHP (ni en HTML d'ailleurs)

echo'<a href="clics.php?id='.$data['id'].'" target="_blank"><img src="../images/partenaire/'.$data['logo'].'" alt="'.$data['alt'].'" width="130" height="130" border="0"></br>'.$data['titre'].'</a>  
'; 

Attention, le tag alt est l'affichage du texte alternatif à la place de l'image. IE l'utilise également pour faire l'affichage de l'infobulle, mais ce n'est pas son utilisation première.

Si tu veux afficher une infobulle avec Firefox il fauut utiliser le tag title

Code : Tout sélectionner

<img src="..." alt="le texte alternatif à la place de l'image" title="l'info bulle">

Et pour faire simple, je te propose de mettre le même texte dans les deux.

Enfin, pour améliorer la lisibilité de ton code, tu n'es pas obligé d'utiliser la double-quote en PHP (ni en HTML d'ailleurs)

echo'<a href="clics.php?id='.$data['id'].'" target="_blank"><img src="../images/partenaire/'.$data['logo'].'" alt="'.$data['alt'].'" width="130" height="130" border="0"></br>'.$data['titre'].'</a>  
'; 

"...Et pour faire simple, je te propose de mettre le même texte dans les deux..." une technique que j'utilise systématiquement et recommande également

pour faire simple, je te propose de mettre le même texte dans les deux

Sauf que, pour une synthèse vocale ou un navigateur textuel (comme Lynx), ça fait doublon.

Petit rappel de la sémantique d'alt et de title :
- alt permet de fournir une alternative textuelle à une image ou à une zone cliquable aux utilisateurs qui ne peuvent voir les images soit par handicap (aveugles) soit par limitation logicielle (navigateur textuel, navigateur où l'affichage des images est désactivée, image non chargée ou en cours de chargement), laquelle alternative doit être courte (pas plus de 60 ou 80 caractères ou d'une dizaine de mots) ;
- title permet de fournir un renseignement d'avertissement concernant l'élément dans lequel il est employé ("This attribute offers advisory information about the element for which it is set", dit la spécification HTML), lequel renseignement est affiché sous forme d'info-bulle par les navigateurs graphiques et dont le contenu est moins contraint en termes de nombre de caractères (on peut monter jusqu'à 120 caractères).

L'attribut title, s'il est employé conjointement avec alt, devrait être plus complet et précis que l'attribut alt, de la même manière qu'employé dans l'élément A, il précise la nature du lien lorsque ce dernier est isolé de son contexte.

Ben oui on est d'accord que ce n'est pas la même utilisation mais quand il s'agit d'une image, alt est nécessaire pour le texte alternatif et si l'on veut une info onmouseover sur l'image, title est nécessaire avec FF etc. Donc globalement...

Pas vu d'autre solution, et toi comment t'y prends-tu pour afficher une légende au survol d'une image ?

OK ... dans le cas où tout ton site respecte les recommandations d'accessibilité aux handicapés. Et ça ne s'arrête pas aux tag alt et title, loin de là ... D'ailleurs le site du gouvernement relatif à la loi 2005-102 qui impose cette accessibilité aux sites officiels ne respecte pas ces règles sur les alt et les title.

Et puis, il faut un peu arrêter avec les gens qui ont désactivé l'affichage des images ... c'est bien gentil, mais ça représente combien de pouillièmes de millièmes de pourcent ? A un moment donné, il faut appliquer le principe de réalité.

Pas vu d'autre solution, et toi comment t'y prends-tu pour afficher une légende au survol d'une image ?

Pour ma part, j'utilise l'attribut title ; mais, s'il s'agit d'indiquer la même chose que pour alt, j'estime que ça ne vaut pas vraiment le coup, sauf à aimer les doublons.

Pour ma part, j'utilise l'attribut title

Pas toujours

Pas toujours

Code : Tout sélectionner

<img src="images/en-tete.png" alt="Victor BRITO - Webmaster" width="500" height="60" />

Certes ; mais, dans ma précédente intervention, c'était pour répondre à une question posée par AB. Et puis, sache que l'attribut title est facultatif, quel que soit l'élément pouvant le contenir.

Et puis, il faut un peu arrêter avec les gens qui ont désactivé l'affichage des images ... c'est bien gentil, mais ça représente combien de pouillièmes de millièmes de pourcent ? A un moment donné, il faut appliquer le principe de réalité.

Dans ce cas, autant ne pas tenir compte des utilisateurs d'un navigateur autre qu'Internet Explorer ou qui n'ont pas de quoi lire un fichier WMV, parce qu'IE représente 80 à 90 % de parts de marché des navigateurs et que la plupart des gens ont Windows Media Player comme lecteur de vidéo.

Indépendamment de la désactivation des images, on n'est jamais à l'abri d'une indisponibilité temporaire. Et puis, côté référencement, n'oublie pas que les robots des moteurs de recherche sont les handicapés les plus célèbres parmi les utilisateurs du Web (ils sont tout aussi aveugles que Lynx).

Eh oui ! l'accessibilité, c'est tenir compte de scénarios que tu peux juger corsés ou quasi improbables, mais qui peuvent se produire à un instant t (fût-il très court ou exceptionnel) chez un utilisateur x (fût-il le seul à qui le scénario se produit).

Pas vu d'autre solution, et toi comment t'y prends-tu pour afficher une légende au survol d'une image ?

Pour ma part, j'utilise l'attribut title ; mais, s'il s'agit d'indiquer la même chose que pour alt, j'estime que ça ne vaut pas vraiment le coup, sauf à aimer les doublons.

Je vois le pb un peu différemment. Si je veux afficher une légende au survol d'une image, que j'aime les doublons ou non, je suis bien obligé d'utiliser "title" pour un bon fonctionnement avec FF.

Maintenant il est vrai que pour des album photo ou je peux inscrire une légende en dessous de la photo, je ne l'utilise pas.

Mais dans les autres cas si je veux profiter des info bulles pour renseigner les utilisateurs voyants, je suis bien obligé de faire ces doublons. Ou alors pour ne pas faire ces doublons (qui ne sont pas dramatiques pour les non voyants), je prive tous les utilisateurs voyants utilisant FF, des info bulle sur les images...

Dans ce cas, autant ne pas tenir compte des utilisateurs d'un navigateur autre qu'Internet Explorer ou qui n'ont pas de quoi lire un fichier WMV, parce qu'IE représente 80 à 90 % de parts de marché des navigateurs et que la plupart des gens ont Windows Media Player comme lecteur de vidéo.

C'est une question de principe de réalité. En 2007, j'ai eu l'expérience du développement d'un extranet pour environ 1000 utilisateurs identifiés utilisant IE6, IE7 ou FF sauf cinq utilisateurs qui utilisaient IE 5 sur Mac OS 9. Que faire ? Tenir compte de ces 0,5% d'utilisateurs et brider fortement les fonctionnalités du site ? Ou leur demander d'évoluer vers Mac OS X et des navigateurs modernes ?

Indépendamment de la désactivation des images, on n'est jamais à l'abri d'une indisponibilité temporaire.

Dans ces cas-là, il n'y a pas que les images qui ne s'affichent plus, il y aussi les CSS, les fichiers javascripts externes, Bref, les 3/4 du site sont en rade ... Encore une fois, principe de réalité : est-ce qu'il faut passer des heures à envisager des cas qui ne se produiront que quelques minutes par an dans le pire des cas ?

Et puis, côté référencement, n'oublie pas que les robots des moteurs de recherche sont les handicapés les plus célèbres parmi les utilisateurs du Web

Effectivement. Mais les tags d'images ne sont pas les préoccupations premières des robots. Il y a surtout tout le texte qui entoure les images qui est important.

l'accessibilité, c'est tenir compte de scénarios que tu peux juger corsés ou quasi improbables, mais qui peuvent se produire à un instant t (fût-il très court ou exceptionnel) chez un utilisateur x (fût-il le seul à qui le scénario se produit).

Je respecte ton opinion, mais je ne la partage pas. En tant que professionnel du développement de sites Web, on me demande (et je demande à mes équipes) d'être rentable. Donc couvrir rapidement 80% des besoins, 90% ou 95% si cela ne demande pas trop d'effort supplémentaire, mais surtout ne pas passer 90% du temps à tenter d'envisager des réponses aux cas improbables.
Il est cependant indispensable qu'il y ait des organismes qui édictent des règles, il est indispensable que nous essayons tous d'appliquer le maximum de ces règles, mais il ne faut pas non plus que cela tourne au fanatisme religieux. Il y a et il y aura toujours des cas improbables : eh bien tant pis !

Non, l'accessibilité, ce n'est pas prendre en compte 100% des cas (le seul à qui le scénario se produit), c'est jongler entre assurer le meilleur service possible à l'immense majorité des personnes et prendre en compte la plupart des autres en dégradant le moins possible le service et en l'adaptant le mieux possible à leurs besoins. Mais non, on ne peut pas tout gérer. Sinon, on en serait encore avec un Web uniquement composé de pages telles que celle-ci

En tant que professionnel du développement de sites Web, on me demande (et je demande à mes équipes) d'être rentable.

Les utilisateurs qui n'entrent pas "dans le lot" ne sont pas rentables ?

Quant aux utilisateurs de navigateurs anciens, il y a moyen d'en tenir compte sans pour autant brider le développement : par exemple, en CSS, en appelant les feuilles de style externes non pas par l'élément LINK, mais par un élément STYLE et la règle @import (une règle CSS 2 qui n'est pas implémentée par des navigateurs anciens comme IE 4 ou Netscape 4), ce qui permet, certes, de priver l'éventuel utilisateur d'un ancien navigateur de feuilles de style, mais surtout de s'assurer qu'il pourra consulter la page Web, fût-elle brute de décoffrage, sans se heurter à des bugs CSS ; de même, d'ici quelques années, on pourra utiliser cette même règle @import suivi du média auquel s'applique la feuille de style (@import "url-de-la-feuille-de-style.css" screen, par exemple) pour éviter que les utilisateurs d'une version d'IE antérieure à la 8 ne se trouvent avec des bugs CSS (surtout si l'on applique des fonctionnalités CSS 2 très avancées, voire certaines de CSS 3). Mais, il va de soi que, si les utilisateurs se mettent à jour en matière de navigateurs, mieux ce sera.

De plus, je ne vois pas en quoi tenir compte de l'accessibilité dès le départ est une perte de temps ; en revanche, rendre accessible un développement existant qu'il ne l'est pas du tout peut être une perte de temps. Mais, compte tenu des profits qu'on tire du respect de l'accessibilité, le jeu en vaut la chandelle et la mise en place, dès qu'on en a cerné le principe et les enjeux, est relativement aisée (sinon, aucun site ne décrocherait un des labels mis en place par Accessiweb, par exemple ; d'ailleurs, le site de la mutuelle Intégrance fait partie des sites qui ont reçu le label or, le plus rigoureux des labels Accessiweb, et d'autres sites, même s'ils n'ont que le label bronze, n'en montrent pas moins un minimum d'accessibilité : ils sont mentionnés à la galerie des sites accessibles d'Accessiweb).

Mais non, on ne peut pas tout gérer. Sinon, on en serait encore avec un Web uniquement composé de pages telles que celle-ci

Qu'est-ce qui ne te plaît pas dans cette page du W3C ?

Les utilisateurs qui n'entrent pas "dans le lot" ne sont pas rentables ?

Désolé, mais non. Quand on a un budget (généralement serré) à tenir, on n'a pas le temps de se préoccuper de faire un site Internet avec une double conception et n mises en page pour les utilisateurs sans handicap et les utilisateurs avec toutes les formes possibles de handicap (ceux qui ont besoin de lettres sombres sur fond clair, ceux qui ont besoin de lettres claires sur fond sombre, ...). C'est cruel, mais c'est comme ça.

Lors d'une consultation pour effectuer le site d'une mairie il y a 2 ou 3 ans, nous avions inclus en option le développement pour intégrer l'accessibilité aux handicapés, en faisant appel à une boîte spécialisée qui justement, permettait de gérer à peu près tous les types de handicap possibles et imaginables. Résultat : budget initial +25% et le client a décidé de ne pas prendre. Qu'est-ce qu'on fait ? On fait quand même en perdant de l'argent ?

il y a moyen d'en tenir compte sans pour autant brider le développement

Par exemple, l'intérêt d'un site tel que Netvibes, c'est justement tout l'aspect visuel et toute l'ergonomie qui ne fonctionnent qu'avec les navigateurs modernes. Si tu retires toutes les possibilités de fenêtrage, de dimensionnement, de déplacement, Netvibes n'a plus aucun intérêt. Quand la valeur ajoutée d'un site, c'est justement tout l'aspect interface utilisateur évoluée, il n'y a vraiment pas besoin de se prendre la tête pour ceux qui pour une raison ou une autre, ne peuvent pas avoir accès à cette interface évoluée.

Qu'est-ce qui ne te plaît pas dans cette page du W3C ?

Je n'ai pas dit qu'elle ne me plaisait pas. J'ai dit qu'heureusement on peut aller sacrément plus loin aujourd'hui, quitte à sacrifier les pauvres utilisateurs de Windows 98 et ceux de Mac OS 9.