jpv

Pour appuyer matthieu, la balise alt est destiné à proposer une brève (!) description de l'image, la limite de 60 caractères est assez restrictive et offre peu de possiblité. Rien n'interdis d'utiliser les deux méthodes, une balise alt pour renseigner le sujet de l'image et l'attribut longdesc et/ou la méthode alternative du lien D pour apporter toutes les précisions nécessaires à la compréhension des informations portées par l'image. Il ne faut pas non plus tomber dans le travers de vouloir décrire toutes les images non-décorative (ces dernières devant se voir attribuer un alt vide), par exemple une silhouette de ville anonyme, en illustration d'un article, ne représente aucun intérêt pour l'utilisateur d'une plage braille ou d'un lecteur vocal... Les moteurs de recherche se contrefoutent de la longueur d'une balise alt, par contre la répétition systématique des mêmes mots clés dans les balises alt risque elle d'être très pénalisante... JP

Aux dernières nouvelles 5500 sites sont concernés par cette loi.

Sarc à raison, Une solution consiste juste à remplacer le float:left par position:absolute, pour extraire le div du flux. Après cela va dépendre des éléments qui devaient couler à l'origine à droite de l'image et que tu va devoir adapter pour eviter un effet de recouvrement. Petite question au passage, pourquoi créer autant de div "vide" avec des images en background ??? Le gabarit focntionnera tout aussi bien si tu positionnes directement l'image sans l'encapsuler dans un div. Même remarque pour les paragraphes qui ne contiennent que des images, ça n'à pas d'utilité...

Dans cette partie du forum on va quand même être obligé de parler un peu du code, tu à énormément d'erreurs graves et très génantes pour l'accessibilité. En l'état ce site est simplement totalement inaccessible, window eyes par exemple ne parviens pas à dépasser le premier menu qui est de plus illisible.. Sans rentrer dans le détail du code qui, désolé de le dire, mais est effectivement à hurler..., il y à des choses qui sont gravissimes, comme la carte du site en flash !!! La carte du site est souvent le seul moyen pour des handicapés de naviguer sur un site. Là tu propose une carte du site avec un design de la mort, qui ne fait plaisir qu'à MSD mais est totalement inutilisable... C'est d'autre part un peu pervers de proposer une disposition pour l'accessibilité inaccessible, un peut comme si tu mettais un panneau "rampe d'accès" qui amène à un escalier avec un petit panneau "bonne blague non ?"... Fin des hurlements... Concernant ton formulaire de recherche, le label doit être placés avant chaque élément de formulaire qu'il décrit dans le code HTML, après tu peux le placer où tu veux sur l'affichage graphique avec CSS, voir, sous condition de le tester, de les placer hors de la zone de display pour respecter ton design. Par contre il te faut te poser la question de l'ergonomie de ce formulaire. Ce n'est jamais une bonne idée de mettre des conditions avant le sujet qu'elles doivent discriminer. Pour le moment ce que tu propose ce résume à "A condition que... effectuer cette recherche", ce qui présuppose que l'on ait préalablement connaissance de la relation entre les conditions et le champs de recherche. Pour un utilisateur de navigateur vocal par exemple qui ne "voit" pas la structure du formulaire il lui faut le lire une première fois entièrement pour pouvoir l'utiliser... Ce serait sans doute une très bonne idée de proposer un enchainement plus "naturel" "Chercher... à condition que...". Là aussi en dissociant la forme du contenu tu pourrais parvenir à un résultat acceptable en codant ton formulaire de manière logique et séquencé dans le code html et en travaillant la présentation graphique avec CSS. Dernière remarque : quel est le rôle de la seconde séquence "et..." ? Je n'en vois pas l'utilité, un seul champs de recherche n'est_il pas suffisant ?

l'erreur est sur l'opérateur => qui doit être >= function chars(c) { if(c<=1) document.envoi_mail.len.value='Votre message fait '+c+' caractère'; if(c>=2) document.envoi_mail.len.value='Votre message fait '+c+' caractères'; } D'autres part tu à quelques erreurs de syntaxe sur ton appel de fonction, il faut écrire : <textarea onkeyup="chars(this.value.length);" cols="60" rows="7" name="message"></textarea> avec des guillements partout et l'event en minuscule. Enfin, tu n'es pas obligé de passer par un champs de formulaire pour afficher ton résultat, n'importe quel élément de texte peut convenir, par exemple un <p> ou un <span>. Cela evite de charger le formulaire d'éléments inutiles. function chars(c) { if(c<=1) document.getElementById('len').firstChild.nodeValue='Votre message fait '+c+' caractère'; if(c>=2) document.getElementById('len').firstChild.nodeValue='Votre message fait '+c+' caractères'; } Enfin tu devrais utiliser un navigateur comme mozilla ou firefox qui posède un débuggeur javascript, celui ci t'aurait indiqué immédiatement ton erreur. jp

Pour pouvoir répondre à ta question, il faudrais avoir le detail des fonctions. L'exemple que tu donnes ne constitue pas un script, ce sont de simples appels aux deux fonction getcookie et changefontsize. Sans le détail de ces deux fonctions on ne peux pas te dire grand chose... D'autre part, pourquoi à tu besoin d'utiliser une procédure javascript pour augmenter la taille de tes caractères ? Si la taille des polices sont exprimées en em, le visiteur à tout loisir d'en déterminer la taille par les menus de son navigateur. jp

