Auteur
Pages :
fvsch
#
20376 Posts
... c'est aussi pour les utilisateurs «lambda», pour toutes sortes de raison.

Petit exemple : en faisant un tour sur le site de l'assurance maladie, je tombe sur ceci (attention, image sans texte alternatif Smiley lol ) :
upload/2043-ameli-half-.png

Je n'ai pas pas plongé dans le code ni effectué le moindre test sur l'accessibilité du site ameli.fr, mais de visu on constate ceci :
- pour une raison ou pour une autre (dérangement sur le serveur, problème avec mon proxy ?...), certaines images ne s'affichent pas ;
- les images significatives, notamment celles qui portent un lien, sont remplacées par leur texte alternatif, ce qui rend le site utilisable malgré tout.

En tant qu'utilisateur, je dois dire que ça fait plaisir. Smiley smile

Ah oui, le lien vers le site :
http://www.ameli.fr/

^
Benjamin D.C.
#
Modérateur
2980 Posts
Ah oui, c'est du bon boulot. Avec les images, ça a tout de suite une autre geule évidemment, mais ça montre que c'est du solide derrière.
Au passage, qu'est-ce que tu faisais sur le site d'ameli?! Smiley biggol
Modifié par Benjamin D.C. (19 Jun 2007 - 13:17)

This is the way, step inside.

^
Laurent Denis
#
7979 Posts
Faites une galerie de ces sites. Alsa est un bon endroit pour les recenser. Et ce sera utile.

Ne parlons pas de choses nouvelles. Commencez par ne pas détourner CSS de son objet, ce que vous faites immanquablement avec des techniques sexy qu'on enseigne ici.

^
fvsch
#
20376 Posts
Benjamin D.C. a écrit :
Au passage, qu'est-ce que tu faisais sur le site d'ameli?! Smiley biggol

J't'en pose des questions ? Smiley lol
Modifié par Florent V. (19 Jun 2007 - 13:39)

^
fvsch
#
20376 Posts
Laurent Denis a écrit :
Faites une galerie de ces sites. Alsa est un bon endroit pour les recenser. Et ce sera utile.

Ça c'est une idée qu'elle est bonne. Smiley smile

^
Igor
#
Modérateur
6072 Posts
Laurent Denis a écrit :
Faites une galerie de ces sites. Alsa est un bon endroit pour les recenser. Et ce sera utile.


Dans la foulée je suis passé sur mon-opquast images désactivées, j'ai pas vu la différence d'emblée et tout était fonctionnel Smiley ravi

^
Laurent Denis
#
7979 Posts
Pour conclure ce thread éminement sympathique, rappelons tout de même que le texte alternatif ne devrait pas exister, qu'il n'est qu'un accident de l'histoire HTML, et qu'il ne devrait y avoir que des contenus. Mais bon, la clé n'est pas encore suffisamment opérationnelle aujourd'hui... Quoique... ?

Smiley ravi
Modifié par Laurent Denis (20 Jun 2007 - 19:05)

Ne parlons pas de choses nouvelles. Commencez par ne pas détourner CSS de son objet, ce que vous faites immanquablement avec des techniques sexy qu'on enseigne ici.

^
fvsch
#
20376 Posts
Laurent Denis a écrit :
et qu'il ne devrait y avoir que des contenus

Du genre :
<img> Toute l'info utile/nécessaire dans le contexte

ou encore :
<img>Une partie de l'info utile également exprimée sous forme d'image</img> et le reste

ou rien de tout ça ?

^
Laurent Denis
#
7979 Posts
Bien tenté. Mais non, rien de tout cela. HTML a beaucoup mieux dans sa besace.

<private joke title="JPV">Tiens, tu vois, ça donne envie d'en parler en effet, dans un autre contexte Smiley cligne </>
Modifié par Laurent Denis (20 Jun 2007 - 19:37)

Ne parlons pas de choses nouvelles. Commencez par ne pas détourner CSS de son objet, ce que vous faites immanquablement avec des techniques sexy qu'on enseigne ici.

