Bonjour,

J'ai travaillé à rendre accessible le site dont l'url (temporaire) est http://www.villesurinternet.com/figari
Je vous remercie de bien vouloir me donner vos remarques et conseils.

J'ai passé les tests de Acces-pour-tous, de la sympathique Synthia et du "terrible" Bobby.

Je pense devoir améliorer le contenu des "alt". Mais, pour certaines images, je ne sais pas les décrire en détail (photos de classe par exemple).
Pour d'autres, j'avoue que je ne sais pas quoi indiquer.
Comme quoi, pour moi aussi, l'accessibilité n'est pas parfaite parce que je manque d'informations.

Pour le label du formulaire de recherche, j'ai "triché" parce que je ne mets pas de texte comme cela se fait habituellement pour un moteur de recherche.
Cette "ruse" est-elle acceptable ?

Pour les images réactives, j'ai utilisé les liens côté serveur. Est-ce que cela suffit ?

J'attends vos remarques sur tous les points qui vous semblent utiles.

Cldt.

Gilbert

Tout simplement : non !
Cette "ruse" fait peut-être passer la validation formelle, mais ce n'est pas le but du jeu : il s'agit de rendre ce formulaire réellement accessible, autrement-dit de lui donner un vrai label textuel.

Si tu veux à tout prix le masquer graphiquement, utilise plutôt cette ruse CSS qui elle est inoffensive :