C'est d'ailleurs assez paradoxal de constater que la prise en compte des thèmes liés à l'accessibilité du web n'est pas plus importante de la part des sites gérés par des handicapés ou par des entités concernés par le handicap que la moyenne. Aller jeter un oeil sur handicap international par exemple, qui bat des records en la matière... Il y à là le même besoin d'information et de pédagogie, même si, explications données les réactions sont généralement plus positives. Ca peut se comprendre de la part d'association ou de groupes informels qui sont souvent confrontés à des problèmes de moyens ou de compétences. Mais dans le cas d'une société comme Handica qui en aurait sans doute les moyens c'est effectivement assez surprenant. Ceci étant rien ne dit qu'ils ne soient pas en train de le préparer... Enfin il faut noter aussi que le sujet du concours ne concerne pas en propre l'accessibilité du web mais fait référence à des sites dont la thématique est lié au handicap. Un site totalement innacessible à donc toute ses chances. D'un certain point de vue ce n'est pas non plus très étonnant, handica est clairement un business sur le handicap (pas de connotation péjorative, je pécise au cas où...), c'est le responsable "marketing et partenariat" qui à fait l'interwiew du JDN et on peut constater que le partenariat avec visual friendly semble très actif (15 citations ou présentation de produits) pour 8 citations sur WAI/WCAG/braillenet... Il leur reste effectivement pas mal de chemin à faire, ou peut-être simplement de lire in-extenso la reprise des articles d'openweb qu'ils ont publiés sur leur site en novembre 2003 :)

Si tu à absolument besoin de le faire avec IE pour des raisons d'utilisabilité, une solution javascript vite fait : <script type="text/javascript"> function init(){ if(document.getElementsByTagName("a")){ for(i=0;i<document.getElementsByTagName("a").length;i++){ document.getElementsByTagName("a")[i].onfocus=colour; document.getElementsByTagName("a")[i].onblur=none; } } } //Couleur du focus function colour(event){ this.style.backgroundColor='#ff0000'; } //Pas de couleur function none(event){ this.style.backgroundColor=''; } window.onload=init; </script> à coller dans le head, ou mieux à placer dans un fichier externe. Avantage: Ca emule le focus sur l'element a pour IE. Inconvenient : Ca ne fonctionne pas sans javascript et c'est un chouia lourdingue. Ca ne t'empêche pas d'utiliser la méthode CSS. JP

Loin de moi l'idée de vouloir "descendre" quoi que ce soit ou qui que ce soit, ce n'est vraiment pas mon genre. D'ailleurs, pour en savoir plus, handica à été interwiewé par le JDN et je ne doute pas de leur volonté d'améliorer l'accessibilité du web. Concernant mes remarques sur leur site, elles ne sont qu'un simple constat me laissant penser que le sujet du concours ne semble pas intégrer les préoccupations basiques de l'accessibilité, et ça tombe bien puisque ce n'est pas son objet. Bon je pourrais rajouter le fait que dans l'interwiew il n'est jamais fait mention ni du WCAG, ni du référentiel de l'ADE, ni même d'accessiweb et que c'est bien dommage, une belle occasion de ratée... Ce qui donne des éléments de réponses à monique : Pour le concours je sais pas, pour l'interwiew je confirme... :) JP PS: La seule chose que je "descend" c'est labelvue que je traite de "béquille". Ca n'à effectivement rien à voir avec le sujet du concours, c'était juste un petit plaisir... Je ne sais pas si vous avez essayé ce système qui consiste à réécrire à la volée des pages "light" (produites par une plateforme serveur en abonnement ASP mensuel hors de prix) selon des profils utilisateurs nécessitant une inscription (adresse email + proposition de mailing publicitaire ) et donc la saisie d'un login à chaque visite de site, mais bon... Moi ça m'à laissé un peu dubitatif même si visual friendly qui produit labelvue semble plus sensible aux techniques du WCAG depuis quelques temps, quoiqu'ils continuent de proposer labelaffaire et un logiciel d'évaluation qui produit très cher des rapport plus que léger voir indi... Aaaaargh j'arrête le mauvais esprit me reprends...

Avec 30 failures dont 20 de niveau WAI/A, 4 iframes, du layout drag&drop et la béquille label vue, ça serait étonnant que le WCAG soit pris en compte

Heuu... Ce j'ai à te dire est un peut délicat et je ne voudrais pas que tu les prenne mal, on à tous débuté un jour, alors j'y vais sans détour : malheureusement, c'est un peut n'importe quoi ton script. Voici quelques conseils qui devrait t'aider : D'abord il faudrait savoir ce que tu veux faire avec ton menu, ensuite bien réfléchir à l'utilisation de javascript au cas où par exemple tu n'en ai pas besoin... Si toutefois tu penses avoir besoin de javascript il faut savoir ce que le script va prendre en charge, si c'est uniquement un problème de rollover la solution peut être extremement légère et innofensive pour ceux qui ne peuvent pas ou ne veulent pas utiliser javascript sur leur navigateur. Si ton ambition est de produire des effets d'arborescence, du type menu déroulant, alors appuie toi sur des codes déjà fait, adapte les à tes besoins et teste les. En outre tu dois répondre à ces éléments qui sont la base de tout bon développement javascript : 1. Ton menu doit être utilisable si javascript est désactivés par ton visiteur, tant que ça n'est pas le cas, ça ne sert à rien de l'implémenter. 2. Dans toute la mesure du possible (et c'est toujours possible) tes fonctions scriptées doivent être contenu dans un fichier externe avec un appel de ce fichier au chargement de la page. 3. Dans toute la mesure du possible (et c'est toujours possible) il faut recourir à la version standardisé de javascript, appellée EcmaScript. Comme tu le vois le chemin risque d'être un peut hardu en partant de ton code qui en l'état et ne le prends pas mal est à oublier dans sa totalité. Ne serait-ce que parcequ'il à le terrible handicap de produire la structure HTML de ton menu, ce qui fait que sans javascript ton menu n'apparait simplement pas... Je manque de temps pour te donner des liens pour commencer ton apprentissage, je repasserai plus tard le faire si toutefois les hubiens ne l'ont pas fait avant moi jp PS: ha si il y à le lien donné par monique dans un post : Menu Ecmascript mais qui est en anglais Ou chez Raphael : Alsacreation - tutoriels Dans la section construction de menu Commence par visiter ces resources ce qui devrait t'aider à déterminer la réalité de tes besoins et trouver les bases nécessaire pour écrire le script de tes rêves

