Ganf

IE est loin d'être une référence. Si tu codes en fonction de lui ce n'est pas étonnant que tu ai des problèmes de compatibilité. <area shape='circle' coords='470,106,5' href='#' alt='paris Station: 01 - paris Valeur: ' > Donc on est d'accord : tu remplaces le "alt" par un "title" et logiquement ça devrait aller mieux si ton image principale n'a elle même pas de "title". Après, au lieu de mettre un href="#" qui n'est pas du tout prévu pour ça, met donc un "nohref". Logiquement ça devrait marcher. Si ce n'est pas le cas il faudra sortir un javascript pour créer ta bulle d'aide. Donc : <area shape='circle' coords='470,106,5' nohref title='paris Station: 01 - paris Valeur: ' >

Pourquoi devrait-il ? le alt c'est un contenu "alternartif". Mozilla arrive à afficher les images, il n'a aucune raison d'afficher le texte alternatif (que ce soit en bulle d'aide ou ailleurs) quand c'est le cas. Visiblement il manque beaucoup de htmlentities() ou htmlspecialchars() mais ça n'est pas trop ce qui nous préoccupe. J'allais te dire qu'il fallait mettre ton info en title="" plutot qu'en alt="" mais visiblement tu le fais aussi. Est-ce que tu pourrais nous donner le code HTML résultat plutot que le PHP (qui ne nous sert pas à grand chose ici) ? à priori faire simplement un "voir source" sur ta page dans le navigateur et nous copier ce que ça donne, sinon nous donner l'url de la page de test.

> Ya a t il moyen de contourner ce probleme? - javascript pour adapter en runtime - ou tailles fixes et images adaptées pour ne pas avoir de surprises - ou min-width et min-height pour que le bloc soit au minimum de la taille de l'image > Egalement CSS permet il de declencher des sons avec a:over? - Via les behavior / htc / bindings ça devrait être faisable sous MSIE et Mozilla (mais pas standard) - Sinon tu fais un javascript qui va se servir des événements DOM pour traquer tout ça CSS est fait pour la présentation, pas vraiment pour l'interaction (le :hover étant entre les deux), à priori du javascript via les DOM events me parait plus adapté même si c'était faisable.

MSIE sait télécharger les polices via les déclarations CSS mais c'est je crois le seul. La seule solution (qui en plus est une bonne idée), c'est de donner des alternatives dans tes déclarations (Helvetica, OU bitstream, OU ....) puis de spécifier la famille générale à la fin au cas où (serif, sans ou mono). Si quelqu'un n'a pas ta police ça en utilisera une autre. Tant que le texte est lisible correctement, est-ce grave si certains ne voient pas le texte avec la même police que toi ?

J'ai eu l'occasion d'avoir un contact avec une aveugle utilisant intensément Jaws ce WE. Elle m'a donné son accord pour lui envoyer quelques questions ou tests de temps en temps pour qu'on sache ce qui passe bien ou pas. Ce que je vous propose c'est de faire quelques pages et je lui envoie pour avoir ses réactions : - une comme tu as proposé au départ : labels en valeur par défaut - une label en valeur par défaut et effacement automatique - une label en valeur par défaut et effacement auto + les labels 'normaux' en texte à coté - une label en valeur par défaut + les labels 'normaux' en texte à coté - les labels 'normaux' en texte à coté, pas de valeur par défaut Si vous me donnez les URL je jette un coup d'oeil, envoie et poste ici la réponse.

