LaurentDenis

<a href="..." tabindex="1">...</a> Voir http://www.la-grange.net/w3c/html4.01/inte...l#adef-tabindex en l'absence d'attribut tabindex, les navigateurs doivent tabuler selon l'ordre d'apparition des liens et éléments de formulaire dans le fichier HTML.

Désolé si c'était un peu elliptique : Utilise les hr comme des séparations logiques entre les grandes parties de ta page (bandeau titre du site / contenu de la page / menus / pied de page). ça rendra ta page plus claire dans les navigateurs "étranges" (non graphiques et ceux qui ne savent pas comprendre ta CSS). Pour avoir un exemple, regarde ton site dans http://www.delorie.com/web/lynxview.html qui te donne un aperçu de ce qu'elle donne dans Lynx, l'un des principaux navigateurs-texte. Pour approfondir, télécharge et installe Lynx. Mais ces hr ne sont pas facilement stylables avec CSS dans les navigateurs "normaux". Donc, il vaut mieux : - les cacher à l'aide d'une règle hr {display: none;} - utiliser la propriété border (plus facile à maîtriser) pour créer le même effet visuel. Si ça n'est pas plus clair : - oublie les hr, - utiliser la propriété border-bottom ou border-top pour faire apparaître des lignes horizontales délimitant visuellement les parties de ta page là où tu en as besoin.

Dans l'absolu, HTML et XHTML ne favorisent pas plus l'un que l'autre l'accessibilité (utilisateurs handicapés) et l'interopérabilité (diversité des médias) d'une page. XHTML favorise cependant l'évolution et la pérennité, étant plus orienté XML. Mais concrètement, maintenant, selon les compétences de chacun, il vaut mieux une page CONFORME (pas seulement valide) HTML4.0, logiquement conçue et soucieuse d'accessibilité à un XHTML mal digéré, mal structuré et non accessible. Bref, faire peu-ambitieux-mais-bien, en approfondissant la technique, c'est mieux que faire ambiteux-mais-approximativement.

hr est très utile pour le rendu hors navigateurs CSS, autrement dit dans les navigateurs textes, Netscape 4 et consors. Donc: - sépare chaque section logique de ta page par un hr (et regarde ta page dans lynx !) - évacue-les dans les navigateurs CSS2 avec un hr {display: none;} - crée les effets visuels avec des border-top et des border-bottom de tes div existantes.

Je ne suis pas sûr de comprendre. Mais si c'est ça la question, l'élément br s'écrit <br />, avec espace et / comme pour toute balise ouverte-fermée d'un coup (img par exemple)

