[WAI] Formulaires, vider les valeurs ?

[ste]

elo, all...

bon, s'il faut faire en sorte que les input, textarea et leurs labels,

et surtout que leurs valeurs ne soient pas vides...

comment puis-je faire pour vider les valeurs au moment du clic souris,

voire de l'accès clavier ?

[Dan]

Salut Stephane,

Un simple appel JavaScript

onfocus="this.value=''"

devrait faire l'affaire, non?

Dan

[ste]

Un simple appel JavaScript

onfocus="this.value=''"

devrait faire l'affaire, non?

vi, tout simplement...

merci Dan,

[ste]

Et, concernant l'accès clavier, je dois certainement rajouter l'événement :

onkeypress="this.value=''"

n'est-ce pas ?!

[Monique]

Et, concernant l'accès clavier, je dois certainement rajouter l'événement :

onkeypress="this.value=''"

D'après le formulaire de recherche d'Openweb, non.

accesskey="1"  tabindex="1"

Les combinaisons de touches pour accèder au formulaire :

- Windows : alt+maj+ 1 ou alt+1

- Macintosh : ctrl+1 ou pomme+1

[LaurentDenis]

Attention : onfocus="this.value=''" peut poser un problème dans certains cas.

Par exemple, l'utilisateur a entré son adresse mail et a fait une erreur. Il veut revenir sur le champ pour corriger... tout est effacé.

Il vaut mieux prévoir l'effacement seulement si la valeur est du champ est égale au texte par défaut.

J'utilise (pour un champ contenant le mot "facultatif" par défaut) :

onfocus="if this.value == '(Facultatif)') {this.value=''}"

Mais on doit pouvoir faire bcp mieux ?

[Ganf]

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

[Steph. K.]

Bonjour tout le monde,

Le fait de ne pas laisser de zones de formulaire vides est obsolète, je pense qu'il est plus important d'accoler un label avec un texte significatif... sinon la solution proposée par Laurent Denis me semble être la meilleure.

Si l'on consulte une page contenant un formulaire avec un logiciel tel que Link's ou Lynx l'input pré-rempli pose sûrement plus de problème que la même zone vide (il faut d'abord effacer le texte avant de saisir le sien et le javascript n'est pas implanté sur les navigateurs textuels).

Steph. K.

[LaurentDenis]

Le fait de ne pas laisser de zones de formulaire vides est obsolète

Source ??? Suis très intéressé, là. La Wcag vieillit mal, et les remises en question ne manquent pas, mais sont très dispersées. Le remplissage exemplaire des zones de formulaires semble en effet apporter peu...

Et le label est effectivement plus important... Pour une fois qu'un attribut d'accessibilité est réellement exploité par les Jaws et autres IBM HPR...

[Ganf]

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 ?

[Beatnykk]

la question est surtout dans la présentation d'une page avec de nombreux champs.

quand il y en a peu, un nom explicatif à côté suffit.

quand il y en a beaucoup, à défaut de devoir multiplier la taille du formulaire, et d'être 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.

il est clair que ce texte doit disparaître dès lors que l'utilisateur clique dans le champ pour entrer sa valeur.

mais si ces textes par défaut ne sont pas lisibles dans certains explorateur, alors une fois de plus il faut faire dans le conditionnel.

trouver quels explorateurs ne gèrent pas ce code, et si les utilisateurs ont désactivé javascript ou non. dans ces deux cas conditionner par php un formulaire "classique".

pour le reste (else, majorité) avec explorateurs compatibles ET javascript, un formulaire "amélioré" avec la solution judicieuse proposée au-dessus.

en tout cas je vois pas mieux. il y avait 8 lettres ???

[Ganf]

> 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 ?

[ste]

Oulah, vous m'embrouillassionnez un peu là !!!!

bon, je reprends :

