Le texte alternatif, ça n'est pas que pour les aveugles et Google...

Bonjour,

a écrit :
Du coup on serait plus portés à penser non pas en alternative textuelle mais en alternative visuelle... ce qui serait dans la cohérence du document : d'abord le contenu structuré puis les couches graphiques (les images, les CSS de mises en forme) et événementielles.

Ben oui mais non, tu penserais mal et le document n'en serait pas plus cohérent au contraire (ça ne préjuge pas de la qualité de ta moquette hein )

Il n'y à aucune raison valable de privilégier l'un ou l'autre, une image est un contenu qui à sa place en tant que tel.

Le défaut de la balise img c'est justement qu'elle privilégie (ou plus exactement impose) un seul canal de restitution.

En réalité la balise img est, de fait, inadaptée aux possibilités du web en tant que "media multiple" si vous me pardonnez ce "barbarisme".

Il y à d'ailleurs cette phrase, lourde de sens, sur la page d'où tu à tiré l'exemple d'implémentation :

a écrit :
Les versions antérieures de HTML permettaient aux auteurs d'inclure des images (via l'élément IMG) et des applets (via l'élément APPLET). Ces éléments ont plusieurs limitations :

* ils ne répondent pas au problème plus général de la manière d'inclure les nouveaux comme les futurs types de média ;
* l'élément APPLET ne fonctionne qu'avec des applets basés sur le langage Java. Cet élément est déconseillé en faveur de l'élément OBJECT ;
* ils entraînent des problèmes d'accessibilité.

Spécification Html 4.01 - 13.1 Introduction aux objets, images et applets

Ecris donc en 1999, 10 ans après nous y sommes encore....

Par ailleurs le fonctionnement que tu décris n'est pas logique : si je veux implémenter une image c'est bien parce que c'est une image...

Ce n'est pas une question de "priorité" mais de "canal" : la balise img ne possède qu'un canal de restitution (visuel) et une rustine techniquement limitée, c'est du contenu sans vraiment en être et il ne peut être que textuel !

C'est un peut juste, cela ne corrrespond pas à la notion de "ressource" attachée au web.

Par ailleurs, la manière de le gérer (l'attribut) nous amène à le concevoir et le traiter comme une alternative-en-cas-de-besoin et pas du tout comme la simple présentation d'une information au travers de plusieurs canaux de restitution différents.

La balise object, en revanche, fonctionne de cette manière c'est sa nature et son rôle, ce qui me permet de multiplier les possibilités de traitement de l'information.

De les multiplier, de les adapter de manière très fine, d'en inventer des nouvelles ou de s'adapter à des usages, des conventions, du consensus, ou des technologies nouvelles.

Bref tout ce qui fait le web...

La balise img+alt+longdesc "si tout va bien" est évidemment pas le bon client pour ça.

Petit exemple juste pour vanter la qualité de la moquette de mon bureau...

Imaginez que j'ai envie de donner un contenu équivalent à une image sous forme d'un son (genre une alerte sonore pour une alerte visuelle)

Evidemment pour éviter un futur troll on admet que j'ai de très bonnes raisons de vouloir donner cette information de cette manière.

Comment je fais avec ma balise img ?, je fais pas, je prends ma béquille et je clopine avec du texte, ce qui n'est pas ce que voulais faire...

Au delà de cet exemple simpliste, cela "interroge" comme dirait un candidat au bac philo, sur la notion d'alternative, et ça, pour le web, c'est tout bon

Jean-Pierre
Modifié par jpv (25 Jun 2007 - 20:20)

Hermann a écrit :
A quoi correspond les aides techniques?
Qu'elles ont les User Agents qui pourraient exploiter les données EXIF?

Tous ceux qui s'en donnent les moyens.

Il y à d'ailleurs déjà des choses qui existent comme l'extension fxif pour firefox Mozdev - extension fxif (en)

Hermann a écrit :

Autre chose:
Etant donné que le alt doit être consédéré comme un contenu textuelle commes les autres contenus textuels (paragraphes...), je suppose qu'il faut
penser à séquencer ce contenu comme un paragraphe?
Ce qui revient à placer les image dans un paragraphes:

<p>Texte1</p>
<p><img src="..." alt="texte2" /></p>
<p>Texte3</p>

Mais pour un lecteur d'écran, est ce que ça ne revient pas au même de mettre:

<p>Texte1</p>
<img src="..." alt="texte2" />
<p>Texte3</p>

Non pas du tout.

Tu à d'abord une erreur dans ton code, img est de type inline et nécessite un conteneur.

Au delà, une image est du contenu, si l'image nécessite d'être restituée dans le flux d'une phrase elle doit l'être.

En revanche dans le genre limitations de l'attribut alt on peut citer l'impossibilité technique d'implémenter par exemple :
- Une abréviation
- Une indication de langue
- Une ressource (URI)
Et de manière générale : utiliser ce que j'ai besoin d'utiliser parce qu'à ce moment là et dans ce contexte là c'est pertinent et adapté...

Jean-Pierre

jpv a écrit :

Il y à d'ailleurs déjà des choses qui existent comme l'extension fxif pour firefox Mozdev - extension fxif (en)

Merci, dommage seulement que le fichier xpi retourne une erreur.

jpv a écrit :

Tu à d'abord une erreur dans ton code, img est de type inline et nécessite
un conteneur.

Mon code supposait un div englobant. ça suffit non?

Bonsoir,

Hermann a écrit :

Mon code supposait un div englobant. ça suffit non?

Si je ne m'abuse, en (X)HTML Strict, on ne peut pas mixer des éléments inline et des éléments blocks dans un élément block, et les exceptions à cette règle (dont li si mes souviendres ne me font pas trop défaut) seront éliminés sauvagement dans les prochaines version d'HTML.

Lanza a écrit :
Bonsoir,
Si je ne m'abuse, en (X)HTML Strict, on ne peut pas mixer des éléments inline et des éléments blocks dans un élément block.

D'ou tu sors ça? On ne peut pas avoir directement d'élements inline dans le <body> en DTD strict ça c'est c'est vrai mais un élément comme <div> peut très bien contenir des éléments inline et block simultanément.
Modifié par Hermann (25 Jun 2007 - 22:24)

Hermann a écrit :
D'ou tu sors ça?

Une légende urbaine qui traine.

Hermann a écrit :
On ne peut pas avoir directement d'élements inline dans le <body> en DTD strict ça c'est c'est vrai mais un élément comme <div> peut très bien contenir des éléments inline et block simultanément.

Voilà, c'est tout comme ça, et on le vérifiera avec bonheur en consultant directement la DTD Strict de XHTML 1.0.

Par ailleurs, et d'après ma dernière lecture à ce sujet, le plan pour (X)HTML 5 pour l'élément div est qu'il ne puisse plus contenir que :
- soit des éléments de type bloc (au sens large et approximatif, il me semble) ;
- soit des éléments de type en-ligne ;
- mais pas un mélange des deux.
Même chose pour les li.
Cf. http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/Overview.html#content-model-changes

Bonsoir,

Christian Le Bouler a écrit :


De complémentarité plutôt que d'alternative, d'autant que ce que tu décris nous entraine loin de la définition stricte de l'alternative :

A ou B mais pas les deux, et pas ni l'un ni l'autre.

Heu... nous parlons bien de la même chose je pense, je n'ai pas eu l'impression de décrire un mécanisme complémentaire, au contraire.

Ce que je voulais dire c'est que les capacités de la balise object de servir un même contenu (c.a.d de l'information) sous de multiples formes modifie les perspectives de l'alternative.

Pour les images en loccurence nous ne sommes plus dans une perspective de pallier une défaillance (supposée ou réelle) : je ne "remplace" pas l'image (une image est irremplaçable) je rends simplement une information disponible sous plusieurs formes.

Prenons un cas simple, un peut caricatural mais bien pratique : un joli graphe sous forme de camembert, avec un quartier mis en exergue (l'info importante) et son alternative.

Comment je le traite actuellement : j'implémente un alt qui est censé me donner l'information nécessaire à la compréhension du contenu (donc le quartier mis en exergue) et je référence un attribut longdesc qui lie une ressource contenant une description détaillée.

Très bien, mais il me faut réunir des conditions précises à l'utilisation de cette technique : il faut que l'UA ait référencé les attributs, choisis une méthode de traitement et mette à disposition des fonctionnalités adhoc...

Par ailleurs ces alternatives, quoi qu'on en dise, sont "hors contexte" pour la ressource via longdesc, et pas tout à fait un véritable contenu pour l'attribut alt.

On connait le succès : Tu peux tant mieux, tu peux pas tant pis.

Maintenant j'implémente ce même camembert avec object. Que vais-je mettre comme "alternative" : exactement ce que je veux et ce que j'ai besoin :

- Un simple résumé de l'info nécessaire à la compréhension du contenu.
- Un tableau en html pur jus avec un titre, un résumé et tutti quanti.
- Un tableau en html pur jus et une légende reprenant l'information nécessaire à la compréhension du contenu (au cas ou l'utilisateur passe outre la restitution du tableau).
- Un simple résumé de l'info nécessaire à la compréhension du contenu ET un lien vers une ressource contenant un tableau en Html pur jus...
- Tout autre chose d'encore plus pertinent.

Quel que soit mon choix (et mes contraintes) je reste totalement maitre du jeux, je ne me pose plus la question de l'attribut, de la méthode, de la restitution, des palliatifs en cas défaillance, de manque de support ou de la nature du bulletin météo du lendemain.

J'ai juste de l'info (l'image et son contexte) à proposer d'une autre manière, la plus pertinente et adaptée...

Je ne fais plus de l'alternative (au sens rampe d'accès), je produis du contenu dont la restitution ne dépends que de la capacité de l'UA à interpréter l'un OU l'autre des canaux disponibles.

C'est un détail qui à de l'importance car cela signifie que mon "alternative" est restituée dans son contexte, elle ne dépends pas d'une fonctionnalité, elle n'est pas restituée sous une forme particulière : c'est tout bêtement du contenu et rien d'autre.

Ca ne change pas les problématiques de contextualisation, ca ne change rien aux statuts relatifs des images...

En revanche ce que j'implémente joue le même rôle, au même moment et, du point de vue de l'information, de la même manière.

Image ou pas image c'est bien pareil...

Bon l'exemple est un peut caricatural puisqu'au final je ne fais que remplacer une méthode défaillante par une méthode efficace.

C'est déjà pas si mal...

En revanche et c'est sans doute ce qu'il faut retenir, c'est que du point de vue de l'information il n'y à pas de différence entre la ressource embarquée via l'attribut data et le ou les contenus "alternatifs" : dans les deux cas je fais ce que j'ai besoin de faire et le résultat c'est du contenu.

A contrario il y à une vraie différence entre la ressource via l'attribut src d'une image et le contenu de l'attribut alt : avec src je fais bien ce que j'ai besoin et c'est du contenu, avec alt je fais surtout ce que je peux et ce n'est pas un véritable contenu.

Bon je vais attaquer la moquette du voisin...

Jean-Pierre