_AT_manu&marc : Effectivement, certains sites seront des cas particuliers En fait la réalité du terrain c'est plutôt que chaque site est un cas particulier... Dans les missions d'audit que je mène, je m'interesse d'abord à la structure du site et au layout avant même de plonger dans le détails des adaptations, car il est souvent très facile en modifiant l'architecture des pages et la gestion du flux de résoudre énormément de problèmes sans avoir besoin de les traiter ultérieurement par le WCAG 1.0. Pour ne prendre que cet exemple, exprimer des listes de lien avec des éléments de listes fixe la règle des liens adjacents sans qu'il soit nécessaire de recourir au célébrissime "pipe", sans modification notable du design. Je suis venu à l'accessiblité par l'entremise d'une amie tétraplégique utilisant un head-stick et pour cette sorte de public la navigation internet est un véritable défi, face aux improvisations des architecture de liens. Quand aux accesskey ils sont très difficilement utilisables pour les handicaps moteurs, même si ils sont correctement implémentés. Essayez avec un seul doigt de déclencher un accesskey numérique avec le clavier en mode "accessibilité", vous vous rendrez compte de la bonne blague... C'est pourquoi je suis toujours un peut méfiant quand accessibilité= mal et non-voyants car on ne règle qu'une partie du problème (Il y à plus de handicaps moteurs que de non-voyants) Accessiweb n'est pas une nome ni une pseudo-norme mais selon la définition qu'en donne l'ADAE une "méthode d'application" reprise in-extenso dans son référentiel qui va servir de cadre d'application des futurs décrets. Braillenet fait du super boulot, surtout en terme de sensibilisation, mais on peut regretter que leurs grilles d'évaluations se focalisent essentiellement sur les handicaps visuels (c'est leur coté braille) et n'apporte pas autant d'importance à l'utilisation de langages standardisés et de leur répercussions éminement positives sur le layout. En tout cas, bravo pour votre travail et M... pour la suite...

Tel qu'll est donné ton lien peut indifféremment être lu dans un lecteur de fil, inclus dans une page html ou être récupéré par une fonction de traitement. Du coup avoir cette notion de "qui l'utilise' est très difficile. De plus il faudrais préciser ta demande, tu veux savoir qui reprend ce lien sur leurs pages ou qui utilise ton lien pour afficher des informations sur leurs page. Dans le premier cas une recherche de backlinks sur google peut peut-être t'apporter des réponses ponctuelles. Dans le second cas, il te faut encapsuler ton flux xml dans un processus d'authentification à l'image des marqueurs des services de statistiques.

La question des liens "retour" est un cas d'espèce à ne pas généraliser, dans la mesure où ça viens se rajouter d'une part à la fonctionnalité page précédente du navigateur et d'autres parts aux fonctionnalités propres au logiciel adapté utilisé par le visiteur mal-voyant. Tous les lecteurs d'écrans et navigateur vocaux possèdent leur propre gestion de l'historique ainsi que leur propres raccourcis. Il apparait donc inutile de rajouter, en plus de ces mécanismes logiciel un lien "retour" généralisé, si celui-ci n'apporte rien de plus à ces mécanismes natifs. Par contre il peut être très pertinent d'utiliser un lien retour pour revenir à l'origine d'un processus d'enchainement d'action. Par exemple une série de formulaire enchainé à tout intérêt à utiliser un dispositif de ce type pour pouvoir revenir à l'étape 1. Très utile également dans le cas d'affichage séquencé de type slideshow intégré à une page. La remarque vaut également pour le fil d'ariane qui est rès efficace dans une structure linéaire simple (page-rubrique-sous-rubrique) mais deviens plus difficilement gérable si la structure deviens plus complexe. N'oubliez pas que les logiciels adaptés possèdent leur propre gestions de l'historique de navigation qui sera plus familier à l'utilisateur. Une bonne définition du titre des pages et un plan du site suffiront dans la majeure partie des cas, sans qu'il soit nécessaire de doubler ce dispositif "simple" par des dispositifs annexes plus sophisitiqués. Là encore la généralisation est délicate, si il est souhaitable qu'un élement de menu ne contienne pas trop (trop combien ?) d'items, il est par contre fortement déconseillé de créer artificiellement des arborescences inutilement compliqués pour restreindre le nombre d'items d'une liste de menu. Par ailleurs cette remarque est en contradiction avec la carte d'un site qui est, par définition, la page contenant le plus grand nombre de liens internes du site. Par exemple, accessiweb à formalisé cette approche en mesurant et en rendant "obligatoire" les limites de 9 catégories pour l'arborescence d'un menu et 40 liens pour le nombre de liens de la page "hors liens de navigation". Le WCAG 1.0, référence d'accessiweb ne donne aucune limite, mais note simplement que la navigation doit être cohérente. D'aure part ces limites sont par essence innaplicables, par exemple le grand chalon, labellisé accessiweb OR possède au moins une page possédant plus de 40 liens hors navigation. Si on applique stricto-sensu la regle des 9 catégories à un annuaire, ou un catalogue en ligne comment fait-on ?, certains catalogue ne pouvant pas se réduire à 9 catégories, problème encore plus ardus avec un annuaire généraliste. C'est le grand avantage du WCAG 1.0 qui de ce point de vue demande à l'auteur d'interpréter ces règles et de les adapter à la réalité du contenu. Il faut donc faire très attention de bien faire comprendre que ces dispositfs et ces recommandations doivent être analysés en fonction de la réalité du contenu et du projet éditorial, faute de quoi on prends le risque de faire apparaitre ces dispositions comme restrictives, ce qu'elles ne sont pas, en tout cas dans l'esprit du WCAG 1.0 Je persiste également à penser que focaliser l'accessibilité sur les mal-voyants est une approche dangereuse en ce qu'elle ne permet pas d'évaluer les dispositifs à mettre en place dans leur globalité et que d'autre part les dispositions spécifiques à ces autres handicaps sont notoirement insuffisants comme la gestion calamiteuse des accesskey par exemple. Et plus généralement cela me parait un chouia discriminatoire..

En vrac... C'est une évidence que le web de "monsieur tout le monde" qui semble dans vos propos être au web ce que la ménagère de moins de 50 ans est à la télé, n'est que très modérement concerné par les standards et la normalisation. Mais enfin cela reviens à dire que les normes comptables ou financières ne sont d'aucune utilité et n'ont aucune chance d'être adopté au prétexte que monsieur tout le monde n'à que faire d'un bilan ou d'un compte d'exploitation. Je suis bien d'accord de considérer que le HTML de monsieur tout le monde ne disparaitra pas mais je ne vois vraiment pas pourquoi cela rendrait caduque l'ntérêt des standards. Il y aura par contre un effet évident à l'adoption massive des langages standards et particulièrement des dialectes XML, c'est d'une part une professionnalisation accrue des métiers du web et d'autres part l'emergence d'espace web plus différenciés. Tout à fait d'accord mais du HTML Transitionnal est parfaitement normatif. En attendant que des expériences comme celle de Nvu deviennent suffisemment convaincantes. Et c'est donc une excellente nouvelle que certains d'entres aux, google en tête, se montre si bienveillants vis à vis de la standardisation, si l'on en juge par l'intérêt que porte les sociétés de référencements à l'effet de ces normes sur le réferencement. Et pourquoi ferait-ils ça ??? Quel serait leur intérêt, reconnaissons que ce serait quand même particulièrement hasardeux pour ne pas dire plus. Les équipes de developpement des moteurs ont un interêt objectif à ce que les langages standards soient massivement adoptés, ça ne peut que les aider à produire de meilleurs résultats, alors pourquoi auraient-ils cette idée saugrenue, qui leur demanderaient en outre un énorme travail pour finalement obtenir le même résultat, c'est à dire une meilleure indexation. Par contre on pourrait envisager avec la généralisation d'XML et d'XHTML modulaire que certains d'entres eux soit tentés de recourir aux namespaces pour capitaliser une "clientèle", c'est sans doute de cette idée que se rapproche le plus la grande affaire du nofollow... Je veux bien, de temps à autre, sortir de ma naiveté béate pour me frotter au réel mais de là à adopter une attitude systématiquement paranoiaque à base de complots souterrains ourdis par des superpuissances du web, il y à un pas que je ne franchis pas, c'est une des forces du web que d'être difficilement controlable et un des intérêt principaux des standards de nous débarasser des tentatives hégémoniques... Les standards du W3C sont appuyés sur l'idée que tout le monde y à intérêt, même monsieur tout le monde qui s'en contrefout. Et parmis ces acteurs les moteurs de recherche sont en première ligne et je n'en connais pas un qui montre une quelconque réticence. MSN Search par exemple même une expérience consistant à générer ses résultats au travers d'un flux XML, en loccurence RSS. MSN c'est redmond et on ne peux pas les soupconner de la moidnre intention philantropique, c'est plutôt une amorce de capitalisation de ces "nouvelles" technologies et c'est quand même savoureux de constater que la plus hégémonique des sociétés mènent une expérience "de pointe" fondé sur un sandard W3C... D'autres parts des protocoles comme SOAP, la technologie d'annuaire UDDI, WSDL et plus prêt de nos préoccupations, entre IBM et madame michu, des grammaires comme RDF et des formats comme RSS sont massivements répandus et massivement utilisés, un acteur comme un moteur de recherche qui déciderait de sortir de ces domaines pour bricoler ses propres méthodes dans son coin risquerait fort de se retrouver bien seul. Et pour les éditeurs de sites web commerciaux ou professionnels la question n'est pas "a quoi bon les standards" mais plutôt "Quand faudra-t_il le faire" ou alors je n'ai rien compris à la notion d'évolution... Bon évidemment parler à madame michu de SOAP voire de RSS pour son site sur son dernier voyage au mont st michel, évidemment, vu de ce coté de la lorgnette le W3C est équipé d'une chasse d'eau ou d'un broyeur et SOAP est aux légumes ou au pistou...

En relisant mon post sur le web sémantique, je me rends compte que faire ce raccourcis fulgurant entre le détournement de balisage et des concepts comme le web sémantique et l'ontologie était peut-être un peut violent, ce sont il est vrai des thèmes encore très "techniques", même si, sur le fond ils sont beaucoup plus simples qu'il n'y parait. Je venais en fait de visiter une page expliquant comment construire des fils RSS, bourrés de mots clés, pour créer du page Rank, et de nouveau je me suis laissé prendre au jeu de la colère... Désolé pour ceux que ce post à pu indisposer... Ben c'est justement actuellement que, plouf !, tu dois faire toi même le tri d'une liste de résultat non ?. Plus la pertinence des moteurs est affutée plus les résultats vont correspondre à l'objet de la recherche, donc moins il y aura de chances de tomber sur des résultats hors contexte. La pertinence n'est pas une valeur quantitative, ramener le plus grand nombre de résultats, mais qualitative, le moins de résultat mais les plus pertinents. Tu cites le terme de contexte, et c'est justement un des grands problèmes des moteurs que de pouvoir évaluer le contexte de ce qu'ils indexent. Quand on dit que les pages dont la structure et le balisage est normalisé réagissent mieux sur les crawls des moteurs, cela ne veut pas dire qu'elles seront mieux placées, mais que les algos des moteurs bénéficieront d'un matériel de meilleur qualité , d'un meilleur étalonnage et par exemple en s'appuyant sur une hiérarchie de titre pouvoir mieux pondérer l'indexation ce qui aura pour conséquence d'accroitre le potentiel discriminant des requêtes sur ces pages. C'est en ce sens que l'effort est important, pas pour se fondre dans une "pensée unique" dictée par je ne sais quelle mystérieuse entité, mais simplement pour élever la qualité purement technique du matériel à disposition des moteurs. Il est vrai que j'ai la dessus une position très tranchée, je trouve particulièrement improductif de concentrer de l'énergie et, souvent des bagages techniques intéressant à exploiter le détournement des règles du jeu d'un système qu'on utilise. Au risque de me faire taxer de gestapiste, si on applique stricto sensu ce raisonnement aux messageries alors on justifie le spam au prétexte de refuser l'exclusion... D'ailleurs, je n'arrive pas à comprendre en quoi les normes des langages web seraient en quoi que ce soit exclusives. C'est le contraire, car en définissant un cadre commun, elle libère internet des technologies et des usages propriétaires. Cela va même plus loin puisque le W3C à, évidemment, pensé à assurer la rétro-compatibilité avec les méthodes et usages traditionnels. Par exemple si tu te sens plus à l'aise pour utiliser un frameset ou un iframe, éléments "exclus" des normes strictes, tu peux non seulement continuer à les utiliser mais en plus tu peux le faire dans un cadre normatif, que demander de mieux. Et en poussant le bouchon si tu veux faire une page en HTML 3.2 tu peux le faire aussi. Je commence à avoir une expérience non-négligeable dans ce domaine et je ne me suis jamais trouvé dans la situation de devoir dire à un éditeur de site, "ha ben non, ça là on ne peut plus le faire, désolé c'est la règle", même si ça demande souvent une certaine dose de patience pour trouver la bonne manière de le faire. Et j'aimerais quand même qu'on m'explique comment utiliser la balise H pour tenter de surqualifier du contenu est d'un quelconque intérêt pour qui que ce soit... C'est une remarque intéressante, mais je crains que ce soit plus du domaine des peurs irrationnelles. Pour un moteur de recherche, vouloir orienter ses résultats dans un sens ou dans un autre serait suicidaire. Je veux dire que le jour ou sera démontré que google oriente ses résultats il y à fort à craindre que son utilisation décroisse rapidement. Quel serait ta réaction si tu savais ça ? tu continuerais d'utiliser google ? Encore une fois je prends le contre-pied de ta remarque, c'est à l'heure actuelle que l'information cachée et pourtant très pertinente est difficile à atteindre. Une thèse isolée et archivée dans un serveur web d'université, n'à aucune chance à l'heure actuelle de sortir en bonne place sur une liste de résultat. Elle sera systématiquement supplantée par des études ou des ouvrages, le plus souvent payant, parce que son éditeur aura sus trouvé l'expert capable de le positionner, quitte à utiliser les failles du système. Maintenant, dans un cadre normatif, où tout le monde (je suis un grand rêveur) respectent ces normes qui sont plus du domaine du bien commun que de l'injonction réglementaire, cette thèse aura de bien meilleures chances de sortir sur une liste de résultat. Tu sais sans doute comme moi qu'il est toujours assez intéressant d'aller fouiller au delà des premières pages au cas où le document qui réponds parfaitement à ta recherche ne s'y serait pas glissé... Par contre ta remarque est intéréssante, il est vrai que la normalisation donnerait plus de "pouvoir" aux moteurs en ce sens qu'ils auraient plus de lattitude pour controler leurs résultats. Et c'est là où redébarque le web sémantique, car dans ce projet les résultats des moteurs ne deviennent eux-même qu'un matériel, parmis d'autres, utilisé par un agent unique et personnel dont tu à le controle total, qui entretiens une base de connaissance qui te correspond et appartiens à une "famille" que tu choisis en le liant à tes amis et connaissances sur laquelle il pourra s'appuyer pour être encore plus efficace, comme tu appelles un ami quand tu es dans une impasse. Un petit google perso en somme, mais bien plus évolué car capable non seulement de trouver l'information mais encore de la traiter selon tes besoins. Science Fiction ? troll ? exagération ? Pas vraiment, les technologies existent, RDF en est une des briques et XML sa base grammaticale, le potentiel existe, on trouve tout sur le web. Reste à préparer cette masse d'information lisible par l'homme, un peut moins si il est handicapé et pas du tout ou si peu par les machines. Et le pire c'est que quand-même ce n'est pas si difficile, apporter une structure "sémantique" et technique commune et pour le (X)HTML véritablement "basique" en respectant un minimum de normes, sur lesquelles s'appuient ces futures technologies ne me parait pas être un effort monstrueux, pas plus qu'elles ne nécessitent qu'on abandonne quoi que ce soit de sa liberté ou de sa créativité. Evidemment, dans ce contexte, le détournement de balisage et le refus idéologique de recourir à ces normes, je ne parle pas de leur ignorance ce qui es tout autre chose, viens un peut saloper le travail... Toute ces remarques ne concernant que ce thème des standards et du référencement, parceque utiliser à mauvais escient le balisage diminue l'accessibilité du contenu et ça c'est, encore un autre débat.

Loin de moi, l'idée de vouloir assimiler les référenceurs à des escrocs, bien au contraire, mais un référencement basé sur du détournement de balisage comme du reste du cloaking, du farm link ou du pollupostage de commentaires, oui je veux bien assumer le terme Il suffit de googler "référencement garanti" pour s'en rendre compte. C'est ce qui c'est passé pour les métadonnées, même si je reconnais volontier que les "référenceurs" n'en soient pas les seuls responsables, mais enfin, ce ne sera pas vous faire injure de vous rappellez les techniques d'optimisation des méta données de la fin des années 90... Le vrai problème du détournement de balisage c'est que le recours à ces techniques en diminuant la portée de la sémantique créé cette situation très paradoxale : plus il y aura de détournement plus la pertinence des listes de résultats sera amoindrie, plus il sera difficile de réferencer et ipso facto, plus le recours à ces techniques sera massif. D'ou ma réaction un peut vive sur cette approche de l'utilisation des standards qui consiste à exploiter ses failles au lieu d'exploiter ses bénéfices naturels, particulièrement en terme de référencement et d'efficacité des moteurs de recherche. L'ambition du W3C est de proposer un ensemble de techniques et de standard qui permettraient de faire évoluer le web, ambition résumé par la citation de Tim Berners Lee (Je cite de mémoire) : Dans ce monde idéal, le métier de référenceur ne serait-il pas plus intéressant ? positionner du contenu, tracer des ontologies, qualifier des audiences, utiliser le potentiel de l'IA c'est quand même plus exitant que trouver la dernière astuce qui tue la mort non ? Quel rapport avec la balise H me direz vous ? Le rapport est fondamental parceque l'une des première étapes de ce projet passe par une normalisation des langages et des usages afin de disposer d'un matériel adéquat et préparer l'avenir, en plus des autres bénéfices mille fois cités... Par voie de conséquence chaque fois que vous utilisez sciemment une balise en la détournant de son usage vous sciez la branche sur laquelle vous êtes assis et vous freinez l'évolution du web. La normalisation des langages web est une oeuvre "babylonienne" de longue haleine qui s'annonce difficile si on tiens compte du facteur humain, alors c'est vrais, je veux bien le reconnaitre, la permanence de ces tentatives de bidouilleur çà me fout les boules, milles excuses... PS: En passant pour ceux que ça intéresse : Traduction de l'interwiew de Tim Berners Lee sur le web sémantique. et Article du JDN sur le web semantique

_AT_lafleur : Ben je vois pas comment qualifier autrement le fait de vendre des prestations fondées sur des tricheries... D'autres parts il y à eut des condamnations, le fait par exemple de citer une marque concurrente dans une balise de keyword est un délit... Mais, bon comme cet aspect des choses n'à pas de rapport avec le sujet je te propose de clore notre échange là dessus afin d'éviter de surcharger le fil, ou d'en ouvrir un autre à ton bon plaisir.

Pourquoi vouloir limiter l'accès à ces techniques à "monsieur tout le monde" ? Après tout il sera bien libre de choisir, du HTML Transitionnal au XHTM Strict, et au moins ceux qui veulent tenter l'aventure auront un outil adapté. J'y vois moi plutôt une bonne idée, du point de vue de la promotion de ces techniques, même si faire du XHTML en WYSIWYG, sur le papier ça parait vraiment difficile... Ceci dit, il est vrai qu'on pourrait plutôt souhaiter que Nvu se concentre d'avantage à optimiser encore son moteur d'écriture de code qui bien que donnant des résultats satisfaisants souffre des défauts inhérents au WYSIWYG...

Tout dépends du but du détournement, des experiences comme l'utilisation de la valeur "nofollow" dans un attribut "rel" sont envisageables ou en tout cas discutables en ce qu'elles tente de résoudrent un problème. Mais des détournements qui consistent à tenter d'abuser un moteur de recherche par exemple sont absolument condamnables, puisqu'en terme très clair il ne s'agit de rien d'autre que d'une escroquerie. Pour ne prendre qu'un exemple, le détournement de la metabalise keywords par les référenceurs à aboutis à sa dépréciation par les moteurs de recherches, au détriment des utilisateurs, qui doivent se farcir la pollution permanente des listes de résultat par les "expert en détournement et allez vous faire foutre" catégorie dans laquelle, j'ose l'espérer, tu ne te ranges pas. Il en va de même du détournement de la balise H ou strong, des fusions de texte sur la couleur de fond, de l'abus des propriétés hidden, j'en passe et des meilleures. Si un "référenceur" n'est pas capable d'assurer la pérénité d'un référencement et une place honorable dans une liste de résultat avec des moyens normaux c'est qu'il es simplement nul et qu'il lui faut changer d'orientation au lieu de pourrir la vie de tout ceux qui essaient de faire correctement leur job. Et je me suis retenu pour ne pas paraitre tenir des propos "exagérés".

Bonjour, C'est l'inverse, c'est parcequ'ils apportent un minimum de rigueur que les standards tendent à transformer ce qui n'étaient que du bricolage en véritable standard de développement. Et pour faire echo a ta remarque sur le XML, l'un des buts de cette normalisation est de préparer l'ère du tout XML, avec des langages hybride comme XHTML. D'ailleurs en passant XML sans une couche d'interprétation ne sert pas à grand chose, et si tu parcours les specs d'XPATH ou d'XSLT, là tu vas comprendre ce que rigidité et standards de développement veux dire... Ben justement, il n'y en aura aucune, le propos d'un H1 n'est pas de spécifier un titre de page, mais le plus haut niveau de la hiérarchie de titre. Il est souvent naturel qu'un titre de page soit le titre de plus haut niveau mais ce n'est pas une fatalité. Du point de vue de la sémantique peut importe qu'un élément H1 soit un titre de page ou un titre de section, ce qui importe est de déterminer une structure hiérarchisée. Il est par contre fondamental que tous les éléments de même niveau soit hierarchisés avec le même marqueur. C'est la seule "rigidité" de la méthode qui présente l'avantage d'être d'une logique inoxydable. Et si tu rencontres des soucis à établir une hierarchie satisfaisante c'est que, probalement, ton contenu n'est pas lui même suffisemment structuré. Pour les listes appliqués au menu, la réponse est effectivement plus ambigue, mais il serait évidemment assez stupide de construire une simple collection de liens avec une liste de définition, d'ailleurs ce serait techniquement impossible. La question est différente avec un menu de type section/rubriques, mais là c'est le manque de rigidité qui pose problème, car l'interprétation des spécifications n'interdis pas d'utiliser une structure de liste de définition si l'on considère que l'ensemble des rubriques d'une page s'apparente à la définition de la section les contenant. Personnellement je trouve cet usage peut pertinent car il tends à dévaloriser la sémantique formelle d'une liste de définition, là c'est un exemple ou justement plus de rigidité ou disons plus de clarté des spécifications eut été souhaitable. Il est vrai que ce genre de "complexité" peut se rencontrer mais cela reste exceptionnel. Mais cette rigidité et cette structure de normalisation a tendance justement à rendre plus complexe le développement de certains types de pages qui ne nécessite pas autant de d'immobilité. J'ai beau chercher je ne vois aucun exemple illustrant ce propos. Pour ne prendre que cet exemple un langage comme XHTML est quand même beaucoup plus simple à apprendre, à manipuler, à maintenir et à developper que les versions non standardisées d'HTML et son lot infernal de balises et d'usages propriétaires. Et puis, dire qu'un titre est un titre, un paragraphe un paragraphe et qu'une liste est une liste c'est quand même intelligent avant même d'être normatif. Quand on y reviens, ça évite au moins de se poser la question et ça c'est vachement plus simple... Aprés tout, une liste de post n'est elle pas qu'une suite de données indexées par rapport à un sujet (h1) initial ? (et donc réalisable à partir d'affreux <table>) Tu à raison, c'est juste qu'éviter d'utiliser des tables, si ce n'est pas pertinent, c'est plus d'efficacité, plus de souplesse, plus de sémantique, plus de rapidité, plus d'accessibilité, plus d'interropérabilité, et juste pour caser un moins dans cette liste non-exhaustive d'avantages c'est moins de charge de code et ça c'est un vrai, un grand, un immense bonheur... Je trouve que là est la limite du w3c, de l'accessibilité et de la standardisation bien que j'y sois, je le rappelle, complètement adhérent ! La seule limite c'est la force des habitudes d'une profession somme toute encore assez jeune. C'est sur que sortir tout frais d'une école de webmastering où l'essentiel de l'apprentissage à consisté à prendre en main l'interface de dreamweaver ce qui n'à qu'un très lointain rapport avec le développement web et se rendre compte qu'il faut réapprendre ça fout les boules. Quand à considérer que l'accessibilité est une limite c'est comme considérer que les places de parking handicapés sont une limite au droit de se garer, syndrome il est vrai assez répandu et qui mesure le chemin qu'il reste à parcourir...

