Vérifier l'accessibilité de mon site

[nizouille]

Hello,

Quelqu'un d'expert en accessibilité pourrait-il vérifier l'accessibilité de ce site internet sur les ressources pédagogiques pour l'enseignement

Accessoirement, je veux bien apprendre quelques conseils ..

[technyweb]

Bonsoir Nizouille

Tu as 2 post-it juste au-dessus sur ce forum concernant l'accessibilité, tu pourrais y faire un p'tit tour.

Sympa ton site

Modifié 2 Janvier 2005 par technyweb

[Loupilo]

Hello,

Quelqu'un d'expert en accessibilité pourrait-il vérifier l'accessibilité de ce site internet sur les ressources pédagogiques pour l'enseignement

Accessoirement, je veux bien apprendre quelques conseils ..

<{POST_SNAPBACK}>

Salut à toi,

Couleurs désactivées, ton menu déroulant n'est pas lisible, mais je ne vois qui peut naviguer les couleurs désactivées (j'ai vérifié ça car Monique le faisait quand on parlait des menus déroulants accessibles).

Avec Lynx, le rendu est très correct, si ce n'est que le menu est bien long et donc bien compliqué à naviguer.

Sinon, le site est agréable à parcourir, et l'idée de "partager pour mieux enseigner" ne mérite que des encouragements

Bonne continuation,

Loupilo.

[Ernestine]

Coucou,

Je ne suis pas une experte de l'accessibilité, mais ta page me semble très correcte. Deux petits défauts toutefois :

1/ tu as des divs imbriqués les uns dans les autres, c'est à éviter. Les divs doivent être de niveau 0, éventuellement de niveau 1... mais à partir d'un troisième niveau de hiérarchie c'est pas conseillé.

2/ Tu as plein de balises méta inutiles : les seules indispensables sont la méta keywords et la meta description. Ca n'a rien à voir avec l'accessibilté, mais en revanche ça améliore la lisibilité

Au plaisir,

Ernestine

[Denis]

Bonjour, vite comme ça, ça a l'air pas mal, mais il y a quelques petites bricoles qui posent problèmes... en voici quelques unes à mon tour (mes observations se limitent à la page d'accueil) :

1. Les cibles de tes hyperliens ne sont pas spécifiées. Il faut leur attribuer un petit attribut title pour corriger le tir. Actuellement, un synthétiseur vocal qui lirait uniquement les liens de la page ne permettrait pas forcément à l'utilisateur de se faire une tête sur la destination de ceux-ci. Et pendant que tu y es, si le lien pointe vers un document dans une autre langue, tu pourrais aussi y ajouter l'attribut hreflang).

Ex. : <a href="" title="texte court et significatif pour supporter le href" hreflang="en">

2. Certains liens adjacents ne sont pas clairement séparés les uns des autres. C'est au moins le cas pour tes liens "Inscription - Newsletter et Forums" qui, bien que clairement séparés par CSS d'un point de vue visuel, ne sont qu'un petit tas de code mis ensemble en réalité. Pour les départager, l'utilisation d'une liste serait d'un bel effet, avec les efforts qui s'imposent pour l'adapter visuellement au design.

Au passage, mes plus sincères félicitations pour un code conforme et une navigation dynamique qui fonctionne sans javascript. Voilà qui donne envie d'aider son prochain !

Toutefois, il te faudrait mettre un accent très prononcé sur la sémantique de ton HTML parce que pour le moment, c'est nettement le point le plus faible de ton projet qui autrement, est d'un très bon calibre. De plus, cette sémantisation de ton HTML te permettrait de te débaresser de cette armée de span qui pollue ton code pour te concentrer à CSS-iser les éléments HTML qui comptent vraiment. Il faudrait également à songer à une séparation plus nettre entre ta structure et ta présentation, en commençant par sortir toutes ces règles CSS de ton HTML et les envoyer dans un fichier externe.

Voilà pour mes premiers commentaires. Bravo autrement !

[benjiiim]

Bonjour,

