Un ptit test site svp! à votre bon coeur

Bon si y a des volontaires pour jeter un oeil http://www.tektonika.com je suis preneur j'ai 100 partout avec Adesigner mais ça me suffit pas, je préfère un avis humain.

Sinon dans le genre bizarre synthia says me trouve un erreur sur mon formulaire alors qu'il a bien un label.

Pour un info le site est dans les cartons depuis pas mal de temps et donc à l'époque je faisait encore avec un tableau de mise en page mais par contre il est valide

goetsu a écrit :

Sinon dans le genre bizarre synthia says me trouve un erreur sur mon formulaire alors qu'il a bien un label.

Peut-être le label en dehors du form ?

Sinon ton formulaire ne passerait en mode strict, il faudrait le modifier :

<form name="rechercher" method="post" action="/recherche/index.php">
<p>
<input name="request" id="recherche" accesskey="4" class="recherche">
<input name="Submit" type="image" src="/images/btsearch.gif" alt="Valider la recherche" align="top">
</p>
</form>

<ul>
<li><a href="#contenu" accesskey="s">Contenu</a></li>
<li><a href="#references">Derni&egrave;res r&eacute;alisations</a></li>
<li><a href="#nav">Navigation</a></li>
<li><a href="#outils">Outils</a></li>
<li><a href="/aide/index.php#raccourcis" accesskey="0">Raccourcis clavier</a></li>
<li><a href="#moteur">Moteur de recherche</a></li>
</ul>

Pourquoi cette partie est cachée?


Sinon pour le form même réponse que stephkup la position de ton label.



Sinon un petit

label{cursor:pointer}

Moi je trouve cela bien.

Ya un truc qui me titille qd meme dans ton site , je le trouve clair etc , c'est ps mal fait mais je vois que tu utilises souvent des bordures de 1px noir pour entourer un peu tout ce qui passe.

Je ne suis ps contre ces bordures mais c'est plutot la couleur noir qui me pose pb, ne saurait ps tu la descendres dans le gris foncé ( voir gris légerement plus foncé que tes bordures de 4 ou 5 px) afin que les bordures s'intègrent au mieux dans ton deisgn ???

pour la partie cachée c'est des liens d'accès rapide utile notament pour les utilisateurs de lecteurs d'écran (je sais c'est utile pour tout le monde mais graphiquement j'avais pas le choix)

Pour le cursor pointer effectivement c'est un oubli merçi

Pour la position du label je suis preneur de retour d'utilisateur de jaws et autre (chez moi l'association est bien faite entre le champ et la label) donc si ça pose juste un probleme à synthia says et pas aux utilisateurs, je m'en fou un peu

pour la couleur des bordures elles sont déjà en gris plus foncé

yes mais bon tu me comprends, si je te dis ca c'est parce qu'elles sont trop foncé à mon gout. Avis personnel

Ecoute je ne suis pas sur que ta syntaxe soit la bonne, pour la création d'un formulaire.

Plus précisement pour le label
Modifié par knarf (22 Jul 2005 - 15:50)

Pour ma part, le fait que le <label> soit hors du formulaire ne me pose pas de problème, dans la mesure où:
- il est bien attaché au contrôle par for=
- il précède immédiatement le contrôle dans l'ordre linéaire du contenu (autrement dit, une fois le tableau linéarisé).

Mais ce n'est qu'un exemple de test. A confirmer
Modifié par Laurent Denis (22 Jul 2005 - 15:55)

Bonjour,

En html transitionnal mettre un label en dehors d'un formulaire, aux conditions précisées par Laurent ne pose pas de problème de validation, mais bon ya pas grand chose qui pose de problème en HTML 4.01 transitionnal .

En revanche je ne vois rien dans le code qui le justifie du coup, pourquoi ne pas le mettre dans le formulaire et assurer le coup ?

JP

jpv a écrit :
Bonjour,

En html transitionnal mettre un label en dehors d'un formulaire, aux conditions précisées par Laurent ne pose pas de problème de validation, mais bon ya pas grand chose qui pose de problème en HTML 4.01 transitionnal .

Tiens, du coup, petite vérification... : un <label> hors d'un champ de formulaire est parfaitement valide en HTML Strict et en XHTML1.0 Strict .

Mais je serais assez d'avis comme le dit sagement jpv d'assurer le coup : je ne suis pas sûr que tel ou tel outil ne vas préjuger de la présence du label dans le formulaire, en exploitant le DOM par exemple...
Modifié par Laurent Denis (22 Jul 2005 - 16:26)

car pour des raisons de précisition de placement il est dans deux td différent et il n'est pas valide de mettre le form autour d'un tr
Modifié par goetsu (22 Jul 2005 - 16:28)

Bon alors une contradiction de plus ou c'est encore moi qui ne comprends pas quelquechose.

a écrit :
Pour associer implicitement un label à une autre commmande, l'élément de commande doit se trouver à l'intérieur de l'élément LABEL. Auquel cas, cet élément LABEL ne peut contenir qu'un seul élément de commande. Le label en question peut se placer avant ou après la commande associée.

Le label en question peut se placer avant ou après la commande associée.

je l'invente pas.

et

Laurent-Denis a écrit :

il précède immédiatement le contrôle dans l'ordre linéaire du contenu (autrement dit, une fois le tableau linéarisé).

EDIT:

Il faut avouer que des fois c'est pas facile de se faire une idée de ce qu'il faut mettre en oeuvre exactement entre les specs, les validateurs, les utilisateurs, on se retrouve des fois avec 3 interprétations différentes.

Je vous assure pour quelqu'un de néophyte et d'autodidacte qui s'interesse à l'accessibilité vous ne facilitez pas les choses dans ce monde.

