LaurentDenis

Chercher le balisage approprié, c'est d'abord chercher la solution la plus directe qui respecte la spécification (X)HTML adoptée. En particulier, dans le propos d'un tutoriel ou de règle de bons usages. Or, des div, des span forcés à se comporter en éléments-blocs... sont autant de solutions inutilement lourdes et contournées. Dans le cas d'un poème en strophes, pourquoi chercher autre-chose que p, qui n'indique qu'une unité logique du texte ? Dans le cas d'une strophe en vers, sachant que le retour à la ligne identifie le vers (entre autres notions), pourquoi chercher autre chose que br, dont le sens est précisément de provoquer un retour à la ligne ? Dans la lignée des spans, Denis, je te propose un autre excès amusant de rafinement. Puiqu'un poème est une certaine forme de liste de vers, on pourrait tout aussi bien proposer : <ul> <li>Elle dormait : son doigt tremblait, sans améthyste</li> <li>Et nu, sous sa chemise, après un soupir triste</li> <li>Il s'arrêta, levant au nombril la batiste</li> </ul> Avec évidemment ce qu'il faut de list-style-type: none dans la CSS Evidemment excessif et inutile

C'est impossible en CSS de cette manière, car le contenu généré n'est pas "interprété" par le navigateur, mais juste restitué passivement. Voir la spécification CSS2 : http://www.yoyodesign.org/doc/w3c/css2/generate.html#content

Totalement inutile. Comme le rappelait Monique, width et height sont des attributs (X)HTML valides pour l'élément img <img src="..." width="..." height="..." alt="..." /> Passer les déclarations de dimensions d'images en CSS n'apporte aucun gain de validité ni de sémantique. En revanche, cela alourdit inutilement le code avec des styles internes et complique la tâche. Quant à placer en css les images purement décoratives.... Oui, tout à fait.

br est indispensable dans certains cas où: - le texte a une unité logique qui empêche son fractionnement en plusieurs éléments blocs (plusieurs paragraphes par exemple) - le retour à la ligne a une valeur sémantique (ça existe !). Le cas type, ce sont les vers en poésie : <p> Elle dormait : son doigt tremblait, sans améthyste<br /> Et nu, sous sa chemise, après un soupir triste<br /> Il s'arrêta, levant au nombril la batiste </p> <p> Et son ventre sembla de la neige où serait<br /> Cependant qu'un rayon redore la forêt<br /> Tombé le nid moussu d'un gai chardonneret </p> <p> <cite>Stéphane Mallarmé</cite>, <cite>Mysticis umbraculis</cite> </p> Note : quelqu'un (?) avançait aussi le cas de la balise address, où le saut de ligne aurait également son utilité...

Comme le rappelle Denis, hr est l'élément tout désigné pour créer une séparation entre des sections. Il est vrai qu'il n'est pas aisément stylable. Pour trouver de l'aide à ce sujet, voir http://www.sovavsiti.cz/css/hr.html Le meilleur compromis me semble de : - placer avant tout des hr là où il faut (entre les grandes sections de la page : en-tête, contenu, menus, pied); C'est très agréable pour les utilisateurs de navigateurs textes. - les cacher en CSS avec display:none (ou visibility:hidden) - utiliser CSS pour générer des bordure-top et des bordure-bottom, ou éventuellement des background-image en bottom repeat si on veut des séparations graphiques plus évoluées mais sur des éléments ou des div existants. S'ils n'existent pas, c'est signe que la séparation ne s'impose pas, ou que la structure de la page n'est pas bonne. cela dit, hr n'a... rien de sémantique du tout, dans la mesure où le XHTML 1.x est "plat" c'est à dire ne distingue pas des niveaux de structuration de texte emboîtés. C'est juste le minimum vital de balisage présentatif conservé en XHTML : il en fallait quand même un peu

Comment y accèderont ceux qui ne distinguent pas les couleurs ? Une des règles de l'accessibilité est de ne pas faire passer une information uniquement par la couleur

L'essentiel sur les polices et les tailles via CSS, résumé dans deux articles d'André Vincent: http://edu.ca.edu/article67.html (Les polices : Quelle famille choisir ?) http://edu.ca.edu/article70.html (Les polices : quelle taille choisir ?)

Quelle version de Lynx utilise-tu ? Car chez moi (Lynx v2.8.4) , tout apparaît normalement

Désolé, je me suis mal fait comprendre : l'information désignant l'acceskey du lien doit figurer "en dur" dans le contenu de chaque page où apparaît le lien, et bien évidemment dans son contexte. Sur le principe de : <a href="..." accesskey="X">...</a> (accesskey X) Ce qui surcharge évidemment le menu en question... Ce qui gêne les utilisateurs n'utilisant pas les accesskeys... Ce qui montre que rien n'est parfait au royaume de l'accessibilité, et tout spécialement les accesskeys

