Aller au contenu

Denis

Hubmaster
  • Compteur de contenus

    1 537
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par Denis

  1. Hummm... merci Monique, c'est trop d'honneur pour l'humble petit vermisseau que je suis !
  2. Si je puis me permettre d'intervenir sur la question Marie, je proposerais hônnetement de conserver ta décision d'y aller avec DotClear. Je crois que c'est une très bonne décision. Même si je ne l'utilise pas moi-même (je dois être un des rares à encore utiliser un système fait maison), j'ai plusieurs copains bloggueurs qui utilisaient d'autres systèmes plus connus comme MT et Blogger qui sont passés à DotClear dans la dernière année et qui en sont extrèmement satisfaits. Parmi les raisons évoquées pour les changements, d'affreux problèmes de services de BD chez Blogger et un sentiment impersonnel avec le système MT. De plus, l'auteur du logiciel, Olivier Meunier, est un type très bien, disponible et à l'écoute de ses utilisateurs.
  3. Et bien, je vois avec plaisir que tu as fait la réflexion nécessaire à propos des enjeux d'accessibilité... c'est vraiment super. Maintenant pour ce qui est de trouver le temps de le mettre en pratique, je sais très bien ce que c'est que d'avoir plus de choses à faire que de temps pour le faire ! On a beaucoup de bonne volonté mais peu de temps. Bon courage !
  4. Je ne connais pas de statistiques à cet effet, mais je considère que le simple fait que ce format de diffusion est promu à un bel avenir est une raison sufisante pour l'implanter et contribuer à le faire connaître. Personnellement, je le vends systématiquement à tous mes clients qui peuvent en bénéficier pour une raison ou une autre et j'en parle à tous les autres pour qui je ne vois pas priori un intérêt évident de l'acheter, ne serait-ce que pour les éduquer. Avec la prolifération du spam, pour ne nommer que ce fléau, je pense que d'ici quelques mois/années, le RSS (ou un dérivé éventuel de ce format) sera un incontournable sur le Web comme le sont aujourdhui les newsletters et applications dynamiques de communiqués de presse ou de nouvelles. Enfin, c'est mes deux sous canadiens.
  5. Et ça, mon cher ami et confrère, ça ne serait pas une bonne ligne directrice didactique pour un site comme OpenWeb ? Commencer à aborder les problématiques d'un angle pratique et réaliste, en prenant en compte les circonstances réelles dans lesquelles la majorité des développeurs construisent le Web ? P.S. : En passant, tu te lèves beaucoup trop tôt !
  6. L'oeuf ou la poule, la poule ou l'oeuf... peu importe comment on regarde le problème, on pourra toujours faire valoir nos opinions. La force du Web, c'est justement d'être un médium auquel il est relativement facile de s'initier. Prendre la décision de passer directement à un langage complexe et complet aurait pour effet de purifier le Web certes, mais surout d'en exclure la presque totalité des concepteurs de pages Web. La progression par étape n'est pas seulement importante, elle est essentielle pour que le Web demeure le médium du peuple et non celui des mégacorporations.
  7. Attention, les comentaires exprimés dans ce message risquent d'en offenser quelques uns, mais n'ont aucun autre but que de briser les mythes et de remettre les pendules à l'heure. Je te l'accorde, c'est ce que tout le monde dit et répète inlassablement, c'est le discours tenu par les évangélistes dont j'en suis, c'est le discours tenu par tous les OpenWeb et tous les wannabe Zeldman de ce monde. En vérité, ce n'est pas tout à fait vrai et il est temps que l'on parle des vraies faits... parce que continuer à diffuser cette idée trompeuse, c'est à nouveau mentir aux décideurs qui seront vendus à l'idée et la dernière chose que nous voulons, c'est que ces mêmes décideurs associent le mouvement de standardisation à toutes les autres bulles trompeuses, buzzwords et vaporware qui ont éclaté par le passé et ont contribué à réduire à néant la confiance des décideurs envers l'industrie du multimédia au tournant du siècle. Si pour un développeur expérimenté il est plus rapide de bien faire (tout conforme, standard et accessible), que de se forcer à mal faire avec les vieilles techniques du millénaire dernier, il en va tout autrement pour un développeur qui n'est pas ou peu expérimenté avec les méthodologies de développement standardisées et accessibles. Pour ceux-ci, arriver à bien coder un site conforme et accessible demande un effort et une adaptation considérable qui a inévitablement un prix, souvent très fort... il faut le reconnaître; faire conforme et accessible, ça coûte plus cher. Le vrai argument, c'est que malgré le coût supérieur, l'investissement en vaut pleinement la peine. Les plus audacieux, dont le designer Andy Budd, avancent que faire un site accessible a un coût associé d'environ 2% supplémentaire... c'est un pourcentage raisonnable pour un développeur expérimenté qui sait exactement ce qu'il fait et ce qui doit être fait systématiquement pour réussir à la tâche. Par contre, celui qui fait la navette entre le WCAG et son site, qui essaie désespérément de comprendre les messages cryptiques des validateurs et de trancher entre ses vieilles habitudes et des pratiques recommandables qu'il ne maîtrise pas ne pourra jamais faire un site conforme et accessible au même coût qu'un site fait selon ses vieilles habitudes. Par vieilles habitude, et c'est là que le bas blesse, c'est-à-dire n'importe comment, sans réfléchir à la portée de chaque octet de HTML lâché dans ses pages. Donc je résume simplement en disant que c'est faux d'affirmer systématiquement qe le développement conforme et accessible coûte moins cher... mais ça n'empêche en rien de valider l'intérêt de cracher les dollars supplémentaires. Frappez pas la tête s'il vous plaît !
  8. Oui, c'est vrai que tu marques un point là-dessus. Dans la mesure ou tu pourrais avoir une page multilingue, il y a forcément des décisions à prendre. Puisqu'il faut trancher, à ta place je me poserais la question suivante : vers quoi pointes-tu ? La structure du site ou son contenu ? Voilà qui devrait te donner une réponse pour la valeur du hreflang de ton hyperlien. Parce que honnêtement, je ne crois pas qu'il y est de vérités absolues dans un tel cas... il n'y a que des choix amenés par des réflexions éclairées.
  9. Ouais... Je serais bien curieux de mettre la main sur un document qui comparerait les deux outils et démontrerait les bases sur lesquelles les évaluations sont faites ; ce serait assurément très instructif et révélateur. Nous serions en droit de supposer que personne ne puisse être plus strict que le W3C lui-même pour ce qui a trait à l'application des règles... y'a t-il quelqu'un ici qui possède un élément de réponse ? Je demanderai à Karl Dubost s'il a une idée là-dessus la prochaine fois que je le verrai. Je pourrai peut-être vous revenir avec quelque chose un de ces quatres.
  10. J'ignore si cela peut véritablemet t'être utile compte tenu que je suis au Québec avec une devise différente de la tienne, mais ici dans mes mandats de freelance, lorsque je fais affaire avec mon designer (13 ans d'expérience en print, dont 6 en Web) qui s'occupe de tout mon print et de mes mandats de design, je le paie 50$ CAN l'heure. En euros, ça doit représenter quelque chose comme 31 ou 32 euros de l'heure, ce qui est peu cher en France, mais tout à fait respectable au Québec puisque le coût de la vie est beaucoup moins élevé ici que là-bas... Enfin, si ça peut t'aider tant mieux... Par contre, au boulot, lorsque mes employeurs sont mandatés pour un tel travail, ils chargent facilement un peu moins que le double. Au final, tout est toujours une simple question d'offre, de demande et de marché.
  11. Merci, c'est gentil. J'essaie de faire de mon mieux et de ne pas dire trop d'âneries. Pour répondre à ta question à propos du Breizh Power, c'est simplement que je développe CYBERcodeur.net avec un ami programmeur, Fabien Le Bars qui lui est Breton. Comme il a dynamisé l'ensemble du site (je suis un programmeur backEnd très limité, aux tout début le PHP était très simple), il convenait donc d'afficher une mention à cet effet suite à ses améliorations dynamiques, l'implantation d'une BD et l'ajout de fonctionnalités visant à rehausser l'interactivité sur le site. Moi mon créneau, c'est le frontEnd alors PHP, MySQL et tout le reste, ppffftttt...
  12. Et c'est justement pourquoi il importe de créer une couche entre le W3c, ses activités et ses recommandations et les acteurs qui seront éventuellement appelés à les mettre en pratique. Des associations comme AccessiWeb, AccessibilitéWeb, w3Québec, BrailleNet, OpenWeb, Pompage et les autres sont importantes parce qu'elle rendent les documents (disons-le) plutôt arides du W3C en textes et en idées plus facilement assimilables par le commun des mortels. C'est d'aileurs le même phénomène qui est observable avec les carnets Web qui parlent de standardisation... Il est beaucoup plus facile de s'initier aux standards et à l'accessibilité en lisant des weblogs qu'en se tappant les specs du W3C. En même temps, les dits documents du W3C n'ont pas pour mission d'être des documents fleuves, mais bien des recommadations techniques adressées à des gens techniques dans un langage technique. Ce n'est que lorsqu'ils sont vulgarisés par les initiés qu'ils deviennent compréhensibles pour le reste du monde. Ce n'est pas le rôle du W3C de rendre le tout facilement appropriable. Son rôle c'est de fournir la matière première et d'amener les actuers de l'industrie à arriver à des concensus ; c'est déjà assez !
  13. J'aurais dû être plus clair sur un point... quand je me prononce sur la question, je parle effectivement de XHTML, pas de HTML qui gère le tout différemment. Donc quand je déclare un lien en XHTML 1.1 (qui est mon langage de prédilection), j'utilise l'attribut hreflang avec la valeur appropriée (fr, en, es, it, etc.). Quand j'utilise un mot en anglais dans un document français par exemple, je l'entoure généralement d'un <em xml:lang="en"></em>, simplement parce que sémantiquement j'aime bien le spécifier comme ayant une emphase par rapport au reste du texte. C'est évidemment l'autre façon de spécifier le changement de langue.
  14. Non, pas du tout, je n'en ai ressenti aucun effet. Aux États-Unis bien sûr, comme tout le monde sait, ils ont la Section 508, mais ici au Canada, il n'y a que quelques minces efforts de suggestions comme celle dont tu fais mention, ou le Look and Feel Guideline, mais pas de vraies lois mises en place pour s'assurer d'un respect de l'accessibilité et des utilisateurs. Nous en sommes donc toujours aux bonnes intentions et dieu sait que ça, ça va jamais bien loin. Par contre, ces temps-ci, il y a un exercice gouvernemental au Québec pour (ré)organiser le futur gouvernement en ligne et le collectif W3Québec, que j'ai fondé et préside, a émi un communiqué à cet effet auprès du député responsable de mettre le projet en branle. Ce député, Henri-François Gautrin, a déjà rencontré des goupes de personnes handicapées qui ont fait valoir l'intérêt de l'accessibilité et comme le W3Québec est un collectif de promotion des normes issues du W3C, nous faisons valoir l'accessibilité comme l'un des éléments importants à prendre en compte lors de l'élaboration des méthocdologies de mise en place des pratiques Web du gouvernement québécois. Il n'y a donc rien de vraiment concret à ce niveau ici, ce qui me fait croire que nous ne sommes pas forcément plus avancés que nos cousins français à cet égard. Enfin, pour le moment, parce que je compte bien talonner le gouvernement jusqu'à ce qu'il entende raison ! Trois exemples concrets : 1 - http://www.cybercodeur.net/w3qc/w3qc_init03.php 2 - http://www.accessibiliteweb.org/ 3 - http://www.ledevoir.com/2004/04/05/51481.html
  15. Effectivement, en désactivant javascript de mon navigateur, je constate que même si je ne bénéficie plus du menu sur mouseover (normal), je peux tout de même les retrouver une fois rendu dans les pages... donc pas de javascript obstructif, simplement du javascript servant à enjoliver l'expérience pour ceux qui sont en mesure de le supporter. Et ça, c'est très bien. Cependant, l'utilisation de Flash elle, ne semble pas m'offrir d'alternatives textuelles ou d'images avec contenu alternatif dans un ALT, ce qui est bien dommage. Comme mon Firefox n'a pas Flash d'installé (volontairement), je suis donc un peu laissé en plan à ce niveau. Comme utilisateur bien sûr, puisque c'est mon choix de ne pas l'utiliser, c'est mon problème, mais l'utilisateur qui lui, n'aurait pas la possibilité de l'installer serait tenu à l'écart d'une partie du site. Et ça, c'est moins bien. Si je puis me permettre bien sûr...
  16. Hum... je peux donner mon avis même si je ne suis ici que depuis quelques heures ?
  17. Je me répète un peu d'un commentaire laissé dans un thread différent, mais je crois que la solution à l'émancipation des principes d'accessibilité ne passera jamais par la culpabilité de fermer ses portes à une personnes handicapée... encore moins lorsqu'on parle d'aveugles, puisqu'ils figurent probablement parmi les internautes les moins favorisés sur le web. C'est bien sûr le premier réflexe très naturel et humain que de revendiquer un web accessible à tous, mais au-delà des considérations morales, il y a la réalité financière qui est beaucoup plus forte, qu'on le veuille ou non. Un décideur en entreprise qui réfléchit à la possibilité d'investir le petit 2% estimé pour rendre son site moyennement accessible regardera pricipalement le retour sur son investissement, ce que son effort peut lui rapporter en terme d'argent. Cela lui apportera t-il vraiment des ventes supplémentaires ? Un meilleur impact dans ses affaires ? Bien sûr, il y a le retour sur investissement en terme d'image sociale, mais celle-ci ne fait malheureusement pas le poids dans la majorité des cas. Un excellent niveau d'accessibilité vient effectivement grandement en aide aux aveugles et autres personnes handicapées, mais ce n'est pas en essayant de les rendre victimes que nous leur rendont service. Par contre, en se mettant à promouvoir l'accessibilité pour les personnes vieillissantes servira un double emploi. Premièrement, il englobera un bassin beaucoup plus large, donc moins facilement misau banc et deuxièment, sans même parler d'eux, les handicapés en bénéficieront autant, tout comme tous les internautes qui seront mis en face de sites mieux construits.
  18. Effectivement, tu as tout à fait raison... C'est d'ailleurs pourquoi il serait très intéressant de pouvoir jeter un coup d'oeil au code pour savoir de quoi il en retourne et à quel point le dit javascript peut s'avérer obstructif. Et si oui, de voir comment il pourrait être adapté pour ne pas l'être. Au fait, je suis aussi ravi de te retrouver ici que tu l'es de me retrouver dans le Hub !
  19. Personellement, je travaille beaucoup avec des groupes de personnes handicapées, autant dans le cadre de mes activités professionnelles que para-professionnelles. Si je suis naturellement convaincu de l'intérêt et de l'importance d'offrir les contenus que je produit à tous les utilisateurs indépendamment de leurs conditions, je constate que l'accessibilité, pour vraiment passer auprès des entreprises et des gouvernements, doit tout d'abord mettre en contexte l'intérêt auprès des populations vieillissantes que des personnes handicapées. C'est très dommage, mais la bonne morale ne vend pas... la crainte de perdre un bassin important de clients potentiels (notamment la génération des baby boomers et celles qui les prècède et qui s'informatise de plus en plus à chaque années) incite beaucoup plus à la mise en place de principes d'accessibilité.
  20. Comme le dit Laurent, utilse la balise noframe pour offrir le contenu en alternative à ceux qui ne pourraient supporter les frames... et surtout, n'oublie pas d'utiliser l'attribut title dans chacun des frames pour permettre aux navigateurs alternatifs de lire ce qui se cache derrière le frame en question. Exemple : <FRAME SRC="mvbg_droite.htm" NAME="ZONE2" MARGINWIDTH=0 MARGINHEIGHT=0 NORESIZE TITLE="Description courte du frame, de ce que c'est"> Et au passage, de bonnes pratiques de code t'inciterais à mettre les valeur des attributs entre guillemets, même si tu utilises HTML 4.01 -- si tu souhaitais passer à XHTML 1.0 Frameset (j'avoue que c'est une autre débat), il faudrait alors également songer à écrire les attributs en minuscules et éviter de simplement écrire NORESIZE ; il faudrait écrire noresize="noresize". De plus, les attributs marginwidth et marginheight devraient être relégués à la feuille de style, pas au HTML puisque ce sont des éléments à fins de présentation, pas de structure d'information.
  21. Le problème est-il toujours existant ? Je serais curieux de voir quel était le problème puisqu'à priori je ne vois pas ce qui porterait entrave à l'accessibilité du site si le javascript ne sert qu'à des fins d'effets de présentation. Utiliser getElementById pour changer l'état du curseur lors de circonstances particulières ne devraient en théorie n'affecter en rien la disponibilité des contenus. Donc, l'utilisation de javascript ne porterait aucune entrave à l'accessibilité si le dit javascript n'est pas obstructif... là est tout le secret de combiner js et accessibilité
  22. Personnellement, je le spécifie toujours, même si la destination (l'URL) est dans la même langue que la provenance (la page Web). Comme je n'ai jamais trouvé aucune documentation nulle part à cet effet me disant le contraire et que l'attribut hreflang a définitivement sa raison d'être, je me suis toujours refusé à prendre la liberté de l'utiliser seulement lors de changements de langue. J'aime mieux prévenir que guérir. Quelqu'un détient-il une information complémentaire à ce sujet ?
  23. Je sais que ce message date de bien longtemps déjà, mis pour les biens de l'information, de l'archivage et du transfert de connaissance, je me permet d'y répondre quand même. Le validateur du WDG est intéressant comme outil, justement pour sa possibilité de valider plusieurs pages à la fois. Cependant, la mention est légèrement trompeuse puisque même si elle laisse entendre que le validateur puisse valider un site dans son entièreté, il est tout de même limité à 50 pages maximum. De plus, il se promène dans l'arborescence du site par les URLs, si bien que débuter une validation sur une page pointant que sur quelques autres pages limitera la validation aux pages qui peuvent être "crawlées". Le truc, c'est donc de commencer la validation à partir d'un sitemap si le site comporte 50 pages et moins, ou de différents points de départ dans le site pour en couvrir l'ensemble si celui-ci comporte plus de 50 pages. J'ai aussi remarqué qu'il est moins permissif que le validateur du W3C, aussi ironique que celui puisse paraître. Je me rapelle quelques occasions ou le validateur du WDC me notait une erruer là ou le validateur du W3C me garantissait une page conforme.
  24. Merci à toutes, c'est gentil. Quand je regarde vos numéros de membre et le mien, je me dis que j'ai probablement manqué le train quelque part ! Maintenant, me reste plus qu'à me familiariser avec les différentes sections et les rouages du forum.
  25. Alors, comme c'est la coutume et que ma maman m'a bien élevé, je me présente. Mon nom est Denis, je suis un carnétiste engagé/enragé qui maintient le site cybercodeur.net et s'efforce de vendre l'idée des standards Web et de l'accessibilité parotut ou je passe. Je suis québécois, je travaille professionnellement comme architecte web, conseiller en utilisabilité et accessibilité, développeur et quelques autres trucs que je réunirais modestement sous le titre de webmestre depuis plusieurs années. Voilà, c'est tout pour le moment. J'ai bien hâte de vous rencontrer sur ce forum... ça fait un petit moment que j'ai envie de recommencer à trainer dans un lieu comme celui-ci. Ben voilà...
×
×
  • Créer...