^
Lanza
#
Ah ! Je fais le zouave !
939 Posts
Je remarque que plus le temps passe, plus Laurent parle pour en dire moins. Je me demande si c'est parce qu'il essaie d'en dire plus avec moins de mots ou si c'est juste parce qu'il boude à force qu'on lui reproche de tenir un langage inintelligible pour le commun des mortels. Smiley lol

Si je ne m'abuse, XHTML2 propose ce genre de possibilités :

<p src="shadock.jpg">Pourquoi faire simple quand on peut faire compliqué ? </p>


Ce qui est similaire au deuxième exemple de Florent, à la différence que c'est en quelque sorte l'image qui devient l'alternative au contenu régulier.

<!-- sans commentaires... -->

^
fvsch
#
20376 Posts
Laurent Denis a écrit :
Bien tenté. Mais non, rien de tout cela. HTML a beaucoup mieux dans sa besace.

Ben je suis pas contre tout ce qui peut ressembler à des exemples, explications, voire indices... Smiley smile

^
jpv
#
757 Posts
Bonjour,

Laurent Denis a écrit :
HTML a beaucoup mieux dans sa besace.


Laurent parle de la balise object créé trop tard dans l'histoire de Html, en tout cas après la balise img...

Pour rappel : Au début Html ne peut prendre en charge que du contenu textuel.

En 1993 est mis à disposition le premier navigateur graphique mosaic qui implémentait une balise nouvelle et révolutionnaire : la balise img.

Ce n'est pas le seul aspect révolutionnaire de mosaic, on peut citer également le support des formulaires interactifs notamment.

Bref, pour en revenir à notre balise img, sa création fut le premier acte de l'inflation du balisage et sa cohorte de balises dédiées à des types de contenus non textuels.

Mais à bien y regarder cette approche (créer autant de balises que de types de contenus non textuels) est particulièrement contre-productive, compliquée et pour tout dire ingérable pour les UA.

Le W3C en entamant la longue marche vers la normalisation du langage Html y mit le holà en créant une balise neutre, la balise object.

On utilise généralement object pour du contenu dit "multimédia" mais en réalité on peut s'en servir pour n'importe quoi, notamment pour des images...

Object possède deux capacités essentielles et uniques (les balises embed, iframe, applet et autres joyeusetés n'en sont que des avatars) :

- En premier lieu elle permet de référencer un procédé applicatif, notamment un programme pluggé pour prendre en charge la ressource embarquée dans la page.
C'est très intéressant parce que cela signifie que la restitution de la ressource ne dépends plus des capacités de l'UA mais simplement d'un protocole nécessaire pour lancer le programme pluggé ou appliquer un traitement particulier à la ressource (par exemple les balises de paramètres).

- En second lieu elle permet d'embarquer un même contenu sous deux types différents : un type natif joué par le programme pluggé et un autre type par exemple textuel.

On explique, par commodité, que ce contenu textuel est une alternative mais ce n'est pas tout à fait ça : dans l'esprit, en tout cas on peut l'interpréter comme ça, il s'agit d'un contenu équivalent sous une forme différente.

Mais lorsque la balise object à été créé, la balise img était devenue un fondement du web "graphique" et était déjà devenue indéboulonnable.

Ce qui nous amène à la réflexion de Lanza :

Lanza a écrit :
...c'est en quelque sorte l'image qui devient l'alternative au contenu régulier.


C'est un peu ça, même si ce n'est pas aussi simple.

L'image ne devient pas l'alternative au contenu et l'inverse est également vrai.

Il s'agit simplement de considérer que nous avons un contenu unique (de l'information) que la technologie web nous permet de présenter sous différentes formes, adaptées à tel ou tel mode de restitution.

Dans cet esprit, certaines images, celles qui sont là pour apporter de l'nformation, devraient être considérées comme la présentation spécifique d'un contenu (c.a.d adaptée au mode restitution graphique).

