Aller au contenu

Steph. K.

Webmaster Régulier
  • Compteur de contenus

    61
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par Steph. K.

  1. Bonjour tout le monde, Merci Monique d'avoir pris la relève pour l'exemple full css, surtout que je suis sur le départ et absent pour un mois. Cette discussion est très interessante et je ne manquerai pas de revenir. Elle ne prend pas en compte le positionnement css et c'est ca qui sème la zone. Ce qui serait bien ce serait de pouvoir mettre au point 3 ou 4 modele de css spécifiques et qui prennent en compte aussi bien les tableaux que les css, en s'appuyant sur l'extrait que pasé hier ca ne parrait pas sorcier. Bonne continuation à tous.
  2. Mauvais problème, changer problème Le Tao du web Défini ta div la moins large en em et ne fixe pas la taille de la plus large. Fait à l'arrache mais c'est l'idée : <div id="container" style="width:100%"> <div id="gauche" style="width:15em;"> <p>Bla bla</p> </div> <div id="droite" style="float:left"> <p>Bla bla Bla bla Bla bla Bla bla</p> </div> <hr style="clear:both;display:none" /> </div> Tu ne dois pas être loin de ce que tu veux. Si tu vires la div container tu vas avoir un ascenceur horizontal. C'est un faux débat, le w3c autorise aussi les gifs animés et les caractères en taille 6px, ce n'est pas parce que c'est autorisé que c'est une bonne idée. Sinon la solution que vous avez utilisée est sûrement la meilleure.
  3. Et oui, il faut "éduquer" autant les webmasters que les utilisateurs. Aïe t'as les reflexes conditionnés par les tableaux, mets déjà ta div gauche avec width:15em et tu éviteras des problèmes de superposition puisque la taille du block changera en même temps que celle des caractères. C'est sûr que si les développeurs font du positionnement css "à la dreamweaver" ca ne facilite pas la tâche. Pour info Dreamweaver transforme une page en tableaux en une page ou tous les éléments sont en poition:absolute, c'est pratique pour eux mais c'est une très mauvaise solution. Il faut combiner les dimensions en em et celle en % tout comme il faut utiliser les float:left ou right à boin escient et positionner ses blocks en relatif ou en absolu suivant l'effet voulu. Ce n'est pas forcement simple au début de l'apprentissage mais c'est le prix à payer pour obtenir de bons résultats.
  4. Ah mais non c'est pas réglo, si tu ne nous donnes pas toutes les armes comment tu veux que l'on te massacre tout bien comme il faut Tu ne peux pas imaginer le plaisir que j'ai de lire ceci. On est d'accord mais explique comment tu gère le cas de la personne qui préfère grandement les pages avec un fond sombre (mais pas noir) et des textes très clair (je parle evidemment de la couleur, mais pas blanc) ? Je ne vois pas d'autre solution que les feuilles de style alternatives. Je reviens sur le choix des couleurs, pour un utilisateur lambda sans problèmes de vue d'aucune sorte, les trop forts contrastes sont fatigants, c'est même déconseillé pour les personnes victimes de crises d'épilepsie. Par contre certains malvoyants ont besoin de forts contrastes, je suis donc confronté à un problème insoluble... je ne peux pas satisfaire tout le monde quel que soit mon choix. Comme je suis opposé à la mise en place de sites spécialement destinés aux malvoyants ou aux manchots ou aux personnes tétraplégiques ou aux "bien portants", je fais un site qui fonctionne pour tout le monde et dont la version par défaut convienne à la majorité, par contre je m'efforce de ne rien faire qui bloque complètement l'accès à une partie de mes visiteurs. Une fois cela posé j'essaye d'offrir ce me qui semble être le mieux pour aider "les minorités" quelle qu'elles soient et a ne pas les empécher d'utiliser leurs outils spécifiques. C'est loupé ! tout au moins pour certaines personnes. Je te crois sur parole mais je l'ai dit plus haut je ne veux en aucun cas les empécher de le faire, bien au contraire. Je vérifie que mes page fonctionnent sans javascript ou sans souris, je vérifie mes formulaires avec Links ou Braillesurf ce n'est pas pour martyriser les malvoyants Les FDS alternatives sont un plus, pas un remplaçant. Elles permettent d'améliorer le confort de tout le monde, en principe sans gêner personne. Je parlais de bons navigateurs (Mozilla et toute sa famille, Opéra, sûrement Safari...) où cette fonctionnalité est implémentée à la base. Sur Firebird ou Mozilla tu as un petit logo à gauche de la barre d'état et un simple clic fait apparaitre la liste des FDS alternatives. Fais un essai sur openweb (j'ai fait autrement sur acces-pour-tous) et tu verras que c'est simple d'utilisation. L'amélioration des navigateurs rendra peut être un jour les aides techniques inutiles. Pour revenir sur la FDS de ton ami j'aimerai vraiment savoir comment elle est foutue, le plus universel me semble être de linéariser complètement la mise en page. pour les tableaux je mettrais toutes les balises de type block en display:inline (en peufinant pour garder la logique des th) et je devrais rapidement avoir un résultat satisfaisant, pour le positionnement via css il faut annuler le positionnement en relatif et en absolu. Ce n'est pas plus compliqué, je t'invite à essayer le Small Screen Rendering de Daniel Glazman et tu verras qu'il se joue de la mise en page d'origine sans difficulté que ce soit des tableaux ou du positionnement css. Un extrait du code css : /* remove all positioning */ position: static ! important; /* remove all positioning offsets */ top: auto ! important; left: auto ! important; /* and cancel floats */ float: none ! important;
  5. Je me suis mal exprimé, je critique le flash quand il n'apporte rien... c'est tout. Sinon le WAI préconise d'ajouter des images et des vidéos chaque fois que cela apporte un plus à la page, le tout est de le faire correctement pour ne pas léser toutes une partie des visiteurs. Suivant ce que tu veux montrer sur ta page, un graphique est la meilleure solution et il n'y a rien de mieux qu'une image pour que le visiteur comprenne tout de suite de quoi tu parles, le problème apparaît lorsque tu bases ta démonstration uniquement sur des images car cela veut dire que celui qui ne peut pas les voir n'aura pas accès à tes infos. Humour quand tu nous tiens ;-) La Loi de Murphy explique (je simplifie mais tu trouveras toutes les infos sur le net) que chaque fois qu'il y a une faille quelquepart les utilisateurs feront leur possible pour tomber pile poil dessus, qu'ils le veuillent ou non.J'en ai encore eu la démonstration il y a 2 ou 3 jours, pour le validateur d'acces-pour-tous je fais une vérification de l'url transmise avant tout traitement (pour des raisons de sécurité et d'ergonomie) et je pensais avoir trituré cette fonction dans tous les sens et un utilisateur a mis moins de 3 minutes pour tomber juste sur le cas auquel je n'aurai jamais pensé (et il n'a pas fait exprès). je reviens sur l'ergonomie parce que c'est quelque chose de fondamentale pour assurer une bonne accessiblité pour tout le monde. C'est un point délicat à juger car on a chacun nos habitudes, ce qui parrait logique à l'un parraitra absurde à un autre sans que l'un ou l'autre ai tort c'est pourquoi il est bien en termes d'accessibilité de multiplier les formes d'accès à une meme information. C'est quelquechose que l'on voit encore trop peu sur le net et c'est dommage.
  6. hs Je trouve le fonctionnement de ce forum (le script pas les participants) déroutant, il n'y a pas moyen de répondre à un message particulier ? Je vais donc essayer de quoter correctement pour que cela soit le plus clair possible sans être obligé de faire 4 ou 5 messages. /hs Okay pour la trouvaille de l'image mais quid des utilisateurs de navigateurs graphique, j'ai du former des gens à l'internet et à la gestion d'un site conséquent avec un gros back office et j'ai passer pas mal de temps à faire du "pas à pas" au téléphone... ce type de lien n'est à ce titre pas pratique Loi de Murphy oblige le débutant cliquera toujours sur le mauvais lien. Pour illustrer différemment mes propos je me fais très régulièrement avoir sur le site openweb... le titre de l'article est en bleu et souligné et je clique naturellement dessus pour lire l'article complet alors que le lien est un peu plus bas (habitude quand tu nous tiens) et pourtant j'ai quelques années d'internet derrière moi. Pourquoi ne pas mettre le lien directement sur le titre de la news ? D'un côté tu réfutes toutes les erreurs sauf une et là vous travaillez à rendre le site plus accessible. C'est un peu contradictoire. Pourquoi utiliser 12 tableaux imbriqués (avec leur détracteurs) alors qu'il me semble enfantin de monter la page avec un seul tableau de 3 lignes et 2 colonnes et de confier le reste de la mise en page aux css. Est-ce que cette approche avec un seul tableau donnerai de bons résultats avec la FDS spécifique ? Je ne suis pas d'accord avec cette affirmation, faut-il être malade pour être un bon médecin ? Un éditeur doit-il être écrivain ? Tout ca pour dire clairement que je soutiens complètement l'initiative d'accessiweb envers les étudiants. Le problème est ailleurs, il faut convaincre les webmasters et les décideurs de faire des sites internet accessibles et c'est pour cela que les sites traitant d'accessibilité doivent être exemplaires, clairs, beaux... La réaction de Pixame illustre bien ma pensée. Je ne comprend pas du tout ta réaction, qui t'empêche de faire un site conforme et d'utiliser un minimum de tableaux pour ta mise en page ? De toutes manières un site conforme avec des tableaux est mieux qu'un site non conforme (par exemple sans attribut alt, une myriade de trucs qui clignotent, du flash inutile...) avec ou sans tableaux. C'est contradictoire, un avantage indéniable des standards et des navigateurs orientés utilisateurs est de pouvoir offrir des FDS alternatives accessibles en un seul clic. Si j'adore les couleurs pastel libre à moi de faire mon site ainsi. Je n'ai qu'à prévoir 3 FDS alternatives une avec un fond clair et un fort contraste, une autre avec un fond sombre et des textes en blanc et une troisième pour l'impression car de nombreuses personnes préfèrent lire un document papier. Tout le monde est content avec un code source commun... que du bonheur.
  7. Est-ce une erreur d'interprétation de ma part ou faut-il traduire formelle par stricte ? Nous sommes d'accord sur le fond mais mon interprétation est différente. J'ai testé ma page avec Braillesurf, Linx et Links et j'obtiens un résultat conforme à mes attentes, par contre si effectivement les malvoyants utilisent d'autres outils/solutions je serai ravi d'en apprendre plus. Je vais convier les membres d'Openweb à participer aux débats parce que je pense que nous avons tous à y gagner.
  8. Pour les saisies d'écran, je crois que le débat est faussé. csszengarden est un exercice de style destiné à montrer la puissance des css point barre. Personnellement je considère que l'avenir repose sur les standards car justement ceux-ci doivent permettre de s'affranchir au maximum des outils spécifiques et permettre aux malvoyants de visiter un site avec un rendu le plus proche de celui d'origine. Je suppose que la FDS utilisée par ton ami a été mise au point pour lui permettre de visiter la majorité des sites actuels (IE non conformes et avec des tableaux. J'aimerai, si c'était possible, qu'il visite acces-pour-tous et qu'il utilise les fonctionnalité que je propose (inverson des couleurs, version linéaire permettant d'agrandir énormement les caractères sans chevauchement...) et qu'il me dise ce qu'il en pense. Je suis tout à fait prêt à modifier mon point de vue.
  9. 3.2 Créez des documents qui soient validés par la grammaire formelle publiée. et 11.1 Utilisez les technologies du W3C quand elles sont disponibles et appropriées pour une tâche, et utilisez les dernières versions dès quelles sont supportées.
  10. Est-ce que ce forum est modéré ? car j'ai fait une réponse hier au soir et je ne la trouve pas... Est-ce une erreur de ma part ou y-a t'il une autre explication ? Pour les liens visités je confirme simplement ce que Monique a avancé, c'est utile à tout le monde. Pour ce qui est du codage en HTML 4 transitional, le WAI est très clair et cela me semble primodial. En effet j'espère que de nombreux outils d'aide aux personnes handicapées vont voir le jour (mesdames et messieurs les développeurs du libre, ceci est un appel aux bonnes volontés) et les développeurs n'auront pas d'autre choix que de s'appuyer sur les standards. C'est ce que je fais dans le cadre du développement d'une barre d'outils XUL destinée à faciliter la consultation des sites internet par les personnes mal-voyantes et je peux vous assurer qu'il est beaucoup plus simple d'analyser une page conforme plutôt qu'une codée "avec les pieds". De plus une page respectant la séparation contenu / présentation est beaucoup plus simple à maintenir et il est également plus simple de fournir des FDS alternatives (impression, fort contraste, couleurs inversées...) afin de répondre aux éventuelles attentes des visiteurs. Pour les formulaires vides je suis d'accord avec Yobiwan, il en est de même AMHA pour ce qui est de l'imbrication des balises h1 à h6, c'est une erreur au niveau sémantique mais cela ne pose pas de problème au niveau accessibilité. Pour revenir sur le full css, acces-pour-tous est valide XHTML 1.0 strict, les css sont valides et à ma connaissance le résultat est identique sur tous les navigateurs graphiques quel que soit l'OS.
  11. Bonjour tout le monde, Je suis l'auteur du site acces-pour-tous.net et ne suis pas complètement d'accord avec certains points avancés lors de cette discussion. Il est possible de faire du full css et d'agrandir les textes sans que la page ne soit trop dégradée. Mieux qu'une longue argumentation je vous invite à visiter mon site et d'agrandir les textes, le menu (largeur fixée en em) pousse le corps de la page mais sans barre de défilement horizontale et sans géner outre mesure la lecture de la page. Celle-ci est valide XHTML 1.0 strict ainsi que la feuille de style. Les tableaux tout en n'étant pas formellement interdits sont toutefois déconseillés. Je reconnais que ce point peut entraîner de longues discussions étant donné que les textes de référence ne sont toujours d'une clarté suffisante. et Les 2 extraits précédents viennent de la page suivante : check liste des points de controle Par ailleurs je relève quelques autres points tels que la non identification des liens visités, la présence d'une barre de défilement horizontale en 640 par 480, un codage désuet et transitional, qui plus est avec de nombreuses erreurs Validateur html, des balises dépréciées qui seraient avantageusement remplacées par les équivalents en css. Loin de moi l'idée de polémiquer gratuitement mais je pense aussi que les sites traitant d'accessibilité se doivent d'être le plus proche possible de la perfection, c'est pourquoi je reste disponible (jusqu'au 5 février 16h après je parts bosser loin d'internet) afin de développer les points abordés.
×
×
  • Créer...