LaurentDenis

Contrairement à une idée bien ancrée, le pixel n'est pas une unité absolue. Ah... Nous n'avons manifestement pas les mêmes valeurs, alors. Enfin, les mêmes pixels En effet: .verdana { font-family: verdana; font-size: 10px; } .arial { font-family: arial; font-size: 11px; } .tahoma { font-family: tahoma; font-size: 11px; } ... donnent uniformément un résultat très laid et beaucoup trop petit chez moi Il faut apprendre à lâcher prise sur le design...

Commint : merci de prendre la peine de regarder au moins le code source d'une CSS avant de faire des suppositions... qui pourrait être plus aimablement dites. Les tailles de polices du site en question ne sont pas fixées en px ou en unités absolues, mais en unités relatives (100% pour body, 0.8em pour #content). Ce qui provoque la dégradation de la police utilisée (Arial, il est vrai)... se passe uniquement du côté de ton navigateur

( http://openweb.eu.org/articles/css_impression/ )

Tu devrais trouver ce qu'il te faut pour les bases dans: - http://openweb.eu.org/articles/css_impression/ - http://openweb.eu.org/articles/exemple_css_print/ (Attention, pour le premier article : les propriétés CSS permettant de modifier l'orientation de la page imprimée et ses marges sont trop mal implémentées dans la plupart des navigateurs actuels pour être utilisées). Juste un détail, au cas où : il s'agit bien d'une image de contenu ? Autrement-dit un élément <img src=...> ? Dans ce cas, pas de problème. En revanche, l'impression des images d'arrière-plan ne peut pas être forcée, et dépend entièrement de la configuration du navigateur.

Si ta liste est précédée d'un véritable élément de titre, la marge inférieure de celui-ci doit être annulée elle aussi : <h1 style="margin-bottom:0;">La liste :</h1> <ul style="margin-top:0;"> <li>item 1</li> <li>item 2</li> <li>item 3</li> </ul>

Pour ménager certaines susceptibilités bien compréhensibles, pourrais-tu préciser ce que tu entends par

Lorsque l'identité du navigateur est masquée (proxy, firewal...), ton site affiche une jolie page blanche avec la mention "_AB_GETOUT" Un script anti-aspirateur, peut-être ? (Voir http://blog-and-blues.org/weblog/2004/12/1...3-access-denied pour un argumentaire sur le sujet )

Le gros du travail est déjà fait, en effet. Disons que ceux qui ont déjà compris l'importance du media "handheld" méritent d'être encouragés, et que c'est un bon exemple qui peut en entraîner d'autres...

Deux suggestions : - renoncer à la détection du navigateur conditionnant l'accès au site. - renoncer aux Active-X conditionnant l'affichage du contenu sous IE

Le scroll apparaît dans Opera en mode "Small Screen rendering" (mode mobile, si tu préfère) et dans l'émulateur OpenWave, dès qu'on descend en dessous de 345 pixels de largeur de fenêtre... On est loin des 120px disponibles sur certains mobiles Il s'agit en fait plus probablement du textarea de la saisie des commentaires. Tu devrais pouvoir le redimensionner en %.

Le WAP Forum, devenu depuis l'Open Mobile Alliance, qui regroupe les principaux acteurs du marché "mobiles", a abandonné officiellement le format WAP1.x et WML depuis 2001, au profit d'XHTML Mobile Profile, qui est une version légèrement étendue du XHTML basic du W3C... WAP est une norme périmée

Je viens de tester rapidement ton accueil dans IBM HPR (lecteur d'écran) : ton formulaire est tout à fait utilisable La navigation dans ta page d'accueil de tableau en tableau est assez facile, car ils se linéarisent bien. Mais elle pourrait être plus confortable avec: - des liens d'évitement de tes listes de liens (un lien avant chaque liste pour "sauter" celle-ci et aller au contenu suivant) - davantage de titres <h...> (un par section de la page) afin de permettre de naviguer vraiment de titre en titre (j'avoue une préférence personnelle pour ce mode de navigation dans un lecteur d'écran ) - un lien d'accès direct au formulaire de recherche, placé en tête de page, ainsi qu'un lien d'accès au contenu principal de la page. Mais si davantage de sites étaient comme cette page d'accueil... ce serait déjà très bien

le problème est dû à la soumission du formulaire via javascript : <form onsubmit="return CNSubmitComment()" method="post" name="comment" id="comment" action=""> A éviter à tout prix Javascript n'est pas supporté par tous les navigateurs sur mobiles, et se trouve fréquement désactivé quand il est supporté. Par ailleurs, pour améliorer ta CSS handheld : - scroll horizontal à éviter (problème de marge ?) - taille de caractères par défaut trop petite (70%) - contraste insuffisant sur les liens Quelques liens utiles: - http://www.alistapart.com/articles/pocket/ - http://my.opera.com/community/dev/device/ - http://www.htmldog.com/ptg/archives/000055.php

margin-left = width + padding latéraux (200+10+10) Cette largeur et cette marge sont nécessaires : un élément flottant non remplacé doit avoir une largeur explicite. Le code sans largeur de tictact... fait flop dans Opera, par exemple. Accessoirement, voir Initiation au positionnement CSS : 2.position float pour les bases sur les flottants.

L'idée, si tu utilises les flottants, c'est : - de ne faire flotter que le premier élément, doté d'une largeur fixe - de laisser le 2e élément en flux remplir l'espace disponible à côté du flottant. En CSS: .cmenu { color: #999999; background-color: #eeeeee; padding: 10px; float: left; width: 200px; } .contenu { border: 1px solid; margin-left: 220px; } en HTML: <div class="cmenu">le menu ici</div> <div class="contenu">Le contenu ici</div>

Pourrais-tu: - donner une url (ou à défaut, un code plus complet) - préciser ton "bouton" ? - préciser le navigateur de ton modèle de Sonyericsson : navigateur spécifique ? Opera ?

Pour ma part, et en dehors de mes petites interventions sur le Web, c'est plutôt dans le contexte de mon métier que j'interviens en matière d'accessibilité : en tant qu'enseignant, j'ai à répondre aux demandes de scolarisation d'élèves handicapés. Il m'est donc arrivé à plusieurs reprises dêtre confronté à des problèmes d'accessibilité bien "concrets" concernant les locaux, le matériel scolaire... ou ma pédagogie

Tu peux appliquer une règle a:focus { background-color: red; } ... qui ne sera pas prise en compte par tous les navigateurs (Firefox l'applique, IE ne l'applique pas si ma mémoire est bonne). Sinon, la propriété outline s'applique par défaut aux liens ayant le focus au clavier, à moins que tu ne l'aies annulée dans ta CSS.

Le Lynw Viewer est une simulation. Affiche le code source de ta page vue dans Lynx Viewer : tu verras que les contrôles de formulaires sont remplacés par du texte simulant leur apparence dans Lynx. Il est donc normal qu'ils ne fonctionnent pas Pour tester ton formulaire, utilise plutôt le "vrai" Lynx et un lecteur d'écran

- navigateurs textes (Lynx est le plus évident, en effet) - lecteurs d'écran : Jaws est utilisable gratuitment en version bridée limitée à 40 mn de session, IBM HPR est utilisable gratuitement dans une version antérieure... - navigateur graphique, mais sans souris

Non Denis, dans le cas de Handica, ce n'est pas ça. Handica est une association ancienne, dont les salons annuels existent depuis plus d'une dizaine d'année. Ce n'est pas, en revanche, une association prioritairement axée sur l'accessibilité Web :elle s'occupe plutôt de l'accessibilité des services "réels", des matériels spécifiques pour handicapés, etc. Le Web est un terrain nouveau pour cette association, et elle fait d'ailleurs appel à des spécialistes extérieures afin de constituer les jurys de ces premiers "trophées" Web. Il s'agit de méconnaissance, non d'opportunisme. Donc, encore une fois : encourager, ne pas casser. (Qu'aurait-on pu dire de BrailleNet il y a quelques années ! )

Je reviens tout de même sur le sujet. Peut-être vais-je tout de même aller voir cette animation, puisque tout le monde la dit si belle. Ce qui est justement intéressant ici, c'est quon voit bien l'importance et le rôle du contenu HTML dans ce type de page: il serait absurde, en effet, de se priver des possibilités offertes par Flash, et de s'interdire de créer pour l'esthétique, pour le plaisir, sous prétexte que ce n'est pas accessible, ou pas référençable, ou etc. Mais de telles pages ne doivent pas, AMHA, se transformer en "page tunnel" sans aucune alternative ou explications pour celui qui, pour une raison ou une autre, ne peut pas accéder à son contenu flash. Un contenu alternatif HTML simple et peu coûteux suffirait : - à donner matière à indexer aux moteurs de recherche, - à donner une idée de ce qu'est cette animation à ceux qui, comme moi, iront volontier la voir, même si son temps de téléchargement est très long, si on leur donnait envie de le faire, - à donner accès au reste du site, qui ne pose peut-être pas le même type de problèmes.

Ah... J'aurais eu plein de choses à dire, sans doute. Mais je n'ai pas dépassé http://perso.wanadoo.fr/ykotech/index2.html , dont la superbe blancheur immaculée et totalement vide de tout contenu me laissait pourtant rêveur (PS: Oups, j'avais oublié d'activer Flash. Trop tard, je suis déjà reparti )

On est effectivement peut-être loin de l'accessibilité standard, et plus près d'une accessibilité "moyens du bord" à l'ancienne. Mais la composition des jurys donne à penser qu'handica est justement en train d'évoluer de ce côté là. Ce qui est à encourager, évidemment, plutôt que de "descendre" cette initiative.