Défi HTML: quel balisage pour cet élément?

Gekkogo a écrit :
Avec l'image en background du h1 et le span masqué...

Non, ce type de technique (dite de «remplacement d'image») pose des problèmes d'accessibilité. Notamment dans tous les cas de figure où l'image n'est pas disponible, et où les styles CSS sont appliqués malgré tout: on n'a ni l'image, ni le texte.

Une image de contenu accessible, c'est cela et uniquement cela:

<img src="..." alt="le texte qui va bien" />

Réponse à 18:00 CET.

Happy N<img src="" alt="e" title="Logo internet explorer" width="" height="" />w Year!

Victor BRITO a écrit :

Et comment le masquerais-tu ?

Avec un text-indent par exemple.

Il est certain que niveau accessibilité rien n'est mieux qu'une image avec un alt renseigné mais dans notre cas étant donné que l'image est au beau milieu du texte je ne suis pas certain que ce soit le top non plus...

Gekkogo a écrit :
Avec un text-indent par exemple.

Si les images sont désactivées et que les CSS demeurent activées, le texte indenté demeurera masqué et rendra l'ensemble difficilement compréhensible.

C'est l'heure de la solution.

---

Pour commencer, voici les principaux problèmes à éviter:

- Les techniques de remplacement d'images et globalement toutes les images de fond en CSS, inutile ici et posant les problèmes d'accessibilité que l'on sait (si l'image n'est pas affichée, le texte reste masqué par les styles CSS... voire on n'a même pas mis de texte masqué).
- Le texte alternatif qui décrit l'image au lien de transcrire sa fonction. Si vous découpez le logo d'IE (en forme de lettre "e"), le texte alternatif correspondant devrait être "e" et certainement pas "Logo Internet Explorer".
- Les balises dans les mots. Une balise dans un mot, ça découpe le mot en plusieurs mots séparés. Visuellement, ça passe, mais dans un lecteur d'écran ce n'est pas le cas.

---

On pouvait donc obtenir une première solution:

Happy <img src="..." alt="New" /> Year!

Le problème avec cette solution, c'est que si tout le mot "New" est une image, et les deux autres mots du texte HTML, obtenir exactement la même typographie pourra être difficile.

---

Pour éviter cette écueil, une solution évidente s'impose:

<img src="..." alt="Happy New Year!" />

Bravo à KaZhaR qui a fourni cette réponse. Bravo également à _CUT_HERE_ sur Twitter qui propose la même chose, mais avec un H1 autour de l'image, ce qui est une erreur. En effet, ici le contexte est absent, et le fait que le texte soit gros ne suffit pas à conclure que c'est un titre de section.

---

Enfin, ma solution préférée serait la suivante:

<img src="..." alt="Happy New Year With Internet Explorer!" />

Ici le texte alternatif rend mieux compte du sens de la composition graphique.
C'est bien sûr une interprétation, qui est contestable. De plus, en cherchant à transcrire très précisément le sens d'une image on se retrouve souvent à rédiger des alternatives aberrantes, et donc je ne vous conseille pas spécialement de faire du zèle.
Modifié par Florent V. (10 Jan 2010 - 18:15)

Les défis de Florent V. ou de l'art du dépouillement dans le code.

Mouais, pas mal... J'avoue mais j'aimais bien ma dernière proposition
Bravo Mathieu ! Je suis sur que tu as répondu à l'arrache en plus

Bon... ça a le mérite d'être simple et de pas utiliser trop de code.

<mauvaisefoi>Mais quand même, utiliser seulement une image pour écrire du texte c'est pas top, mais sans contexte c'est vrai qu'on s'en fout un peu</mauvaisefoi>

Maintenant que je sais dans quel esprit Florent organise ses concours je ferai plus gaffe
A quand le prochain ?

Florent V. a écrit :

Pour éviter cette écueil, une solution évidente s'impose:

<img src="..." alt="Happy New Year!" />

<img src="..." alt="Happy New Year!" lang="en" />

Laurent Denis a écrit :

<img src="..." alt="Happy New Year!" lang="en" />

C'est bien dit !

Sur les chipotages:
- L'utilisation d'un attribut lang dépendra du contexte de publication. L'exemple vient d'un site en anglais (le blog Microsoft consacré à Internet Explorer).
- Sur l'utilisation d'un strong: oui, ça tient la route.
- Attributs width et height: utiles essentiellement pour des questions de performances (limiter les reflow, éventuellement permettre à un client mobile de décider de ne pas télécharger une image trop volumineuse mais je ne suis pas sûr que ce dernier cas soit d'actualité). Et aussi pour l'affichage graphique du texte alternatif dans Safari lorsque l'image n'est pas chargée (bug de Safari, à mon sens). Donc au final ces attributs ne me semblent pas indispensables.

Florent V. a écrit :

- Attributs width et height: éventuellement permettre à un client mobile de décider de ne pas télécharger une image trop volumineuse mais je ne suis pas sûr que ce dernier cas soit d'actualité).

Effectivement faudrait faire des tests ou connaître le comportement des principaux navigateurs mobile actuels, mais personnellement j'ai arrêté de faire du webmobile...

Florent V. a écrit :

Et aussi pour l'affichage graphique du texte alternatif dans Safari lorsque l'image n'est pas chargée (bug de Safari, à mon sens). Donc au final ces attributs ne me semblent pas indispensables.

Comment ça se manifeste?

C'est un détail ici mais il me semble que les attributs de taille peuvent servir à des robots
d'indexation genre Google image (qui parvient quant à lui à détecter la taille intrinsèque de
l'image sans l'aide des attributs de taille) pour sélectionner les images à afficher selon les
préférences de taille d'image choisies par l'internaute.
Modifié par Hermann (14 Jan 2010 - 00:55)

Hermann a écrit :
Comment ça se manifeste?

Si l'élément image n'a pas de dimensions explicites et que la ressource ne peut pas être chargée, on a juste une icone «image pas chargée», et le texte alternatif n'apparait pas. Si l'image a des dimensions explicites on a une zone dessinée où on retrouve cette même icone et le texte alternatif à côté. Problèmes:
- l'icone est rarement nécessaire, et souvent gênante (menu de navigation avec boutons en images, si les images ne sont pas chargées on préfèrerait le texte alternatif stylé en CSS);
- si pas de dimensions données dans le HTML, pas de alt affiché;
- le texte alternatif peut être plus long que la zone créée par les dimensions de l'image.

Problème existant dans Safari (4), Chrome (3), Safari Mobile, le navigateur webkit d'Android, etc. Je crois qu'il y a un navigateur utilisant Webkit sous OS X qui contourne ce problème, donc c'est en partie dû à la manière dont le navigateur exploite webkit, plutôt qu'à une incapacité de Webkit.

Capture d'écran sur Chrome:
http://dl.dropbox.com/u/145744/screens/chrome-alt-display.png