désolé, j'ai lu trop vite le résultat du validateur, c'est simplement que l'attribut était mal écrit, mais il est bien autorisé, tu as raison. Tu as je pense raison, c'était une erreur de ma part. Il n'est pas "vide". Mais si je me met à la place d'un outil automatisé. Je lis le contenu de <label> pour le champ, que puis-je retourner à l'utilisateur comme descrition du champ ? à priori je n'ai aucune information, donc je suis dans l'incapacité de renseigner l'utilisateur. Ton label n'est pas vide au sens strict, mais il ne sert à rien, qu'il soit là ou pas ne changera rien pour personne. C'est indépendant. Tes champs n'ont pas de description qui peut être lue automatiquement par un outil informatisée. Maintenant je dis que c'est indépendant, mais si tu corriges le problème et met des labels séparés, il n'y a plus lieu de les mettre par défaut dans tes champs. Il y a tout de même une relation. Attention aussi au "doit". Il s'agit de lignes de conduite. Si les comportements des navigateurs changent ou sont différents de ce qui était prévu, c'est à toi d'adapter. Il ne s'agit pas de règles gravées dans le marbre mais de fils directeurs. D'ailleurs la "règle" commence explicitement par "tant que ...". Si cette première condition (le fait que les navigateurs aient des problèmes avec des champs vides) n'est plus vérifiée, la règle n'en est plus une. C'est pareil, je me contente d'utiliser le résultat. Je prend tapage et j'essaye de naviguer au clavier pour remplir le formulaire. Le fait est que ça ne marche pas. Je n'ai pas exploré pourquoi donc je ne m'avancerai pas trop. Je pense que tu n'as du mettre un tabindex que sur les groupes, donc on navigue entre les fieldset sans pouvoir atteindre les champs à l'intérieur avant pas mal de tabulations. En pratique je pense que ça serait probablement mieux sans tabindex dans ton cas. Et bien .....il s'agit de grouper certaines valeurs ensemble pour faciliter le repérage à l'intérieur du <select>. Un peu comme si pour lister les pays tu les regrouppe par continent. Ce que tu as mis n'est pas un groupe de valeurs, mais un descriptif du champ. (nb: tout ce que je dis là, ainsi tout ce que je dis en général, n'est que mon interprétation, je ne pense pas détenir "la" vérité) Maintenant là aussi peu importe : le fait est que en pratique tu as rendu plus difficile ma compréhension du formulaire au lieu de l'améliorer, cette simple constatation implique que ce n'est pas à faire, quoi qu'il en soit. À mon avis, pour suivre une vieille recommandation d'accessibilité qui veut qu'on remplisse les champs de formulaire, tu es en train de dégrader tout le reste de ton formulaire : absence de label, effacement automatique des champs, valeur par défaut non pertinente (ce que tu as dans "nom" n'est pas un nom, ce que tu as dans "intitulé de la formation" n'est pas un intitulé de formation ....), etc. Il faut savoir repasser tout par la pratique et faire des compromis. Je ne connais pas assez les navigateurs spécifiques (oraux, brailles, etc.) pour affirmer que laisser vides les champs ne gêne personne, mais ce que je pense c'est que l'équilibre que tu as là n'est pas le bon. Si je devais faire un choix entre ta solution et une solution "classique" (champs vides par défaut et labels mis explicitement en externe) je considérerai la classique comme plus accessible, et personnellement préférerai de loin l'avoir en face de moi. Maintenant, encore une fois, ce ne sont que mes interprétations. Peut être faudrait-il demander aux concernés en quoi des champs vides gênent, dans quelles mesures et si c'est toujours d'actualité. Déjà on avancerait pour trouver un compromis.

