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. 
Simple quesion d'économie de moyens, admirablement illustrée par l'intervention attendue de Jean-Pierre
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)
</> 