histoire que vous vérifiez { http://devepl.stephane-huc.net/cfppa/ensei...nt/information/ } !

Ainsi que vous le voyez le form est, me semble-t-il, correct, des fieldsets que j'ai essayé de bien pensé, idem pour les labels...

j'ai essayé de penser le plus logiquement aux accesskeys, tabindex, etc...

donc, ma démarche, hormis l'effort (intense ?!), pour rendre accessible autant le site que ledit form était de permettre à l'utisateur que quand il accède à un champ input ou textarea, la valeur de contrôles qui sont pleines se vident au moment de l'accès...

je ne vois vraiment pas en quoi, cela déroge (comprendre 'pose problème') à l'accessibilité... là, j'ai vraiment du mal à vous comprendre !

???

cf : WCAG 1.0 directives 10.4

[Ganf]

Ainsi que vous le voyez le form est, me semble-t-il, correct, des fieldsets que j'ai essayé de bien pensé, idem pour les labels...

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

la valeur de contrôles qui sont pleines se vident au moment de l'accès...

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).

[ste]

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>.

Désolé, mais là-dessus, vous êtes beaucoup à vous tromper...

http://www.la-grange.net/w3c/html4.01/inte...tml#edef-LEGEND => côté HTML 4.01 montre que l'attribut accesskey est opérationnel !!!

quant à la DTD xhtml1-strict, elle pose l'élèment legend ainsi :

<!ELEMENT legend %Inline;>     <!-- fieldset label -->
<!ATTLIST legend
  %attrs;
  accesskey   %Character;    #IMPLIED
  >

ET, apparement c'est même le seul attribut !!!

Sachant cela, et j'ai vérifié à nouveau avant de poster ici, (histoire d'être sûr... ), il m'a semblé très logique de positioner la clé d'accès sur cet élèment sachant qu'on doit le retrouver dans tous FIELDSETs ...

Ce qui permet ainsi d'arriver à un groupe d'élèments, puis de naviger grâce aux déclarations TABINDEX ; me tromperais-je ? suis-je FALSE dans mon raisonnement ?

Après, j'ai vraiment du mal à comprendre pour les LABELs, toi tu me dis que mes LABELS sont vides, donc, j'ai repris la doc du W3C sur le WAI, et Openweb Group, je pense avoir compris pour cela :

  <LABEL for="firstname">First name: 
     <INPUT type="text" id="firstname" tabindex="1">
   </LABEL>

Est considéré comme vide le LABEL, s'il n'y a pas de caractères même si présence est d'un élèment de FORM !?!

Cela n'empêche en rien que je doive spécifier une valeur non vide dans la valeur des élèments INPUT & TEXTAREA, n'est-ce pas ???

Après le reste, faut que je relise, car à froid, j'y pige rien, mais vraiment rien !!!

Je suis franchement désolé...

Surtout, au niveau de l'ordre des TABINDEX, ce n'est pas ainsi que je dois le traiter .... ? Je ne comprends vraiment pas comment je dois les traiter !???

Ainsi que là :

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.

Je ne comprends pas en quoi j'ai détourné le sens !!!

Modifié 1 Avril 2004 par ste

[Ganf]

côté HTML 4.01 montre que l'attribut accesskey est opérationnel !!!

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.

Ce qui permet ainsi d'arriver à un groupe d'élèments, puis de naviger grâce aux déclarations TABINDEX ; me tromperais-je ? suis-je FALSE dans mon raisonnement ?

Tu as je pense raison, c'était une erreur de ma part.

Est considéré comme vide le LABEL, s'il n'y a pas de caractères même si présence est d'un élèment de FORM !?!

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.

Cela n'empêche en rien que je doive spécifier une valeur non vide dans la valeur des élèments INPUT & TEXTAREA, n'est-ce pas ???

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.

Surtout, au niveau de l'ordre des TABINDEX, ce n'est pas ainsi que je dois le traiter .... ? Je ne comprends vraiment pas comment je dois les traiter !???

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.

Je ne comprends pas en quoi j'ai détourné le sens !!!

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.

[Monique]

Bonjour,

Bien d'accord avec toi, Stéphane... ce n'est pas simple !