alt, title, acronym, hiérarchie des titres... sont requis à deux niveaux : - d'abord d'un strict point de vue structurel et sémantique, sans rapport avec l'accessibilité ; - ensuite seulement pour l'accessibilité. Les specs (X)HTML ont été écrites avec, entre autre intentions, l'accessibilité. Il est donc logique (et rassurant) qu'un bon codage et une bonne utilisation des outils de structuration soit nécessaires à une bonne accessibilité. Mais ce n'est pas la raison d'être unique de ces outils. Marie Ayant quelques handicaps personnels, j'utilise : - quotidiennement une béquille, - de plus en plus souvent un lecteur d'écran. Ce sont des patchs. Je comprends la générosité qui est au fond de cette idéalisation du handicap. Mais je crois qu'elle mène, techniquement, à des approches erronées, et qu'humainement, elle est... disons, lassante.

Le but du jeu, c'est de signaler l'accesskey dans tous les medias : si ça passe par une règle CSS, c'est absurde, puisque ce ne sera visible que dans certains navigateurs. De ce point de vue, span, em, strong... sont équivalents. Il faut passer par un contenu HTML explicite indiquant quel est l'accesskey, "en toutes lettres".

Attention à cette dérive consistant à idéaliser l'expérience des handicapés sur le Web et ce qu'elle peut apporter aux concepteurs : cette expérience est évidemment indispensable pour qui se soucie d'accessibilité réelle, mais l'accessibilité a beaucoup à nous apprendre... à propos d'accessibilité uniquement, rien de plus. Ce n'est pas une révélation mystique ! Pour dire les choses clairement et appeler un chat, un chat : l'accessibilité consiste à remédier à des handicaps à l'aide de "patchs". Jaws, tout comme une tablette braille, est une béquille. Et le Web, vu sous l'angle utilisateur, est encore aujourd'hui un media principalement visuel. Vu sous l'angle d'un lecteur d'écran, c'est une expérience laborieuse, même menée dans les meilleures conditions.

J'enfonce le clou : la nécessité d'une validation humaine est importante même pour des mesures d'accessibilité telles que les attributs alt des images ! En effet, il ne suffit pas que l'attribut soit présent (ce que la machine peut valider), il faut encore qu'il soit pertinent (ce dont elle est incapable) : - attribut vide pour les images typo, décoratives, invisibles... - attribut explicite pour les images significatives, sauf redondance avec le texte du contenu environnant... - voir longdesk ou lien D pour les images dont l'équivalent ne peut être donné brièvement.

He he... C'est là où Opera et sa recherche "instantanée" dans l'historique est bien sympa Encore un de ces petits détails d'ergonomie norvégienne... qui gagnera sans doute les autres navigateurs bientôt

Denis, il arrive au W3c de faire des choses purement théoriques. En l'occurence, les accesskeys du validateur : - alt+s pour "skip navigation" est inopérant dans IBM HPR et certaines versions de Jaws ; - alt+k est inopérant dans certaine versions de Jaws ; - alt+h neutralise dans bcp de navigateurs l'accès à l'aide locale (Help) ; Les accesskeys numériques qui suivent sont un peu plus probantes, n'étant guère utilisées en dehors de Window Eyes et de certaines implémentations de Jaws, mais elles ont le défaut d'être trop ciblées et inutilement redondantes avec des tabindex. Dans le meilleur des mondes, si racourcis-clavier locaux et accesskey étaient strictement différenciées ou correctement gérés, ce serait pertinent. Mais l'implémentation des standards et leur conception elle-même sont en défaut dans ce cas.

Hum... Une différence, il me semble, d'après ce qu'Eric Daspet est venu me dire sur http://www.blog-and-blues.com/2004/avril/1...d_et_object.asp : -Flash est un logiciel, c'est à dire strictement dépendant du plugin propriétaire. -Adobe est plus ouvert, plus orienté "format" puisqu'il est (un peu) exploitable en dehors d'Adobe. Quant à préférer un bon HTML capable de basculer à l'imprimer, on est exactement dans la problématique des standards "ouverts" et pas dogmatiques Tout le monde ne peut pas produire un HTML imprimable. En revanche, tout le monde peut produire un PDF propre, avec un minimum de formation à moindre coût.

Une question toute bête : pourquoi voulez-vous déterminer cette largeur ? Promis, en échange, j'ai une excellente ressource qui explique le pb des tailles de caractères en %, en em et en px selon les navigateurs, et qui vous détaille trois solutions possibles à repiquer tel que