Bon, j'ai bien conscience de donner l'impression d'avoir fumé la moquette en disant ça mais laisser fermenter cette idée lentement et vous verrez que c'est moins psychédélique que ça en à l'air.

Et, donc, la balise img est redoutablement défaillante à nous mener vers cette réflexion car elle ne possède pas, à contrario d'object, de procédé natif permettant d'implémenter un même contenu sous des formes différentes.

L'attribut alt est une rustine et l'attribut longdesc une béquille... Smiley smile

Au delà de ce "petit délire entres amis" souvenez vous de la réflexion de Laurent qui disait, je résume : Il faut se donner les moyens d'éviter les alternatives aux images.

L'utilisation de la balise object parce qu'elle confère une nature duelle à un contenu est une piste intéressante.

Il y en à d'autre, comme de se repencher sur des règles issues de la presse écrite, notamment celle qui interdisait (à l'imparfait car c'est de moins en moins vrai) de publier une photo informative sans légende.

D'ailleurs, une légende est une sorte d'archétype de ce principe de proposer un contenu, en loccurence de l'information, sous deux formes différentes...

Il y à en tout cas quelque chose à défricher dans cette direction et de ce point de vue une conteneur comme object est le client idéal pour ça...

Bon je retourne à ma moquette... Smiley lol

Jean-Pierre
Modifié par jpv (23 Jun 2007 - 00:18)

^
Laurent Denis
#
7979 Posts
Lanza a écrit :
Je remarque que plus le temps passe, plus Laurent parle pour en dire moins. Je me demande si c'est parce qu'il essaie d'en dire plus avec moins de mots ou si c'est juste parce qu'il boude à force qu'on lui reproche de tenir un langage inintelligible pour le commun des mortels. Smiley lol


Simple quesion d'économie de moyens, admirablement illustrée par l'intervention attendue de Jean-Pierre Smiley ravi

Cela dit, je rebondirai sur ce qui vient d'être excellement dit:

L'image est très rarement l'information, comme on commence peu à peu à le percevoir ici (attention, être et apporter sont deux verbes bien différents).

Mais lorsqu'elle l'est ? Lorsque la démarche du "Il faut se donner les moyens d'éviter les alternatives aux images" n'est évidemment plus pertinente ?