Pas simple à bien mettre en oeuvre pour le webmaster, et pas simple à utiliser pour l'internaute.

J'ai essayé une fois de compléter un formulaire avec Jaws, le fiasco !

Il s'agissait d'une enquête avec des zones de textes et des boutons radio.

Je n'ai jamais réussi à placer correctement le curseur virtuel, ce qui fait que quand je validais un choix, il ne correspondait pas à ce que je voulais (et cela, je ne pouvais le savoir que parce que je voyais).

Dans ton formulaire, l'absence de label (label vide) est perturbant : si après avoir cliqué on a un moment d'inattention, plus rien ne permet de savoir ce qui était demandé.

Quand à l'ordre des tabindex, effectivement cela semble donner un peu n'importe quoi : je suis envoyée d'un élément de formulaire à un lien, je reviens dans le formulaire...

J'ai essayé de comprendre en comparant ton code à ceci

La navigation procède à partir de l'élément avec la plus petite valeur pour l'attribut tabindex vers l'élément avec la valeur la plus élevée. Les valeurs ne se suivent pas forcément ni doivent commencer à une valeur particulière. Les éléments dont les valeurs de l'attribut tabindex sont identiques devraient être parcourus dans l'ordre de leur apparition dans le flux de caractère ;

mais...

[Steph. K.]

Ce que j'avancai est avant tout le fruit de nombreux essais avec Link's, Linx, braillesurf et cela a été confirmé par Yobiwan dans un autre thread.

Par exemple, une erreur soulevée dans un des validateurs et le manque de textes explicatifs dans les champs de formulaire.

Ce critère est clairement inutile et les les listes techniques de WAI dans lesquels je suis inscrit l'ont tres clairement exprimé. C'est d'ailleurs une des raisons pour laquelle ce critère disparait totalement des WCAG 2.0 qui sont entrain de voir le jour. J'en avais parlé avec Wendy Chisholm (la responsable de la redaction des WCAG 2.0) quand elle etait venu nous voir chez BrailleNet et elle avait reconnu la gêne pour nombreux utilisateurs que provoquait l'application de cette recommandation.

[Monique]

Bonjour,

J'ai demandé à Sof (RaZorbacK Blog, - Infos utiles et sélection de softs accessibles aux déficients visuels) de donner son avis.

Il a testé ton formulaire, Stéphane... voilà sa réponse :

=== copie ===

bonjour,

Je viens de visiter la page et il y a, avec jaws, effectivement queleques

problèmes. Mais c'est aassez difficile d'expliquer par mail mais je vais

essayer.

Si tu connais JAWS, tu dois sans doute savoir qu'il y a ce que l'on appelle

le curseur virtuel qui nous sert à nous déplacer dans une page avec les

flèches de direction, pg up ou pgdn comme si c'était un texte se

curseur virtuel ne marchant que pour internet explorer. Si on n'utilise pas

le curseur virtuel on utilise la touche tabulation pour se déplacer entre

différents liens ou les difféerents champs d'un formulaire.

En fait, quand on se déplace avec ce fameux curseur virtuel,

c'es-à-dire du haut vers le bas de la page, les infos sont très bien

lues et dans l'ordre.

Par contre, quand on se déplace avec tab, tout est désordonné, les

liens viennent s'insérer antre les champs du formulaire, du moins c'est

ce que je perçois vocalement.

De plus, avec ma version de JAWS (ca risque d'être pareil avec les

autres), quand on arrive par exemple sur une boîte de liste , par exemple

celle qui demande de sélectionner le choix de formation désirée, la

synthèse lit tout le contenu de la boîte de liste.

ca nous donne:

"choix de formation désirée BPA UC BP REA bac pro horticole bts

horticole environnement Teleformations - FOAD services entreprisesADPA

Après avoir entendu tout ca d'un trait , on peut sélectionner les

choix, a part bien sur si on interrompt la synthèse.

Ensuite, après cette boite de liste, il y a "coordonnées personnelles