J'aime beaucoup le design de ton site.

Une toute petite remarque en passant ne concernant pas l'accéssibilité : je crois que si tu spécifies l'encodage de ta page comme ceci :<?xml version="1.0" encoding="ISO-8859-15"?> au tout début de la page (1ere ligne), tu n'as plus besoin de spécifier les caractères spéciaux comme tu le fais et tu peus mettre les accents dans ton code, ca sera bcp plus lisible.

Néanmoins, c'est à vérifier et si quelqu'un pourrait confirmer...

[nizouille]

Merci pour ces réponses ...

Je me suis en effet attelé à créer un site xhtml + css. Merci pour vos critiques positives. Soucieux d'améliorer constamment mon site, je voudrais quelques précisions sur certains points :

- Quelqu'un pourrait vérifier les propos de Benjiim ci-dessus ?

- Je sais n'avoir mis aucun accesskey, est-ce grave ?

- l'attribut title est validé je crois par le w3c. Est-il pris en compte pour le référencement ?

- Denis, je vais m'atteler à faire ce que tu me dis. Je me suis attaché à séparer un maximum contenu et mise en forme, mais je sais qu'il reste encore quelques style: dans le code, mais c'est une question de jours et ce sera réglé. Entends-tu autre chose par sémantisation du code ? Pourrais-tu me donner un exemple ?

- Ernestine : comment faire pour ne pas imbriquer plusieurs div, rien que mon cadre arrondi (je précise : avec un effet ombré) nécessite ces div. Y vois-tu une alternative ? En quoi est-ce gênant ?