Une (mauvaise) approche, celle qui est historiquement la démarche canonique en HTML, consiste à informer sur le contenu d'une ressource de format X (l'image) via une ressource combinée de format Y (le texte alternatif alt, la description longdesc). Mauvaise, car:
- faisant peser sur ceux qui produisent le format HTML la charge de gérer une information qui ne relève pas de leurs compétences (ce n'est pas aux rédacteurs de faire ou de vérifier ou de traiter d'une quelconque manière des alternatives de ce type, c'est au photographe/graphiste ou à l'archiviste).
- créant de la complexité pour les agents utilisateurs et les aides techniques (mapper l'image et des données textuelles qui lui sont externes).
- finalement problématique ou laborieuse pour l'utilisateur en bout de chaîne.

Une (bonne) démarche, s'il reste un petit peu de moquette, consistera à laisser chacun jouer son rôle dans le workflow:
- le photographe, puis surtout l'archiviste, produisent des données exif étendues
- le graphiste... ah bah, tiens: SVG apparaît (malgré la dérive totalitaire démente de la spec actuelle, qui est un autre problème).
- le rédacteur... rédige du texte et se contente d'inclure l'image. Son outil peut alors gérer l'alternative adaptée au contexte, de manière transparente, celle-ci étant alors dramatiquement simplifiée, puisqu'en gros, c'est une simple invite adressée à l'utilisateur pour qu'il passe à ce que produit le point suivant.
- l'UA et l'aide technique exploitent, selon la demande de l'utilisateur et de manière conforme à ses besoins/préférences, soit uniquement l'alternative, soit les métadonnées exif étendues. Ou passent le relais à l'outil client de visualisation idoine (plugin... tiens, on retombe sur l'un des atouts majeurs d'object, qui ne me limite plus à la seule capacité de traitement graphique du navigateur). Et les API pointent le bout de leur nez.
- l'accessibilité commence à prendre son sens de démarche globale

Mais mais mais... entends-je: ces données EXIF auront nécessairement été crées avant la mise en contexte de l'image ! Elles ne peuvent pas être pertinentes ?

Oui, mais non (relisez depuis le début, c'est à dire le message de Jean-Pierre). Nous sommes:
- dans une problématique ciblée où l'image est l'information en elle-même. le problème contextuel n'a pas disparu, mais il est considérablement plus ténu.
- dans un workflow dédié à la publication d'un contenu déterminé: l'archiviste a les moyens d'ancitiper la pertinence de ses métadonnées. L'outil a les moyens de décliner des exif/SVG liées à des scénarios (un autre gros mot: XML et format-pivot).

On commence à approcher les choses dans les termes appropriés, c'est à dire en ressources (Une page web est un agrégat de ressources et de fnctionnalités d'interface, formant elle-même une sorte de meta-ressource, ou de ressource riche). Et chaque ressource intègre la problématique d'accessibilité de manière optimale à son propre niveau. On fait donc intervenir une part nécessaire de modularité de l'accessibilité des contenus. ça n'a rien de transcendant ni d'original, c'est simplement WCAG2 un peu aidée à expliciter sa propre logique.

<edit class="soupir">(C'est aussi pourquoi, à mon sens, le RGAA, même inscrit dans une démarche WC2G1.0, ne devrait pas avoir à se prononcer sur les dispositifs d'accessibilité liés aux contenus multimédia en fonction de problématique type site de l'INA, c'est à dire agrégateur de contenus. Il en est de même de la question des zones d'espaces publics dans les sites concernés par le RGAA. Il ne s'agit pas du tout d'exceptions ou de dérogations, mais de règles qu'on chercherait à prononcer à mauvais escient).</>

Mais il ne reste plus rien de la moquette.
Modifié par Laurent Denis (23 Jun 2007 - 10:33)

Ne parlons pas de choses nouvelles. Commencez par ne pas détourner CSS de son objet, ce que vous faites immanquablement avec des techniques sexy qu'on enseigne ici.

^
Patidou
#
2632 Posts
Et hop, encore une discussion dans mes favoris Smiley jap

Avertissement : il est inutile de m'envoyer des mp pour demander de répondre à vos sujets sur le forum. Je répond si j'ai un élément de réponse et si j'ai le temps. Merci d'avance.

^
Christian Le Bouler
#
3109 Posts
Laurent Denis a écrit :

Mais il ne reste plus rien de la moquette.


M'en fiche, j'ai ma propre réserve...

Bon, on va y passer des heures sur les deux posts précédents, ce qui est bien c'est que plus c'est expliqué plus c'est difficile Smiley cligne

Je ne suis pas trop du genre à dire merci mais là sans hésitations c'est un très grand "MERCI !"

jpv a écrit :

Il y à en tout cas quelque chose à défricher dans cette direction et de ce point de vue une conteneur comme object est le client idéal pour ça...


Oui c'est une chose que me disais depuis longtemps. En fait depuis que Laurent avait évoqué le fait que <img> était un cas très particulier (sans avoir de raison particulière de l'être, sauf historique si je suit bien) par rapport à l'incorporation d'objet dans le document via la balise <object>.
Et d'ailleurs on pourrait bien opter pour un principe de développement qui substitue à toute <img> un <object data="telle image.jpg" etc...></object>

Avec une péripétie un peu particulière néanmoins c'est que :

<edit>

Aucune péripétie finalement comme me l'a fait remarquer Jean-Pierre un peu plus loin dans la discussion

</edit>
Modifié par Christian Le Bouler (25 Jun 2007 - 15:50)

^
knarf
#
1091 Posts
Bonjour,

Ouiiii y'en à marre c'est toujours pareil, non j'déconne Smiley lol Smiley confused