et d'après ce que j'entends, les deux premier champs ne sont pas

libellés apparamment, et on ne peut pas savoir sur quel case on est. Il

en est de même pour les champs se trouvant après la boîte de liste

"civilités".

Désolé, je ne suis peut-être pas clair, c'est assez dificile

d'expliquer ce qu'on entend pas mail, en plus, n'étant pas du tout expert

dans les langages web, je ne peux même pas te donner de pistes pour

arranger les éventuels problèmes. En fait, l'histoire de la boîte de

liste serait surtout une façon de rendre la lecture vocale plus

confortable, par contre, les champs non libellés et l'ordre dans lequel

se présente le formulaire quand on se déplace dedans avec la touche tab

sont très gênants.

Encore une fois, cela dépend beaucoup du navigateur de chacun, de sa

revue d'écran, de ses habitudes de navigation, s'il travaille en braille

ou en vocal...

Si tu veux, je peux te proposer un contact vocal genre via skype ou msn

afin que tu puisses juger en temps réel.

j'espère vraiment avoir pu aider, et n'hésite pas si je peux faire

mieux. Je peux peut-être te rediriger vers des gens plus compétents que

moi dans le domaine du html, php et le reste et qui sont déficients

visuels.

excuse si j'ai fait des fautes, c'est le matin.

a bientot,

Best regards, Sof

=== fin de copie ===

Je vais contacter Sof par msn comme il me le propose

[ste]

Bon, j'ai revu, corrigé le form { http://devepl.stephane-huc.net/cfppa/ensei...nt/information/ } tant au niveau des libellés qu'au niveau des TABINDEX... laissant en général, les valeurs des élèments INDEX et TEXTAREA non vides.

là, où je ne suis pas trop sûr, c'est à propos de l'implémentation actuel, tel quel des TABINDEX... car, à mon avis, tout ne fonctionne pas correctement !

Mais, il est clair que côté navigabilité, c'est déjà mieux...

Donnez moi le votre, svp ?!

A contrario, malgrès les explications de mangeur-de-cigogne sur les OPTGROUP, j'ai vraiment l'impression de suivre les règles...

PS: Monique, je viens de lire ton post et le contact que tu as eu...

je te permets de laisser mon contact MSN : ci-dessous, au cas où tu voudrais et pourrais me mettre en contact, moi aussi...

Merci à toi particulierement, et aux autres, des efforts que vous faites pour m'aider à comprendre clairement, calmement, tranquillement : j'apprécie beaucoup !

Modifié 2 Avril 2004 par ste

[Monique]

Cet annonce vient de m'arriver dans les alertes de Google :

Un article (en anglais) présenté sur nexen.net : Des formulaires intelligents

L'article, Clever forms with PHP, décrit des techniques de validation, rappel des valeurs, affichage des erreurs à l'aide de scripts php.

Ne connaissant pas ce langage je ne pourrais pas commenter ce qui est proposé dans l'article

[Ganf]

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.

[ste]

Eric, tu peux envoyer le lien ci-dessus, as you want, sachant que j'ai corrigé toutes les valeurs, et autres labels selon ce que chacun m'a permis de comprendre ici

Pour ce qui est des défauts de conception relevé ici, tel que mon formulaire au début, tu peux faire vérifier avec ceci : http://ecrits.net/ecrit/citations/30/15/Vi...ir/#Vive_le_GNU

(ce lien est celui d'un formulaire sur mon site d'écrits... -template commun- où j'y ai appliqué les mêmes erreurs de compréhension que le formulaire dont on a discuté ici ; normal, en fait ... j'ai créé celui-ci, bien avant, selon ma compréhension d'il y a quelques mois !)

Sur celui-ci, les valeurs sont pleines, mais les LABELs vides tel que vous me l'avez expliqué

En plus, il me faut ajouter les TABINDEX !

Monique, je vais étudier tes liens, bien que n'aimant pas l'anglais

Modifié 5 Avril 2004 par ste