LaurentDenis
-
Compteur de contenus
1 281 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par LaurentDenis
-
Quelques remarques rapides: - le label en question est de niveau bronze, c'est à dire le niveau minimal (donc, des ambitions d'accessibilité explicitement modestes qu'il ne faut pas juger avec des critères surévalués) - le label est récent, mais des changements ont pu être apporté depuis au site. Dans ce cas, BrailleNet précise bien que BrailleNet n'est pas responsable des modifications que les concepteurs du site pouront apporter au site après la date indiquée en début de rapport. - la démarche de BrailleNet est d'accessibiliser l'existant, avec les moyens disponibles, donc les tableaux, en effet. - le site n'utilise pas, à première vue, de tableaux imbriqués, mais des tableaux minimaux. Leur linéarisation ne semble pas compromettre l'accès au contenu. Je n'ai pas examiné le site en détail, et certains détails sont sans doute problématiques ([edit] quoique contrairement à ce qu'il m'avait semblé d'abord, il y a bien un lien d'évitement de la navigation [/edit] ), mais le problème me semble plutôt relever d'une certaine incompréhension (fréquente) de la démarche de BrailleNet dans le petit monde des Standards (ce qui n'exclut pas un problème probable de lisibilité de cette démarche, qui n'est pas toujours bien expliquée)
-
A quoi est censé ressembler le gabarit ? (Il n'est pas évident de voir les décalages sans le modèle d'origine) A première vue, la solution sera de modifier la CSS du gabarit pour décaler les divers éléments, un à un, des 10 ou 20 pixels vers le haut et vers la droite qui semblent nécessaires.
-
A ce stade, résumons un peu (et évitons de perdre titange305 dans des subtilités délicieuses, mais qui ne lui répondent pas vraiment ) - la méthode naturelle et simple est la position fixe CSS... Mais ça ne va pas car ça ne marche pas dans IE. - il existe des bidouilles CSS pour obtenir une pseudo position fixe CSS dans IE, mais elles ne sont pas faciles à adapter à un cas précis quand on ne connaît pas bien CSS, et ce sont des bidouilles au résultat douteux. - il existe une solution clé en main via un module DreamWeaver, mais titange305 n'utilise pas DreamWeaver - il existe des solutions javascript à la main, mais elles nécessite qu'on les adapte à sa page et qu'on connaisse javascript. Le script http://www.editeurjavascript.com/scripts/s...ation_1_116.php indiqué par Geo avait l'air de marcher pour titange305. le seul problème étant la DTD à modifier. Donc: utilise http://www.editeurjavascript.com/scripts/s...ation_1_116.php puisque tu as pu l'adapter à ta page. Et supprime sans remords les lignes: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> NB pour les puristes qui sont déjà en train de manger leur clavier : oui, je conseille de faire une page sans DTD... Ce qui est la recommandation officielle du W3C lorsqu'un code est invalide au regard des specs HTML ou XHTML (ce qui a toutes les chances d'être le cas ici)
-
Le décalage est-il horizontal ? vertical ? Veux-tu dire qu'un de tes blocs se retrouve "rejetté à la ligne ?" Une url ou le code précis seraient utile... Sauf en police monospace, un texte mis en italique occupe en effet plus de place qu'un texte "normal", dans tous les navigateurs. Là encore, il faudrait le code de ta page: si tes largeurs sont très précisément définies et ne laissent pas de jeu permettant à tes flottants de rester en place quelque-soit le box model utilisé par le navigateur, la solution consisterait à donner du jeu, justement.
-
C'est une question récurrente, la réponse étant que tu ne peux pas le faire (C'est une limite inhérente aux frames). Tu pourrais en profiter pour envisager l'abandon des frames et le passage à hébergement avec PHP (par exemple) pour remplacer tes frames par de simples include.
-
La spécification HTML4.01 est claire sur la présence de commentaires avant la DTD: Le code suivant est donc tout à fait admissible: Normalement, la première DTD (transitional abrégée) doit être ignorée, et le document obéit à la seconde DTD (stricte complète). Mais pour ce qui est du mode de rendu Quirks ou Strict, IE6.0 a un bug bien particulier : la présence de quoi que ce soit avant la DTD le fait basculer en mode Quirks, quelque-soit la DTD. (C'est ce qui se produit avec un prologue XML) Donc, dans ton cas: - IE n'interprète pas la DTD mise en commentaires - Mais il passe en mode Quirks parce que la page ne commence pas par la DTD Tu peux t'en assurer facilement en inversant l'ordre de tes DTD. IE repasse en mode de rendu strict avec: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -->
-
??? le "#" est parfaitement accepté en XHTML.
-
??? C'est, au contraire, l'indication d'encodage contenu dans une meta http-equiv pour un document servi en application/xhtml+xml (ou plus généralement application/xml) qui sera ignorée. Voir http://www.w3.org/TR/2002/NOTE-xhtml-media...ation-xhtml-xml Le charset défini dans l'en-tête HTTP Content-Type est bien pertinent et recommandé (voir le lien ci-dessus).
-
(source) (...) Autrement, tu pourrais préciser un peu le passage concernant le "XHTML servi comme du HTML" et le "n'adhère pas aux règles qualitatives du XHTML" (surtout le deuxième passage, je ne suis pas certain de voir ce que tu veux dire, même si je pense que tu fais référence à l'accessibilité principalement, point que je compte bien régler à terme ) ? <{POST_SNAPBACK}> Ah... Il y a manifestement quelque-chose à éclaircir sur la notion de "type MIME" et sur ce qu'est une meta "http-equiv". L' information de type MIME doit être associée à une ressource ((X)HTML, image, autre) au niveau HTTP, c'est à dire dans les échanges client-serveur, et non par le biais de la meta http-equiv, qui ne sera pas actuellement exploitée par les navigateurs pour choisir le mode de traitement du document (moteur HTML ou parseur XML). La <meta http-equiv="content-type" content="...> ne fait que dupliquer cette info HTTP (c'est le rôle des meta dotées d'un attribut http-equiv par opposition aux <meta name="...">). Elle fournit bien au serveur, en théorie, un moyen de déterminer le type MIME à associer au document dans l'en-tête HTTP Content-Type lorsque cela n'a pas été paramétré par ailleurs. Mais dans la pratique, ce mécanisme est inopérant En revanche, cette meta joue un rôle essentiel pour préciser le type d'encodage du document. voir Spécifier l'encodage des caractères d'un document (X)HTML) Ici, ta page est reçue et interprétée par les navigateurs comme du text/html, malgré la présence de ta meta. Tu peux facilement le vérifier en affichant les informations sur la page dans Opera ou dans Firefox, ou encore en visualisant les en-têtes HTTP envoyés par le serveur (Voir dans les Outils du Hub). Autrement dit, pour exploiter le type MIME application/xhtml+xml, il faut intervenir au niveau serveur, dans le .htaccess, ou avec un header('Content-Type: application/xhtml+xml; charset=...'); en PHP par exemple. Tout le monde n'ayant pas forcément la possibilité ou les compétences pour intervenir de cette manière, et tous les navigateurs n'étant pas capables d'exploiter les document application/xhtml+xml, le XHTML1.0 a été conçu de manière à pouvoir être servi et traité comme du HTML (en fait du HTML invalide) par les navigateurs, à condition de respecter une série de règles de compatibilité. Ces règles sont indiquées dans un appendice de la spécification XHTML: Appendice C. Règles de compatibilités du HTML. Elles permettent de s'assurer que le moteur HTML du navigateur saura corriger ce qui est pour lui un HTML erroné de manière à obtenir un affichage sans "casse" (pour un exemple concret de "casse", voir <p></p> ou <p /> ? <br /> ou <br></br> ? Lisez les specs !. En fait, le choix à faire est: - faire du XHTML1.0 en gérant effectivement les deux types MIME à adresser selon la capacité du navigateur, pour le plaisir de faire du XHTML pur et dur et apprendre comme ça marche. - faire du XHTML1.0 en s'en tenant au type text/html et en respectant les règles de compatibilité HTML, pour apprendre la syntaxe XHTML - faire tout simplement du HTML4.01, si la priorité est de délivrer un contenu normalisé, favorisant l'accessibilité que tu veux travailler par la suite, interopérable, etc. Voir également XHTML1.1, beaucoup de bruit pour rien qui contient diverses choses valables également pour XHTML1.0.
-
Autant donner l'information plutôt que d'inviter les gens à jouer aux devinettes. Le sujet sur les .info gratuits est http://www.webmaster-hub.com/index.php?showtopic=6279
-
La liste complète des caractères problématiques est donnée dans Codage valide des caractères Windows illégaux en HTML et XHTML (avec les encodages numériques et caractères valides).
-
L'orthographe ca compte aussi!
LaurentDenis a répondu à Sebastien - Forum : Accessibilité et Ergonomie Web
J'avoue froidement que : - je m'efforce, par plaisir, de respecter la règle typo française des espaces avant les signes de ponctuation doubles. Je la trouvé également plus lisible, par habitude. - mais que je n'en fais pas une affaire d'Etat, et que l'alignement sur la typographie anglosaxonne ne me choque pas plus que cela -
L'orthographe ca compte aussi!
LaurentDenis a répondu à Sebastien - Forum : Accessibilité et Ergonomie Web
Me serais-je laissé emporter ? Pour les signes de ponctuation, dans la typographie française: - les signes simples (point, virgule, points de suspension) sont accolés au mot qu'ils suivent. - les signes doubles (deux-points, point-virgule, points d'exclamation et d'interrogation) sont précédés d'une espace fine... autrement dit de l'espace insécable & nbsp; dans un document Web. Il en est de même entre les guillemets et leur contenu. -
Le script ne passe pas dans Opera. Reste à vérifier le résultat dans Safari, Konqueror... Il est d'autre part innaccessible au clavier. Enfin, il rend les liens inutilisables lorsque CSS est activé mais pas javascript. Sans compter la présence dans le HTML des liens "<a href="#" class="slien" onclick="sites_close(1);">Fermer</a>" totalement dénués de sens dans n'importe quel media autre que les navigateurs graphiques avec CSS et javascript activés (navigateurs textes et vocaux, lecteurs d'écrans, mobiles, robots d'indexation, etc). Sur la séparation entre comportement et structure, voir http://pompage.net/pompe/separation/ (en français) Autrement dit, c'est un bon exemple de javascript obstructif qui entrave l'accès à la page, affaiblit sa structure et diminue son ergonomie Non ! Surtout pas... - comme tu le dis d'ailleurs, le prologue XML genère un bug d'IE : ce n'est pas un mécanisme de doctype switching, mais un accident. - le prologue n'a aucun sens dans un document XHTML servi comme du HTML, ce qui est le cas ici. Pourquoi encourager une syntaxe inappropriée ? Mieux vaut s'en tenir à une DTD abrégée qui fera basculer IE en mode quirks, sans recourir à un bug du navigateur. Et à tout prendre, une DTD HTML plutôt que XHTML (avec les modifications nécessaires dans le code de la page), dans la mesure où celle-ci n'adhère pas aux règles qualitatives du XHTML.
-
L'orthographe ca compte aussi!
LaurentDenis a répondu à Sebastien - Forum : Accessibilité et Ergonomie Web
La première chose à faire, AMHA, est de méditer cette remarque de K. Dubost : http://www.la-grange.net/2003/05/07.html Sinon, en attendant l'article de février d'OpenWeb sur le sujet ( ), voir: - http://www.uzine.net/article1802.html - http://www.publishtogether.com/pompeurs/TypoGraphie La "typographie Web" devrait privilégier la lisibilité (d'où effectivement l'importance du respect des majuscules, de la ponctuation de base, des formats de guillemets nationaux, des tirets demi-cadratin et cadratin...), mais on peut s'interroger sur l'intérêt, pour ce média, d'autres règles telles que: - les majuscules accentuées - l'apostrophe typo & #146; - l'espace fine & thinsp; (inutilisable actuellement d'ailleurs en raison de problèmes d'implémentation dans les navigateurs) - l'usage typographique de l'italique ( voir la discussion en commentaires de http://navire.net/archives/web_standards/italique.html ) qui suscite de multiples confusions entre contenu et présentation -
Les styles CSS appliqués à iframe ne concernent que le contenu alternatif qui sera affiché si le support des iframe est désactivé ou absent. Autrement-dit, dans: <iframe src="foo.html"> <p>Les iframe ne sont pas supportés par votre navigateur.</p> </iframe> Ce n'est pas le contenu de foo.html qui peut être stylé, mais uniquement <p>Les iframe ne sont pas supportés par votre navigateur.</p>
-
Attention à ne pas indiquer les accesskeys uniquement via un effet CSS : l'information sera alors perdue pour de nombreux utilisateurs, et tout particulièrement pour ceux qui sont le plus susceptibles d'en avoir besoin. Rappelez-vous que les effets CSS sont ignorés entre autres par les lecteurs d'écran et les navigateurs textes. Il est donc nécessaire de faire figurer cette information "en toutes lettres" dans le contenu HTML: - dans chaque document - et/ou dans une page spécifique d'Aide qui doit elle-même être accessible immédiatement depuis n'importe quelle page du site.
-
Hum... Mettre un menu en fixe (donc non scrollable s'il dépasse la hauteur de l'écran) pour le rendre ensuite scrollable avec overflow... C'est un peu tordu, non ? Par ailleurs, l'overflow:scroll fait générer des barres de scroll internes à la page, ce qui est assez disgracieux. Et compromet partiellement l'accessibilité en rendant l'accès-clavier beaucoup plus difficile, voire parfois impossible. Vu sa longueur indéfinie, ce menu gagnerait plus simplement à être en position absolue, comme le suggère Ernestine.
-
Il est possible, en effet, que le serveur ne renvoie pas pour ce fichier le type-mime convenant à une feuille de style CSS (text/css), mais un autre type mime (peut-être text/plain) appliqué arbitrairement à cause du nom de fichier en .inc.css. Auquel cas, Opera et IE appliqueront la CSS, mais Firefox l'ignorera. C'est donc le premier point à vérifier en analysant les en-tête HTTP renvoyés par le fichier CSS.
-
En fait, la page ne peut pas s'afficher correctement dans tous les navigateurs : Opera réagit comme le validateur CSS et traite toutes les URL (CSS, favicon, images...) sous la forme "http://www.gemsbrokers.net/www.gemsbrokers.net-site/www/" Par ailleurs, lorsqu'on tente de visualiser les en-têtes HTTP, on obtient: ( http://www.delorie.com/web/headers.cgi?url...glish/agate.htm ) Il s'agit donc d'un problème de configuration serveur à régler avec l'hébergeur. Au passage, un petite erreur de code XHTML (sans rapport): les syntaxes du type <img src="..." alt="..." width="..." height="..."></img> ... sont fortement déconseillées par les spécifications XHTML, bien que formellement valides: elles ne seront en effet pas supportées par tous les agents utilisateurs. Il est recommandé de s'en tenir, pour les éléments vides, à la syntaxe classique: <img src="..." alt="..." width="..." height="..." /> (Réciproquement, on évitera la syntaxe <script /> et on utilisera <script></script> pour les éléments qui ne sont pas spécifiquement marqués EMPTY par la DTD)
-
Il suffit de déplacer l'identifiant de <noscript> vers l'élément conteneur de ton menu (<p> dans ta version actuelle, sinon <dl> ou <ul>): <noscript title="pas de script"> <p id="nsc"> et pour la CSS: p#nsc { ... }
-
Modifier la taille des caractères en fonction ...
LaurentDenis a répondu à Perrine - Forum : (X)HTML et CSS
Pour dire les choses clairement, aucune des technologies concurrentes de téléchargement de police (EOF, PFR) n'a abouti à un résultat viable : elles sont restées propriétaires et trop dépendantes de technologie type contrôle ActiveX, javascripts, plugins, etc. Le W3C a d'ailleurs fait une croix sur les mécanismes de téléchargement et de synthèse de polices que prévoyait CSS2 sur le papier : ils disparaîtront totalement de la prochaine révision CSS2.1. Bref, on peut oublier le téléchargement de police si on souhaite diffuser des documents avec un minimum d'interopérabilité. Concernant le choix de la police Monotype Corsiva : il s'agit d'une police cursive. Celles-ci sont réputées pour leur très médiocre lisibilité sur le Web: - oeil (hauteur d'un caractère sans jambage) trop réduit et jambages trop longs - trop fort contraste entre pleins et déliés - approche (espace entre les caractères) nulle ou trop réduite - faible contraste de graisse Elles rendent par ailleurs le rendu à peu près totalement imprévisible, en raison de leur trop grande hétérogénéité : une police cursive donnée, même de celles qui accompagnent Microsoft Word (comme Monotype Corsiva), a toutes chances de ne pas être présente sur le système de nombreux utilisateurs. La substitution d'une police locale peut alors être catastrophique, vu les différences énormes d'apparence et de lisibilité entre polices cursives. Enfin, il me semble me souvenir que le paramétrage de certains navigateurs leur substitue le plus souvent illico une police serif ou sans-serif sans autre forme de procès (C'est le cas pour Opera). L'idée de spécifier quelque-chose comme: font-family: "Monotype Corsiva", Verdana, sans-serif; ... est assez aventureux, comme tu l'as constaté: les différences de taille apparente sont en effet très importantes entre polices cursives et polices sans-serif (Verdana). Et il n'existe aucun moyen de spécifier des tailles de caractères en fonction de la police utilisée. Donc, AMHA: - ou on en reste sagement aux polices fiables, à la lisibilité éprouvée, comme ton premier choix Verdana et Georgia, - ou on fait du Flash (Voir par exemple la technique sIFR) -
Je n'aime pas du tout ce qui s'approche de près ou de loin de cet anti-microsoftisme tant à la mode aujourd'hui. Mais là, j'avoue que c'est un cas d'école: 323 malheureuses lignes de codes supposées constituer une bête page HTML (c'est à dire une page web)... et le meilleur outil de correction automatisé de code (Tidy) se suicide en plein effort après avoir recensé plus de... 16 000 erreurs formelles ! De fait, quelque-soit l'outil utilisé pour créer cette page, la première chose à faire est de l'abandonner : il génère un document qui n'a de sens que pour les logiciels Microsoft, et qui n'a aucune chance d'être exploitable par d'autres navigateurs qui s'en tiennent au simple respect des normes de base du HTML. Ce n'est pas corrigeable erreur après erreur, car la conception la plus élémentaire est déjà défectueuse. Je ne peux que te suggérer de t'orienter à la fois: - vers un outil plus ouvert au HTML de base universellement partagé : NamoWeb, DreamWeaver... - vers une excellente lecture pour découvrir ce qui se passer derrière la fenêtre du navigateur, en termes simples et efficaces: http://www.tuteurs.ens.fr/internet/web/html/
-
Ce n'est pas gênant, c'est possible et potentiellement très utile. Une page n'a pas qu'une langue. Elle a en fait: - une ou des langue(s) primaire(s), qui sont les langues de son public potentiel. Celles-ci sont spécifiées à l'intention, entre-autre, des robots d'indexation capables de sélectionner une ressource en fonction des préférences linguistiques de l'utilisateur (Google en est plus ou moins capable). - une ou des langue(s) de traitement, qui indiquent pour chaque élément de contenu de la page, y compris les <meta>, la langue naturelle de leur contenu. Il s'agit essentiellement de faciliter par exemple le travail d'un synthétiseur vocal qui va lire ce contenu et qui doit le faire en utilisant la librairie vocale appropriée selon la langue, ou le travail d'un traducteur automatique qui ne doit pas tenter de traduire en anglais un contenu qui l'est déjà (inclus dans une page en français). Le problème de ces meta est qu'elles sont, et c'est rare, à la jonction de ces deux informations: - langue primaire car les metas sont destinées aux robots d'indexation - langue de traitement car le seul outil permettant de préciser la langue de ces mots clés est l'attribut "lang", qui est à la base du mécanisme des langues de traitement. Bref, préciser cet attribut et différencier les deux balises <meta> est tout à fait rigoureux vis à vis des robots d'indexation.
-
Les mauvaises nouvelles d'abord: Astrocea n'est pas conforme à XHTML1.1, bien que le validateur HTML du W3C affirme sa validité : c'est une donnée qui lui échappe pour l'instant. En effet, XHTML1.1 est du pur XML, pas du HTML. Il te manque une donnée essentielle pour différencier les deux: le type mime envoyé au navigateur par ton serveur, qui provoquera un traitement différent selon qu'il s'agisse de XML ou de XHTML, y compris au niveau CSS, de la part du navigateur. Pour l'instant, Astrocea est en XHTML1.1 traité en tant que HTML à cause du type mime HTML incompatible avec celui-ci. Il faut donc: - soit revoir le choix du XHTML1.1, sachant que son numéro de version n'en fait pas la DTD la meilleure parce que la plus récente, - soit mettre en place les mécanismes de gestion serveur du type mime selon les capacités des navigateurs, qui ne savent pas tous traiter du XHTML1.1 correctement (IE ne sait pas). Voir à ce sujet: - http://webstandards.org/learn/askw3c/sep2003.html (en anglais) - http://www.w3.org/TR/xhtml-media-types/xht...edia-types.html (en anglais) - http://blog-and-blues.org/weblog/2004/06/1...bruit-pour-rien (en français, tiré des précédents) Au plus simple, Astrocea est sans doute valide et conforme en XHTML1.0 transitional ou strict, et n'a peut-être pas besoin de XHTML1.1 s'il n'utilise pas le langage MathMl. Les bonnes nouvelles ? L'une des différences de rendu CSS gênantes est due aux propriétés CSS par défaut des listes <ul> propres à chaque navigateur: IE, Mozilla/FifeFox, Opera, ont chacun leur marge de manoeuvre dans ce domaine. Voir Gérer l'espace à gauche d'une liste selon les navigateurs.