Bon c'est long je m'y suis repris à plusieurs fois mais plus c'est long.....(enfin c'est ce qui se dit) Smiley cligne

Donc une utilisation de la balise object avec des données Exif/svg de l'élément qu'elle porte liée a des scénarios XML qui pourraient être utilisés par le rédacteur en fonction du contexte.

Si j'ai bien tout suivis, est-ce qu'il n'yaura pas un peu le même problème qu'avec la balise img, à savoir le choix pertinent ou nom du scénario par le rédacteur et si oui ou non il faut en utiliser un?

Un petit peu comme pour l'image et la nécéssité d'un texte alternatif ou pas et le choix pertinent de ce texte alternatif en fonction du contexte?

Edit:

Sinon pareil que christian sur l'utilisation de la balise object dans le code

Edit2:

Je suis passé à coté de cela:

a écrit :
l'UA et l'aide technique exploitent, selon la demande de l'utilisateur et de manière conforme à ses besoins/préférences, soit uniquement l'alternative, soit les métadonnées exif étendues.


Donc cela réponds en partie à la question. Smiley lol
Modifié par knarf (23 Jun 2007 - 18:31)

^
jpv
#
757 Posts
Christian Le Bouler a écrit :


Avec une péripétie un peu particulière néanmoins c'est que :

<p><img /></p>


est possible dans les DTD

et que

<p>
<object data="telle image.jpg" etc...></object>
</p>


ne l'est pas.



Heu... je ne vois pas ce qui interdis d'insérer un élément object dans un paragraphe.

A ma connaissance object est de type inline...

De quelle DTD parles tu ?

Jean-Pierre

^
Christian Le Bouler
#
3109 Posts
jpv a écrit :


A ma connaissance object est de type inline...



Ah, dans ce cas au temps pour moi, c'est une grossière erreur de ma part.

^
Hermann
#
4523 Posts
Bonjour,
merci à vous deux (Laurent et JPV bien sûr) pour vos intervention riche d'enseignement malgrés quelques points obscures.
a écrit :
- l'UA et l'aide technique exploitent, selon la demande de l'utilisateur et de manière conforme à ses besoins/préférences, soit uniquement l'alternative, soit les métadonnées exif étendues.

Intéressant... A quoi correspond les aides techniques?
Qu'elles ont les User Agents qui pourraient exploiter les données EXIF?

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>

Modifié par Hermann (25 Jun 2007 - 16:19)

^
Arsene
#
1205 Posts
Magnifiiiiique et merci à Laurent et JPV Smiley biggrin

Concernant <object> :

a écrit :
Les éléments OBJECT imbriqués sont utiles pour offrir des solutions de repli au cas où l'agent utilisateur ne reconnaîtrait pas certains formats. Par exemple :

<OBJECT data="barrenavigation.png" type="image/png">
<OBJECT data="barrenavigation.gif" type="image/gif">
texte décrivant l'image...
</object>
</object>

Si l'agent utilisateur ne reconnaît pas le format PNG, celui-ci essaye de restituer l'image GIF. Si celui-ci ne reconnaît pas le format GIF (par exemple, parce qu'il s'agit d'un navigateur vocal), il se rabat par défaut sur la description textuelle fournie en contenu de l'élément OBJECT interne.


Extrait de www.la-grange.net

... ce qui ne solutionne pas tout, et notamment pas la question de la relation contextuelle créée entre le contenu des balises <object> et les textes l'entourant, question qui relève effectivement d'une stratégie éditoriale.

D'autre part <object>, d'un point de vue opérationnel, inverse un peu la règle du jeu en disant à l'UA : "si tu ne peux pas faire ceci (restituer une image par ex.) alors fais ceci (affiche un texte)". Si un monde idéal existait tout ça se présenterait probablement en ordre inverse : "si tu peux faire ceci (afficher un texte) alors essaie plutôt de faire cela (afficher une image de remplacement)". 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.

J'ai droit aussi à ma part de moquette ???

^
Pages :