De toutes façons l'utilisation abusive de balises H, ou tout autre d'ailleurs (comme la folie des strong il y à quelques temps) pour escroquer les moteurs de recherche est particulièrement puérile... Il ne faut pas prendre les équipes de développement de google pour des imbéciles... _AT_Lafleur: Tu es évidemment libre de contester l'autorité du W3C, ça ne risque pas de gêner grand monde vu que le W3C n'à aucune autorité, c'est bien ce qui fait sa force. Quand à la légitimité de détourner des techniques créés pour améliorer la nature du web, ça ne peux qu'être une source de motivation supplémentaire pour accélérer la normalisation qui à, entres autres but, de débarasser internet de ce genre de parasitage.

Pourquoi restreindre le questionnaire à l'accessibilité des "mal-voyants"... L'accessibilité ne concerne pas que les déficits visuels mais aussi les déficits moteurs et cognitifs. Par exemple la gestion de la navigation au clavier est un élément crucial d'un site web qui veut être accessible. De même les enchainements d'action sur les formulaire et la navigation interne sont des éléments à prendre en compte pour tous les déficits cognitifs... Dernier exemple la taille de certain lien image ou la nature et la gestion des actions de focus sur les objets de la page sont également un point très important. Certe, les déficits visuels sont les plus caractéristiques et bénéficient de toutes les attentions en terme d'accessibilité, ce qui est nomal, mais il ne faudrait pas que cela soit fait au détriment des autres handicaps. Votre projet de fin d'étude si il ne concerne que le handicap visuel risque fort de louper sa cible, confère la citation de Tim Berners Lee sur ce sujet :