Hum... Cette accumulation de div te complique inutilement la tâche. Le code devrait d'abord être simplifié (première étape : après, si ça t'intéresse, on parlera sémantique ) <div class="page"> <div class="conteneur"> <img src="sitootit.gif" width="300" height="100" class="left" alt="SitooYato"> <img src="MissYato.gif" width="100" height="100" alt=""> </div> ... suite du contenu éventuellement dans un <div="contenu"> </div> La méthode de centrage du conteneur est bonne (bien qu'une largeur relative donnerait un layout plus fluide). Mais le positionnement de tes images n'a pas besoin de passer par absolute : un simple text-align pour celle de droite et un float pour celle de gauche devraient suffir. Quelque-chose comme : body { font-family: Comic sans MS; font-size: 12px; background: #FFdead; text-align: center; } .page { margin-left: auto; margin-right: auto; width: 750px; text-align: left; } .conteneur { margin-top: 12px; border: 5px solid #FF4500; background: #ff7f00; text-align: right; width: 100%; } .left { float: left; } Vite fait et sûrement à améliorer... D'une manière générale : - quand on commence à multiplier les div dans des div pour obtenir un positionnement, c'est qu'on est dans la mauvaise voie ou qu'on veut réaliser un effet pas forcément possible. - même remarque quand on se met à mélanger les positionnements à coup de marges, d'absolute/relative, voire de float. Il vaut mieux s'en tenir à une technique, au moins au début. CSS est un outil simple... si on l'aborde avec la volonté de s'en tenir à des résultats et à des moyens simple [edit] A l'éditeur/modérateur de ce message : je n'utilise pas le tag HTML parce qu'il introduit des choses bizarres du genre alt="</span>"> <<span style='color:blue'>/div>" lorsqu'on édite le message [/edit]

http://www-306.ibm.com/able/guidelines/web/accessweb.html

Denis, tu te souviens du doc IBM sur l'accessibilité dont j'avais commencé la traduction l'année dernière (projet abandonné pour des raisons de droits d'exploitation) ? Je crois que c'est exactement ce que tu cherches.

C'est un problème de HTML, en fait. Tu utilises des <br /> là où il y a en fait (sémantiquement) deux listes imbriquées : <ul class="puces"> <li> <ul> <li>19-04-2004 : ajout du...</li> <li>debut de la feuille de style</li> <li>ajout du lien vers Rico</li> </ul> </li> <li>15-04-2004 : ajout des premiers liens sur le sujet mangeur de cigogne</li> <li>14-04-2004 : création de la page d'accueil</li> </ul> Il suffit ensuite, pour la présentation, d'aligner les marges et les padding gauche des deux listes.

Je vais tâcher moyen d'y être, comme on dit chez moi.

Attention, sur ce blog, pensée non banalisée, volontier provocante, surtout faussement innocente et souvent dérangeante. Blague à part, Denis, je te la devais, celle-là : tu ne cesses de me surprendre

Je vais être brutal, mais des entreprises vendant de l'accessibilité sur un marché naissant font parfois, par intérêt commercial, le choix de privilégier des techniques complexes et des surcouches de technologies : dans quelle mesure s'agit-il d'impressionner le client et de s'assurer une réputation d'expertise ? Sur le fond, en tout cas, l'efficacité n'est pas forcément au rendez-vous : les techniques d'accessibilité sont fondamentalement simples, au niveau d'un attribut dans un élément de code, ou d'une disposition basique du contenu. [edit] message édulcoré à deux reprises[/edit]

Réaliser ex nihilo un site 100% standard et 100% accessible (si tant est que ce soit possible) avec un surcoût minimal ou admissible... ce n'est effectivement réaliste que pour le développeur confirmé. Et certainement pas dans tous les projets. Mais un paramètre supplémentaire doit être pris en compte, AMHA : la méthodologie, c'est à dire : - on oublie trop que l'accessibilité a été conçue dès l'origine par paliers successifs (les 3 ordres de priorité du WCAG par exemple), définissables non seulement par importance des points à régler, mais aussi par coût ou difficulté. Pour prendre un exemple simple : la gestion des accès-clavier (accesskey, tabindex) est un casse-tête... mais a en fait le rang de priorité 3, c'est à dire le moins urgent. - on oublie également qu'une démarche d'accessibilisation "saine" est progressive dans un site. Selon le rôle des pages dans la navigation, leur fréquentation, leur pérennité... il ne s'agit pas de faire du "tout ou rien", mais plutôt des choix d'optimisation bien ciblés. Le coût est évidemment pris en compte. Le W3C Quality Assurance développe, il me semble, ses efforts dans ce sens. Et quand on regarde la démarche de braille.net par exemple, on s'aperçoit vite que son discours technique est loin du "tout ou rien", et qu'il privilégie les solutions d'accessibilité les plus simples et les plus génériques. Mais il manque encore, en matière d'accessibilité comme de standards en général, une plus grande visibilité de ce "comment s'y mettre dans le monde réel", avec des propositions de stratégies, et plus seulement du discours technique.

Hum... D'un côté, la permissivité toujours possible en HTML: - la langue par défaut du contenu étant définie par lang="fr" (au niveau de l'en-tête par exemple) - on peut raisonnablement supposer que la langue par défaut des cibles de lien sera la même, en l'absence d'hreflang=fr - et on peut se contenter de signaler les changements à l'aide de hreflang="en" etc. - et j'ai un gros doute sur le fond : je ne suis pas tout à fait sûr que Jaws et HPR implémentent hreflang Quelqu'un peut confimer/infirmer ? En tout cas, omettre les hreflang="fr" est la pratique la plus fréquente, parce que la plus simple. Mais d'un autre côté, en XHTML : - rien ne le justifie dans les specs car rien ne lie lang (xml:lang en XHTML) et hreflang, document source et cibles. - c'est une source de problème à la moindre erreur (oubli d'un hreflang="en"), si l'on fait par exemple une transformation via xslt de la page source pour un tri des liens. Comme souvent, la permissivité a un prix, celle de favoriser les erreurs en cascades et de compliquer un traitement sémantique de la page. Donc, malgré la tentation de l'économie, je serais plutôt de ton avis : hreflang "devrait" être systématiquement employé au moins en XHTML.