Sans être allé très loin, je me suis immédiatement arrêté sur une chose : des class="titre" à la place de titres en bonne et due forme. Ce choix a priori suprenant a-t-il une raison ? Ce n'est pas une question de design, mais de structure, et c'est bcp plus important (avec un coût minime pour la modification à faire) Pas une question de design... quoique tous les medias ont un comportement par défaut qui signale d'une manière ou d'une autres les titres. [edit] Aïe ! je suis allé plus loin : la page entière est en div, sans aucun balisage textuel (paragraphes, listes, titres)... Très franchement, le design n'est pas la priorité. Commencer par une structure de page significative [/edit]

N'utilisez pas javascript pour l'accessibilité : il n'a aucun sens en dehors de quelques navigateurs. Groumpf !

Denis, je suis franchement revenu de ma vieille hostilité au pdf depuis que : - j'ai vu que ce n'était pas tout à fait un "document de verre" figé, quand on prend la peine de faire un bon pdf, c'est à dire autre-chose qu'un bête scan papier ; - le format propriétaire adobe joue le jeu des formats ouverts ; - OpenOffice en particulier permet de gérer du pdf. Tout ceci, à partir du moment où : - on ne privilégie pas le pdf sur un html correctement imprimable (une css d'impression suffit pour un coût minime) - on réserve le pdf aux documents qu'il serait trop coûteux de convertir en html, donc originellement "papier" - ou bien on propose les deux formats en alternative "pdf ou html". Finalement, en tant qu'utilisateur, je préfère un pdf propre que je peux lire à tête reposée à un html inimprimable ou trop coûteux pour moi à imprimer pour cause de balisage lamentable où les menus... ne peuvent être virés.

Je me permets de te renvoyer ici, et surtout à la page d'exemple de l'article en question : http://openweb.eu.org/articles/initiation_centrage/ Ce n'est pas évident d'expliquer la différence entre valeurs absolues et valeurs relatives, résultat rigide et résultat élastique. Disons que ton 750 px provoquera des scroll horizontaux dans diverses résolutions d'écran (pas que les vieux machins : pensez aux portables) dès qu' IE ou Mozilla ont unpanneau latéral (liens...). Donc tu peux réduire à moins de 750px, ou mieux, utiliser une valeur en %

La navigation en premier, et ensuite surtout le fait que les pages ne sont plus scrollables et qu'il faut naviguer d'écran en écran dans la même page. Après, les formulaires franchement rébarbatifs et parfois immaniables quand ils sont trop complexes... Enfin, j'ai noté parfois des différences de rendu inattendues entre l'aperçu dans Lynx Viewer et la réalité dans Lynx, dû sans doute à des bugs. Franchement, Lynx, c'est 5-10 minutes pour le téléchargement et l'installation, et c'est un excellent test

a[title~=pdf]:after { content: "\00A0[Ceci est un affreux PDF]"; } est une règle CSS de "contenu généré" : dans les navigateurs respecteux de CSS2, tout lien du type : <a href="..." title="attention: document pdf">...</a> sera suivi de la mention [ceci est un affreux PDF] Le principe est simple : -le sélecteur a[title~=...] stipule que ça s'applique aux liens qui ont un attribut title d'un certain type -le sélecteur :after stipule que ça doit intervenir juste après les liens en questions -la règle content... signifie qu'il faut ajouter ce qui suit dans la page à cet endroit. Bref, au moment où il applique la CSS à la page, le navigateur ajoute le contenu en question là où on lui demande C'est apparemment génial... sauf que : - ça ne marche pas dans IE, qui ne gère pas les contenus générés, - ça ne marche pas dans tout autre navigateur ou media qui ignore les feuilles de styles. Donc, c'était plutôt un clin d'oeil à Monique qu'une recommandation. Le plus simple est d'écrire en toute lettres dans sa page : <a href="..." title="attention: document pdf">...</a> (PDF).

Oublie les pourcentages d'utilisateurs de lynx et autres, c'est une bataille sans fin. l'important, c'est que Lynx ne retient que la structure brute de la page. Autrement dit, si c'est cohérent et agréable dans lynx, c'est un très bon signe : c'est bien parti pour être accessible sur les medias que tu ne connais pas. Cela dit, il y a une marge entre l'aperçu dans lynx et lynx lui-même. C'est pourquoi je t'encourage à télécharger celui-ci par la suite, ne serait-ce que pour les joies de la navigation au clavier (te presse pas et assimile déjà cequi te préoccupe maintenant). Sur le fond, voir un extrait traduit d'un concepteur que j'aime bcp : http://www.blog-and-blues.com/2004/mars/13..._philosophy.asp

D'une manière générale, quand on se retrouve à faire un <br> ou un <br />... c'est qu'il faudrait structurer autrement le contenu en question. Bien-sûr, il y a des exceptions (une strophe de poème, par exemple). Mais pas bcp