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 ..

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

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.

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

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).


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 ! :up:

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 ! ^_^

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...

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

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

Merci Ernestine


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. -_-

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.


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'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.


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.


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.

Bonjour,

Excellente initiative, excellent boulot :up:

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)


Menus déroulants accessibles?

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.

Bien réalisés (comme celui de nizouille B) ) 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.

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 ?

D'abord ton menu est beau B)

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

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,

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

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. ^_^


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> :

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.



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. ^_^


Ç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 !

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


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 ?




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

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é) ?

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 vrai que le menu me semble toujours à la même place


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 s’en remettre exclusivement aux couleurs. du WCAG recommande de s'assurer que les textes et graphiques sont compréhensibles quand on les visualise sans couleur.

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

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).

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... ^_^

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 ? )

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

Ce n'est malheureusement pas aussi simple. Quelqu'un est surpris ?

Si tu souhaites utiliser du gras pour mettre une véritable emphase sur quelques mots et que cette emphase apporte une véritable valeur ajoutée au message, alors tu utilises un <strong> parce que cet indice est important au message.

Si tu veux mettre du gras pour le nom du site Web, comme tu le fais actuellement, alors utilises le <b> car ton emphase n'est que visuelle, elle n'apporte aucun sens supplémentaire au message, elle ne fait qu'attirer l'attention sur les mots.

De toute manière, pour deux trucs qui se valent en terme de récultats, entre 4 caractéres pour écrire un <b> et 20 caractères pour écrire <span class="gras">, l'optimisation te pousse nettement vers le premier choix.

Mais si on devait résumer, alors oui ; si tu dois faire du gras, utilises le <strong> parce qu'en définitive, si tu veux mettre du gras, c'est que ce traitement apporte une valeur ajoutée. Mais rappelle toi que trop de <strong> tue le <strong>, comme trop de <div> tue le <div>.

Vous connaissez cet instrument du w3c ?
http://www.w3.org/2002/08/extract-semantic.xsl

Pourquoi ça ne donne rien pour mon site sur l'enseignement et les préparations de cours

Tu confonds ici deux concepts très différents. Il y a sémantique HTML et Web sémantique. Une recherche rapide sur Google pour "semantic web" et "html semantics" te permettra d'y voir un peu plus clair.

Le document auquel tu réfère sert à "mesurer" la sémantique de l'information contenue dans le document. Pour y arriver, l'outil recherche un certain nombre d'éléments et de technologies comme RDF ou FOAF, qui ne figurent évidemment pas dans tes pages. Ce qui explique pourquoi ça ne fonctionne pas pour toi.

Ce que tu cherches toi, c'est mesurer la valeur sémantique de ton code, pas de ton contenu. Pour cela, il n'existe malheureusement pas d'outils automatisés comme par exemple le validateur. C'est une question d'analyse et de recul vis-à-vis tes intentions pour faire les meilleurs choix - et les plus optimisés.

C'est lorsque je m'aventure dans des réponses comme celles-là que je m'ennuie de Karl Dubost et Laurent Denis...

Je ne comprends pas pourquoi j'ai autant de problèmes avec ceci :
http://validator.w3.org/checklink?uri=http...th=&check=Check

http://www.enseignons.be/../fondamental/co...amental-20.html
What to do: Usually the sign of a malformed URL that cannot be parsed by the server.
Response status code: 400
Response message: Bad Request
Line: 85
http://www.enseignons.be/../fondamental/co...amental-18.html
What to do: Usually the sign of a malformed URL that cannot be parsed by the server.
Response status code: 400
Response message: Bad Request
Line: 85
http://www.enseignons.be/../secondaire/cou...aire-43-10.html
What to do: Usually the sign of a malformed URL that cannot be parsed by the server.
Response status code: 400
Response message: Bad Request
Line: 90


Et y en a 96 comme ça ... J'ai vérifié mon code, les liens, ... et là ..

j'ai rien dit ... de grooooosses erreurs de ma part j'ai honte

Et pour le bénéfice des millions de téléspectateurs qui nous regardent à la maison, tu pourrais partager les raisons de ta honte, pour que d'autres en apprennent un tout petit peu également ?

J'avais tellement honte que j'ai préféré éteindre mon pc, le fuir en courant, nu vers l'océan.

Plus sérieusement, je n'avais pas mis à jour mon menu principal, et je l'avais changé de place il ya de cela un bon bout de temps ... et TOUS les liens relatifs pointaient vers quelque chose qui n'existait pas ..

http://www.enseignons.be/../fondamental/co...amental-18.html

Les navigateurs étant très intelligents (sauf IE ), tous redirigeaient automatiquement vers http://www.enseignons.be/fondamental/cours...amental-18.html
ce qui fait que je n'ai vu l'erreur qu'aujourd'hui en le passant au link checker du w3c ...

OOOOOOOouuuuuuuuh
Tiens j'ai essayé le lien que j'ai donné tantôt sur mon flux rss :
http://www.enseignons.be/forum/rss.php, mais ça n'a pas donné grand chose non plus