(Pour les détails, voir Lecteurs d'écran : cachez ce sein que je ne saurais voir

Merci.
C'est fait.
D'autres remarques ?

Evite absolument les remplissages du type "photographie" ou "campagne pour les images de la page d'accueil.

Donne une brève description du contenu de l'image en rapport avec celui de la page: par exemple, ton "route bordée de chênes-lièges" est bien, parce qu'il apporte au visiteur non-voyant une information nouvelle et pertinente qui autrement serait réservée au visiteur voyant : cette commune est dans une région où pousse ce type d'arbre... et le site comporte justement une page consacrée à l'artisanat du liège

A ce propos, dans http://www.villesurinternet.com/figari/liege.htm :
- si les chênes-lièges étaient essentiellement plantés en bordure de parcelle ou de route, plutôt que sur les parcelles elles-mêmes, comme l'image semble suggère, il serait intéressant de l'intégrer dans le alt de la première image
- la seconde image montre que le liège était d'abord débité en bûches grossières...
- la troisième image, récolte en 2002... est intéressante parce qu'apparemment, on utilise toujours l'âne...

Autre exemple : dans http://www.villesurinternet.com/figari/pre...iremoyenage.htm, la photographie de la Chapelle San Quilico di Montilati : en quoi est-elle représentative d'une certaine architecture ? Son plan rectangulaire (pas en croix) ? Son toit presque sans pente ? L'appareillage de ses murs ? Le fait qu'elle soit apparemment isolée en pleine campagne ?

Finalement, remplir les alt des images est très loin d'être un travail dénué de sens et d'intérêt en soi

Si l'image ne te semble apporter aucune information de ce type... C'est peut-être bien qu'elle n'est que décorative. Dans ce cas, un alt="" l'évacue.

Que veux-tu dire ? Sur quelle page du site ?

Merci pour les images. Tes idées sont bonnes, je vais y travailler.
La difficulté est que parfois, je n'ai pas l'information.
Pour d'autres, il faut effectivement décrire la photographie en détail.
C'est pour ça que j'ai dit dans mon premier message que je comptais l'améliorer.

Pour l'image, je parlais de la page
http://www.villesurinternet.com/figari/plan.htm
Comme quoi, il faudrait aussi que je mette un texte à côté pour dire qu'on peut cliquer sur l'image.

Deux choses encore :

- l'accesskey du moteur de recherche n'est pas implémentée dans le formulaire :



- tu pourrais envisager un "menu d'accesibilité" tout en début de page (visuellement au dessus du "Bienvenue sur le site Officiel de la Commune de FIGARI, Corse-du-Sud") avec les liens vers :
* le contenu (#content, ou plutôt le premier titre texte de la page)
* le menu (rajouter une id sur le <ul class="menu nav">)
* la recherche (#recherche)
* la politique d'accessibilité (lien direct vers la page)

Au fait, c'est un très beau site, particulièrement agréable à consulter

Dans le détail (merci d'être allé aussi finement
> - si les chênes-lièges étaient essentiellement plantés en bordure de parcelle ou
> de route, plutôt que sur les parcelles elles-mêmes, comme l'image semble
> suggère, il serait intéressant de l'intégrer dans le alt de la première image
Ce n'est pas le cas.

> - la seconde image montre que le liège était d'abord débité en bûches
> grossières...
>- la troisième image, récolte en 2002... est intéressante parce qu'apparemment, >on utilise toujours l'âne...
OK.

>la photographie de la Chapelle San Quilico di Montilati : en quoi est-elle >représentative
> d'une certaine architecture ? Son plan rectangulaire (pas en croix) ? Son toit >presque sans pente ?
>L'appareillage de ses murs ? Le fait qu'elle soit apparemment isolée en pleine >ampagne ?
C'est là que j'ai une limite. Je ne connais pas l'architecture religieuse. Mais je vais me renseigner pour avoir plus d'information. Ce sera utile à tous, moi y compris !

le title de l'img est inutile. En revanche, reproduit les alt des area dans des title (les lecteurs d'écran l'utiliseront pour donner un intitulé au lien, en particulier IBM HPR) :



Et vu le petit nombre de lien de l'imagemap, tu pourrais peut-être faire comme on fait pour les imagesmap côté serveur : reproduire carrément les 5 liens "en dur", dans un mini-menu texte en dessous de l'image.
De la sorte, tu es certain de ne plus avoir le moindre problème d'accessibilité [edit]Concernant cette imagemap[/edit]

Chouette !

Bonjour,

Pas grand chose à ajouter après le passage de Laurent, si ce n'est confirmer son avis : c'est un site très agréable et intéressant B)

Pense quand même à passer les pages au validateur, il y a quelques petites choses à corriger... tant qu'à bien faire
- vraisemblablement à la suite de modification, des balises h3 qui se perdent
- des attributs pour les images (border, hspace, vspace) qui ne peuvent plus être utilisés avec le doctype choisi (XHTML 1.0 strict) mais doivent être spécifiés dans la feuille de style

Merci.


Pour donner un ordre d'idée, sur 30 pages, j'ai enlevé 150 tableaux.


OK.
Quel validateur ?
J'ai utilisé Bobby, Cynthia et Acces pour tous.


Je n'utilise pas ces balises. Je vais vérifier qu'elles ne restent pas de l'ancienne version.

Ok pour le validateur XHTML, je corrige ça.

Oups... j'aurais pu être plus précise

Outre les outils pour vérifier l'accessibilité des pages, il y a les validateurs pour vérifier la validité du code.
Pour le (X)HTML : celui du W3C ou celui du WDG. Ils se valent mais diffèrent surtout au niveau de l'explication des erreurs (plus didactique pour le WDG).
Pour les CSS : celui du W3C

Pour les images, c'est le cas pour le plan par exemple.

Euh sans vouloir encore casser un rêve, je vois quelques erreurs que je vais lister ci dessous, rien de bien méchant mais bon je suis chiant c'est dans ma nature

- La page est cassé simplement en augmentant la taille de police en 1024 (taille du texte -> la plus grande), on a donc une perte très importante d'infos a cause de l'ascenseur horizontal.

- La structure pourrait etre optimisée à mon avis (par exemple sur la home en mettant de la structure pour le menu principal (pixel transparent par exemple) idem pour le menu du bas de page ou au minimum pour l'actualité qui est un bloc visuel de structure mais pas dans le code.

- Toujours du point de vue structure : le plan du site qui est la page structurée par définition ne l'est pas vraiment dans le code.

- Point de vue très personnel mais pourquoi les contenus apparaissent avant le menu dans le code alors que visuellement ce n'est pas le cas. Pour avoir suivi la foramtion donnée par WAI a paris en juillet ils considèrent comme BrailleNet que c'est une faute, il vaut mieux rendre les contenus en linéaire tels qu'ils le sont visuellement et donner des moeyns de naviguer en interne par la suite (haut de page accès au contenus, accès au menu ...)

- Attention au changements de langue non signalés (les icone de conformance par exemple)

Voila rapidement mes remarques sans pousser plus que ca

C'est à la fois l'intérêt et le danger d'un forum de ce type :

- le danger parce que nos remarques peuvent donner à penser que nous faisons un travail d'expertise qui serait l'équivalent d'un "label" d'accessibilité. Or c'est loin d'être le cas. (A ce propos, je dissipe une confusion éventuelle : lorsque je disais qu'il n'y aurait plus de problème d'accessibilité, cela ne concernait que l'imagemap en question, pas le site dans sa totalité !)

- l'intérêt, parce que des experts "validés" comme yobiwan (et bientôt Monique si je ne m'abuse) y participent avec une approche plus rigoureuse et systématique que la nôtre...



Hum... Pourrais-tu approfondir les arguments ? J'avoue que le "en linéaire" me semble refléter une mauvaise compréhension des mécanismes de positionnement CSS, qui distinguent clairement les notions de flux et justement de "retrait du flux".

Alors ...

c'est pour moi très clair essayons donc de l'être sur le papier.

Pour nous et WAI (pour en avoir parlé un peu avec eux), lorsque des contenus sont organisés logiquement d'un point de vue visuel, il faut que dans le code cela soit rendu à l'identique.

Donc si visuellement on en 1 menu a gauche, un contenu au centre, et un menu à droite, dans le code et en linéaire donc, il faut que ce soit la meme chose.

Ce sont les mécanismes de naviagtion internes qui permettent de "sauter" les blocs.


j'éspère etre clair

Si je suis venu proposer mon site, c'est bien pour apprendre et progresser.


J'ai tenté de résoudre ce problème dans tous les sens. J'ai fait en sorte que le texte reste lisible en changeant la police comme tu le dis. Mais je me trouve devant des contraintes contradictoires: à la fois augmenter la taille de la police, ne pas user d'ascenseur horizontal, ne pas réduire la page à un timbre-poste si on choisit à l'inverse de réduire la police.
J'ai donc libellé les tailles de police en "em". J'ai tenté de libeller la taille des blocs en px, en em, en %. Mais à chaque fois, il y a un problème.
Si vous avez une solution qui permet de tout résoudre, je suis preneur !!
Remarque: sur le hub, si je mets la taille la plus grande, ça ne fait rien ! Alors, certes, il n'y a pas d'ascenseur horizontal



Je n'ai compris.




Oui. J'ai passé la moulinette XHTML aujourd'hui pour donner à mon code une structure plus logique. Je partais d'un code mauvais, j'ai donc choisi de faire d'abord l'accessibilité, ensuite le XHTML et le code propre. C'est un choix critiquable.
Si tu regardes, cela devrait être mieux. Mais sans doute pas parfait.



J'ai lu des conseils sur les sites / accessibilité qui disaient qu'il fallait faire apparaître le contenu principal en premier. Et donc le texte avant le menu.
Exemple: http://www.la-grange.net/accessibilite/day_10.html
J'ai appliqué la règle donnée.
Il semble que tout le monde ne soit pas d'accord sur le sujet. Cela dit, on ne peut pas je crois me reprocher d'appliquer une règle donnée par certains bons sites. Si tous les experts ne sont pas d'accord sur la question, ce n'est pas ma faute.
On peut me reprocher de ne pas bien appliquer les règles, pas d'appliquer une règle contestée. Vrai ? ;-)


OK.

Sur le plan technique (respect des règles) comme humain (jugement perso), je suis preneur de toute remarque.

Merci pour vos interventions.

Gilbert

Là aussi, j'ai regardé ce qui se faisait en termes de plan et menus. J'ai trouvé 2 ou 3 modèles différents. Le plus couramment conseillé est celui avec ul/li. Je l'ai appliqué sur le menu et le plan.
Quelles erreurs ai-je faites ?

Je ne comprends pas.


OK pour le fil d'ariane. Logiquement, ce devrait être un blonc ul/li.
Mais je ne sais comment indiquer en css d'afficher linéairement un ul/li.


Le code pour l'actualité est

C'est bien un blonc, non ?

Voir http://openweb.eu.org/articles/initiation_display/ pour les propriétés CSS à utiliser à cet effet et un exemple de base.

Parfait.

Pour le changement de taille de polices par l'utilisateur, je n'ai trouvé pas de solution parfaite comme je l'ai dit.

En gros, on a techniquement les possibilités suivantes:

- taille de la page
Faut-il utiliser px ou em ?
- taille des blocs
Faut-il utiliser px, em ou % ?
- taille des caractères
* em est la meilleure solution recommandée
* les noms: medium, large ... ne donne pas le même résultat sur IE et Mozilla, je l'ai donc évité.
* px est à éviter absolument

Si vous avez un exemple simple illustrant le propos...

La seule solution réellement accessible que je connaisse consiste... à ne spécifier aucune taille de caractère : les réglages par défaut de l'utilisateurs s'imposent immédiatement sans autre intervention de sa part, et il est seul responsable de ses maladresses

Cela dit, comme on a toujours du mal à ce que ça soit moche dans son propre navigateur avec ses propres réglages quand on regarde son propre site, cet article et surtout ses critiques peuvent te donner des éléments de réponse sur la technique des em :

omment définir la taille du texte en ems (traduction)

(Désolé, je n'arrête pas de citer mes propres textes. Je dois décidément avoir besoin de nouvelles lectures ).

C'est la page que j'ai utilisée pour passer à la taille en "em".

Mais le problème est que je ne sais pas comment faire en sorte que la taille de la page sot correcte et que tout s'ajuste bien quand on change les paramètres.

Dois-je spécifier la taille de la page en px ?

Quant au fait de ne pas spécifier de taille, évidemment, c'est impossible !
L'accessibilité est un objectif mais ce n'est pas le seul. En plus, je crois qu'un texte uniforme perdrait bcp d'informations pour la plupart des gens et donc serait moins compréhensible, en plus d'être moins agréable à lire.

Ce type de dégradation est relative :
- à la détermination des tailles par l'auteur,
- mais aussi à la configuration utilisateur !

Autrement dit, il serait illusoire de vouloir qu'une mise en page "élastique" (ce qui est déjà un progrès considérable à l'heure actuelle) ne se "casse" pas dans une configuration utilisateur donnée.

Elle se dégrade. Et l'utilisateur y perd en utilisabilité. Selon son handicap (difficulté à scroller) cela peut nuire à sa capacité à accéder aisément au contenu.

Mais là, on est dans le domaine de l'utilisateur, non de l'auteur (avec beaucoup de précautions d'usage, évidemment).

En d'autres termes, identifier accessibilité et expérience de navigation identique n'est-il pas illusoire ?

En d'autres autres termes :
- une pages est ou n'est pas valide au regard des normes (X)HTML CSS,
- mais au mieux elle tend vers un minimum d'inaccessibilité.

Quand je parle de structure je parle des balises des structure H.



Euh la je peux pas etre d'accord.
Je ne te parle pas d'une confoguration utilisateur donnée mais simplement du premier test d'accessibilité qu'une personne fait quand il test sa page et que WAI applique dans son preliminary review, tout comme le test en 800*600 ou encore la compatibilité sur les différents navigateurs.

En effet bcp de gens l'ignore mais avant meme valider les critères 1 pâr 1 toute évaluation de l'accessibilité passe par une preliminary review (http://www.w3.org/WAI/eval/#prelim) et l'augmentatopn de la taille de police fait partie des tests.

Je ne l'ignore pas, je cherche une solution. Et je ne la trouve pas.

Ma réponse était surtout vis a vis de la remarque de laurendenis sur la relativité de ce type de tests

On en revient à mes multiples interventions concernant le full CSS et les soucis qui en découlent.

Je ne connait pas ton code parfaitement donc je vais te faire des suggestions très basiques qui ont peut etre déjà éét appliquées

-> définir une div encadrant l'ensemble avec un width :100%;
-> définir une largeur en % a toutes tes divs pour les obliger à rester dans un cadre général de 100%;


-> revoir ta structure html

<body avec couleur de fond foncé>

<div générale pour le fond a 90% avec 5% de marge des deux cotés>

<div avec le bandeau du haut sur fond clair>
<div du menu avec un width suffisant et un float left;>
<div du corps de page>
<1 élément avec un clear:both;> HR ?
<div du menu de bas de page>
<div ds infos complémentaires>

</div générale>

</body>


Je vois pas pourquoi ca ne marcherait pas, maisla encore il faut tester tout ca