Un peu trop même parce que tu renseignes une access key pour <legend> alors que c'est interdit, tu références aussi des cibles inexistantes dans tes <label>. label absent pour l'utilisation par le navigateur Ceci dit pour la plupart des <label> ils sont inutiles : <label for="mail"> <input type="text" id="mail" name="mail" tabindex="1" value="Votre e-mail" onfocus="this.value=''" /> </label> Si tu ne met aucun texte dedans, avoir spécifié la balise ne sert pas des masses (enfin c'est mon avis). C'est un peu comme un <h1> vide ... Je n'attend pas que le navigateur utilise la valeur par défaut comme valeur pour le label, parce qu'il peut normalement y avoir une valeur par défaut ET un label, et les deux sont bien distincts. Le navigateur n'a donc aucun moyen d'associer un champ à une descrition, tu te bases sur la compréhension implicite du lecteur (ce qui peut être une mauvaise idée suivant son mode d'accès ou si le doc est interprété avant d'être rendu) effacement de valeur utilisateur Oui, là je te conseille d'utiliser ce que quelqu'un a mis plus haut : un code pour que ça ne vide que s'il s'agit de la valeur par défaut. En pratique : - je rempli l'adresse - je rempli le nom (qui est au dessus) - je souhaite naviguer vers la suite à coup de TAB - quand je passe au dessus de l'adresse ça déclenche le focus et la vide Si tu tiens à utiliser le label en tant que valeur par défaut il te faut mettre au moins une structure de contrôle pour ne pas vider un champ qui a déjà été rempli manuellement. > je ne vois vraiment pas en quoi, cela déroge (comprendre 'pose problème') à > l'accessibilité... Oubli des description Test bête : je rempli nom, prénom, adresse .... - mon navigateur devient dans l'incapacité de me dire à quoi sert quel champ (et *pan* pour ceux qui n'ont pas la mémoire longue ou ceux qui naviguent sans vue globale por se repérer : par exemple les navigateurs oraux - hum .. merde, je n'ai pas fait une bêtise ? c'etait nom+prenom ou prenom+nom qu'on me demandait ? je suis dans l'incapacité de répondre Vérification par l'utilisateur Autre test : - je rempli tout - je veux vérifier ce que j'ai mis .... impossible, je ne sais plus ce qu'on me demande (c'était intulé du diplome ? description ? école ? année ? optgroup Autre point à prendre en compte : les <select> où tu as utilisé le <optgroup> à la place du label. Pour le diplome, mon navigateur positionne automatiquement à "oui" sur le coté. Je ne joue pas l'idiot mais je n'ai pas été capable de comprendre à quoi ça servait, et je suis sérieux. J'ai compris ensuite en regardant le source de la page. Ce n'est clairement pas pratique, tu détournes l'utilisation d'un élément pour autre chose que son sens original. Un peu comme les tableaux, sauf que là ce n'est ni l'usage commun ni pratique pour l'utilisateur. Auto-completion des navigateurs Tu met en échec les champs qui se remplissent automatiquement dans les navigateurs modernes : - soit le navigateur passe par dessus les valeurs par défaut et non seulement l'utilisateur n'a plus accès aux labels (ce qui peut se révéler gênant si le navigateur se plante en resservant des mauvaises valeurs) mais en plus tu vas vider la valeur auto-complétée quand l'utilisateur va passer dessus - soit le navigateur laisse la priorité aux valeurs par défaut et tu vient d'annuler une facilité/fonctionnalité utilisateur (ce qui n'est jamais une bonne idée) Traitement des erreurs Que fais tu en cas d'erreur dans le formulaire ? logiquement on refourni les valeurs fournies en valeurs par défaut. - si tu le fais tu casses la possibilité de savoir à quoi servait le champ, donc de corriger l'erreur (si il y a erreur c'est potentiellement qu'il s'est planté sur le contenu à mettre) - si tu ne le fais pas tu imposes de tout retapper en obligeant l'utilisateur à tout repenser ce qu'il avait entré - si tu ne le fais pas mais que tu met les anciennes valeurs à coté tu te reposes sur son habilité à faire du copier/coller (grosse assertion, je ne suis pas sûr que ce soit facile pour tout le monde), et à ce moment là autant mettre le label à coté et la valeur dans le champ non ? ordre des tabulations Je te laisse naviguer dans ton formulaire à coup de TAB, c'est quasi aléatoire, en tout cas vraiment inaccessible pour quelqu'un qui a besoin de ce type de navigation (c'est à dire tous ceux qui n'ont pas un pointage graphique).

> quand il y en a beaucoup Plus il y a d'infos, plus c'est dense, plus il faut être explicite au contraire. > gêné ou bloqué dans la mise en page à cause de la densité d'info à faire passer, peut être cette > idée d'un texte par défaut, clair et précis, peut aider et résoudre l'ensemble des problèmes. Sauf que tu raisonnes là en terme de rendu graphique uniquement. Exit tous les navigateurs moins courants qui se basent sur le sens et rôle des balises pour rendre la page. > il est clair que ce texte doit disparaître dès lors que l'utilisateur clique dans le champ pour entrer sa valeur. Donc j'ai un formumlaire avec 20 champs, tous le label en valeur par défaut. Je commence à remplir, j'ai rempli 15 champ, je n'ai plus aucune idée de ce à quoi correspondent les différents champs. C'est vraiment une amélioration ?

Le point 10.4 (je pense que c'est à celui là que vous faites référence) dit : "10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3] " En gros la question est "est-ce que les navigateurs gèrent les champs vides correctement ?" Est ce que vous connaissez des navigateurs (mêmes très peu utilisés ou très spécifiques) qui ne gèrent pas les champs vides ? Si vous répondez non alors il n'y a aucune raison de mettre des valeurs par défaut inutiles. Si vous répodnez oui pour certains la question devient "est ce que l'absence de ces valeurs par défaut pour certain fait plus ou moins de dégats d'accessibilité que la présence de contenu inutile pour d'autres ?" Qui peut répondre à la première question ?

Je n'ai pas suivi, pourquoi souhaites tu vider automatiquement un champ ? Je ne vois qu'une seule application de l'effacement automatique : ceux qui mettent le label du champ à l'intérieur du champ au lieu de le séparer. Chose qui devrait à priori être évitée de toutes façons. As tu une autre utilisation que je ne vois pas ? à priori si il y a une valeur par défaut c'est pour s'en servir, sinon autant ne pas la mettre