fabrice_bonny

Essayons d'être clair et de différencier les aspects. Le respect des standards: Faire du code valide le rend lisible et compréhensible par une machine et par conséquent par un robot. La sémantique: Je suis intimement persuadé qu'un code structuré (h1, h2, h3, strong, etc) joue dans le référencement. Ou alors, j'ai une chance du tonnerre depuis 3 ans. ;-) Les meta: Je n'utilise plus de meta depuis 2 ans et j'arrive encore à classer sur la première page de Google et d'autres les sites que je conçois. Je parle des keywords et description, même si ce dernier peut être utile dans le cas des annuaires. Les metadonnées comme Dublin Core sont lus par les moteurs internes majeurs mais par aucun moteur grand public. Par contre, il est possible qu'il le soient bientôt. Il s'agit donc d'un investissement. Pour résumer, faire du XHTML ou du HTML ne change rien, il faut qu'il soit valide et structuré. Si un CMS ou autre permet ça, alors on peut l'utiliser.

Juste pour rire, une liste très partielle de ce que MSIE ne comprend pas, que d'autres comprennent et qui sont des standards: - HTML: * pas de support des <link> (HTML 2); * les bouttons des formulaires sont buggés, MSIE renvoye tous les boutons et pas seulement celui cliqué; * pas de support des colspan="0" pour permettre des cellules adaptables. -CSS: * position: fixed; * pas de support du display:table. - toutes les technologies sorties depuis 1996: * PNG; * MNG; * JNG; * SVG; * SMIL; * MathML; * XML. Une liste quasi-complète des standards que MSIE gère et pas les autres: * support de _AT_font-face (CSS); * support du filtrage PICS; * support de la césure (HTML); * support de l'export MHT.

Commençons par un aveu: cet article avait surtout pour vocation d'attirer les amateurs de ces gadgets vers un site parlant des standards et de l'accessibilité. Il s'agissait de casser l'image de ces deux domaines. Je vais me permettre un parallèle: au début, Linux passait pour un système de chevelu asocial. Enfin, il ne faisait pas que passer. :-) Quelque soit les efforts que l'on faisait, on avait jamais la bonne distribution, le dernier kernel, etc. Maintenant, Linux est un OS professionnel distribué par des boîtes côtées en bourse. Il n'y a pas si longtemps les standards, et là je plaide pleinement coupable, était sur la même voie. On flinguait tous les cons qui ne comprenaient rien à l'Internet. Peu à peu, on a appris à soutenir les efforts plutôt qu'à les détruire. Les standards sont devenus incontournables et il suffit de consulter The Weekly Standards, CSS Vault ou Web Standards Awards pour le constater. L'accessibilité commence à sortir de cette phase normale et structurante. Il m'arrive encore moi aussi de m'emballer contre les mauvaises personnes. Souvent même. Tout ceci est bon signe, le signe de l'on approche de la maturité. Je suis donc parfaitement d'accord avec l'idée qu'il faut expliquer pourquoi les frames, les menus déroulants et autres tableaux posent encore des problèmes même s'il est possible de les rendre partiellement accessible. On ne pouvait pas présenter l'accessibilité il y a encore quelques mois comme on avait fait des standards, on aurait plus nui qu'autre chose. Il faut encourager, laisser du temps et expliquer que ce n'était qu'un premier pas. Un site passant le validateur W3C ne respecte pas forcément la philosophie du Web. Un site passant le validateur Bobby n'est pas forcément accessible. Nous avons démontré les lacunes du Web à l'ancienne, il est temps maintenant de présenter les avantages du Web moderne. Beaucoup ont commencé mais la vocation d'OpenWeb n'est pas d'être un pionnier en terme de débats. Je propose donc un article de fond sur le non-emploi des frames ou du JS par les professionnels et pourquoi. Avec des arguments d'accessibilité mais pas seulement. J'avais aussi lancé l'idée d'une partie interview comme un axe important d'OpenWeb dans la vision que j'en avais. Yobiwan? ;-)

Il existe au moins un cas où ce menu fonctionne mal: désactiver une option du menu sur un navigateur donné (MSIE) et une version donnée (la 5). Le problème a été corrigé sur la version 6, a priori. En effet, ignorer les couleurs de la page doit mettre un fond blanc et non pas supprimer carrément le fond. Je note que la Web Developper Bar sur Mozilla fait de même. Je vais donc voir s'il est possible de détecter ça. Menu non WAI pour l'instant. A suivre... J'entends par là qu'il s'agit juste de montrer la voie. Certains feront des dérivés moins bien, d'autres mieux mais l'accessibilité s'en trouvera augmentée. J'essaye de faire le plus performant possible mais chacun adaptera mon exemple avec plus ou moins de bonheur. Je ne pense pas que chacun teste X navigateurs, X OS, X versions, X options, etc.