Quelles balises meta sont réellement inutiles (j'entends pour tout le monde, pas seulement pour Google) ? En quoi est-ce que ça "améliore la lisibilité" ?

Merci pour vos commentaires

[Ernestine]

Super analyse de Denis

Oui, la balise Title est extrêmement importante pour le référencement.

Pour les balises méta, dans l'absolu aucune n'est réellement indispensable. Libre à chacun d'indiquer ou non les KeyWords, le Copyright ou l'Auteur. Mais autant ne renseigner que celles qui servent à quelque chose comme la Keywords et la Description. J'avais oublié, il faut aussi mettre la content-type.

Pour les divs, bien sûr on est parfois obligé de les imbriquer, notamment pour faire des cadres aux bords arrondis Le principal est de ne pas en abuser. Et tu n'en abuses pas donc ça va Je pense qu'à un ou deux endroits tu pourrais t'en passer, peut-être que cet article t'éclairera : trop de div tue le div

Au plaisir,

Ernestine

[Denis]

Super analyse de Denis

Merci Ernestine

Je pense qu'à un ou deux endroits tu pourrais t'en passer, peut-être que cet article t'éclairera : trop de div tue le div

Dans le même ordre d'idées, une "claque", openweb-style

http://openweb.eu.org/humeurs/calques_perdent/

Nizouille, je reviendrai sous peu pour pousser plus de l'avant mes réponses à tes questions. Là, il est l'heure d'aller coucher les enfants.

[Denis]

Une toute petite remarque en passant ne concernant pas l'accéssibilité : je crois que si tu spécifies l'encodage de ta page comme ceci :<?xml version="1.0" encoding="ISO-8859-15"?> au tout début de la page (1ere ligne), tu n'as plus besoin de spécifier les caractères spéciaux comme tu le fais et tu peus mettre les accents dans ton code, ca sera bcp plus lisible.

Néanmoins, c'est à vérifier et si quelqu'un pourrait confirmer...

Cette information me semble éronnée. S'ill est vrai qu'il n'est pas nécessaire de spécifier le prologue XML parce que certains navigateurs sont imcapables de le supporter (lire MSIE entre autres), le spécifier n'est pas un mal, pas plus que de déterminer le charset de l'information à faire afficher.

Je sais n'avoir mis aucun accesskey, est-ce  grave ?

Non, ce n'est pas grave, c'est une façon alternative d'accéder aux contenus, mais ce n'est pas la seule. Les accesskeys soulèvent de nombreuses controverses parce que leur utilisation N'est pas standardisée. Tu trouveras toute l'information souhaitée à ce sujet dans un article de Laurent Denis, paru sur OpenWeb :

http://openweb.eu.org/articles/accesskey_e...non_transforme/

L'attribut title est validé je crois par le w3c. Est-il pris en compte pour le référencement ?

L'attrribut title est bien sûr conforme aux diverses normes (x)HTML. Tu peux donc en abuser en toute confiance. L'important c'est de ne pas tomber dans l'excès inutile, comme pour faire dire à la valeur du title le même type d'information que le lien porte lui-même.

Denis, je vais m'atteler à faire ce que tu me dis. Je me suis attaché à séparer un maximum contenu et mise en forme, mais je sais qu'il reste encore quelques style: dans le code, mais c'est une question de jours et ce sera réglé. Entends-tu autre chose par sémantisation du code ? Pourrais-tu me donner un exemple ?

Oui bien sûr, mais pour bien comprendre ce dont je parle, il faudrait d'abord que tu lises ce petit texte qui te dresseras un portrait initial :

http://openweb.eu.org/articles/respecter_semantique/

Grosso modo, la sémantique HTML, c'est tout d'abord de pratiquer une économie des balises HTML que tu utilises, tout en réfléchissant auxquelles sont les plus appropriées pour remplir un rôle précis. L'exemple clasique, ce serait d'utiliser une liste à puces pour faire un menu, plutôt que d'utiliser un paragraphe avec des br par exemple.

Dans le cas de ton propre site, nous pourrions justement réfléchir sur l'intérêt des :

1. fameux trois items de menus en span qui causent un problème d'accessibilité ;

2. span utilisés comme des éléments de block alors que le div sert justement à cela ;

3. br pour créer de l'espace entre deux paragraphes ;

4. span utilisés uniquement pour passer des class CSS alors qu'il y a déjà des éléments HTML qui peuvent les accueillir.

5. Etc.

comment faire pour ne pas imbriquer plusieurs div, rien que mon cadre arrondi (je précise : avec un effet ombré) nécessite ces div. Y vois-tu une alternative ? En quoi est-ce gênant ?

L'imbrication de divs n'est pas gênante, tant et aussi longtemps que chacun de ces div peut être justifié. Mais comme cette question nous ramène aux textes que je t'ai proposé plus haut, je te laisse tout d'abord les lire.

[Monique]

Bonjour,

Excellente initiative, excellent boulot

Le gros problème à mes yeux c'est le menu déroulant... et cela me fend le coeur de dire ça parce qu'il est vraiment réussi

Pour ne pas réinventer la roue, voilà une copie de deux interventions qui s'adaptent à ton cas :

Conseils pour un menu dynamique accessible (à l'exception du JavaScript)

Ce que tu décris ressemble plutôt à un plan/carte de site qu'à un menu de navigation !

Donc :

- simplifier le menu et s'en tenir aux items principaux, pour éliminer le javascript et les menus déroulants, toujours moins agréables à consulter qu'une page plate quand les items sont trop nombreux;

- laisser au plan de site son rôle de liste organisée de toutes les pages disponibles (utiliser une bonne hiérarchie de titres pour faciliter l'accessibilité)

Menus déroulants accessibles?

Il faut néanmoins bien comprendre une chose au delà même de la résolution technique de ce type de menus :

Ce type de menus posent vraiment de très lourds problèmes à une frange importante de personnes handicapées.

- Les personnes ayant des problèmes de mobilité qui ont bcp de mal à pointer leur souris sur ce type de zones.

- Les enfants handicapées cognitif pour qui un clic doit obligatoirement definir une action.

- Les personnes malvoyantes qui une fois qu'elles ont zoomées la page et passent la souris sur ce type de menus doivent obligatoirement descendre dans la page pour voir l'ensemble des éléments et du coup enleve le focus du lien faisant disparaitre le sous menu.

- Les personnes souffrant de problème de concentration qui voit apparaitre de nul part un sous menu juste parcequ'elles voulaient cliquer sur un lien ?

Au delà même des personnes handicapées énormèment de personnes débutants sur le web ne repèrent pas du tout ce type de navigations peu intuitives.

Il faut donc bien comprendre que si ce type de menus peuvent etre techniquement accessibles (et ce n'est pas le cas a 100% aujourd'hui) cela ne veut pas dire que pour les utilisateurs ce sera le cas.

[Denis]

Le gros problème à mes yeux c'est le menu déroulant... et cela me fend le coeur de dire ça parce qu'il est vraiment réussi 

Bien que j'ai tendance à toujours essayer de dissuader mes clients de recourir à ce type de pratiques pour plutôt préconiser une solide réflexion sur l'architecture des contenus, je dois dire que je suis plus ou moins d'accord avec un tel nivellement par le bas. Oui, ces menus peuvent présentés un certain nombre de problèmes pour un certain nombre d'utilisateurs très marginalisés, mais ils ne sont pas impossibles à utiliser pour autant par ceux-ci... tant et aussi longtemps qu'ils sont construits intelligemment, avec une structure HTML irréprochable, sémantique et bien sûr, sans javascript.

[Monique]

Bien réalisés (comme celui de nizouille ) j'ai toujours trouvé ce type de menus séduisants et j'en étais une adepte avant de m'intéresser de plus près aux problèmes d'accessibilité. Je passais d'ailleurs outre de mes propres problèmes : trop impulsive avec ma souris je sors continuellement de la zone cliquable, avec mon habitude de naviguer en fenêtre réduite je dois souvent jouer de l'ascenceur pour récupérer le bas des listes trop longues.

Je pense cependant que l'utilisateur d'une synthèse vocale ou d'une tablette braille aura beaucoup de difficultés pour tirer efficacement parti d'un menu de près de 80 liens.

[nizouille]

Merci pour vos commentaires.

Je connaissais la plupart des sites qui ont été mis en lien, mais les relire rafraîchit toujours un peu la mémoire

Je suis paré à travailler la sémantique de mon site, c'est partiiii.

Je ne vois pas trop comment travailler sur ces spans apparemment mal utilisées. Je me suis peut-être mal renseigné, mais c'était dans ma tête la seule possibilité.

Par ailleurs je ne vois pas de quoi tu parles Denis, en disant "

2. span utilisés comme des éléments de block alors que le div sert justement à cela ;

4. span utilisés uniquement pour passer des class CSS alors qu'il y a déjà des éléments HTML qui peuvent les accueillir."

Ensuite, je n'ai pas bien compris la discussion qui avait trait à mon menu déroulant. Il est bien fait mais mal finalement ?

[Monique]

Ensuite, je n'ai pas bien compris la discussion qui avait trait à mon menu déroulant. Il est bien fait mais mal finalement ?

<{POST_SNAPBACK}>

D'abord ton menu est beau

Ensuite il est techniquement accessible, c'est à dire qu'il n'y a pas d'obstacles à l'accès à l'information.

Par contre il y aura inconfort ou difficulté pour certains utilisateurs, par exemple :

- écouter une liste de 80 liens avec une synthèse vocale pour y choisir une cible n'est pas facile

- parcourir le menu avec une loupe d'écran est assez acrobatique puisqu'il faut déplacer la souris (donc perdre le focus) pour jouer de l'ascenceur

PS : nizouille, cette annonce pourrait t'intéresser : Cartes de géographie

Modifié 3 Janvier 2005 par Monique

[nizouille]

Re,

La proposition peut paraître absurde, mais j'aimerais appliquer une sémantique plus conforme, y aurait-il quelqu'un qui pourrait m'y aider ? Surtout concernant ces span. N'hésitez pas à consulter d'autres pages également, j'ai l'impression que j'ai fait une assez mauvaise utilisation de div ...

J'espère ne pas paraître timbré en vous proposant cela

Bien sûr, je ferais tout, mais cil s'agit juste de m'indiquer précisément ce qui pose problème, et une possibilité pour le résoudre ..

Bien à vous,

[Matthieu Faure]

Ensuite il est techniquement accessible, c'est à dire qu'il n'y a pas d'obstacles à l'accès à l'information.

Salut Monique (meilleurs voeux )

Permets-moi de préciser ta pensée

Le menu déroulant est toujours présent quand on désactive les feuilles de style; en cela il valide le critère AccessiWeb 10.2 ("Avec les feuilles de style désactivées, l'information est-elle toujours présente ?").

Par contre, il invalide le critère 10.3 ("Avec les feuilles de style désactivées, l'ordre d'apparition de l'information est-il respecté par rapport à l'ordre d'apparition initialement défini ?"), puisque le menu passe après le contenu une fois les CSS désactivées. Ce critère est bronze, donc sa non validation entrainera impossibilité d'accès à une catégorie d'utilisateurs. On invalide aussi de fait le critère 12.2 ("Le menu principal de navigation interne dans le site est-il toujours présent à la même place dans les pages ?")

Le critère 3.1 est aussi invalidé ("L'information donnée par la couleur est-elle aussi lisible lorsque les couleurs sont désactivées ?"). En effet, ce qui permet de voir le contenu du menu est son fond blanc; si les couleurs sont désactivées, on voit "au travers" du menu et tu obtiens une superposition de textes, ce qui les rend illisibles. (Tu peux le vérifier avec la webdeveloper toolbar, menu Disable, choix Disable Page Colors.)

Pour en revenir à l'utilisateur, c'est principalement les personnes utilisant des loupes d'écran (et éventuellement des CSS personnalisées) qui seront pénalisées par un tel menu.

Voila

Mes 2 centimes

[Denis]

Avec un peu de retard, mais plein de bonne volonté, je me lance quand même dans une réponse pour essayer de t'éclairer un peu sur ce que j'entendais. Je m'excuse d'avance, je sais que ce sera long.

Je ne vois pas trop comment travailler sur ces spans apparemment mal utilisées. Je me suis peut-être mal renseigné, mais c'était dans ma tête la seule possibilité. Par ailleurs je ne vois pas de quoi tu parles Denis, en disant :

2. span utilisés comme des éléments de block alors que le div sert justement à cela ;

4. span utilisés uniquement pour passer des class CSS alors qu'il y a déjà des éléments HTML qui peuvent les accueillir."

Commençons par le point 2 si tu le veux bien. Tu utilises trois spans pour créer le menu du haut pour les items inscription, newsletter et forum. Voici comment tu as codé le CSS qui accompagne ces <span> :

/* les 3 boutons du header*/ 
.bt1 { 
  position: absolute; 
  top: 18px; 
  left: 470px; 
  font-size: 13px;
} 
.bt2 { 
  position: absolute; 
  top: 38px; 
  left: 440px; 
  font-size: 13px;
} 
.bt3 { 
  position: absolute; 
  top: 58px; 
  left: 415px; 
  font-size: 13px;
}

Autrement dit, en positionnant ces trois <span> comme des éléments distincts, tu leur donnes un rôle semblable à celui qu'un <div> remplirait, donc un élément block. Pour faire la distinction entre un élément en-ligne (ex. le span), par opposition à un élément bloc (ex. le div) et la différence entre un <div> et un <span>, voir les articles suivants :

http://www.netmechanic.com/news/vol6/css_no16.htm

http://www.webmasterworld.com/forum83/3980.htm

http://webdesign.about.com/cs/htmltags/a/aa011000a.htm

C'est pas terrible, mais c'est ce que j'ai trouvé de mieux pour le moment.

C'est pourquoi je faisais initialement allusion à l'effet d'utiliser une liste HTML avec trois <li> plutôt que trois <span> (ou mieux, <div>). Sémantiquement parlant, le <ul> serait plus indiqué pour regrouper ton menu que ces trois liens qui actuellement ne sont pas regroupés du tout. Est-ce que je suis un peu plus clair ?

Et maintenant, pour le point 4 : "span utilisés uniquement pour passer des class CSS alors qu'il y a déjà des éléments HTML qui peuvent les accueillir". Prenons quelques exemples, tu comprendras tout de suite.

<span class="gras">Enseignons.be</span>
<span class="gras">échange de ressources pédagogiques</span>
<span class="gras">50 préparations</span>

P.S.:<span class="gras">Enseignons.be étant à ses débuts, peu de préparations se trouvent à ce jour sur notre serveur. Nous vous demandons votre plus grande collaboration pour que rapidement des documents soient à disposition des autres utilisateurs, afin de pouvoir lancer le mouvement d'échange.</span>

Dans les deux cas, tu utilises une classe "gras" pour simuler la balise <b> que tu as décidé de ne pas utiliser, fort probablement parce que tu as lu quelque part qu'elle ne véhiculait aucune valeur sémantique (et c'est vrai). En remplaçant ton <b> par un <span class="gras">, tu es tombé dans le même piège que tout le monde (je n'y ai pas échappé non plus il y a quelques années).

Heureusement, c'est le genre de truc qu'on te dit une fois et plus jamais tu ne refais l'erreur par la suite. Si tu voulais conférer aux mots que tu soulignes une valeur supplémentaire d'emphase (et pas juste un effet visuel), tu devrais utiliser la balise <strong> qui est tout à fait indiquée pour cela. Dans ce cas-ci, c'est un abus de CSS et de span.

En résumé, si tu veux juste faire du gras, sachant que la seule valeur sera visuelle, garde plutôt ce bon vieux <b> qui fait partie de la norme XHTML 1.0 strict de toute manière. Si tu veux aller un peu plus loin en terme de focus, utilise le <strong>.

Dans le deuxième cas, pour l'exemple de ton paragraphe avec un P.S., tu utilises un <span> de trop. Tu aurais tout aussi bien pu écrire <p class="gras"> et t'éviter le recours à un <span>... parce que la sémantique, c'est aussi l'économie des balises.

La proposition peut paraître absurde, mais j'aimerais appliquer une sémantique plus conforme, y aurait-il quelqu'un qui pourrait m'y aider ?

Ça peut se faire... ce serait très formateur pour tout le monde je crois.

Pour commencer, je te propose de réfléchir sur le rôle que doit remplir chaque bout de code. En fonction de la réponse, tu auras déjà une meilleure idée du choix de balise HTML à utiliser pour tes pages. Revenons à ce fameux menu avec trois <span> pour réfléchir sur les menus en général.

Qu'est-ce qu'un menu, sinon une série de liens, regroupées ensemble ? Pour que le sens de regroupement existe ailleurs que simplement viuellement, il faut les structurer pour qu'ils soient contenus dans un bloc, un conteneur. C'est pourquoi le <ul> peut être tout indiqué, puisqu'il regroupe un nombre illimité d'items (les <li>) de menu potentiel. Mais ce n'est pas la seule solution... d'un point de vue accessibilité, un <p> avec trois <a> à l'intérieur, séparés par des caractères délimitateurs adjacents comme le | pourraient aussi faire l'affaire, tout comme le ferait un <ol> ou même un <div>, traité comme un paragraphe (mais dans un tel cas, il faudrait que tu te questionnes sur la pertinence d'utiliser le <div> puisque le <p> serait tout indiqué).

Fais cette réflexion avec chaque bouts de code utilisés et pose toi la question de la pertinence du code choisi... est-il le plus approprié pour le travail, en fonction de ce que tu connais de sa raison d'être ?

J'arrête ici pour le moment, parce qu'on va finir par me crier de me la fermer !

[nizouille]

Par contre, il invalide le critère 10.3 ("Avec les feuilles de style désactivées, l'ordre d'apparition de l'information est-il respecté par rapport à l'ordre d'apparition initialement défini ?"), puisque le menu passe après le contenu une fois les CSS désactivées. Ce critère est bronze, donc sa non validation entrainera impossibilité d'accès à une catégorie d'utilisateurs.

Oui, mais ce serait stupide de sacrifier le référencement (les 300 premiers mots du texte) au menu, sous prétexte d'accessibilité.

On invalide aussi de fait le critère 12.2 ("Le menu principal de navigation interne dans le site est-il toujours présent à la même place dans les pages ?")

C'est faux ! le menu est toujours à la même place sur toutes les pages. Bien sûr, il y a deux menus différents, mais ne doit-on se limiter qu'à un seul menu ?

Le critère 3.1 est aussi invalidé ("L'information donnée par la couleur est-elle aussi lisible lorsque les couleurs sont désactivées ?"). En effet, ce qui permet de voir le contenu du menu est son fond blanc; si les couleurs sont désactivées, on voit "au travers" du menu et tu obtiens une superposition de textes, ce qui les rend illisibles. 

Y a des gens qui désactivent les couleurs ??? Quel intérêt ?

[nizouille]

Concernant le point 2., je suis entièrement d'accord

Concernant le point 4., j'explique ma démarche peut-être. Ce que je voulais faire, c'est séparer au maximum contenu et forme. Or, mettre un <b> ou <strong> à l'intérieur du code ne va-t-il pas à l'encontre du xhtml (même si validé) ?

[Monique]

Oui, mais ce serait stupide de sacrifier le référencement (les 300 premiers mots du texte) au menu, sous prétexte d'accessibilité.

Dans la discussion Besoin de clarté sur le doctype, et sur la position du menu et du contenu, tu trouveras des explications à propos des liens en début de page (Aller au menu, Aller au contenu...) qui permettent de résoudre ce problème.

C'est faux ! le menu est toujours à la même place sur toutes les pages. Bien sûr, il y a deux menus différents, mais ne doit-on se limiter qu'à un seul menu ?

C'est vrai que le menu me semble toujours à la même place

Y a des gens qui désactivent les couleurs ??? Quel intérêt ?

En réalité, ils y a ceux qui ne perçoivent pas (ou perçoivent mal) les couleurs, ceux qui utilisent un écran noir et blanc. C'est pourquoi la Directive 2. Ne pas sen remettre exclusivement aux couleurs. du WCAG recommande de s'assurer que les textes et graphiques sont compréhensibles quand on les visualise sans couleur.

[Monique]

Concernant le point 4., j'explique ma démarche peut-être. Ce que je voulais faire, c'est séparer au maximum contenu et forme. Or, mettre un <b> ou <strong> à l'intérieur du code ne va-t-il pas à l'encontre du xhtml (même si validé) ?

<{POST_SNAPBACK}>

Tu as tout à fait raison de vouloir séparer contenu et forme

Pour l'usage de la balise <b> les avis sont partagés, je n'y reviens pas.

La balise <strong> aura pour conséquence l'affichage en gras avec la plupart des navigateurs graphiques, une modification de l'intonation avec les synthèses vocales (ce qui indiquera l'importance de la portion de texte).

[Denis]

Or, mettre un <b> ou <strong> à l'intérieur du code ne va-t-il pas à l'encontre du xhtml (même si validé) ?

Et franchement, quelle est la différence entre un <span> et un <b> ? Dans les deux cas, tu es aux prises avec une balise qui n'a strictiement rien à voir avec ta structure de code...

[nizouille]

Le mieux selon toi serait la balise strong donc (même si il n'y a plus alors de séparation effective entre contenu et forme ? )

[Matthieu Faure]

C'est vrai que le menu me semble toujours à la même place 

<{POST_SNAPBACK}>

Sauf si tu désactives les CSS.

Avec CSS, il est "avant" le contenu (à gauche du contenu dans le sens de lecture gauche->droite, donc avant le contenu). Sans CSS, il est après le contenu.

(ce n'est pas trivial, mais ce n'est pas "faux!" )

Matthieu