Bah en fait, j'avais mis un double retour parce que je pensais que ça appartenait quand même à un même paragraphe, malgré une toute petite distance... En fait, je pense que je voulais pas faire de paragraphes d'une ligne, donc rattacher à un autre Tu es seul juge de la structure de ton texte, néanmoins si tu es obligé d'utliser deux br successifs, le paragraphe n'est pas loin... J'ai commencé sur la page sur la luminance mais ça me pose un petit problème : maintenant, le CSS pour les liens:hover ont été rajoutés sur tous les titres... C'est très laid ! Je dois rajouter deux class dans le CSS pour enlever ca, ou il y a un moyen de le faire autrement ? Il te faut faire une classe dédiée, soit pour ces liens, soit pour les liens du menu . Ces liens ne répondent pas au "problème" mais garde les ils sont bien pratiques... Les liens de navigation interne sont plutot dédiés à faciliter la navigation entre les grandes parties de la page. Par exemple ton lien "haut depage" est un lien de ce type. L'ideal est de placer, en haut de page des liens d'accès rapide pour toutes les grandes structures de la page. En ce qui te concerne c'est "contenu" et "menu" et d'affecter un attribut accesskey pour crééer un raccourcis clavier. De cette maniere, où qu'il soit, un utilisateur handicapé, particulièrement un handicapé moteur pourra, en utilisant la touche de raccourcis, accéder directement au contenu, par exemple aller directement au menu ce qui lui évitera de devoir passer un à un tous les lien de la page avec la tabulation jusqu'à parvenir à la liste de liens du menu. Tu viens de m'apprendre un nouvel attribut... Effectivement, ca peut paraitre interessant pour mon site L'attribut longdesc, référence un lien vers une page contenant une description textuelle de l'image. Donc c'est de la forme : <img src=""... longdesc="description.htm" /> Mais cet attribut n'étant pas universellement supporté il te faut également le doubler d'un "lien D" qui consiste à répéter le lien vers la page de description juste après l'image. Plus que de grande explication va visiter cette page et ragarder, dans le code et sur la page comme est traité la description alternative des images. Exemple Donc faire une page html je suppose ? J'avais seulement mis un lien vers les images... Absolument de toute manière c'est mieux Ce qu'il te faudra faire c'est implémenter un longdesc et un lien D sur le même modèle que précédemment. Pardon ? J'ai pas compris ça... :/ Cela concerne la tabulation, un utilisateur privé de souris devras pour atteindre un lien particulier utiliser la tabulation. Il faut donc vérifier que les liens de ta page se présente en "ordre logique", ce qui est souvent le cas si la structure de la page est également "logique" et c'est ce qui pose de redoutable problème avec la mise en page par tableau. Si l'ordre que tu obtiens est sstisfaisant tu n'à rien à faire, sinon il te faut déterminer l'ordre toi-même avec l'attribut tabindex surle modèle : <a href=""... tabindex="n" /> Note importante : Cela concerne aussi les champs de formulaire, et plus généralement tout objet sur lequel tu peux obtenir un focus. Le WAI est le département du W3C en charge de la promotion des recommandations et des techniques destinés à faciliter l'accès des contenus électroniques aux handicapés. Pour les contenus web la référence est le WCAG (Web Content Accessibility Guideline) qui date de 1999 Pour te renseigner plus avant sur ces techniques indispensables, tape "accessibilite web" dans google ou consulte le forum accessibilité ici... Ces techniques sont absolument indispensables car internet, représente un enjeux capital autant qu'un outil indispensable pour le confort de vie et l'intégration sociale pour tous ces publics... JP