Bon des fois je percute pas vite d'accord mais quand même, ou alors je me pose trop de questions ou peut être pas les bonnes ?

Une autre chose dans le code de goetsu les ancres par des id de blocs et nombres de sites font exactement la même chose, alors que l'on me conseille d'utiliser des ancres <a name=""></a>pour ne pas desynchroniser le flux.

Moi ce que je n'arrive pas à comprendre aussi c'est comment vous pouvez réaliser une navigation logique au clavier pour IE et ff en utilisant ou des id ou des ancres.
Modifié par knarf (22 Jul 2005 - 17:21)

knarf a écrit :

Le label en question peut se placer avant ou après la commande associée.

Oui. Mais cette précaution est justifiée : simplement parce que le for= ne sera pas nécessairement pris en compte par tous les dispositifs d'accès. Si le label est, disons, "lu" comme un texte "normal", la seule chose qui permettra à l'auditeur de faire la liaison, c'est la succession logique label > contrôle.
Modifié par Laurent Denis (22 Jul 2005 - 17:26)

knarf a écrit :
Il faut avouer que des fois c'est pas facile de se faire une idée de ce qu'il faut mettre en oeuvre exactement entre les specs, les validateurs, les utilisateurs, on se retrouve des fois avec 3 interprétations différentes.

Je vous assure pour quelqu'un de néophytes et d'autodidacte qui s'interesse à l'accessibilité vous ne facilitez pas les choses dans ce monde.

Hum... Qui complique les choses, tiens ?
- WCAG1.0, qui prend de l'âge, et qui attend sagement WCAG2.0 ?
- Les dispositifs d'aides, qui ne "collent" pas nécessairement aux specs, même s'ils tendent à présent à s'en rapprocher de plus en plus ?
- Les développeurs HTML-CSS, qui ont parfois des idées tordues, comme de vouloir placer le label d'un input text après celui-ci ?
- Les utilisateurs handicapés, qui n'ont pas nécessairement la bonne version de la bonne application ? Ni toute l'aide et toutes les fonctionnalités de celle-ci en tête ?

Oui, c'est parfois un peu compliqué, l'accessibilité
Modifié par Laurent Denis (22 Jul 2005 - 17:39)

Qu'appelle tu

a écrit :

"lu" comme un texte "normal"

Pour la logique de l'ensemble c'est vrai que le sens label > contrôle à son importance.

Donc il pourrais être fait mention d'une régle spécifiant que les 2 sont possibles au niveau de la validité mais que par soucis d'utilisation il est préférable que le label précède le controle.


Des fois pour une question de graphisme il est mieux de pouvoir placer le label aprés donc si on le fait en connaitre les conséquences, même si c'est valide cela risque d'en amoindrir l'accessibilité.

a écrit :

- Les développeurs HTML-CSS, qui ont parfois des idées tordues, comme de vouloir placer le label d'un input text après celui-ci ?

Et toc! je vais revoir notre Questionnaire
Modifié par knarf (22 Jul 2005 - 17:50)

effectivement concernant les ancres je suis au courant faut que je corrige ça merçi de me le rappeler

Pour le label le cas que tu cite concerne l'utilisation de label sans id et for genre <label>texte <input></label> mais qui n'est plus conseillé.
Quand à mettre le <label> avant le champ je ne suis pas forcement d'accord, je pense que c'est au lecteurs d'écran de lire correctement les choses d'ailleurs le mien https://webspace.utexas.edu/chencl1/clc-4-tts/ me dit bien: type du champ, intitulé;
que le label soit avant ou apres
-----
edit je parlais justement du cas des checkbox
Modifié par goetsu (22 Jul 2005 - 18:17)

knarf a écrit :

Donc il pourrais être fait mention d'une régle spécifiant que les 2 sont possibles au niveau de la validité mais que par soucis d'utilisation il est préférable que le label précède le controle.

Pas forcemment, pour les checkbox il n'est pas rare de trouver le label après la checkbox sans que cela ne gêne les utilisateurs ce qui est important c'est de lier explicitement le label et l'input avec le for="".

a écrit :
Il faut avouer que des fois c'est pas facile de se faire une idée de ce qu'il faut mettre en oeuvre exactement entre les specs, les validateurs, les utilisateurs, on se retrouve des fois avec 3 interprétations différentes.

L'accessibilité est un domaine où l'expérience est primordiale et je dirais d'ailleurs qu'il n'y à que ça qui compte, les recommandations du WCAG étant particulièrement réduites et facile à apprendre.

Ceux qui trainent des pieds en se disant qu'il sera toujours temps de prendre le train en route (je parle des professionnels du web) vont avoir des réveils douloureux.

Et si il est facile de former un technicien du code en quelques semaines, moi après 5 années de travail sur le sujet et des dizaines de sites refaits, j'en apprends encore tous les jours, et quand je dis tous les jours c'est vraiment tous les jours.

Là je viens d'apprendre qu'on pouvait mettre un label en dehors d'un formulaire, l'idée ne m'en était même jamais venu, tant il parait naturel de l'associer dans le code à son contrôle, ce qui est recommandé par tout le monde...

Peu-être n'est ce finalement pas aussi important que ça et peu-être même que ça ouvre des perspectives, par exemple à goetsu et à pas mal d'autres auteurs auxquels ça pose problème dans des tables de layout.

Tu m'aurais inttérrogé y'à deux heures la dessus je t'aurais "affirmé" mordicus que c'était une erreur et un contre-sens et je me serais trompé.

C'est sur que comme tout les domaines "d'expertise" l'apprentissage est plus long, mais ce qui en fait également son intérêt.

JP