Aller au contenu

LaurentDenis

Membres
 Afficher le profil  Parcourir son contenu

  • Compteur de contenus

    1 281

  • Inscrit(e) le

  • Dernière visite

 Type de contenu 

Tout ce qui a été posté par LaurentDenis

  1. LaurentDenis
    S'il s'agit de pseudo-frame, il y a bien une première occurence qui est la première mention dans l'ordre HTML brut : c'est cette premire occurence-là qui est visée par les conseils d'accessibiliré recommandant de signaler via un title le sens d'une abréviation "lors de sa première occurence". Il y a un truc bien qui s'appelle un glossaire. On peut lier l'abréviation (dûment balisée comme telle avec <abbr></abbr> au glossaire du site, ajouter dans le <head> des pages un lien relatif vers celui-ci, et surtout faire un beau lien "glossaire" dans son menu de navigation. Tu dois d'abord préciser tes intentions: - fournir l'info systématiquement à tous tes utilisateurs ? Dans ce cas, en effet, l'usage systématique du <abbr title="..."> est la seule solution. - fournir l'info "ceci est une abréviation" aux lecteurs d'écrans et navigateurs vocaux ? Dans ce cas, il faut savoir qu'à l'heure actuelle, les medias oraux ignorent superbement ce beau balisage, et utilisent uniquement leur propre moteur linguistique pour déterminer à leur manière si un vocable est une abréviation, et si celle-ci est éventuellement connue et remplaçable par son intitulé complet. Pour un exemple simple, voir http://blog-and-blues.org/weblog/2004/08/2...u-balisage-html (exemple avec l'abréviation "USD") - autres intentions ? Baliser les abréviations ne coûte rien et satisfait aux normes <abbr>(X)HTML</abbr> et <abbr>WCAG</abbr> actuelles. Renseigner leur title, c'est autre-chose... D'autre part, s'adapter au contexte ou au public, c'est faire l'éternel pari très hasardeux et très tentant sur l'utilisateur lambda, ce qu'il est, ce qu'il n'est pas, ce qu'il aime et ce qu'il n'aime pas, ce dont il a besoin, ce qu'il sait faire, etc. La norme est claire: les abréviations doivent être balisées comme telles. Optionnellement, leur signification peut être renseignée. Elle devrait en effet être renseignée sur leur première occurence dans le document. Mais cela n'épargne pas la peine de faire un glossaire en bonne et due forme. Enfin, à propos de la distinction acronyme/abréviation/sigle/patati/patata: - ce sont des distingo passionnants, mais hors sujet. "acronym", "abreviation" ont ici un sens très spécifique (hélas imprécis), purement normatif dans une sphère donnée, celle du HTML.Inutile de s'appuyer sur les dictionnaires terminologiques usuels. C'est un sens arbitraire qui est utilisé ici, et non le sens courant de ces termes. - la distinction abbr/acronym relève essentiellement de la présentation auditive, et non du sens (propriété CSS2 speak, voir http://blog-and-blues.org/weblog/2004/08/2...a-760-preview-1 ). Elle n'a rien à faire en (X)HTML... ce dont XHTML2.0 va selon toutes probabilité tirer la leçon
  2. LaurentDenis
    J'oubliais une lecture passionante sur les hacks : le billet À propos de la popularité des hacks de l'ami Denis Boudreau, et les abondants commentaires qu'il a suscité.
  3. LaurentDenis
    Dans ce domaine, j'aime beaucoup cette réflexion d'Arve Bersvendsen, qui pratique justement le moins possible les hacks... et souvent les commentaires conditionnels : ( http://www.blog-and-blues.com/2004/mars/13..._philosophy.asp )
  4. LaurentDenis
    Ce hack a été récemment popularisé par Trenton Moss ( http://www.evolt.org/article/Ten_CSS_trick..._know/17/60369/ ), et critiqué par Tantek Celik ( http://tantek.com/log/2004/09.html#d07t1434 ). Pour un aperçu de tout cela en français, voir http://blog-and-blues.org/weblog/2004/09/0...ossible-pour-ie , et en particulier les commentaires d'Eric Daspet. Le principe : IE a un bug qui fait qu'il ne respecte pas la prépondérance de !important quand une même propriété CSS est répétée dans la même règle. On peut ainsi spécifier deux valeurs, l'une pour IE, et l'autre pour le reste du monde (en principe) : p { color: green !important; color: red; } - IE "oublie" le !important et applique la dernière occurence de la propriété (couleur rouge). - les autres navigateurs respectent le !important et applique la propriété auquel il est appliqué (couleur verte) Le problème : un !important dans une CSS auteur l'emporte sur une règle "normale" d'une CSS utilisateur. L'utilisateur doit lui-même ajouter !important à sa propre feuille de style user pour surclasser le style auteur. Ce serait un peu gênant pour l'accessibilité... dans une certaine mesure (le premier principe d'une CSS user est de mettre des !important partout où... c'est important ).
  5. LaurentDenis
    La différence de taille est due à deux polices de caractères différentes (Arial et Verdana).
  6. LaurentDenis
    En bref: - mes archives mensuelles étant incomplètes, le lien exact vers l'article de Blog & Blues mentionné par Monique est http://blog-and-blues.org/weblog/2004/10/2...un-document-web - l'utilisation simultanée et systématique de lang et xml:lang n'est pas une règle normative. C'est un conseil de la spécification XHTML1.0 pour assurer la compatibilité du code XHTML lorsqu'il est traité comme du HTML par des outils (navigateurs, traducteurs, lecteurs d'écrans, robots d'indexation...) qui ne savent pas lire du XML. Et les traducteurs, lecteurs, robots... actuels ne savent pas ce que c'est que du XHTML servi comme XML. - lang ne doit donc pas être utilisé lorsque le XHTML est servi en tant que XML à un outil capable de le comprendre (navigateurs supportant application/xml+xhtml). - xml:lang seul n'a aucun sens lorsque XHTML est servi comme du HTML, cet attribut n'existant pas dans les normes HTML4.01. - Actuellement, beaucoup de (la plupart des ?) moteurs de traduction actuels sont soit indifférents aux indications de langue, soit utilisent leurs propres algorythmes de détermination de la langue. Essayez de faire traduire en français par les traducteurs automatiques un texte anglais comportant des sections en français dûment signalées par lang et xml:lang... Vous aurez des suprises amusantes. - Actuellement, une partie seulement des lecteurs d'écrans exploitent l'attribut lang. Il me semble qu'aucun ne connaît xml:lang, ceci étant lié au fait qu'IE, généralement associé avec eux, l'ignore lui-même puisqu'il ne sait pas traiter du XHTML en tant que XML. Donc, dans un souci d'accessibilité immédiate, l'usage systématique de lang (lorsqu'il est autorisé) est essentiel, AMHA. Enfin, pour фифи (fifi), la langue doit effectivement être indiqué pour les deux portions de contenu: - pour indiquer la langue de traitement de l'ensemble. - mais aussi pour styler la police de caractère spécifique de фифи (il faut un span autour). Il faut savoir cependant que de nombreux navigateurs ignorent la pseudo-classe :lang (Opera, IE) et que d'autres ignorent les sélecteurs d'attributs du type span[lang=...] (IE). Il faut donc passer par un attribut class. Voir http://www.w3.org/International/questions/qa-css-lang (en anglais, mais les exemples sont très clairs)
  7. LaurentDenis
    La démarche est un peu surprenante, en fait, puisqu'elle recourt à un object Flash et à javascript. Cela a le mérite de "fonctionner" dans un navigateur doté du plugin idoine. Mais sur le fond, on est très loin de ce que peut réaliser une approche plus innovante du type X-Voice, c'est à dire faisant appel à la modularité XHTML pour réaliser une page entièrement interactive à la voix.
  8. LaurentDenis
    Pour les bases de la mise en forme des tableaux, voir Habillage de tableaux avec des CSS
  9. LaurentDenis
    Eh bien... un webmestre se mettant aux standards (comme le dit ta signature) renonce à utiliser <marquee>, qui est un élément propre à Microsoft, supporté de facto par de nombreux navigateurs, mais invalide. D'autre part, les textes défilants posent des problèmes d'accessibilité importants. Il est esentiel de permettre à l'utilisateur d'interrompre le mouvement et de disposer s'il en a besoin d'un texte statique complet. Du point de vue de l'ergonomie de la page, le texte défilant que tu décris est plutôt gênant. Enfin, la réponse technique à ton idée de textes se croisant est à chercher dans Flash.
  10. LaurentDenis
    Cet affichage trop petit est le résultat de ta feuille de style : body { ... font-size:0.75em; } Les em étant relatifs à la taille par défaut sur la configuration de l'utilisateur, cela donnera : - un corps de base de 12px dans une configuration utilisateur de 16px; - un corps de base de 10px dans une configuration utilisateur de 14px - un corps de base de de 9px dans une configuration utilisateur de 12px; - etc. Certains utilisateurs auront donc un afffichage très réduit. De plus, l'effet d'héritage de la taille de police va réduire encore plus la taille finale pour certains éléments de ta page: .footer { font-size:0.8em; ... Ton pied de page sera affiché à 80% de la taille par défaut du body, autrement dit: - une taille finale de 9px dans une configuration utilisateur de 16px; - une taille finale de 7px dans une configuration utilisateur de 12px; D'autre part, tu ne spécifie qu'une seule police de caractères: font-family:"Arial", sans préciser de famille générique sur laquelle se rabattra le navigateur si la police Arial est absente chez l'utilisateur. Ceci peut conduire, selon les polices et les réglages de l'utilisateur, au choix finale d'une police dont l'oeil est particulièrement réduit (l'oeil étant la taille d'une lettre sans jambage, comme le o). Dans de l'Arial en taille 10px, cet oeil n'est que de 6px, ce qui est déjà à la limite du lisible. Si le navigateur se rabat sur une police à empattement, l'oeil sera encore plus réduit: du Times New Roman a un oeil de 5px en taille 10, et devient franchement illisible. Il serait donc prudent: - de réévaluer la taille par défaut fixée pour le body. Voir http://blog-and-blues.org/weblog/2004/05/24/214-font-size-em et http://edu.apinc.org/article70.html - de mieux préciser tes choix de polices de caractères, en indiquant obligatoirement une famille générique en fin de liste (sanserif), et peut-être en favorisant des polices plus lisibles que l'Arial : voir http://edu.apinc.org/article67.html
  11. LaurentDenis
    le 'Jusqu'à ce que les agents utilisateurs..." pose une question redoutable: jusqu'à quel point faut-il faire à la place des utilisateurs le choix qu'ils sont en mesure de faire ou surtout (c'est là l'essentiel) d'apprendre à faire : - choix d'outil plus performant que le navigateur qui ne supporte pas les CSS alternatives, par exemple - choix d'apprendre à se servir de leur outil. Bref, c'est une remise en cause du principe omniprésent selon lequel l'utilisateur a toujours raison, surtout quand il a tort par ignorance. Pas simple...
  12. LaurentDenis
    La premiere fois sont chargées: - toutes les CSS permanentes de tous les medias - toutes les CSS préférées de tous les medias - toutes les CSS alternatives si le navigateur supporte cette fonctionnalité. Que ces styles soient chacun répartis en une ou plusieurs feuilles ne change rien de ce point de vue. L'ensemble sera disponible et ne sera plus téléchargé (si la config utilisateur y autorise) pour le reste des pages du site.
  13. LaurentDenis
    Je trouve cela assez moral, finalement : avec notre grande g..., nous ne représentons héroïquement qu'à peine 0.5% du Web-hubesque réel. Allez... 1 ou 2% en comptant ceux qui ne se sont pas dénoncés ? ça fait du bien, un bonne claque
  14. LaurentDenis
    Non, lorsque la présentation en question est uniquement associée à un contenu unique d'un document unique. La différence majeure ne se situe pas dans l'usage de la bande passante, mais dans les facilités de gestion des CSS pour le développeur. En effet : fausse question
  15. LaurentDenis
    Arf ! CSS permet de (et invite à) distinguer déjà: - les CSS selon les medias (screen, print, handled, projection, etc) - par media, les CSS permanentes (appliquées dans tous les cas), préférées (appliquée par défaut quand l'utilisateur affiche la page sans autre paramètre), et alternatives (sélectionnable par l'utilisateur en complément des CSS permanentes et à la place de la CSS par défaut)... Maintenant, qu'est-ce que c'est que le contexte de page ? - si la charte de mon site respecte les bonnes pratiques en cours d'évaluation, il y a une certaine unité de présentation sur toutes les pages, qui peut être gérée via une CSS permanente valable pour toutes mes pages. - mais chaque rubrique est susceptible d'avoir ses règles propres, inutiles pour les autres pages des autres rubriques : j'ai donc pour cette rubrique précise 2 CSS permanentes : celle du site et celle propre à la rubrique. - une page peut avoir des styles spécifiques... et donc un CSS idoine. Pour ma part, je me simplifie la vie dans ce cas d'une page unique en utilisant des styles en ligne du type <p style="..."> beaucoup plus facile à gérer. Certains aiment différencier leur CSS permanente en plusieurs fichiers: - un pour le texte (couleur, taille, typo, polices, indentation, etc.) - un pour le positionnement (float, position:... des grandes divs) Là, c'est à chacun de s'y retrouver comme il le préfère. Pour ma part, j'utilise des CSS "uniques", bien organisées (quand j'ai le temps ), réunissant styles de texte et de positionnement... Mais j'utilise surtout le mécanisme des styles permanents et des styles préférés, où l'on trouve le plus d'économies à réaliser. Sans prétentions sur ce vaste sujet, quelques indications sur le contenu d'un feuille permanente : Ménage de printemps: une CSS générique et permanente
  16. LaurentDenis
    C'est possible dans la pratique, via le DOM et CSS. Mais c'est surtout possible dans une mauvaise pratique. En effet, un menu de navigation n'est pas un plan de site... et ce que semble vouloir faire ce menu relève davantage de la liste exhaustive des pages disponibles (plan de site) que du menu (accès à des pages-clés et à des sommaires de rubriques dans un site au contenu complexe et hiérarchisé). Trop d'information... tue l'info. L'exploration de ce type de menu dynamiques et son appréhension par l'utilisateur se révèlent le plus souvent davantage un obstacle qu'autre-chose. Un menu résolument plus simple ne comportant que les liens vers les pages d'accueil de rubrique (tes 5 sections) qui détaillent chacune leurs contenus respectifs... sera plus simple à mettre en place, moins clinquant, mais plus utilisable finalement. Le tout doublé d'un plan de site en bonne en due forme, bien-sûr (une simple série de listes statiques de liens exhaustifs).
  17. LaurentDenis
    Au lieu du lien inutile vers une image déjà incluse dans ton message, pourrais-tu donner un lien vers ta page de test ?
  18. LaurentDenis
    Ce dont tu parles s'appelle les feuilles de styles alternatives. Cette technique est prévue de longue date en HTML: au chargement de la page, le navigateur récupère à la fois la feuille de style effectivement utilisée pour l'affichage, mais aussi une ou plusieurs autres feuilles de styles alternatives, qui peuvent se combiner à la demande de l'utilisateur avec le style par défaut, ou le remplacer complètement. Ceci ne nécessite aucune opération complexe de la part de l'utilisateur, mis à part sélectionner le style alternatif dans une liste fournie par le navigateur, qui l'appliquera immédiatement. Mais... Internet Explorer n'implémente pas les feuilles de styles alternatives. Seuls les navigateurs plus récents tels les navigateurs Opera, Safari, Mozilla, FireFox, Konqueror... les supportent, et mal d'ailleurs puisque le style alternatif choisi est "oublié lorsque l'utilisateur passe à une nouvelle page dans le même site, et qu'il doit alors reformuler son choix. Les manipulations que tu décrits sont effectivement inutilement complexes, car pour tenter de donner à l'utilisateur d'IE un pseudo-équivalent des feuilles de style alternatives, elles le contraignent à répéter pour chaque site une série d'opération tortueuses... qui modifient en réalité un autre type de feuille de style qui n'a pas été prévu pour être utilisé ainsi : chaque navigateur (y compris IE) utilise également ce que l'on appelle une feuille de style "user" (utilisateur), écrite, stockée et modifiée uniquement côté client. Elle permet d'appliquer des préférences de style personnelles à toutes les pages de tous les sites visités, de manière générique. La manipulation ci-dessus revient à la remplacer à chaque nouveau site visité par une feuille propre à ce site, en perdant son caractère gérérique qui en fait tout l'intérêt... Pour résoudre à la fois les problèmes: - de non-support des feuilles de styles alternatives par IE - de non-permanence des styles alternatifs dans les autres navigateurs récents, Certains développeurs ont recours à une gestion côté serveur du choix de style offert à l'utilisateur : la page intègre un formulaire (ou des liens) permettant au visiteur de sélectionner un des styles alternatifs du site; un cookie permet de stocker localement cette information, et le serveur adresse au client pour chaque visitée un code intégrant le style choisi. C'est ce que l'on appelle un "style switcher". Tu en verras des exemples d'utilisation orientés vers l'accessibilité sur le site OpenWeb (gestion des couleurs et des tailles de caractère) ou sur le site du CAMO (Agrandissement des caractères), ou encore sur de très nombreux weblogs. J'avoue être un peu réservé sur le fond (tout en ayant contribué à la mise en place de ces mécanismes sur les sites ci-dessus ): - la CSS "user" permet à l'utilisateur de forcer ses préférences de couleurs, de tailles de caractères, et bien davantage s'il a à sa disposition un interface lui simplifiant la rédaction de ces styles. Tout le problème des CSS "user" est qu'il s''agit d'un outil extrèmement puissant, donnant toute liberté à l'utilisateur d'imposer un rendu visuel conforme à ses besoins... mais d'un maniement encore hors de portée de la plupart des gens, en l'absence d'interface performant (il faut coder à la main sa CSS). - l'agrandissement de l'affichage est géré nativement par les navigateurs, avec plus ou moins de bonheur (d'où les outils de zoom spécifiques qui s'utilisent par ailleurs sur d'autres applications). Dans ce domaine, Opera est le seul navigateur actuellement doté d'un zoom étendu à tout le rendu graphique, images comprises. les styles alternatifs d'accessibilité me semblent donc finalement un pis-aller... peut-être utile pour l'instant ?
  19. LaurentDenis
    La syntaxe du commentaire conditionnelle est inexacte et invalide en HTML. La syntaxe correcte de la balise de fin est <![endif]--> et non <!--[end if]--> Le validateur CSS précise clairement qu'il ne peut être utilisé que sur des documents dont le code HTML a été validé au préalable.
  20. LaurentDenis
    Il n'y a pas de contre-indication dans l'absolu à l'utilisation des comentaires conditionnels permettant de réserver du code aux différentes versions d'IE. En revanche, ton code est un mélange un peu surprenant d'HTML et de CSS. Les commentaires conditionnels ne s'utilisent pas dans une feuille de style CSS, mais dans le code HTML où ils permettent de cacher le code qu'ils contiennent aux navigateurs non IE. Le code correct serait donc plutôt pour ton exemple: <style type="text/css"> div { padding:1px } </style> <!--[if IE 5]> <style type="text/css"> div { padding:3px } </style> <![endif]--> Cela dit, tout est affaire de choix personnel, AMHA. Je préfère pour ma part : - éviter les incompatibilités avec IE en laissant du jeu en particulier pour tout ce qui touche au box-model - laisser la page se "dégrader élégamment" dans IE quand ce n'est pas possible d'obtenir un rendu identique - utiliser un hack minimal (du type html>body ou !important) lorsque je suis vraiment contraint de préciser deux valeurs différentes pour IE et pour les autres navigateurs. - ne pas utiliser les commentaires conditionnels qui m'obligent à modifier la source HTML pour des questions de présentation. Mais ce n'est qu'un choix personnel. L'utilisation des commentaires conditionnels peut être tout à fait justifiée.
  21. LaurentDenis
    On aborde aussi un problème connexe : la distinction de plus en plus floue entre "votre machine" et "le Web". C'est l'enjeu des applications Web, supposées être le big deal des années à venir. Et l'éventuelle menace que cela représenterait pour les applications clients qui ont fait la fortune de Microsoft, du type Office. A petite échelle, le nouveau bidule de Google offrant des fonctionnalités de recherche aussi bien côté utilisateur que sur le Web est exemplaire (je ne sais plus exactement, mais il me semble que ce sujet a été discuté sur ce forum, à propos de la protection des données privées).
  22. LaurentDenis
    Pour être complet: il faut y ajouter la question de la diversification des medias d'accè au Web. Nous nous parlons ici pour l'instant que du media "screen", dans le jargon CSS, ou pour être plus clair des PC (et variantes). Quid des mobiles, marché naissant mais en pleine expansion ? je suis frappé de voir Opera SA jouer son avenir exclusivement sur ce media, où Microsoft est à peu près absent. Et dire que, selon une citation fameuse, Tim Berner Lee nous promet aussi le marché des frigidaires intelligents accédant au Web ! Je me demande qui sera en concurrence sur ce marché-là ?
  23. LaurentDenis
    Une chose me semble importante à souligner: le navigateur au sens traditionnel n'est sans doute pas le domaine majeur où va se jouer la concurrence entre les grands acteurs du type Microsoft / Google, etc. En fait, la frontière entre le navigateur et les autres applications accédant au Web et exploitant les contenus du Web a toutes chances de devenir de plus en plus imprécise. Et la notion de navigateur avec
  24. LaurentDenis
    IE n'est pas vraiment en cause, mais plutôt la feuille de style qui accumule les règles de positionnement et de dimensionnement dans tous les sens Ton design se mettra bien plus aisément en place : - en supprimant la position absolue du conteneur global, destinée apparemment à le centrer. Voir initiation au centrage CSS - en supprimant les positions relatives inutiles. - en précisant la largeur du menu de gauche #menu-v placé en float:left; La plupart des autres mentions de largeur de ce menu et surtout du contenu de droite peuvent être supprimées. - en supprimant tous les autres flottants à l'intérieur de ce menu et pour la colonne de contenu de droite. - en laissant la colonne de droite se placer en flux. Voir Initiation au positionnement CSS : 2.position float. - en supprimant le flottant inutile également pour le pied de page, et en le laissant en flux avec un clear:both pour le maintenir dans tous les cas sous le menu. - en précisant les marges latérales pour aligner le tout.
  25. LaurentDenis
    Ce sujet est intéressant en effet, car il montre bien l'intérêt mais aussi les limites d'une démarche empirique "version spécifique du document pour les mal-voyants": - elle aboutit à un document finalement très accessible car très simplifié (voir l'exemple de http://www.guinot.asso.fr/ ). - mais du coup, face à un document plus complexe, elle peut conduire à sacrifier une partie du contenu, et à confiner les mal-voyants dans une expérience du site passablement appauvrie. - surtout, elle n'est pas forcément nécessaire, et les techniques d'accessibilité plus récentes apportent le plus souvent des réponses plus intéressantes. Le cas des images est assez exemplaire: lorsqu'une page contient une image "de présentation", c'est à dire qui n'apporte pas d'information utile à la compréhension du contenu propre de la page, l'ajout d'un simple attribut alt="" suffit à la faire disparaître dans les medias utilisés par les mal-voyants. A l'inverse, l'ajout de l'information dans l'attribut alt sous forme d'une brève description de celle-ci, ou de sa nature, suffit à faire apparaître l'information dans un media qui ne restitue pas les images... Il est donc inutile de créer une version spécifique du document: il devient utilisable aussi bien par un navigateur graphique que par un utilisateur qui n'accèdera qu'aux informations textuelles. Pour préciser tout cela, voir - http://openweb.eu.org/articles/accessibilite_images/ - http://openweb.eu.org/articles/chantal_laplanche/ Et finalement, cette citation d'un internaute aveugle, formateur à l'UNADEV, qui montre bien un autre point de vue que celui de http://www.guinot.asso.fr/ : ( http://www.temesis.com/article/questionbf_fr.html )
×
×
  • Créer...