Bon, tant pis pour le mythe, je mets les pieds dans le plat. Oui, l'accessibilité absolue n'existe pas plus que l'interopérabilité absolue. Il y a et il y aura toujours un cas minimum où une page ne "marchera" pas. Un navigateur, une configuration, un réglage d'options, etc. J'ai testé mon menu avec la plupart des cas courants. Le but de l'article était plutôt de démontrer que la prise en charge de l'accessibilité est possible et guère compliqué. Soyons francs, un expert ne va pas utilisé ce genre de menu, pour des raisons d'ergonomie entre autres, et l'article se devait d'être un truc prêt à l'emploi pour les débutants ou initiés qui souhaitent un menu déroulant. Je préfère voir fleurir des menus un minimum accessibles plutôt que ceux qui ne le sont pas du tout, à défaut de voir disparaître ces "gadgets". N'oublions pas qu'il y a de plus en plus de débutants sur Internet. Vous me direz qu'il y a ce genre de menus dans tous les logiciels. Certes mais observez un débutant qui surfe. A aucun moment, il ne se sert d'un menu.

L'idée du + en image avec un alt est une vraie trouvaille et j'étais complétement passé à côté. Désolé. Peut-être une mise en lumière d'un manque de communication de Braillenet concernant ses découvertes codistiques... Concernant l'approche de Braillenet / Accessiweb qui consiste à ne retenir que les aspects applicables de la WAI et même à en rajouter, elle est assez différente de celle du W3C. Laissons de côté le débat théorie contre pragmatisme pour nous concentrer sur un risque qui me parait réel. L'accessibilité est un sujet trop sensible et trop fragile à mon sens pour que ses rares acteurs ne poussent pas dans la même direction. Comment faire pour jongler entre recommendations écrites sans se soucier de l'implémentation et recommendations écrites sans se soucier de standardiser (je caricature)? A mon humble avis, il est impératif que les rédacteurs des 2 se rencontrent, recoupent leurs informations et surtout, surtout, les testent en grandeur réelle avec les premiers concernés. Je sais, en disant ça, je laisse transparaître mon penchant pour l'une des 2 approches. Si celà peut en rassurer certains, les débats ont parfois été productifs (bel euphémisme) sur OpenWeb.

Essayons d'être clair au mileu de cette profusion d'idées et de "remarques". Premier point: nous sommes dans une phase de transition. L'accessibilité est un fait relativement nouveau en ce qui concerne sa prise en charge dans la conception d'un site. Il reste beaucoup de lacunes techniques: aucune implémentation des CSS orales, navigateur pour handicapés basé sur une ancienne version de MSIE, etc. Il est évident qu'une CSS torturée répond mal, tout comme il devrait être facile de désactiver les CSS ou d'en choisir une plus adaptée. Le problème relève tout autant, sinon plus, de la conception des outils que de celle des sites. Deuxième point: Accessiweb est attendu au tournant tout comme le fût OpenWeb. Il ne s'agit pas de viser la perfection mais de faire du mieux possible en ce qui concerne la promotion de l'accessibilité. Nonobstant le côté piquant de ma première intervention, elle est l'objet d'une vraie question: pourquoi le site "référence" de l'accessibilité ne respecte pas le minimum de la WAI? Est-ce que cette recommendation est mauvaise (inadaptée, trop théorique...), est-ce un choix délibéré, est-ce une erreur? Pourquoi ne pas expliquer la démarche? Ayant fait le test après les conseils de Braillenet sur OpenWeb, il me paraissait évident que d'entendre "lire la suite, "lire la suite", "lire la suite" était une erreur.

Bonjour à tous. Je me permets de prendre part au débat. Comme il semble être de bon aloi de mettre le doigt là où ça fait mal , une petite réflexion. Concernant la première page d'OpenWeb, nous avions mis des liens "Lire la suite" que nous avons remplacé par "Lire " + le titre de l'article. Ceci suite à un conseil de Braillenet nous expliquant qu'un navigateur vocal allait lire le même lien pour différentes pages liées. C'est d'ailleurs le 13.1 du WAI. http://www.w3.org/TR/1999/WAI-WEBCONTENT-1...eaningful-links Imaginez ma surprise il y a quelques jours en voyant ça: http://accessiweb.org/fr/Information/Actualites/ Ai-je raté quelque chose?