Bonjour,
j'ai regardé sur les contribs, et je n'ai pas trouvé un seul squelette qui passe le validateur du w3c :
http://validator.w3.org/
Personne n'est interressé par l'interopérabilité chez les spipeurs ?
a+.
Le mar 17/06/2003 à 11:25, Jean-Paul Chiron a écrit :
Bonjour,
j'ai regardé sur les contribs, et je n'ai pas trouvé un seul squelette
qui passe le validateur du w3c :
http://validator.w3.org/
Personne n'est interressé par l'interopérabilité chez les spipeurs ?
Houla ... dit comme ça, c'est l'idéal pour relancer le troll de la
semaine dernière 
Plus sérieusement, à part www.perdu.com, t'en connais beaucoup des
sites webs qui font zéro faute sur validator ?
À+, Pif.
Le 17.06.2003 11:32, Christian Lefebvre a écrit :
Le mar 17/06/2003 à 11:25, Jean-Paul Chiron a écrit :
Bonjour,
j'ai regardé sur les contribs, et je n'ai pas trouvé un seul squelette qui passe le validateur du w3c :
http://validator.w3.org/
Personne n'est interressé par l'interopérabilité chez les spipeurs ?
Houla ... dit comme ça, c'est l'idéal pour relancer le troll de la
semaine dernière
Désolé, je ne l'ai pas suivi, et mon but n'est de troller...
Plus sérieusement, à part www.perdu.com, t'en connais beaucoup des
sites webs qui font zéro faute sur validator ?
Ben il y en a quelqu'uns avec un peu plus de graphisme 
http://openweb.eu.org/
a+.
--
Jean-Paul CHIRON
Salut,
On 17 Jun 2003, Christian Lefebvre wrote:
Le mar 17/06/2003 à 11:25, Jean-Paul Chiron a écrit :
> Bonjour,
> j'ai regardé sur les contribs, et je n'ai pas trouvé un seul squelette
> qui passe le validateur du w3c :
> http://validator.w3.org/
> Personne n'est interressé par l'interopérabilité chez les spipeurs ?
Houla ... dit comme ça, c'est l'idéal pour relancer le troll de la semaine dernière
Plus sérieusement, à part www.perdu.com, t'en connais beaucoup des
sites webs qui font zéro faute sur validator ?
Par exemple: http://www.nonaug8rhone.eu.org/ et la quasi-totalité des
sites auquels je participe...
Et si tu trouves des erreurs sur ces sites (hélas, tu en trouveras sur
certains articles), elles sont *uniquement* duent aux code incorrect que
spip génere, et ca m'énerve...
Yannick
--
_/ Yannick Patois _________________ Address (home) __________________
| irc(undernet): Garp on #france25+ | 17, rue du Tonkin |
| email : patois@calvix.org | Apt. 9G, 3iem |
| http://garp.feelingsurfer.net/ | 69100 Villeurbanne |
| Tel-home: +33 (0)4 78 89 76 47 | FRANCE |
| Collectif du Rhône NON AU G8 - - http://www.nonaug8rhone.eu.org/ |
Bonjour !
> > j'ai regardé sur les contribs, et je n'ai pas trouvé un seul squelette
> > qui passe le validateur du w3c :
> > http://validator.w3.org/
> > Personne n'est interressé par l'interopérabilité chez les spipeurs ?
> Houla ... dit comme ça, c'est l'idéal pour relancer le troll de la
semaine dernière
> Plus sérieusement, à part www.perdu.com, t'en connais beaucoup des
> sites webs qui font zéro faute sur validator ?Par exemple: http://www.nonaug8rhone.eu.org/ et la quasi-totalité des
sites auquels je participe...Et si tu trouves des erreurs sur ces sites (hélas, tu en trouveras sur
certains articles), elles sont *uniquement* duent aux code incorrect que
spip génere, et ca m'énerve...
Voir toutes les discussions sur le sujet :
Pour votre info, nous avons entamer ce long débat sur SPIP_DEV .
Sur Spip_Contrib, vous trouverez des fonctions qui corrigent un certain
nombre de choses en respectant les normes W3C/WAI/braillenet (les fous de
l'accessibilité pour les/mal voyants )
http://www.uzine.net/spip_contrib/ecrire/articles.php3?id_article=174
http://openweb.eu.org/articles/intro_accessibilite/
Voici les extraits des messages :
"
Les problèmes du code généré par spip
1) Les problèmes majeurs rencontrés dans les pages générées par spip :
a.. Mauvaise imbrication des tables, des intertitres <h3> et des listes :
ces éléments sont encadrés de balises <p class="spip></p>, ce n'est pas
conforme.
b.. Les balises <img>, <br>, <input>, <hr>, <embed>., ne sont pas
toujours bien fermées
c.. hspace et vspace sont des attributs d'images non valides, ainsi
qu'align
d.. Mise en forme : le gras généré par {{texte gras}} en code spip est un
<b>texte gras</b>, au lieu de <strong>texte très appuyé</strong>... De même
{texte italique} génère <i>texte italique</i> dans spip, à la place de
<em>texte appuyé</em>.
e.. Pour les petits éléments de contenu (Descriptif, Notes, Forums) il
arrive que les paragraphes soient absents, ou partiellement générés.
f.. Au niveau des liens hypertexte : l'attribut title n'est pas complété
g.. L'attribut alt= n'est pas complété lors de l'insertion des logos
h.. Problème lors de l'inclusion de documents
2) Les tableaux générés par spip
a.. Les attributs summary ne sont pas complété dans les balises <table>,
il faut trouver une astuce pour compléter cette attibut dans le cas de
tableau de données.
b.. les balises <caption> ne sont pas utilisées
c.. La première ligne des tableaux est générée avec des balises <td> à
lieu de balises <th>
d.. Il faut placer l'attribut id= dans les balises <th>. Ex : <th id=''
entete1''>En tete1</th>
e.. Il faut placer l'attribut header= dans les balises <td>.
3) Les formulaires générés par spip
a.. Il faut uniformiser les balises (majuscule, minuscule.)
b.. Fermer les balises <input />
c.. Placer les attributs id= et name=
d.. Utiliser les balises <fieldset>, <Legend>, <label>
e.. L'attribut wrap des <textarea> est déprécié
Recommandations pour la création des squelettes
Conforme aux recommandations W3C / WAI / Braillenet
Les images :
a.. Tous les éléments graphiques doivent posséder une alternative. Cette
alternative doit de plus être pertinente.
b.. Pour les images Map, l'image map elle-même, et chacune des zones
sensibles de cette image doivent posséder une alternative propre fournie par
l'attribut alt. Cette alternative doit être pertinente.
(Les zones d'une image map doivent être codées juste après la déclaration
de cette image.)
c.. Il est conseillé d'utiliser des textes mis en forme par une feuille de
style plutôt que des images contenant du texte.
d.. Lors de l'utilisation de textes dans une image, l'alternative à cette
image doit retranscrire les textes présents dans l'image.
e.. Il est conseillé de commenter par ALT="", les éléments de décorations
(puces, pixels de calage .).
f.. Lorsqu'une image est utilisée comme lien, le contenu de l'attribut ALT
doit donner la fonction du lien et non la description de l'image.
g.. La somme des images d'une page ne doit pas gêner la lisibilité de
celle-ci.
h.. Plutôt que d'utiliser des images de grande taille, préférer une image
réduite avec un lien menant vers l'image avec son format de départ.
Les cadres :
a.. Chaque cadre de la page doit être nommé et l'attribut NAME doit
décrire la fonction du cadre et non pas sa position géographique.
b.. Pour décrire la fonction des cadres utiliser l'attribut TITLE.
c.. Prévoir une alternative à l'utilisation des cadres (Balise NOFRAME) et
retranscrire dans cette alternative l'ensemble des informations fournies
dans les cadres.
d.. Le nombre de cadres dans une page ne doit pas dépasser 3.
e.. Laisser le choix à l'utilisateur de pouvoir faire défiler le contenu d
'un cadre (Scrolling= « auto »)
Couleurs/visuel :
a.. Ne pas utiliser la couleur pour transmettre de l'information, si c'est
le cas, vérifier que lorsqu'on désactive les couleurs, l'information est
toujours accessible.
b.. Préférer l'utilisation de couleurs très contrastées.
Multimédia :
a.. Lors de l'utilisation de support multimédia, assurez-vous de la
présence d'une alternative à celui ci.
b.. Lors de l'utilisation d'un support multimédia toujours le synchroniser
avec son alternative. (Vidéo et son par exemple)
Les Tableaux :
a.. Utiliser l'attribut summary pour décrire plus longuement le rôle et le
fonctionnement du tableau (surtout pour les tableaux de données).
Pour les tableaux de données :
a.. Utiliser des balises d'en tête de colonne. (TH)
b.. Utiliser les attributs HEADER et ID pour spécifier les relations entre
les cellules et leur en-tête.
c.. Utiliser la balise CAPTION pour donner un titre au tableau.
Pour les tableaux de mise en forme :
a.. Ordonner les informations de manière linéaire. Vérifier que les
informations apparaissent dans le même ordre lorsque l'on déstructure les
tableaux.
Liens :
a.. Les intitulés de liens doivent être courts, explicites et lisibles
hors contexte.
b.. Les liens qui ont un même intitulé doivent avoir la même page de
destination.
c.. Quant cela est nécessaire utiliser l'attribut TITLE pour une plus
longue description du lien. Par exemple, lorsque plusieurs liens ont un
intitulé identique et mènent vers des destinations différentes (exemple lire
l'article dans les sites de presse).
d.. Pour les liens les plus importants du site, associer des raccourcis
clavier.
e.. Ne pas dépasser plus de 9 rubriques pour un menu.
f.. Ne pas dépasser 40 liens actifs dans une même page.
g.. Pour faciliter la navigation, utiliser des liens de navigation
internes à la page (pixels transparents, lien vers la page d'accueil...)
Applet, JavaScript, Flash :
a.. Lors de l'utilisation de scripts, prévoir une alternative qui reprend
l'ensemble des informations fournies par l'intermédiaire du script.
b.. Aucune action ne doit être dépendante d'un périphérique (ex :
OnMouseOver). Prévoir une alternative à l'utilisation de ce périphérique.
c.. Vérifier qu'il n'y a aucune perte d'informations lorsque l'on
désactive les scripts.
Langue/Validation :
a.. La balise DOCTYPE doit être présente pour spécifier quel type de
langage est utilisé dans la page.
b.. La langue du document doit être spécifiée dans la balise HTML.
c.. Annoncer tout changement de langue dans la page par la balise SPAN
LANG="".
d.. Lors de l'utilisation de sigles ou d'abréviations, expliquer la
signification de ceux-ci lorsqu'ils sont présents pour la première fois dans
le document.
e.. La balise ACCRONYM doit correspondre à l'explication exacte du sigle
utilisé.
Navigation :
a.. Utiliser les balises Hn pour donner les informations concernant la
structure des pages et cela de manière cohérente et non pour de la mise en
page.
b.. Donner un titre à chacune des pages.
c.. Les informations importantes de la page doivent être rapidement
accessibles.
d.. Prévoir, lorsque cela est nécessaire, un plan du site, une aide et un
moteur de recherche.
e.. Dans le cas de l'utilisation d'un moteur de recherche, d'un plan du
site ou d'une aide, prévoir un moyen de le rendre rapidement accessible dans
la page.
f.. Donner un titre UNIQUE et EXPLICITE à chacune des pages
Mise en forme :
a.. Utiliser des feuilles de styles pour séparer le contenu de la
présentation dans la page.
b.. Vérifier que lorsque les feuilles de styles sont désactivées, le
contenu de la page est toujours accessible.
c.. Vérifier que lorsque les feuilles de styles sont désactivées, l'ordre
d'apparition des divisions est identique.
d.. Ne pas coder d'informations de mise en page dans le code source (FONT,
B, I.).
e.. Préférer l'utilisation de valeurs relatives pour spécifier la taille
des tableaux, images...
f.. Dans le cas de l'utilisation de valeurs absolues, vérifier que les
informations restent accessibles, quelles que soient les plates-formes
utilisées (écran, navigateurs .).
g.. Préférer l'utilisation de polices sans serif (ARIAL, VERDANA .).
h.. Ne pas utiliser plus de trois polices de caractères différentes dans
la même page.
Formulaires :
a.. Utiliser la balise LABEL pour associer un texte et son champ INPUT.
b.. Utiliser les balises FIELDSET et LEGEND pour structurer les
formulaires.
c.. Dans les champs de saisie, utiliser un texte explicatif pour préciser
à l'utilisateur la fonction de ce champ.
d.. Organiser les informations dans un ordre logique dans les listes de
choix (par ordre alphabétique par exemple).
e.. Le commentaire du bouton Submit doit être explicite.
f.. Vérifier l'accessibilité du contrôle de saisie de votre formulaire.
(Scripts, champs obligatoires .)
g.. L'espace entre les labels et les champs textes associés doit être
suffisamment réduit.
h.. Les champs textes associés aux champs de formulaires doivent être
explicites et lisibles hors contexte (éviter «faites votre choix » plusieurs
fois dans le même formulaire)
Ergonomie :
a.. La navigation dans la page doit être claire et cohérente.
b.. Prévoir l'utilisation de barres de navigations pour faciliter la
navigation dans le site.
c.. La structure de l'ensemble des pages doit être homogène.
d.. Le menu de navigation doit être placé à la même position dans l'
ensemble du site.
e.. Lors de regroupements de liens, placer des caractères de séparation
entre chacun des liens actifs.
f.. Pour une facilité de téléchargement, une page ne doit pas dépasser 50
Ko.
g.. Lors de l'utilisation de raccourcis clavier, vérifier leur présence
dans l'ensemble des pages du site et vérifier qu'ils sont identiques d'une
page à l'autre.
Divers :
a.. Ne pas faire clignoter ou défiler des informations dans la page.
b.. Ne pas utiliser de rafraîchissement automatique de la page.
c.. Prévenir l'utilisateur lorsqu'un lien ouvre une nouvelle fenêtre.
d.. Ne pas utiliser de scripts lors de l'ouverture de nouvelles fenêtres.
e.. Lors d'un téléchargement de fichiers, fournir des informations
complémentaires sur le fichier (Format, taille en octets...)
f.. Lors d'un téléchargement de fichiers au format PDF, par exemple,
prévoir une alternative (RTF, HTML, DOC... )
g.. Utiliser un langage simple et clair dans vos pages.
h.. Ne pas utiliser de scripts pour effectuer une redirection automatique.
i.. Ne pas utiliser des éléments de code inappropriés pour faire de la
présentation (BLOCKQUOTE, UL pour l'indentation, par exemple).
j.. Ne pas utiliser des majuscules pour de la mise en forme.
k.. Séparer chaque caractère d'un sigle par un point.
"
ou encore "
Voici quelques élements expliquant POURQUOI les différents points déjà
évoqués aide un malvoyant :
Les mal/non voyants utilisent deux techniques pour "visualiser" un site
Web : la synthèse vocale, et le terminal braille.
Tout d'abord, un terminal braille ne peut afficher qu'une ligne de 40
caractères en même temps, donc çà limite déjà pas mal pour la
compréhension d'un site.
Ensuite, les outils qui se greffent sur les navigateurs pour transcrire
en vocal ou en braille, commencent par récupérer l'ensemble des liens
pour faciliter la navigation rapide. Concernant les liens, le paramètre
"title" de la balise <a> permettent une description BREVE du lien.
Ensuite, quand on a par exemple une puce (image) suivi d'un texte, et
que le même lien existe sur les deux, l'outil de restituion de la page
va sortir succesivement le nom de l'image (même le nom du fichier si le
param "alt" n'est pas renseigné, bonjour la compréhension !) puis le
contenu de la balise <a>.
Rien qu'à cause de çà, de très nombreux sites sont très difficiles
d'utilisation pour les mal voyants...
Ensuite, dans la lecture du contenu d'une page, pour faciliter la
compréhension de ce qu'est un titre, un sous-titre, une corps de texte,
etc..., comme on ne peut pas se baser sur des indications visuelles, les
outils de lecture de page décomposent l'articulation logique du texte
grâce aux balises <h1> <h2> <h3> et <h4>...
Sur les images, si le param "alt" n'est pas réglé, l'outil de lecture
ressort le nom du fichier image correspondant... Imaginez avec les
"rien.gif" et compagnie le bordel pour consulter un site... alors
qu'écrire <img src="rien.gif" alt=""> permet de zapper carrément la
présence de l'image lors de l'analyse de la page !
Finalement, l'avantage de l'utilisation XHTML 1.0 (ou HTML 4.0 je vous
l'accorde ;)) et de CSS bien fichues permet de positionner dans le
source XHTML en premier le contenu de la page par exemple, puis de
définir les menus, barre de nav, etc.
Donc l'outil de lecture lit d'abord le contenu, ce qui est quand même
l'essentiel quand on veut consulter un article par exemple, plutot que
de se retaper pour la 50° fois sur le site la définition de toute la
nav, de la pub pour jouer au Casino Raoul Online, etc...
Voila donc simplement QUELQUES points expliquant l'intérêt des recos
W3C/WAI/BrailleNet...
Et l'intérêt des normes c'est aussi çà : çà donne un point de
convergence sur lequel on peut construire différents outils... dont par
exemple les outils de consultation de sites pour malvoyants...
Excusez moi, moi j'aime bien les normes, alors je préfère expliquer ce
que çà apporte et ne pas s'en tenir à une guerre de cathédrale genre IL
FAUT NORMER PARCE QUE C'EST BIEN, contre MOI J'AIME PAS LES NORMES, çà
me fait ch... de tout me coltiner et je vois pas que çà apporte 
Il ne faut pas oublier que les BONNES normes (elles ne le sont pas
toutes, loin s'en faut!!) porviennent quand même souvent de
l'apprentissage des erreurs : qu'est-ce qu'on peut faire pour se
débarasser de tous ces pbs qu'on s'est tapé depuis qu'on fait çà???
A++
Antoine.
--
Antoine ANGENIEUX http://www.clever-age.com
Clever Age - conseil en architecture technique
GSM: +33 6 63 58 36 95 Tél: +33 1 49 01 28 63
"
--neoram (Eh eh eh )
bonjour,
effectivement, il n'y en a pas beaucoup... en ce qui me concerne, et au delà
du code généré par spip, il me semble que tous les webmaster peuvent faire
un effort sur leurs squelettes afin qu'il soient un max standarts... j'ai
quelque peu copié le graphisme de openweb sur un projet de site :
http://outil.apinc.org afin de faire quelques essai sous spip et cela
fonctionne... cela m'a aussi et surtout permis de mettre le nez dans les CSS
et j'ai découvert un nouveau monde génial qui permet de contrôler
intégralement l"interface graphique... d'ailleurs comme le graphisme devient
du code dans ce cas là quid des droits d'auteurs ils ne sont plus gérés de
la même façon, en tout cas pour le graphisme...
Enfin gref tout àa pour dire que même si spip ne crache pas du 100% W3C, il
est tout à fait possible d'améliorer nettement la qualité des sites de ce
point de vue.
Cordialement
\\\\\/////
| - - |
[ ° ° ]
------oOOo--(_)-oOOo---------------
Jean-Luc GRELLIER
Chargé de Mission TIC
jl-grellier@cr-limousin.fr
ICQ : 117061113
Conseil Régional du Limousin
27, boulevard de la Corderie
87031 Limoges Cedex
T. +33 (0) 555-45-18-96
F. +33 (0) 555-45-17-48
------------------Ooooo-------------
( )
ooooO ) /
( ) (_ /
\ (
\_ )
----- Original Message -----
From: "jean-paul chiron" <Chiron@mail.aquitaine.fr>
To: "Christian Lefebvre" <christian.lefebvre@atosorigin.com>
Cc: <spip@rezo.net>
Sent: Tuesday, June 17, 2003 11:45 AM
Subject: Re: [Spip] Squelettes compatibles w3c
| Le 17.06.2003 11:32, Christian Lefebvre a écrit :
|
| >Le mar 17/06/2003 à 11:25, Jean-Paul Chiron a écrit :
| >
| >
| >>Bonjour,
| >>j'ai regardé sur les contribs, et je n'ai pas trouvé un seul squelette
| >>qui passe le validateur du w3c :
| >>http://validator.w3.org/
| >>Personne n'est interressé par l'interopérabilité chez les spipeurs ?
| >>
| >>
| > Houla ... dit comme ça, c'est l'idéal pour relancer le troll de la
| >semaine dernière 
| >
| Désolé, je ne l'ai pas suivi, et mon but n'est de troller...
|
| > Plus sérieusement, à part www.perdu.com, t'en connais beaucoup des
| >sites webs qui font zéro faute sur validator ?
| >
| >
| Ben il y en a quelqu'uns avec un peu plus de graphisme 
| http://openweb.eu.org/
| http://mozdev.org/
| http://linuxfr.org/pub
| http://devedge.netscape.com/
|
|
| a+.
|
| --
| Jean-Paul CHIRON
|
|
|
Le mar 17/06/2003 à 11:25, Jean-Paul Chiron a écrit :
j'ai regardé sur les contribs, et je n'ai pas trouvé un seul squelette
qui passe le validateur du w3c :
http://validator.w3.org/
Tu as regardé les squelettes par défaut ?
a+
Antoine.
Le 17.06.2003 13:48, Antoine a écrit :
Le mar 17/06/2003 à 11:25, Jean-Paul Chiron a écrit :
j'ai regardé sur les contribs, et je n'ai pas trouvé un seul squelette qui passe le validateur du w3c :
http://validator.w3.org/Tu as regardé les squelettes par défaut ?
Houps, non.
En effet, les squelettes par défaut sont entièrement compatible w3c.
Mais comme je n'aime pas la logique de navigation, je n'y pas fait attention du tout...
Je vais le modifier pour en faire ce que je veux...
Merci.
a+.
Les sqelettes "solidaires" qui seront en ligne bientot le sont(en grande
partie)
Éric
Jean-Paul Chiron a écrit :
Bonjour,
j'ai regardé sur les contribs, et je n'ai pas trouvé un seul squelette qui passe le validateur du w3c :
http://validator.w3.org/
Personne n'est interressé par l'interopérabilité chez les spipeurs ?a+.
------------------------------------------------------------------------
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.uzine.net/spip