Aller au contenu

yobiwan

Webmaster Régulier
 Afficher le profil  Parcourir son contenu

  • Compteur de contenus

    77

  • Inscrit(e) le

  • Dernière visite

Réputation sur la communauté

0 Neutre

Information du profil

  • Société
    Braillenet
  1. yobiwan
    Pour mes dernieres heures dans l'accessibilité, je vais te faire la meme reponse que celle déjà faites dans le cadre du concours en ne faisant que citer le règlement du concours. je comprends ta décéption et en même temps nous avons fortement encouragé ton site et un règlement déposé chez huissier est ce qu'il est. Nous aurions aimer te récompenser (et je t'ai meme aidé avant la fin du concours quand j'ai relevé des fautes rapides reconnais le) mais les règles étaient très claires : VI. Critères pour un site Web. Pour pouvoir concourir, un site Web doit respecter les points suivants: être accessible (voire définition et règles de l'accessibilité des sites Web rappelées dans le site Web du concours : http://www.accessiweb.org), être graphiquement original, être créatif, posséder une interface Web, comporter des éléments imposés: une page d'accueil nommée "index", un plan du site, une aide en ligne et un formulaire, comporter un maximum de 10 pages HTML. comporter un minimum de 3 pages. X. Fonctionnement du jury. Le jury se réunira à huit clos 5 jours avant la date de remise des prix. Le palmarès sera tenu secret jusqu'à la remise des prix. Il sera diffusé le lendemain sur le site Internet du concours. Pré-sélection: les membres du jury auront accès 5 jours après la fin de la période de remise des sites Web (cf. article 5), grâce à un code confidentiel, à l'ensemble de la base des sites inscrits et disposeront d'un mois pour les expertiser. Un rapport pré-formaté d'audit sera généré pour chaque site analysé et une note lui sera attribuée. Tous les rapports seront envoyés par courrier électronique au président du jury au plus tard 1 jour avant la réunion de l'ensemble du jury. Tous les sites aillant atteint au minimum le niveau Bronze du Label Accessiweb et qui respecteront les critères précédemment cités (Article 6), seront présélectionnés. Les choses étaient donc très claires et nous avons été les premiers décus de ne pouvoir distribuer des lots que nous avions longtemps négocié auprès des partenaires. Cette deception ne doit pas te décourager mais au contraire te motiver à mieux faire. Mais cela reste de la deception rien d'autre. bon continuation
  2. yobiwan
    Bonjour a tous et surtout à tous ceux avec qui j'ai put echanger si souvent sur ce passionnant sujet qu'est l'accessibilité. Malheureusement pour des raisons connus de certains je susi contraint de quitter BrailleNet. J'ai heureusement reussi à trouver rapidement autre chose mais ce ne sera pas du tout sur le sujet de l'access donc ceci est certainement l'un de mes derniers messages sur le hub faute de temps par la suite. je commence une mission lundi. Je tenais tous à vous remercier des echanges vraiment très enrichissants que nous avons put avoir et ma derniere phrase et mon dernier conseil sera celle que je repete sans arret. L'accessibilité c'est avant tout mettre l'utilisateur en priorité dans tout devoppement. Cela passe bien sur par des standards mais pas toujours et n'oublier pas qu'un standard n'est pas toujours parfait dans notre domaine et que c'est toujours l'utilisateur qui pourra vous faire ressentir le mieux si votre site est accessible ou non. Je vous dis peut etre à bientot et encore merci yoan
  3. yobiwan
    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
  4. yobiwan
    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.
  5. yobiwan
    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
  6. yobiwan
    Je verrais bien des commentaires explicites au liens en passant moi par exemple si je regarde rapidement la page : j'ai un title de lien au dessus d'un cliquez ici qui est :"Voir la fiche détaillée" --> voir la fiche détaillée de quoi ? c pas super explicite hors contexte tout ca idem pour 508 css xhtml ... pour les gens qui connaissent c bien mais pour les autres. quelque chose du genre "page valide XHTML" me paratitrait plus explicite. J'avoue etre très perturbé par la structure du site dans le code par rapport au visuel.* Visuellement j'ai trois colonnes donc trois blocs d'infos et dans le code je n'en ai que deux, les deux menus ne faisant plus qu'un. Le choix visuel est de différentier trois zones donc dans le code cela doit se voir, sinon il faudrait faire deux zones une pour le menu et une pour les contenus. Etant daltonnien moi meme je confirme que les contrastes dans la page sont beaucoup trop faibles. Les textes de input de validation sont pour moi ilisibles (couleurs et typos) Pour les fieldset leur fontion est de regrouper des blocs d'infos ddonc parfaitement valide dans la page. Les textes explicatifs dans les champs de saisis sont aujourd'hui déconseillé meme si nécéssaire pour les WCAG 1.0 --> pas le cas dans les 2.0 et le retour utilisateur est assez négatif la dessus Voila mes qq remarques sasn poussez plus que ca.
  7. yobiwan
    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
  8. yobiwan
    Pour des chiffres tupeux aller sur le site suivant : http://www.thecounter.com/stats/ qui en donne a profusion. Pour infos l'an passé cela tournait autour de 11% /13 % cette année ca tombe a 7 %
  9. yobiwan
    délire l'inteface à traduit les caractères : dc je recommence sans les points virgules à la fin qu'il faudra ajouter % --> % --> Pour els apostrophes prend ton source et fait un rechercher remplacer, tu copies colle le caractère non valide et tu le remplace dans un éditeur de texte (bloc note) par '
  10. yobiwan
    Là l'erreur est très simple En fait avec un charset iso-8859-1, les caractères microsoft ne sont pas reconnus. Si par exemple, tu mets une simple quote sous word, il te créer par un caractère valide mais un caractère "windows" qui au niveau caractères ascii coorespond pas à ton charset. Il faut alors utiliser les caractères défini par HTML, (é pour é) à la place de tes %. pour le % ca doit etre qqch comme % poue le tu verras comme par miracle toutes tes fautes de HTML vont disparître.
  11. yobiwan
    Pourrais tu nous envoyer l'url de validation de ta page stp ? avec le rapport c plus facile de voir les problèmes merci
  12. yobiwan
    Ca marche que sous Mozilla non ? sous IE 6 et opera 7 a pas l'air d'être efficace sur mon PC. Je sais c'est au navigateurs à s'adapter mais bon ... si encore 95 % des utilisateurs trouvent les données en tableau alors que le developpeur veut mettre du linéaire ca reste dommage.
  13. yobiwan
    Bienvenue montecristo. Vrai et faux à mon avis, je te donne l'exemple le plus souvent cité, l'interprettion des feuilles de styles par les lecteurs d'écran. En effet, il te suffit de cacher qqch par le style pour qu'un lecteur d'écran ne le lise pas alors que Lynx le fera facilement. Je ne ferais pas la demonstration inverse pour montrer a quel point lynx est limitatif dans le code (pas d'accronym par exemple, pas de titre H ...). De plus, je me répète je sais mais bon on commence à avoir l'habitude dans la hub , l'accessibilité ne se résume pas aux seules personnes aveugles loin de là. Le séminaire accessiweb l'a montré de manière éfficace je pense. Je vous invite tous à réfléchir aux personnes handicapées moteurs qui ne peuvent facilement déplacer la souris et pour qui les menus en layer sont bloquants, les personnes sourdes qui ne peuvent telecharger des fichiers sons ou entrer leur telephone dans des champs de formulaires car ils ne peuevent entendre le téléphone, les personnes malvoyantes pour qui les images en textes ne peuvent être zoomées correctement, les personnes agées qui sont en 800*600 taille de caractère "la plus grande", juste pour mieux voir .... Soyez donc vigilants et nous vous limitez à dire : si je teste sous lynx je suis accessible et si je teste avec the Wave pareil, l'accessibilité est bien plus complexe et ne se limite pas à une somme d'outils mais bien à l'experience des utilisateurs. Malgré la meilleure connaissance du monde des normes, il est essentiel de toujours faire valider son site par les utilisateurs, vous verrez que vous aurez à tous les coups des surprises de taille.
  14. yobiwan
    La loi est basée sur le referentiel ADAE qui reprend les recommandation du WAI sur la base de AccessiWeb. Il faut donc simplement ésperer (moi je n'en doute pas une seconde) que les recommandations internationales sur l'accessibilité soient valables.
  15. yobiwan
    Complètement pour et je serais heureux avec mes collégues de participer à ce genre d'initiatives comme pour l'article sur les accesskeys.
×
×
  • Créer...