Denis
-
Compteur de contenus
1 537 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par Denis
-
Si je puis me permettre, un bon outil pour connaître les différentes posibilités des CSS c'est http://www.w3Schools.com/css/ Pour les background, c'est ici : http://www.w3schools.com/css/css_background.asp
-
Je ne veux pas enfoncer le clou inutilement, mais c'est vrai en plus que la sur-utilisation de javascript pose des problèmes majeurs d'accessibilité pour les utilisateurs ne le supportant pas. De par la manière obstructive dont il est mis en place, l'accès aux contneus est impossible. C'est dommage. Maintenant, je souhaite m'assurer que l'on souligne tout de même l'effort de Syl a passer en pur CSS... ça prend quand même du courage pour s'y mettre, c'est tellement facile de se réfugier dans ce que l'on connait bien et refuser d'admettre qu'il est temps d'évoluer. Dans un processus normal d'acquisition de connaissance, il est logique de passer par une mauvaise utilisation de la sémantique ou de l'accessibilité... chaque chose en son temps je dirais. Syl : Pour le moment, si l'aventure d'un code conforme, accessible et sémantique te tente, je te propose de commencer par appliquer un doctype à ton document et de t'assurer que tout est valide (code, css). Tu connais probalement les vlaidateurs, ce sont tes amis : HTML : http://validator.w3.org/ CSS : http://jigsaw.w3.org/css-validator/validator-uri.html Par la suite, tu pourras passer à la prochaine étape, soit remettre en question les éléments HTML que tu as utilisé pour chaque section et te demander si l'élément choisi est bien le meilleur pour représenter le travail a effectuer... ça, c'est la sémantique. Parce que ce n'est pas parce qu'un document est valide qu'il est bien construit pour autant. Par exemple, pour faire un menu, l'utilisation d'une liste est beaucoup plus approprié qu'un paragraphe avec dvers items séparés par des br... ou encore, l'utilisation des balises h1 à h6 pour les titres et les sous-titres, plutôt que d'utiliser des paragraphes avec une classe CSS quelconque... refile plutôt le CSS sur un h1 bien senti et ton code aura beaucoup plus de signifiance pour les agents utilisateurs qui ne se fient pas uniquement sur la représentation graphique pour donner un sens à ton site. Y'aurait aussi l'aspect accessibilité qui pourrait être pris en compte... un très bon tremplin à ce niveau, c'est évidemment DiveIntoAccessibility de Mrk Pilgrim... http://www.diveintoaccessibility.org/ Simplement en applicant les étapes qu'il décrit, tu auras déjà fait des pas de géants. Mais rappelle toi que c'est un travail progressif. Essaie de tout faire d'un coup et je te garantie que tu vas tout laisser tomber La patience donc, est de mise. Bon courage, c'est beau l'évolution !
-
Hummm.... Pourtant, en reprenant ton bout de code et en le passant dans le validateur, ça me donne pourtant un code conforme http://webconforme.ca/test.html http://validator.w3.org/check?verbose=1&ur...me.ca/test.html Qu'est-ce que j'ai fait de différent de toi ? <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>webConforme</title> <meta http-equiv="Content-Type" content="text/HTML; charset=iso-8859-1"> </head> <body> <a href="http://www.alapage.com/mx/?type=4&tp=F&donnee_appel=xxxx&VID_NUMERO=490437" target="_blank"><img src="http://imgdata.echo.fr/disque_l?v490437l.jpg" border="0" alt="Pearl Harbor"></a><br> </body> </html>
-
Je rejoins l'avis populaire... trop bleu... évidemment venant de quelqu'un qui a un design de site dans les mêmes tons, je suis mal placé pour te faire le reproche. Nos deux designs souffrent effectivement du même problème... trop froids. Une couleur chaude disposée efficacement règlerait bien le cas. Ensuite, je travaillerais effectivement l'identité de tes éléments graphiques à gauche et à droite... une iconographie me semble effectivementintéressante mais encore là, mon site n'est pas mieux que le tien à ce niveau. Par contre, la structure de ton design me plait bien, c'est propre et clair. Suffit à mon sens que de le pousserlus loin encore pour le personnaliser, pour qu'il prenne l'allure de 4claverie, pas de n'importe quel site à trois colonnes. Ça c'est pour le design... Maintenant, je rejoins l'avis de Laurent lorsqu'il parle de sémantiser ton code, de le rendre conforme aux normes et tout le reste. Ce serait un plus pour la qualité de ton site, qui te permettrait de récolter un certain nombre de bénéfices très intéressants. C'Est doublement pertinent que je constate que tu as fait l'effort de tout mettre en CSS, mais sans spécifier de doctype pour ton HTML... une mise à niveau purement XHTML 1.0 transitonnel te permettrait de pousser l'expérience beaucoup plus loin. À cet effet, je te propose humblement de visiter la section XHTML d'OpenWeb : http://openweb.eu.org/xhtml/ -- c'est très éclairant Particulièrement les articles suivants : http://openweb.eu.org/articles/html_au_xhtml/ http://openweb.eu.org/articles/xhtml_une_heure/ http://openweb.eu.org/articles/respecter_semantique/ Voilà, bon courage dans tes projets de refonte et de redesign !
-
Es-tu en HTML 4.01 Strict ou transitionnel ? Si tu as bien converti tous les & en &, alors c'est peut-être que la valeur de ton attribut href n'est pas fermé par des guillemets ? Je vois les guillemets ouvrants, mais les fermants sont tronqués par la fin du bloc de code... s'ils existent. Mais à priori, s'il ne reconnaît pas tp, c'est qu'il est incapable de poursuivre la lecture... alors ce serait possiblement une erreur de & mal encodé.
-
Je suis bien sûr d'accord avec toi... mais je préfèrerai toujours un bon document HTML capable de basculer à l'imprimé en un format adapté qu'un pdf qui me forcera au format... ne serait-ce que pour l'aspect d'universalité du format HMTL. Dans mon cas, c'est purement idéologique puisque je ne souffre pas d'exclusion à ce niveau là, mais lorsqu'un expert en accessibilité reconnu mondialement me confie que le PDF accessible est possible en théorie mais une belle utopie en réalité, je ne peux endosser complètement le format propriétaire d'Adobe, pas plus que je ne peux endosser le format Flash. Macromedia joue aussi le jeu du format propriétaire qui essaie de devenir sensiblement ouvert, mais il n'en demeure pas moins très ardu de faire du Flash accessible (qui peut aujourd'hui se vanter de pouvoir expliquer en une page comment faire ?). Dès le départ, le format est encapsulé. Travailler à le rendre accessible, c'est bien mais il ne faut pas oublier qu'au départ, pas sa propre nature, le format est exclusif. Ceci dit, je sais apprécier un beau pdf bien construit pour lire à tête reposée au lit avant de dormir... ça me rapproche du livre... mais comme le HTML et les CSS le permettent aussi, le format est de moins en moins pertinent dans la plupart des cas.
-
Merci Monique de m'avoir repris, effectivement j'aurais pu opter pour infobulle plutôt que tooltip...
-
Je suis tout à fait d'accord avec mes illustres collègues Laurent et Monique. Pour ce que mon opinion vaut, je trouve que forcer le téléchargement est une pratique que je ne saurais encourager. Tout d'abord, l'utilisateur doit vivre avec le fait qu'il est pris dans une voie qu'il ne souhaitais pas (lancer une application, s'il la possède). Deuxièmement le PDF est un format propriétaire et pas accessible qui laisse certains utilisateurs de côté. Pourquoi ne pas recourir à du bon vieux HTML pas propriétaire pour deux sous ? La mise en page de tes pdf est-elle si compliquée que tes documents doivent absolument être présentés sous ce modèle ? Si oui, alors je te suggère d'y aller avec la porposition de Laurent pour définir par CSS un message d'avertissement au utilisateurs... Ce sera un moindre mal... en autant qu'ils supportent également CSS.
-
Il n'y aurais pas grand chose à ajouter pour le moment à la question sans risquer de te nyer dans une mare d'information. Je te suggère bien humblement d'aller lire les deux articles proposés par 20cent, ensuite, on pourra discuter un peu plus en profondeur des enjeux reliés à l'utilisation de HTML ou de XHTML. Sache simplement que les deux sont bons, mais que les deux ne te conviennent pas forcément. Tout est une question d'évaluer tes visées avec les documents que tu vas produire. J'en rajouterais une couche en disant que XHTML, c'est du XML. Faire le choix vers XHTML, c'est prendre progressivement la voie du XML et tous ces avantages en terme d'évolutivité.
-
Une petite question comme ça.... Est-ce vraiment du tabindex dont tu as besoin ? Si tu souhaites que ton curseur soit à un point spécifique dans ta page au page load, je crois que ce que tu cherches, c'est l'utilisation de javascript pour t'assurer qu'au chargement de ta page (événement onload), le focus soit mis sur cet élément de menu (événement onfocus)... enfin, mon javascript étant pas mal rouillé, je ne pourrais t'en dire plus sans craindre de me tromper ou de t'indiure en erreur. Quelqu'un peut confirmer que je ne suis pas dans les choux ? Y'a t-il un dieu du javascript dans l'auditoire ?
-
Oh oui J'en ai trouvé une autre version hier alors que j'ai suivi une formation en accessibilité, mais je te remercie pour celle-ci je vais les comparer. Essentiellement, ce sont les 65 points de contrôles issus des 14 règles du Web Content Accessibility Guideline... mais je veux les présenter d'une manière plus intéressante et surtout moins technique pour les développeurs. Ça va très certainement aider. Merci beaucoup pour le temps que tu a pris pour les rechercher.
-
Clair de lune, tu as tout pigé. Cependant, et tout le problème est là, il n'y a pas vraiment de normes spécifiant quel accesskey devrait être utilisé pour pointer vers une telle page ou toute page en fait... C'est d'ailleurs toute la polémique à leur endroit. Certains s'entendent pour dire que l'accesskey 1 devrait pointer vers la page d'accueil, que le accesskey 4 devrait pointer vers la recherche et le accesskey 9 devrait pointer vers la page de contact et encore si c'est une norme, elle est purement de facto. Passé ces trois là, c'est vraiment libre à chacun... Ce qui diminue considérablement l'intérêt de les utiliser puisque l'on ne peut s'imaginer que les utilisateurs prendront la peine d'apprendre la charte de tous les sites qu'ils visitent. Compte tenu de l'imperfection de la pratique et de son support entre les navigateurs et les plateformes, c'est le mieux que l'on puisse espérer pour le moment. J'espère que ça éclaire quand même deux ou trois lanternes.
-
Et bien, personnellement, je fais toujours les deux sur les projets que je développe (quand on me le permet bien sûr), ce qui n'est pas toujours le cas, vous vous en doutez bien. Je commence par faire une page qui traite de l'intérêt de coder selon les normes, en expliquant en quoi cela revêt un intérêt C'est généralement une page que j'appelle "Politique de mise en conformité" ou un truc comme ça. Cette page pourrait se traduire généralement par un lien vers le document d'OpenWeb dont nous parlions plus tôt ou un autre sur les navigateurs alternatifs, mais comme j'aime bien me compliquer la vie dès que je le peux, je travaille à me bâtir un modèle de mon propre cru que je réutiliserai systématiquement. Si cela intéresse quelqu'un, je pourrai le partager avec vous tous lorsqu'il sera à mon goût. C'est vraiment une page générique, un peu comme un avis légal, que je peux reprendre et adapter, simplement en changeant le nom de la société qui y figure. Deuxièmement, je développe une seconde page, en relation avec la première, qui s'intitule généralement "Politique d'accessibilité", à l'intérieur de laquelle je décris l'effort accompli pour rendre le site accessible, son niveau de respect des principes du WCAG (A, AA ou AAA), ainsi que le pourquoi de cet effort. À l'intérieur de cette page, je donne entre autre chose, une description des divers accesskeys que j'utilise, des fonctionnalités de styleswitching et autres trucs du genre. Cette page là aussi je la veux la plus générique possible, tout en pouvant l'adapter en fonction des particularité du site. Encore une fois, je pourrai la partager lorsqu'elle sera à mon goût. Une note sur l'attribut title J'ai longtemps cru que la technique voulant à mettre la valeur de l'accesskey était intéressante et je l'ai souvent utilisé moi-même pour fournir une information complémentaire (comme par exemple, justement annoncer un accesskey). Mais à ma grande stupéfaction, j'ai appris pas plus tard qu'hier que les principaux lecteurs d'écran (dont Jaws) ne lisaient pas les title dans la configuration par défaut, qu'il fallait aller modifier les préférences pour que le logiciel les prennent en compte. C'est donc dire que la très grande majorité des déficients visuels qui ont recours à une technologie paliative pour faire une synthèse vocale ou une plage braille de la page passeront par-dessus "sans le voir" (car quel est le pourcentage d'utilisateurs qui va prendre la peine de paramétrer son logiciel, surtout dans la population des personnes avec déficience fonctionnelle) ? Cela me fait donc un peu hésiter à les utiliser pour des informations importantes, étant donné que les accesskeys servent majoritairement aux gens aux prises avec des besoins spécifiques (reconnaissons-le, qui prend le temps d'apprendre le panneau de navigation alternatif d'un site sans en éprouver un besoin fonctionnel). En fait, pour être plus précis, je n'hésite pas à les utiliser parce qu'ils revêtent un intérêt certain pour les voyants à cause de leur particularité de tooltip, mais pour ce qui est de passer une information de cet ordre, je préfère m'en remettre à une page dédiée à cet effet. Elle sera beaucoup plus fiable pour tout le monde. Cependant, utiliser l'attribut title permet de les présenter d'une autre manière... pas aussi fiable, mais complémentaire. À ta place, je continuerais donc à les utiliser dans l'attribut title si tu le souhaite, mais je réserverais uand même une page dédiée à ta politique d'accessibilité, comme le propose d'ailleurs DineIntoMark en dernier point : http://www.la-grange.net/accessibilite/day_30.html
-
Un petit document bien sympa que j'aime refiler à tous les amoureux inconditionnels du Flash dès que l'occasion se présente : http://patrick.murris.com/articles/flash25.htm Certains des arguments mis de l'avant dans cette liste sont moins pertinents que d'autres, mais l'essentiel de l'argumentaire contre le format Flash est très solide.
-
Bonjour 20cent, heureux de te retrouver ici... c'est toujours plaisant de croiser des personnes connues dans des lieux qui ne nous le sont pas encore. Demeure parmi nous je crois que nous allons bien nous amuser. Alors, comme c'est la coutume, permets-moi de te souhaiter la bienvenue dans le Hub !
-
20 000 messages en si peu de temps, c'est effectivement très impressionnant ! Considérant la qualité des échanges que j'y ai observé jusqu'à présent, je compte bien être avec vous encore pour célébrer le 200 000ième. Un forum en français qui fait une promotion des standards et de l'accessibilité, faut en prendre soin de ça ! Longue vie au Hub ! Longue vie au Hub ! Longue vie au Hub !
-
Super ! Merci. Je le note et l'ajoute à ma liste de ressources pour le grand jour !
-
Et bien, c'est parfait ça... et moins de boulot en plus, tu es gagnant sur toute la ligne. ! C'est d'ailleurs ce que la majorité des gens qui souhaitent supporter les idées émises sur OpenWeb page font... simplement pointer sur l'original. Félicitations, c'est du bon boulot que tu as fait sur ton site.
-
Ça me dit vaguement quelque chose... tu te rappelles de l'URL ?
-
Hummm... elle est passée ou, l'émoticône pour les gens qui parlent plus vite qu'ils ne réfléchissent ? Y'a pas de page rank dans la Mozilla googleBar. Tu peux conserver MSIE pour lem oment... mais je t'aurai à l'oeil dès que ce sera disponible !
-
Désolé, mais sans code à regarder, je ne vois alors pas du tout de quoi tu parles...
-
http://googlebar.mozdev.org/ Est-ce donc dire que je peux maintenant te compter parmi les utilisateurs d'un des nombreux produits de la famille Mozilla/Gecko mon cher ApocalX ?
-
Tiens, c'est flatteur ça... merci beaucoup
-
Si je comprend bien ce que tu dis, c'est une couleur de fond que tu souhaites se voir poursuivre indéfiniment vers la droite... Impossible de penser en terme d'agrandissement dans photoshop car tu ne viendras jamais à bout des configurations de tes utilisateurs (par exemple, je fonctionne actuellement avec une résolution de 1600x1200; te faire un immense photoshop ne règlera jamais le problème, sans compter que tes utilisateurs en 800x600 ne verrait que la moitié de ton design, si tu le faisais fixe à 1600 pixels de large. La solution est ailleurs. Si tout ce que tu souhaites faire, c'est de faire poursuivre une couleur de fond à l'infini à droite, il suffit de déclarer une couleur de fond au body de ta page par CSS. Quelque chose d'aussi simple que : body {background-color: #00f;} Que tu déclarerais idéalement dans un fichier externe lié à toutes tes pages, ou dans le head de tes pages, avec le code suivant : <style type="text/css" media="screen"> body {background-color: #00f;} </style>
-
Pas de problème, bien que je sois certain que ce sera correct. Je serai quand même bien curieux de voir le produit final si t'as envie de m'en faire part.