L'irréprochable politesse de mon ami Denis, qui vient de se présenter, me plonge dans la confusion, car, pour ma part, je n'ai pas respecté cet usage ! Honteux et confus, je répare donc ma coupable négligence : Enseignant, je consacre une part de mon temps à la promotion des standards Web et de l'accessibilité, dont j'ai pu constater la pertinence dans le cadre du Web scolaire. Je travaille dans le cadre de projets collaboratifs comme OpenWeb et WebSemantique, en apportant une modeste contribution de rédacteur à des outils comme DotClear, et plus personnellement à travers un Weblog. J'espère que les questions rencontrées ici nous aideront, au sein de ces projets, à mieux cerner les besoins de formation et de ressources de ceux qui souhaitent s'initier aux standards Web. Voilà voilà... Serais-je pardonné ?

Les sites publics outre-atlantique sont cependant soumis, si je ne m'abuse, à une règlementation plus contraignante qu'en France en matière d'accessibilité : si c'est bien le cas, en as-tu senti l'incidence ? Je suis en tout cas frappé par la qualité d'un travail comme celui du site Web de la Normalisation des sites Internet, par exemple.

Hum... J'inviterais à plus de prudence : s'il véhicule une info à travers ce modification du curseur, il faut cependant que l'info (dans la mesure où elle est utile, par exemple pour la navigation...) soit donnée également par un autre moyen, pour être disponible dans tous les cas. Donc, javascript non obstructif + redondance éventuelle de l'information le cas échéant Au fait, ravi de te retrouver ici

Hum... problème de démarche, en fait. - Tu pars d'une base purement visuelle (d'ailleurs trop complexe pour débuter) pour faire ta CSS sans aucun contenu. - Alors que CSS est une technique qui est explictement une surcouche de présentation sur un contenu HTML pré-défini. En fait, c'est un peu le monde à l'envers : oublie illustrator et ton visuel. Définis un contenu simple. Structure-le (basiquement : titres, paragraphes, listes...). Et au bout du compte, explore progressivement les possibilités de rendu à l'écran via CSS, en finissant par les questions de positionnement que tu prends pour l'instant de front alors que ce sont les plus difficiles.

Je peux risquer un avis brutal ? Pour les coins arrondis, attendez CSS3 finalisés et implémentés dans les navigateurs... Mesurez les gains (pas visuels) et le coût (accepter que l'outil mûrisse).

ça a parfois son utilité : par exemple, obtenir un tableau qui sera "bien" linéarisé et donnera une page plus accessible.

Be-rewt a récemment fait une blogroll en screenshots. Les outils utilisés sont rapidement énumérés ici : http://www.berewt.net/blog/2004/04/07/524

a[title~=pdf]:after { content: "\00A0[Ceci est un affreux PDF]"; }

Pourquoi l'import dans des commentaires ? Enlève-les, et ça ira beaucoup mieux [edit : oubliez-ça, je ne devais pas être bien réveillé. Sorry ]

Si tu utilises des frames... utilise noframe ça ne coûte que quelques lignes de code, et ça améliore considérablement l'accessibilité et l'ergonomie générale du site. Voir http://www.braillenet.org/accessibilite/guide/fiche_2.htm ou http://216.239.59.104/search?q=cache:W4OGl...&hl=fr&ie=UTF-8 (Cache google de la page de braille.net dont le serveur semble avoir des difficultés ce matin)

Les iframes sont un choix possible quand on ne dispose pas d'include côté serveur. Mais : - ils ne sont pas restitués par tous les médias - ils posent des problèmes de localisation de la ressource par les robots (moteurs de recherche, traducteurs automatiques par exemple) - ils nécessitent des mesures d'accessibilité bien spécifiques. Enfin, beaucoup de gens se plaignent de trouver trop souvent des mini-iframe aux dimensions figées et aux polices trop petites. Ils sont à peine lisibles dans de nombreuses configurations d'écrans, de taille de caractère côté utilisateur... Bref, une technique à utiliser avec précautions