yobiwan
-
Compteur de contenus
77 -
Inscrit(e) le
-
Dernière visite
Messages postés par 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
-
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
-
Je ne comprends pas.
Quand je parle de structure je parle des balises des structure H.
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.
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.
-
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
-
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.
-
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
-
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 %
-
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 '
-
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.
-
Pourrais tu nous envoyer l'url de validation de ta page stp ?
avec le rapport c plus facile de voir les problèmes
merci
-
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.
-
Bienvenue montecristo.
J'utilise simplement le navigateur Lynx qui fonctionne en mode texte. Si je peux naviguer avec Lynx, alors tous les lecteurs d'écran pourront en faire autant.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.
-
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.
-
Je propose donc un article de fond sur le non-emploi des frames ou du JS par les professionnels et pourquoi. Avec des arguments d'accessibilité mais pas seulement. J'avais aussi lancé l'idée d'une partie interview comme un axe important d'OpenWeb dans la vision que j'en avais. 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.
-
WAI-TIES donnera une journée complète de formation sur l'évaluation de l'accessibilité des sites Web le 6 juillet à Paris, France. Ces travaux pratiques, expliqués en anglais, sont à l'intention des développeurs Web expérimentés, et donneront un aperçu de la procédure d'évaluation ainsi que des informations détaillées sur l'évaluation de la conformité aux
recommandations sur les Contenus Web "Web Content Accessibility Guidelines 1.0". Le nombre de participants est limité et une pré-inscription est nécessaire.
-
yobiwan s'est battu seul contre tous
J'ai un petit coté calimero je sais ;o)
Je te resumerais donc ce que j'avais avancé à l'époque et que je continue de pense meme si j'espere pouvoir me tromper un jour.
WAI n'interdit pas (je me répète non ?
) de faire des tableaux pour la mise en forme à partir du moment ou leur contenus est linearisable, totu en préconisant de faire des CSS pour la mise en forme lorsue c'est possible.Aujourd'hui comme le dit bien 20cent
"En pratique, les propriétés CSS sont actuellement, tu le sais, très mal implémentés dans certains navigateurs et c'est pourquoi il est encore toléré d'utiliser quelques tableaux pour la présentation globale."En plus du fait que les solutions proposées ne répondent pas toujours aux problèmes d'accessibilité sous jacents.
Les solutions mixtes sont pour moi la meilleure solution a partir du moment ou l'on évite les tableaux imbriqués et qu'on utilise les CSS au max des possibilités/limites qu'elles nous fournissent.
-
J'avoue bien aimer aussi le coup du sensei ;o)
Pour ce qui est de regarder plus en détail, je vais essayer de prendre du temps car ca n'est pas si simple que ca sur une problématique large.
En tout cas, pour le londesc j'avoue etre assez dubitatif. A la fois tu n'as rien de faux coté codage (tu donnes bien l'accès a une description de l'image par ton ancre) et d'un autre coté je n'arrive pas du tout à voir l'interet d'une telle démarche.. Ca me rappel des developpeurs d'IBM madrid que nous avions formé il 'y deux ans qui voulait absolument implémenter toutes les balises d'accessibilité pour ne pas risquer d'avoir des warnings sous bobby.
Dans ton cas précis la description longue de l'image est présente et ne nécéssite pas l'atribut longdesc. D'autant que cet attribut est super mal géré par les naviagteurs.
WAI demande une description longue des images quand c'est nécéssaire, elle n'impose pas le moyen de le faire. Cela peut etre via un lien sur l'image vers cette descrition longue dans un fichier externe, une légende ...
Je pense que tu en as presque trop fait
-
En effet, ignorer les couleurs de la page doit mettre un fond blanc et non pas supprimer carrément le fond.
Le blanc est une couleur non ?
Qui plus est (corrigez-moi si je me trompe), le travail de Fabrice sur ce menu dans le cadre d'OpenWeb, ce n'est pas de fournir une solution toute cuite dans le bec à tout le mondeMon seul souci reste alors le titre de l'article : "Faire un menu dynamique ouvert et accessible "
Nous venons de la voir, il ne l'est pas.
Pourquoi ne pas passer à autre chose et revoir la manière dont nous scénarisons la navigation sur nos sites Web ?Que je suis heureux d'entendre cette phrase --> oublions ce type de menus qui ne sont pas accessible : voilà peut etre la vraie solution. Tambouriner partout que ce type de menus n'est pas accessible et réussir à les faire totalement disparaitre plutot que tenter de trouver des solutions qui sont a priori vouées à l'echec et qui peuvent faire penser que ce type de menus peut devenir accessible.
-
L'Université Pierre et Marie Curie (Paris 6) et BrailleNet accueilleront la 9ème Conférence Internationale " Computers Helping People with Special Needs" les 7-9 Juillet 2004 - Pré-Conférences les 5-6 Juillet 2004.
Cettte conférence sera un des événements majeurs en Europe concernant les nouvelles technologies pour les personnes handicapées. Elle devrait réunir 400 participants du monde entier.
Plus d'info : www.icchp.org
-
Ce menu a exactement le même problème que celui d'Openweb si on supprime la couleur
je ne vois donc pas comment il peut etre triple A
-
Je préfère voir fleurir des menus un minimum accessibles plutôt que ceux qui ne le sont pas du tout,
C'est en effet une approche qui se justifie, même si du point de vue de BrailleNet ca n'est bien sur pas suffisant de faire du "minimum" accessible.
Par contre si je peux emmetre une idée d'article, il serait peut etre interessant de rédiger un article sur les problèmes d'accessibilités que posent ce types de menus.
Tout en ne critiquant pas du tout ton article, il a juste une conséquence, les gens pensent faire un menu accessible si ils suivent tes conseils, ce qui n'est donc pas le cas selon tes propres dire.
La nuance serait donc à mon avis de rigueur pour bien montrer aux gens que ce types de menus posent de lourds problèmes.
-
Ah... que ne l'as-tu pas dit plus tôt
Euhhhhhhh, dans mes souvenirs l'auteur via tristan je l'espère est au courant depuis quasiment la redaction de l'article
(a priori, rien de bien difficile)Je veux bien voir ce que ca donnera alors, même dans les listes techniques de WAI personnes n'a réussi a rendre ce type de menus 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.
-
Je ne suis malheureusement pas certain que le menu fournit pas Open Web soit parfaitement accessible meme si il donne une solution plutot intéréssante.
En effet un des critères d'accessibilité est :
"Vérifier que l'information soit accessible lorsque les couleurs sont désactivées dans la page".
Sur ce menu, faites tous le test suivant :
dans les options accessibilité, désactivez l'option "ignorer les couleurs spécifiées dans les pages web" et vous verrez en quoi ce menu n'est pas parfaitement accessible malheureusement lorsque l'on désactive les couleurs dans la page.
Le chevauchement de l'information rend celle ci illisible.
Trophées AccessiWeb, Concours de création de site Accessible
dans Accessibilité et Ergonomie Web
Posté
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