LaurentDenis

La présence de longdesc est annoncée ("Image Description") lors de la lecture courante. Le lien est activable à ce moment à l'aide du clavier (par exemple tout simplement avec la touche Entrée dans IBM HPR, comme les autres liens)

Alors disons-le clairement : <strong> et <em> n'apportent actuellement rien de plus que <b> et <i> pour l'accessibilité. Et potentiellement non plus d'ailleurs : rendre un <b> avec une intonation différente du reste du texte sera tout aussi logique que de le faire pour <strong>... Ce ne sont donc pas des éléments d'accessibilité (au sens de <label> par exemple).

Longdesc est à présent supporté par Jaws, IBM HPR et pwWebSpeak. C'est un progrès important de ces outils : ne pas utiliser longdesc, mais uniquement un D-link détourné ou non, est-ce vraiment la meilleure façon d'encourager ce type de progrès ?

Monique : quels lecteurs d'écran exploitent-ils <strong> ou <em> actuellement ? Mais surtout, finalement, cette notion de "mise en exergue", d'emphase, d'importance, etc... est tout de même passablement trop vague. - Est-ce à dire que son contenu doit être spécifiquement pondéré lors d'une indexation par un moteur de recherche ? Avec quelle poids par rapport aux titres ? Par rapport aux instances de définition ? Par rapport aux mots clés en méta-donnée ? Faut-il mettre tout cela en rapport (sans compter ce que j'oublie sans doute) pour que ces différentes emphases forment un contenu cohérent ? - Est-ce à dire qu'il doit être spécifiquement retenu lors d'une synthèse automatique du document ? Là encore, avec quel poids ? - Est-ce à dire seulement qu'il doit être rendu, quel que soit le media, sous une forme qui attire l'attention sur lui ? Auquel cas, ce n'est rien de plus qu'un élément de présentation, que celle-ci soit visuelle (graphique ou textuelle), auditive ou autre. Plus le temps passe, et je range strong et em comme dans les éléments "manqués" de HTML4.01, insuffisamment définis pour être utilisés sans erreur, ou pour apporter véritablement un sens supplémentaire au document. Je retiens finalement ce conseil : en cas de doute, n'utilisez ni <em> ni <strong>. Utilisez <b> ou <i>, ou encore un style CSS. C'est le meilleur moyen de ne commettre que des erreurs entraînant les domages les plus limités

Aïe Quelques problèmes de démarche sur lesquels tu devrais, AMHA, te pencher avant de pourquivre: Ton menu déroulant me semble reposer sur des techniques DHTML qui ont largement montré leurs limites: - javascript obstructif, c'est à dire site non navigable sans javascript. - javascript incompatible avec de nombreux navigateurs, car non standard - complexité inutile de l'interface avec menu déroulant+popup, dissuasive pour l'utilisateur - inaccessibilité de la solution Tu réduis finalement beaucoup ton audience potentielle. Quelques liens utiles: - Faire un menu dynamique ouvert et accessible - Créer des pop-up intelligentes

bieuzent, pourrais-tu être un peu plus précis et descriptif ? Ce qui ne "va pas" sous IE n'est pas si évident que cela. S'agit-il des bordure de la partie "acueil / actualité / espace privé" ? Titag : il est tout à fait correct d'omettre l'unité pour la valeur 0.

Un menu contextuel s'ouvre au fur et à mesure de la frappe, avec pour l'élément en cours tous les attributs existants, ainsi que les valeurs type ou normalisées quand c'est possible. Sinon, les icônes de menus correspondants aux balises permettent d'insérer diverses syntaxes-types (personnalisables) pour chaque élément.

Un petit rectificatif à propos de cette page : mon IE ayant par défaut le javascript désactivé... je n'avais pas vu à quel point les javascript de ce site étaient une horreur Après enregistrement de la page (avec ses images, ses css, ses scripts et tout) pour tester ma petite idée ci-dessus... l'affichage de la page locale m'a provoqué une superbe plantage généralisé d'Opera, d'IBM HPR et d'IE, avec applications gelées et impossible à tuer... Je n'aime décidément pas le javascript

A la réflexion: c'est un exemple vraiment intéressant: - une page très bien conçue pour une consultation visuelle - qui passe bien quand on l'écoute - sauf le petit plus visuel que sont les images et leurs légendes... En fait, il faudrait, dans un monde idéal où les lecteurs d'écran supporteraient le media speech (ou aural), faire une petite adaptation de contenu via CSS: @media speech { p.legende, img.legende { display: none } } Dans l'immédiat, je serais presque tenté de supprimer les légendes "en dur", d'utiliser leurs intitulés comme contenu de l'attribut title, et de faire apparaître des légendes uniquement visuelles via un contenu généré CSS: img.legende:after { content: attr(title); display: block; } <edit>Correction : attribut title et pas alt, puisqu'on veut faire disparaître ces images. On garderait des alt=""</edit>

Hum... Cet exemple n'est pas vraiment "simple" Effectivement, sur cette page, les légendes seules n'apportent aucune information pertinente à l'écoute de la page, et renseignent peu sur les images elles-mêmes (particulièrement la dernière image "MSD, laboratoire pharmaceutique fondé sur la recherche"). Mais des alt descriptifs n'apporteraient pas plus d'information "utile" pour enrichir le texte principal de la page. Le problème de fond est que, dans la conception de cette page, les images nécessitent une longue analyse pour dégager une info. AMHA, on a affaire à un cas où des descriptions longues seraient plus appropriées (longdesc, lien D, etc). Mais ce n'est manifestement pas le propos de cette page (qui n'est pas un cours d'histoire industriel approfondi ). En l'état, la page me semble claire et très compréhensible grâce à son texte principal. L'absence de alt descriptifs n'est vraiment gênant que dans les lecteurs d'écran qui ne signalent pas la présence d'image avec alt="" (IBM HPR dans le réglage par défaut, par exemple). Dans ce cas, la lecture des légendes surprend. Ce serait un argument en faveur d'attributs alt renseignés... Vraiment pas évident, j'avoue...

On ne peut pas, AMHA, fixer une règle générique. C'est au cas par cas, contenu par contenu, et en testant dans un lecteur d'écran, qu'on peut déterminer ce qui donne le plus de sens à un document donné lorsqu'il est écouté. Trop de choses dépendent de la formulation propre à chaque contenu.

A l'usage, l'important me semble surtout de bien préciser le fait qu'un texte est la légende d'une image, que celle-ci soit évacuée par un alt vide ou qu'elle soit rendue par un alt descriptif. En effet, ce sont des indices visuels qui permettent aux lecteurs "voyants" de repérer la légende comme telle (position par rapport à l'illustration, typographie/alignement différents du reste du texte, etc...). A l'écoute, s'il n'y a aucune information identifiant ce texte comme étant une légende, le sens peut devenir peu évident. Au mieux, AMHA, la légende doit utiliser une formule faisant référence à la présence de l'illsutration (L'image ci-dessus représente ...). Auquel cas, la présence d'un alt descriptif est tout à fait justifié si la légende elle-même n'est pas une simple répétition de celui-ci, bien-sûr.

lol . j'aurais pu citer ce véritable cas d'école, en effet (Bien sûr, vous avez tous déjà deviné qu'il n'est en ligne que pour fournir un exemple à des fins pédagogiques, n'est-ce pas ). Bon, je ---> []

Pour trouver la meilleure réponse à tes questions, je te conseille une petite séance de dissection anatomique d'un fil RSS Tu trouveras l'explication simple de la structure et du fonctionnement d'un fil RSS0.91 similaire à celui du Hub dans Introduction à la syndication de contenu avec RSS sur OpenWeb. En bref, pour l'essentiel : Le fichier unique d'un fil RSS commence par les informations sur le "canal" (<channel>) correspondant au site (ou ici à la section du site) dont il est question: - un titre, ici Les publications de Webmaster Hub - l'URL de la ressource Web à laquelle se rapporte le fil, ici [i]http://www.webmaster-hub.com/publication/ - éventuellement une description que le lecteur RSS peut afficher. Ici, celle-ci est vide. Ensuite, le fichier se poursuit avec les news successives, chacune étant un <item>, à son tour caractérisé par: - Un titre affiché par le lecteur RSS : Michael James, de la société Mirago "Nous misons sur nos partenaires pour développer notre visibilité - Une description affichée par le lecteur RSS : Une interview de Michael James, Responsable du Développement Commmercial pour l'Europe de la société Mirago. - diverses informations de date, de format, de langue, d'auteur, etc. - et le lien vers la page HTML du Hub où se trouve la publication concernée par la news [i]http://www.webmaster-hub.com/publication/article125.html Il n'y a donc qu'un seul fichier RSS, quelque-soit le nombre de news annoncées (généralement limité à un maximum d'une quinzaine). Lorsque le fil est "plein" et qu'une nouvelle news doit être ajoutée, la news la plus ancienne est supprimée du fichier. Maintenant, pour la différence entre ce qui apparaît dans ton navigateur et ce qui apparaît dans ton lecteur RSS quand tu visualise le fichier RSS: - le navigateur ne sait pas interpréter le format RSS du fichier. Il ne traite donc pas le document et l'affiche comme du XML (arborescence, affichage des tags XML ou tu texte brut, etc, selon les navigateurs et leur configuration). - le lecteur RSS, lui, sait exploiter le balisage RSS du fichier : il exploite les infos générales du canal d'un côté, et les infos de chaque item d'un autre côté. Ce qui crée parfois la confusion, c'est que les descriptions d'item peuvent être: - soit du texte brut - soit du texte formaté HTML, généralement extrait de la source de la page HTML à laquelle se rapporte la news. Les lecteurs RSS ne savent pas exploiter ce balisage HTML, mais ils font appel au moteur HTML du navigateur Web auquel ils sont associés quand il s'agit d'extentions de celui-ci, ou au moteur HTML du navigateur par défaut quand il s'agit d'applications indépendante (FeedDemon). Cette inclusion de balisage HTML dans les fichier RSS est parfois problématique, car elle nécessite que ce balisage soit encodé pour ne pas perturber le parser XML du lecteur RSS, et elle produit parfois des effets indésirables à l'affichage : il est en particulier déconseillé de mettre du balisage HTML dans les titres d'item. Un titre du type Mon article sur la balise <foo> et la balise <bidule> sera fréquemment rendu par un lecteur sous la forme Mon article sur la balise et la balise...

Le fil devrait effectivement préciser son encodage iso-8859-1 dans le prologue XML (bien que celui-ci soit précisé dans l'en-tête HTTP Content-Type: text/xml;charset=iso-8859-1)

Tellement accessible, en effet, qu'un document vraiment XHTML suscite chez les navigateurs utilisés par les handicapés (IE couplé à Jaws, HPR, etc) une jolie petite fenêtre "voulez-vous télécharger ce document ?". Ne parlons pas des navigateurs textes à qui application/xhtml+xml donne des vapeurs. Sérieusement, quel est l'imbécile qui a répandu cette légende selon laquelle XHTML favoriserait l'accessibilité ? Si on pousse un peu, c'est le contraire, en fait. Se contenter de faire du HTML4.01, c'est déjà beaucoup, et c'est tout ce que requiert l'accessibilité en matière de format structurel.

Denis, tu oublies une part du problème, en parlant de popularité googlelienne : la barrière ethnologique. Un blogueur comme toi ou moi appartenons clairement à une des tribus de la blogosphère. Notre manque d'originalité (j'espère ne pas te vexer) nous assure d'être lus, d'être liés, et finalement d'être googlelisés. Sébastien, lui, devrait convaincre notre petite tribu très endogène (tu en parlais récemment) s'il veut y être admis (ce qui n'est pas une nécessité pour lui, en fait). Ou alors, fonder sa propre tribu, avec son totem et ses tabous (il en faut pour être populaire). Bien-sûr, connaissant un peu Sébastien à travers ce forum, je suppose qu'il s'en f... comme de l'an quarante et qu'il se contentera de faire un très bon blog au contenu tout neuf

Ma réponse tient en quelques syllabes: Je préfère l'anémélectroreculpédalicoupeventtombrosoparacloucycle. C'est beaucoup plus joli, pour le coup historiquement barbare à souhait... Mais au fait, vous savez ce que ça veut dire ? (Désolé pour le hors sujet flagrant, mais celui-là, je rêvais depuis des siècles de le caser quelque-part. La tentation fut trop belle )

Bienvenue sur ce forum, Kenny. Toutefois, l'usage étant ici de ne pas utiliser d'images en signature, la tienne a été modifée en conséquence

On a souvent dit, ou répété d'après X qui l'avait lu chez Y, etc... que les navigateurs textes étaient de bons simulacres en matière d'accessibilité (ou de sémantique, tiens, aussi : vous savez, Google est un 'utilisateur aveugle' ?) je crois de plus en plus que c'est une légende urbaine très confortable, dans les deux cas Finalement, je me demande dans quelle mesure nous ne sommes pas aujourd'hui dans un cas comparable à celui de la grande époque NS4 v. IE4 (toutes proportions gardées) : - pour les aides à l'accessibilité du type lecteur d'écran, promouvant des implémentations propriétaires en diable et totalement indifférentes à la notion de standard - dans un autre domaine (mais c'est trop évident pour ne pas le dire ici), pour les navigateurs embarqués sur les mobiles, qui se comportent de manière similaire. Bref, les acquis actuels des standards ne sont guère qu'une petite partie de l'iceberg, et ce qui est en dessous représente encore beaucoup à faire

Il faudra trouver le temps de revenir sur ce site, d'en analyser de près les techniques et les problèmes éventuels, car il me semble très instructif. Mais pour l'instant: - display: none, même placé dans une feuille de style explicitement réservée à l'écran, sera appliqué par les lecteurs d'écrans dans un certain nombre de cas. Il est très difficile de définir des critères généraux, car les cas de figures sont très variés en fonction du mode de lien avec la CSS, du lecteur d'écran, de la configuration utilisateur. - il n'existe à l'heure actuelle aucun lecteur d'écran ou navigateur vocal (à l'exception éventuelle du confidentiel Emacspeak, à confirmer) qui tienne compte d'une règle réservant des styles au media auditif : les descripteurs de media aural (CSS2) et speech (CSS3) ne sont pas implémentés. Même Opera 8.0 (le plus récent et le plus orienté "Standards") implémente les propriétés CSS auditives mais pas le descripteur de media lui-même (c'est en fait une nécessité pour qu'il puisse lire ce que l'utilisateur sélectionne à l'écran). Il faut bien se souvenir que les lecteurs d'écran (Jaws, Windows Eyes) sont à l'heure actuelle à peu près totalement indifférents à l'accessibilité "normalisée" et à l'approche WAI-W3C. IBM HPR est déjà plus ouvert à cette perspective, mais ce n'est qu'une ouverture...

mdr J'oubliais de préciser que je n'utilise IE (et donc les lecteurs d'écrans) qu'en mode totalement paranoïaque : je ne profite donc ni des activeX ni des javascript du site en question... Et c'est amusant, mais ça marche beaucoup mieux comme ça

Il faut bien que ces liens soient quelque-part Qu'ils soient en tête de page ou en fin de page, ils n'en formeront pas moins une liste de liens. Sans doute est-elle un peu longue, et pourrait-elle être dotée de plus de liens slik navigation (Le site du Grand Châlon est beaucoup mieux fait de ce point de vue). Mais je suis sur le site du Tram en ce moment avec IBM HPR, et je ne rencontre pas de liens erronés... sauf justement le seul lien d'évitement de la navigation qui, dans les pages intérieur, semble me ramener en boucle sur le menu Curieux... Heureusement, la navigation de tableau en tableau, ou de titre en itre, permet de se déplacer facilement dans la page.

Oups. Contrairement à ma première impression, erronée, il y a bien un lien d'évitement. (Comme quoi, ce type de test ne se fait pas en 5mn et nécessite bien une expertise justifiant des organismes comme Accessiweb

Excellente idée ! Du coup, tu inaugures la nouvelle catégorie 'Référencements et standards' de mon lecteur RSS