1174 sujets

Accessibilité du Web

Pages :
(reprise du message précédent)

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 ???
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 Smiley cligne )

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... Smiley smile

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... Smiley smile

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... Smiley smile

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 Smiley cligne

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é... Smiley smile Smiley cligne

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?
jpv a écrit :

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 Smiley cligne


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.
Modifié par Christian Le Bouler (25 Jun 2007 - 21:27)
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.

Smiley rolleyes 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)
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, 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.


Sur le (X)HTML actuel, cela reste absolument non problématique.

Sur les versions à venir ben on verra, ce qui semble s'ébaucher te donne pour l'instant raison.

Perso rien de trop à en dire puisque cela conforte ma conceptualisation du balisage block.

. Block "type 1" comme séquençage du flux de niveau texte. Modèle = <p>, plus avatars et particularismes.

. Block "type 2" comme séquençage d'un flux de niveau block. Modèle = <div>, plus avatars et particularismes.


Enfin, on verra bien dans l'avenir... On est loin d'y être quoiqu'il en soit.
Modifié par Christian Le Bouler (25 Jun 2007 - 22:49)
Hermann a écrit :
Smiley rolleyes D'ou tu sors ça?

Une légende urbaine qui traine. Smiley smile

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
Exact, au temps pour moi, je viens de vérifier. Mince alors, j'en étais persuadé. D'où qu'elle venait cette erreur que j'ai eue il y a 6 mois alors ?

Edit : trouvé, j'étais à l'interieur d'un formulaire. Du coup, j'ai cru... Bon, je vais me coucher puisque c'est comme ça.
Modifié par Lanza (26 Jun 2007 - 00:25)
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... Smiley cligne

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... Smiley cligne

Jean-Pierre
Florent V. a écrit :
Ah oui, le lien vers le site :
http://www.ameli.fr/


Bonjour,

J'ai participé au développement du site et on a vraiment pas mal travaillé sur le coté accessibilité du site. On a pas mal profité du site de alsacreations, autant le dire Smiley biggrin

--
Maxime
Pages :