Pour commencer (je n'ai pas tout regardé en détail): Rajouter l'indication de language sur la balise htm : <html lang="fr"> Cela aidera les screen readers à choisir le bon fichier de langue à utiliser. Remplacer les double retours de lignes par des fins de paragraphe, c'est quand même plus logique. Réfléchir à l'utilisation des emphases strong sur les liens du menu. La plupart des screen readers réagissent à ces balises en modifiant le ton de la synthèse vocale, il est donc nécéssaire que leur emploi corresponde à l'indication d'un terme ou d'un passage important ou particulier. Je ne suis pas persuadé que ce soit le cas des terme de ton menu. Si l'effet recherché est purement stylistique il vaudrait mieux employer la propriété CSS font-weight:bold. Il peut être également judicieux d'implémenter des liens de navigation interne, afin de faciliter la navigation dans la structure de la page. Ces liens sont de la forme "aller au contenu", "aller au menu" et pointent sur des ancres. Pour être efficace ces liens doivent être placés au début de la page, si les contraintes de design le justifie il est possible de les déplacer avec des propriétés CSS Ils peuvent en outre correspondrent à des raccourcis clavier déterminés par l'attribut accesskey par exemple : <a href="#contenu" title="Aller au contenu - Accesskey 2">Contenu</a> C'est très intéressant en ce sens que ça aide, non seulement les non-voyants mais aussi tous les utilisateurs de la navigation tabulaire. Le site utilise des illustrations techniques, si cela est pertinent il serait nécessaire d'utiliser un attribut longdesc afin de pouvoir en décrire le contenu. Tu utilises également une présentation animé (principe de la déviation des électrons). Il te faudrait proposer une description textuelle de cette animation comme alternative textuelle pour les non-voyants. Enfin il faudrait "équiper"chaque champ de formulaire l'un label sur le modèle : <label for="nom">Nom</label><input type="text" id="nom"... Le label est un élément important d'un formulaire car il lie l'intitulé à sa valeur, un peut comme scope pour les tables. Bien que le site ne comporte pas beaucoup de page, il serait également interessant de consacrer une page à une carte du site (liste des pages ), sur laquelle tu pourras également indiquer la liste des raccourcis que tu utilise. Et pour terminer prendre soin de vérifier de la cohérence de la navigation tabulaire et implémenter un ordre spécifique si nécessaire. L'ensemble des ces dispositions te permettront d'atteindre WAI/AA, voire AAA dans ton cas car les pages sont simples. JP PS: Petit détail de dernière minute : Sur la page annexes il est indispensable d'indiquer que les liens vont s'ouvrir dans une nouvelle fenêtre par title="Nouvelle fenêtre" afin d'indiquer aux non-voyants qu'ils vont devoir se coltiner la gestion de fenêtre. D'autre part : Cette pratique est fortement déconseillée. Tous les navigateurp propose cette fonctionnalité, c'est mieux de laisser le visiteur décider de ce qu'il veut faire de ton lien..