finidori Posté 9 Août 2004 Posté 9 Août 2004 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
LaurentDenis Posté 9 Août 2004 Posté 9 Août 2004 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 ? 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 : .hidden{position:absolute; left:0px; top:-500px; width:1px; height:1px; overflow:hidden;} (Pour les détails, voir Lecteurs d'écran : cachez ce sein que je ne saurais voir
LaurentDenis Posté 9 Août 2004 Posté 9 Août 2004 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. 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.
LaurentDenis Posté 9 Août 2004 Posté 9 Août 2004 Pour les images réactives, j'ai utilisé les liens côté serveur. Est-ce que cela suffit ? Que veux-tu dire ? Sur quelle page du site ?
finidori Posté 9 Août 2004 Auteur Posté 9 Août 2004 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.
LaurentDenis Posté 9 Août 2004 Posté 9 Août 2004 Deux choses encore : - l'accesskey du moteur de recherche n'est pas implémentée dans le formulaire : <label class="cache" for="recherche" accesskey="4">Texte recherché</label> - 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
finidori Posté 9 Août 2004 Auteur Posté 9 Août 2004 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 !
LaurentDenis Posté 9 Août 2004 Posté 9 Août 2004 (modifié) 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. 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) : <img alt="Plan illustré de la commune de Figari" src="http://www.villesurinternet.com/figari/img/plan/plan_de_Figari.jpg"" usemap="#Map" /> <map name="Map" id="Map"> <area alt="Eglise de San'Andrea et Patrimoine" shape="rect" coords="282,222,367,266" href="patrimoine.htm" title="Eglise de San'Andrea et Patrimoine" />etc... 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] Modifié 10 Août 2004 par LaurentDenis
finidori Posté 9 Août 2004 Auteur Posté 9 Août 2004 De la sorte, tu es certain de ne plus avoir le moindre problème d'accessibilité Chouette !
Monique Posté 9 Août 2004 Posté 9 Août 2004 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 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
finidori Posté 9 Août 2004 Auteur Posté 9 Août 2004 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 Merci. Pour donner un ordre d'idée, sur 30 pages, j'ai enlevé 150 tableaux. 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 OK. Quel validateur ? J'ai utilisé Bobby, Cynthia et Acces pour tous. - 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 Je n'utilise pas ces balises. Je vais vérifier qu'elles ne restent pas de l'ancienne version.
Monique Posté 9 Août 2004 Posté 9 Août 2004 OK.Quel validateur ? J'ai utilisé Bobby, Cynthia et Acces pour tous. 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.
yobiwan Posté 10 Août 2004 Posté 10 Août 2004 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
LaurentDenis Posté 10 Août 2004 Posté 10 Août 2004 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 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... 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 ...) 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".
yobiwan Posté 10 Août 2004 Posté 10 Août 2004 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
finidori Posté 10 Août 2004 Auteur Posté 10 Août 2004 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 Si je suis venu proposer mon site, c'est bien pour apprendre et progresser. - 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. 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 - 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. Je n'ai compris. - 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. 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. - 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 ...) 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 ? ;-) - Attention au changements de langue non signalés (les icone de conformance par exemple) OK. Sur le plan technique (respect des règles) comme humain (jugement perso), je suis preneur de toute remarque. Merci pour vos interventions. Gilbert
finidori Posté 10 Août 2004 Auteur Posté 10 Août 2004 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. 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 ?
finidori Posté 10 Août 2004 Auteur Posté 10 Août 2004 - 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) Je ne comprends pas. idem pour le menu du bas de page 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. ou au minimum pour l'actualité qui est un bloc visuel de structure mais pas dans le code. Le code pour l'actualité est <dl class="breves"> <dt>Actualité</dt> <dd> Nouveau site internet</dd> <dd> Journal en préparation </dd> </dl> C'est bien un blonc, non ?
LaurentDenis Posté 10 Août 2004 Posté 10 Août 2004 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. Voir http://openweb.eu.org/articles/initiation_display/ pour les propriétés CSS à utiliser à cet effet et un exemple de base.
finidori Posté 10 Août 2004 Auteur Posté 10 Août 2004 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...
LaurentDenis Posté 10 Août 2004 Posté 10 Août 2004 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 ).
finidori Posté 10 Août 2004 Auteur Posté 10 Août 2004 omment définir la taille du texte en ems (traduction) 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.
LaurentDenis Posté 10 Août 2004 Posté 10 Août 2004 (modifié) 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. 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é. Modifié 10 Août 2004 par LaurentDenis
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant