Sommaire
Un formulaire HTML est une section d'un document dans laquelle on trouvera du contenu normal, des balises, et des éléments spéciaux appelés contrôles. Les contrôles répondent à des actions utilisateur et acceptent des donnés. Les utilisateurs "complètent" les formulaires en saisissant du texte, en sélectionnat des choix de menus, etc., puis soumettent le formulaire pour traitement. Les formulaires soumis peuvent à ce moment être transmis par courrier électronique ou directement alimenter un programme de traitement de données.
Les contrôles pourront être des cases à cocher, des boutons radio, des labels, des menus, etc. Un nom peut être donné à chaque instance de contrôle. Lorsque le formulaire est soumis, certains contrôles (suivant leur état) "émettront", associé à leur nom, une valeur. La nature de la valeur soumise dépend du contrôle (ex., la valeur d'un champ de texte est le texte inscrit).
Note : Cette spécification inclue une information détaillée sur les formaulaires dans les sections traitant de l'affichage des formulaires. Des chapitres supplémentaires sur la façon de coder le contenu des éléments de formulaire seront ajoutés à ce document provisoire dans le futur.
<!ELEMENT FORM - - %block -(FORM)> <!ATTLIST FORM %attrs; -- %coreattrs, %i18n, %events -- action %URL #REQUIRED -- Gestionnaire côté serveur -- method (GET|POST) GET -- Requête HTTP utilisée pour la soumision -- enctype %ContentType; "application/x-www-form-urlencoded" onsubmit %Script #IMPLIED -- Juste avant soumission -- onreset %Script #IMPLIED -- Juste avant réinitialisation -- target CDATA #IMPLIED -- Où rendre les résultats -- accept-charset CDATA #IMPLIED -- Jeux de caractères supportés -- >
Balise de début : requise, Balise de fin : requise
Définition des attributs
La valeur par défaur de cet attribut est la chaîne réservée "UNKNOWN". Les agents utilisateur compendront cette valeur comme "le jeu de caractère utilisé dans le document HTML qui contenait cet élément FORM".
Attributs définis par ailleurs
L'élément FORM fait office de container pour des contrôles. Il spécifie :
Un formulaire peut contenir du texte et des balises (paragraphes, listes, etc.) ainsi que les contrôles détaillés ci-après.
La portée de l'attribut name associé à chacun ds contrôles situé à l'intérieur d'un élément FORM est limitée à cet élément FORM.
L'exemple suivant spécifie que le formulaire une fois soumis sera traité par le programme "ajoututilisateur". Le formulaire sera envoyé au programme par la méthode HTTP POST.
<FORM action="http://somesite.com/prog/ajoututilisateur" method="post"> ...contenu de formulaire... </FORM>
L'exemple suivant montre comment envoyer le contenu d'un formulaire par courrier electronique.
<FORM action="mailto:Kligor.T@gee.whiz.com" method="post"> ...contenu de formulaire... </FORM>
Les éléments contrôles décrits ci-après apparaissent généralement dans une declaration FORM. Cependant, ces éléments peuvent parfois être implantés en dehors d'un élément FORM lorsqu'ils servent à construire une interface utilisateur. Cet aspect est traité plus avant dans cette spécification, dans la section concernant les événements intrinsèques.
Labels de contrôles
Certains contrôles de formulaires sont automatiquement associés à des labels (boutons d'action créés par un élément INPUT
ou BUTTON) tandis que d'autres n'en ont pas (champs de saisie créés par un élément INPUT ou TEXTAREA, cases à cocher et boutons radio créés par des éléments INPUT, ou encore les menus
créés par une déclaration SELECT).
Pour renseigner les labels implicitement associés à ces contrôles, les agents utilisateur pourront utiliser la valeur de l'attribut value.
Pour les éléments qui ne sont pas associés à des labels, les auteurs ajouteront explicitement les labels avant ou après la définition du contrôle. Ceci est illustré par l'exemple ci-dessous.
<!ENTITY % InputType
"(TEXT | PASSWORD | CHECKBOX |
RADIO | SUBMIT | RESET |
FILE | HIDDEN | IMAGE | BUTTON)"
>
<!-- HSPACE and VSPACE missing due to lack of widespread support -->
<!ELEMENT INPUT - O EMPTY>
<!ATTLIST INPUT
%attrs; -- %coreattrs, %i18n, %events --
type %InputType TEXT -- quel type de "composant graphique" est nécessaire --
name CDATA #IMPLIED -- requis pour tous sauf submit & reset --
value CDATA #IMPLIED -- requis pour les boutons radio et cases a cocher --
checked (checked) #IMPLIED -- boutons radio et cases a cocher --
disabled (disabled) #IMPLIED -- le contrôle n'est pas activable --
readonly (readonly) #IMPLIED -- texte et mot de passe --
size CDATA #IMPLIED -- spécifique à chaque type de champ --
maxlength NUMBER #IMPLIED -- nombre de caractères maximum pour les champs de texte --
src %URL #IMPLIED -- pour tout champ avec images --
alt CDATA #IMPLIED -- description pour les navigateurs alphanumériques exclusifs --
usemap %URL #IMPLIED -- utilisation d'une Imagemap cliente --
align %IAlign #IMPLIED -- alignement horizontal ou vertical --
tabindex NUMBER #IMPLIED -- ordre de tabulation --
onfocus %Script #IMPLIED -- l'élément vient d'avoir le focus --
onblur %Script #IMPLIED -- l'élément vient de perdre le focus --
onselect %Script #IMPLIED -- du texte a été sélectionné --
onchange %Script #IMPLIED -- la valeur de l'élément vient d'être modifiée --
accept CDATA #IMPLIED -- liste des types MIME acceptés pour téléchargement --
>
Balise de début : requise, Balise de fin : interdite
Définition des attributs
Attributs définis par ailleurs
La nature d'un contrôle défini par un élément INPUT dépend de la valeur de son attribut type.
L'attribut type de l'élément INPUT détermine quel contrôle doit être créé.
Plusieurs cases à cocher du même formulaire pourront partager le même nom. Au moment de la soumission, toute case à cocher "activée" y compris celles de nom semblable émet une paire nom/valeur dans laquelle le nom sera identique. Ceci permettra aux utilisateurs de choisir des valeurs multiples pour une propriété unique.
Plusieurs boutons radio du même formulaire pourront partager le même nom. Cependant, seul l'un d'entre eux pourra être actif à la fois. Lorsque l'un des bouton radio est marqué, tous les autres portant le même nom sont automatiquement déselectionnés. Pour cet ensemble de boutons radio, il ne peut donc être émis qu'une seule paire nom/valeur.
Un formulaire peut contenir plusieurs boutons de soumission. Cependant, seule la paire nom/valeur du bouton de soumission actionné sera envoyée dans le formulaire.
Lorsqu'un système de pointage est utilisé pour cliquer sur l'image, le formulaire est soumis et l'endroit physique du clic est transmis au serveur. La valeur x est mesurée en pixels à partir du bord gauche de l'image, et le valeur y est une mesure en pixels à partir du bord supérieur de l'image. Les données soumises incluent nom.x=valeur-x et nom.y=valeur-y où "nom" est la valeur de l'attribut name, et valeur-x et valeur-y les coordonnées x et y respectives.
Si le serveur a des réactions différentes suivant l'endroit où l'on clique sur l'image, alors les utilisateurs d'agents non graphiques seront désavantagés. Pour cette raison, nous vous demandons d'examiner les approches alternatives suivantes :
Une extension future possible serait d'ajouter l'attribut usemap à l'élément INPUT pour rétablir un fonctionnement de type Imagemap cliente lorsque "type=image". L'élément AREA correspondant à l'endroit où le bouton aurait été cliqué contribuerait alors à la sélection de la valeur à envoyer au serveur. Afin d'éviter de reprendre les scripts serveurs, il serait approprié d'étendre l'élément AREA de façon à ce qu'il intégre les valeurs en x et en y, lesquelles seraient utilisées dans le contexte de l'élément INPUT.
Par exemple, la déclaration suivante fait exécuter la fonction appelée verify lorsque l'utilisateur clique sur le bouton. Le script doit être définie dans un élément SCRIPT.
<INPUT type="button" value="Click Me" onclick="verify()">
Consultez la section traitant des événements intrinsèques pour plus de détails sur les scripts et les événements.
Ce type de contrôle sera en général utilisé pour enregistrer des données d'échanges client/serveur qui seraient autrement perdues du fait de la nature volatile des processus HTTP.
Les valeurs des contrôles INPUT de type hidden sont envoyées lors de la soumission du formulaire. Ceci resterait vrai pour tout contrôle qui ne pourrait être affiché pour des raisons de paramétrage de style. Le contrôle suivant, bien qu'invisible aux yeux de l'utilisateur, émettra sa valeur vers le serveur lorsque le formulaire sera soumis.
<INPUT type="password" style="display:none"
name="mot-de-passe-invisible"
value="mon-mot-de-passe">
Les agents utilisateurs encapsuleront de multiples fichiers dans un document de type MIME "multipart" (voir la [RFC2045]). Ce mécanisme encapsule chaque fichier sous forme d'un corps d'entité d'un document HTTP multiple. Chaque corps d'entité peut être précédé d'une en-tête "Content-Type:" propre, et si nécessaire d'un champ d'en-tête "charset" qui spécifie le jeu de caractère pour les type MIME correspondant aux fichiers textuels.
L'extrait de HTML suivant définit un formulaire simple qui permet à un utilisateur de d'entrer son nom, son prénom, son adresse email, et son sexe. Lorsque le bouton de soummission est activé, le formulaire est envoyé au programme spécifié par l'attribut action.
<FORM action="http://somesite.com/prog/adduser" method="post">
<P>
Nom : <INPUT type="text" name="nom"><BR>
Prénom : <INPUT type="text" name="prenom"><BR>
email: <INPUT type="text" name="email"><BR>
<INPUT type="radio" name="sexe" value="Homme"> Homme<BR>
<INPUT type="radio" name="sexe" value="Femme"> Femme<BR>
<INPUT type="submit" value="Send"> <INPUT type="reset">
</FORM>
Ce formulaire serait affiché comme suit :
Dans la section traitant des éléments LABEL, nous discuterons de la façon d'écrire des labels tels que "Nom".
L'exemple qui suit montre comment le contenu d'un fichier spécifié par l'utilisateur peut être soumis par formulaire. Cet exemple est basé sur un exemple écrit dans la [RFC1867].
Dans cet exemple, on demande à l'utilisateur un nom et une liste de noms de fichiers dont le contenu doit être envoyé au serveur. En spécifiant l'attribut enctype du "multipart/form-data", chaque contenu de fichier sera stocké dans une sous-entité séparée d'un document multipart.
<FORM action="http://server.dom/cgi/handle"
enctype="multipart/form-data"
method="post">
Quel est votre nom ? <INPUT type="text" name="nom-de-l'emetteur">
Quels fichiers envoyez vous ? <INPUT type="file" name="noms-des-fichiers">
</FORM>
Consultez la [RFC1867] pour plus d'informations sur la soumission de fichiers.
ISINDEX est obsolète. Les utilisateurs devraient plutôt utiliser l'élément INPUT.
<!ELEMENT ISINDEX - O EMPTY> <!ATTLIST ISINDEX %coreattrs; -- id, class, style, title -- %i18n; -- lang, dir -- prompt CDATA #IMPLIED -- message -->
Balise de début : requise, Balise de fin : interdite
Définition des attributs
Attributs définis par ailleurs
L'élément ISINDEX est un champ de saisie de texte graphiquement séparé du contexte (permettant la saisie d'un nombre quelconque de caractères). L'agent utilisateur pourra se baser sur la valeur de l'attribut prompt comme label du champ.
EXEMPLE OBSOLETE :
La déclaration de ISINDEX suivante :
<ISINDEX prompt="Entrez votre critère de recherche : ">
est équivalente à la déclaration INPUT suivante :
<FORM action="..." method="post"> Enter your search phrase: <INPUT type="text"> </FORM>
| NdA. En fait, après vérification sur plusieurs agents utilisateurs, les deux formes ne produisent pas le même résultat. Il faut encadrer la deuxième par des éléments <HR> pour que les représentations soient identiques |
Sémantique de ISINDEX. Actuellement, la sémantique dans les champs ISINDEX n'est clairement définie que lorsque l'URL de base du document courant est une URL HTTP. En practique, l'entrée est limitée au jeu Latin-1 du fait qu'il n'existe aucun mécanisme dans l'URL qui permette de spécifier un jeu de caractères différent.
<!ELEMENT BUTTON - -
(%inline | %blocklevel)* -(A | %formctrl | FORM | ISINDEX | FIELDSET)>
<!ATTLIST BUTTON
%attrs; -- %coreattrs, %i18n, %events --
name CDATA #IMPLIED -- dansle contexte de scripts/formulaires comme bouton de soumission --
value CDATA #IMPLIED -- passé au serveur sur soumission --
type (submit|reset) #IMPLIED -- rôle du bouton --
disabled (disabled) #IMPLIED -- contrôle désactivé dans ce contexte --
tabindex NUMBER #IMPLIED -- ordre de tabulation --
onfocus %Script #IMPLIED -- l'élément vient d'avoir le "focus" --
onblur %Script #IMPLIED -- l'élément vient de perdre le "focus" --
>
Balise de début : requise, Balise de fin : requise
Définition des attributs
Attributs définis par ailleurs
Un élément BUTTON de type "submit" est similaire a un élément INPUT du même type. Ces deux "widgets" provoquent la soumuission du formulaire lorsqu'ils sont actionnés, mais l'élément BUTTON offre une plus grande plage de possibilités graphiques.
Un élémentBUTTON de type "submit" et dont le contenu serait une image (ex., un élément IMG) est très proche d'un élément INPUT de type "image". Ils provoquent tous deux la soumission du formulaire, mais leur aspect est différent. Dans ce contexte, un élément INPUT devrait être rendu comme une image "plate", tandis qu'un élément BUTTON sera représenté avec son "chanfrein" (c-à-d., en relief, avec inversion de profondeur lorsque cliqué).
L'exemple suivant étend un exemple précédent en y substituant les éléments INPUT qui créent les boutons de soumission et de réinitialisation par des instances d'éléments BUTTON. Les boutons contiennent des images par leur contenu sous forme d'un élément IMG.
<FORM action="http://somesite.com/prog/adduser" method="post">
<P>
Nom : <INPUT type="text" name="nom"><BR>
Prénom : <INPUT type="text" name="prenom"><BR>
email : <INPUT type="text" name="email"><BR>
<INPUT type="radio" name="sexe" value="Homme"> Homme<BR>
<INPUT type="radio" name="sexe" value="Femme"> Femme<BR>
<BUTTON name="submit" value="submit" type="submit">
Send<IMG src="/icons/wow.gif" alt="wow"></BUTTON>
<BUTTON name="reset" type="reset">
Reset<IMG src="/icons/oops.gif" alt="oops"></BUTTON>
</FORM>
Lorsqu'un BUTTON est utilisé en combinaison avec un élément IMG, il est recommandé d'exploiter l'attribut alt de l'élément IMG comme description textuelle pour les agents non graphiques.
Associer une Imagemap à un élément IMG apparaissant en tant que contenu d'un élément BUTTON est considéré comme illégal.
EXEMPLE ILLEGAL :
Ce qui suit n'est pas une écriture HTML autorisée.
<BUTTON> <IMG src="foo.gif" usemap="..."> </BUTTON>
Un élément BUTTON de type "reset" est très similaire à un élément INPUT du même type. Ils provoquent tous deux la remise de tous les champs à leurs valeurs initiales, mais l'élément BUTTON offre une plus grande plage de possibilités graphiques.
L'élément BUTTON peut aussi être utilisé en relation aux scripts clients, auquel cas son type doit être "button". Lorsqu'un tel bouton est cliqué, un script client est exécuté. Cet usage de l'élément BUTTON est développé plus en avant dans ce document, dans la section qui concerne les événements intrinsèques.
<!ELEMENT SELECT - - (OPTION+)> <!ATTLIST SELECT %attrs; -- %coreattrs, %i18n, %events -- name CDATA #REQUIRED -- nom de champ -- size NUMBER #IMPLIED -- nombre de lignes visibles -- multiple (multiple) #IMPLIED -- sélection par défaut (pour une sélection unique) -- disabled (disabled) #IMPLIED -- contrôle désactivé dans ce contexte -- tabindex NUMBER #IMPLIED -- ordre de tabulation -- onfocus %Script #IMPLIED -- l'élément vient de recevoir le "focus" -- onblur %Script #IMPLIED -- l'élément vient de perdre le "focus" -- onselect %Script #IMPLIED -- du texte y a été sélectionné -- onchange %Script #IMPLIED -- la valeur d'élément vient de changer -- >
Balise de début : requise, Balise de fin : requise
SELECT Définition des attributs
L'élément SELECT crée une liste d'options pouvant être sélectionnées par l'utilisateur. Chaque élément SELECT doit contenir au moins une définition d'option. Chaque option est spécifiée par une instance de l'élément OPTION.
<!ELEMENT OPTION - O (#PCDATA)*> <!ATTLIST OPTION %attrs; -- %coreattrs, %i18n, %events -- selected (selected) #IMPLIED disabled (disabled) #IMPLIED -- contrôle désactivé dans ce contexte -- value CDATA #IMPLIED -- contenu de l'élément par défaut -- >
Balise de début : requise, Balise de fin : optionnelle
OPTION Définition des attributs
Attributs définis par ailleurs
Les agents utilisateurs se baseront sur le contenu de l'élément OPTION pour afficher le libellé de l'option dans la liste.
Dans l'exemple qui suit, nous créons un menu qui permet à l'utilisateur de choisir l'un des composants logiciels à installer parmi sept. Le premier et le second composants sont sélectionnés par défaut (initialement) mais pourront être déselectionnés par l'utilisateur. Les autres composants ne sont pas sélectionnés initialement. L'attribut size indique dans ce cas que seuls quatre lignes seront visibles à la fois bien que l'utilisateur puisse toujours effectuer son choix parmi les sept options disponibles. Il sera possible d'atteindre les autres options par défilement de la liste.
L'élément SELECT est suivi par deux boutons, un de soumission et l'autre de réinitialisation.
<FORM action="http://somesite.com/prog/selection-composants" method="post">
<SELECT multiple size="4" name="selection-composants">
<OPTION selected value="Composant_1_a">Composant_1</OPTION>
<OPTION selected value="Composant_1_b">Composant_2</OPTION>
<OPTION>Composant_3</OPTION>
<OPTION>Composant_4</OPTION>
<OPTION>Composant_5</OPTION>
<OPTION>Composant_6</OPTION>
<OPTION>Composant_7</OPTION>
</SELECT>
<INPUT type="submit" value="Send"><INPUT type="reset">
</FORM>
Lors de la soumission du formulaire, chaque option sélectionnée sera appairée au nom "selection-composant" et envoyé au serveur. La valeur soumise pour chaque OPTION sera son contenu, sauf si contrecarré par un attribut value (ici, pour les deux premiers composants).
<!ELEMENT TEXTAREA - - (#PCDATA)*> <!ATTLIST TEXTAREA %attrs; -- %coreattrs, %i18n, %events -- name CDATA #REQUIRED rows NUMBER #REQUIRED cols NUMBER #REQUIRED disabled (disabled) #IMPLIED -- contrôle désactivé dans ce contexte -- readonly (readonly) #IMPLIED tabindex NUMBER #IMPLIED -- ordre de tabulation -- onfocus %Script #IMPLIED -- l'élément vient de recevoir le "focus" -- onblur %Script #IMPLIED -- l'élément vient de perdre le "focus" -- onselect %Script #IMPLIED -- du texte vient d'y être sélectionné -- onchange %Script #IMPLIED -- la valeur de l'élément vient de changer -- >
Balise de début : requise, Balise de fin : requise
Définition des attributs
Attributs définis par ailleurs
L'élément TEXTAREA crée un zone de saisie de texte multilignes (par opposition auchamp de texte INPUT d'une seule ligne). Le contenu de cet élément fournit le texte initial qui est présenté dans la zone de saisie.
L'exemple qui suit crée un contrôle TEXTAREA de 20 lignes sur 80 colonnes qui contient initialement deux lignes de texte. L'élément TEXTAREA est suivi de deux boutons, un de soumission et un de réinitialisation.
<FORM action="http://somesite.com/prog/text-read" method="post"> <TEXTAREA rows="20" cols="80"> Première ligne du texte initial. Deuxième ligne du texte initial. </TEXTAREA> <INPUT type="submit" value="Send"><INPUT type="reset"> </FORM>
En marquant l'attribut readonly , les auteurs pourront inscrire un texte fixe dans un élément TEXTAREA. Ceci diffère du texte habituel du document en ce sens que la valeur du TEXTAREA sera soumise avec le formulaire.
Il est recommandé que les agents utilisateur terminent canoniquement les lignes de texte par une séquence CR puis LF (13, 10 en ASCII décimal) lorsque le contenu de cette zone est soumise. Le jeu de caractère des données soumises est l'ISO Latin-1, sauf si le serveur a indiqué précédemment qu'il était en mesure de supporter d'autre jeux de caractères.
<!ELEMENT LABEL - - (%inline)* -(LABEL) -- label texte --> <!ATTLIST LABEL %attrs; -- %coreattrs, %i18n, %events -- for IDREF #IMPLIED -- valeur d'ID d'un champ -- disabled (disabled) #IMPLIED -- contrôle désactivé dans ce contexte -- accesskey CDATA #IMPLIED -- touche d'accessibilité -- onfocus %Script #IMPLIED -- l'élément vient de recevoir le "focus" -- onblur %Script #IMPLIED -- l'élément vient de perdre le focus -- >
Balise de début : requise, Balise de fin : requise
Définition des attributs
Attributs définis par ailleurs
L'élément LABEL peut être utilisé pour attacher une information à un autre contrôle (à l'exception des éléments LABEL eux-mêmes). Les labels pourront être affichés par les agents utilisateurs d'une multitude de façons (ex., visuellement, auditivement par des synthétiseurs vocaux, etc.)
Lorsqu'un élément LABEL reçoit le "focus", il le passe directement au contrôle qui lui est associé. Vois la section ci-dessous contenant des exemples d'usage de touches d'accessibilité.
Pour associer explicitement un label à un autre contrôle, définissez l'attribut for du LABEL.
L'exemple suivant crée un tableau utilisé pour aligner deux champs INPUT et leurs labels associés respectifs. Chaque label est associé explicitement à l'un des éléments INPUT.
<FORM action="..." method="post">
<TABLE>
<TR>
<TD><LABEL for="nom">Nom</LABEL>
<TD><INPUT type="text" name="nom" id="nom">
<TR>
<TD><LABEL for="pnom">Prénom</LABEL>
<TD><INPUT type="text" name="prenom" id="pnom">
</TABLE>
<FORM>
L'exemple suivant étend un exemple de formulaire antérieur pour y inclure des éléments LABEL. Notez que les éléments LABEL sont associés aux éléments INPUT via l'attribut id.
<FORM action="http://somesite.com/prog/adduser" method="post">
<P>
<LABEL for="firstname">Nom : </LABEL><INPUT
type="text" id="firstname"><BR>
<LABEL for="lastname">Prénom : </LABEL><INPUT
type="text" id="lastname"><BR>
<LABEL for="email"email: </LABEL><INPUT
type="text" id="email"><BR>
<INPUT type="radio" name="sexe" value="Homme"> Homme<BR>
<INPUT type="radio" name="sexe" value="Femme"> Femme<BR>
<INPUT type="submit" value="Send"> <INPUT type="reset">
</FORM>
Un même contrôle peut être associé à plusieurs éléments LABEL, lesquels constituent des références multiples via leur attribut for.
Pour associer un label implicitement à un autre contrôle, il suffit de placer le contrôle comme contenu de l'élément LABEL. Dans ce cas, l'élément LABEL ne pourra contenir qu'un seul élément contrôle. Le texte du label pourra, quant à lui, être positionné avant ou après le contrôle.
Dans l'exemple suivant, nous associons implicitement deux labels et leurs éléments INPUT associés respectifs. Remarquez que cette association implicite nous évite d'avoir à gérer la mise en page des labels et des champs de saisie dans un tableau (voir l'exemple précédent).
<FORM action="..." method="post"> <LABEL> Nom <INPUT type="text" name="nom"> </LABEL> <LABEL> <INPUT type="text" name="prenom"> Prénom </LABEL> </FORM>
<!-- #PCDATA is to solve the mixed content problem, per specification only whitespace is allowed there! --> <!ELEMENT FIELDSET - - (#PCDATA,LEGEND,%block)> <!ATTLIST FIELDSET %attrs; -- %coreattrs, %i18n, %events -- > <!ELEMENT LEGEND - - (%inline;)+> <!ENTITY % LAlign "(top|bottom|left|right)"> <!ATTLIST LEGEND -- fieldset legend -- %attrs; -- %coreattrs, %i18n, %events -- align %LAlign; #IMPLIED -- relativement au groupe de champs -- accesskey CDATA #IMPLIED -- touche d'accessibilité -- >
Balise de début : requise, Balise de fin : requise
LEGEND Définition des attributs
Attributs définis par ailleurs
L'élément FIELDSET permet aux concepteurs de formulaires de grouper des contrôles par thèmes. Le regroupement de contrôles amène une plus grande compréhension de la part des utilisateurs du formulaire tout en facilitant la gestion de la tabulation pour les agents utilisateurs visuels, et la gestion de commande vocale pour les navigateurs vocaux. Un usage approprié de cette implémentation permet de faciliter l'accès aux formulaires à ceraines catégories de personnes handicapées.
L'élément LEGEND permet aux concepteurs de rajouter une légende à un élément FIELDSET. La légende augmente l'accessibilité lorsque le FIELDSET n'est pas représenté graphiquement. Si c'est le cas cependant, l'attribut align de l'élément LEGEND alignera ce titre relativement au FIELDSET.
Dans l'exemple suivant, nous créons un formulaire qu'un patient pourrait remplir dans un cabinet médical. Il est divisé en trois sections : Les informations personnelles, les antécédents médicaux, et le traitement actuel. Chaque section accueille les champs de saisie propres à sa destination.
<FORM action="..." method="post">
<FIELDSET>
<LEGEND align="top">Personal Information</LEGEND>
Last Name: <INPUT name="personal_lastname" type="text" tabindex="1">
First Name: <INPUT name="personal_firstname" type="text" tabindex="2">
Address: <INPUT name="personal_address" type="text" tabindex="3">
...more personal information...
</FIELDSET>
<FIELDSET>
<LEGEND align="top">Medical History</LEGEND>
<INPUT name="history_illness"
type="checkbox"
value="Smallpox" tabindex="20"> Smallpox</INPUT>
<INPUT name="history_illness"
type="checkbox"
value="Mumps" tabindex="21"> Mumps</INPUT>
<INPUT name="history_illness"
type="checkbox"
value="Dizziness" tabindex="22"> Dizziness</INPUT>
<INPUT name="history_illness"
type="checkbox"
value="Sneezing" tabindex="23"> Sneezing</INPUT>
...more medical history...
</FIELDSET>
<FIELDSET>
<LEGEND align="top">Current Medication</LEGEND>
Are you currently taking any medication?
<INPUT name="medication_now"
type="radio"
value="Yes" tabindex="35">Yes</INPUT>
<INPUT name="medication_now"
type="radio"
value="No" tabindex="35">No</INPUT>
If you are currently taking medication, please indicate
it in the space below:
<TEXTAREA name="current_medication"
rows="20" cols="50"
tabindex="40">
</TEXTAREA>
</FIELDSET>
</FORM>
Notez que, dans cet exemple, nous pourrions améliorer la présentation du formulaire en alignant les éléments dans chaque FIELDSET (par des feuilles de style), en ajoutant de la couleur et des informations de police (par des feuilles de style), en ajoutant du script (par exemple, en n'autorisant la section "traitement actuel" que lorsque le patient indiquera qu'il est actuellement sous traitement), etc.
Les éléments actifs de documents HTML doivent être focalisés par l'utilisateur pour pouvoir accomplir leur fonction d'interface. Par exemple, les utilisateurs doivent focaliser et actionner un lien spécifié par l'élément A de façon à pouvoir suivre le lien. De même, les utilisateurs doivent donner le "focus" à un TEXTAREA pour pouvoir y entrer du texte.
Ce "focus" peut être donné de plusieurs manières :
Définition des attributs
L'ordre de tabulation définit l'ordre dans leque les éléments recevront le "focus" lorsque l'utilisateur les balaye par le clavier. L'ordre de tabulation peut inclure des éléments inclus dans d'autres éléments.
Un agent utilisateur naviguera à travers des éléments qui peuvent recevoir le "focus", en respectant les règles suivantes :
Les éléments suivant supportent l'attribut tabindex : A, AREA, OBJECT, INPUT, SELECT, TEXTAREA, et BUTTON.
Dans l'exemple qui suit, l'ordre de tabulation permettra d'atteindre d'abord le BUTTON, puis les champs INPUT dans l'ordre (notez que le "champ1" et le bouton partagent le même indice, mais "champ1" apparaît plus loin dans le document), et enfin le lien créé par l'élément A.
<HTML>
<BODY>
...du texte...
Cliquez pour vous rendre sur le
<A tabindex="10" href="http://www.w3.org/">site Web du W3C.</A>
...encore du texte...
<BUTTON type="button" name="get-database"
tabindex="1" onclick="get-database">
Cliquez-moi pour recevoir la base de données indiquée.
</BUTTON>
...encore...
<FORM action="..." method="post">
<INPUT tabindex="1" type="text" name="champ1">
<INPUT tabindex="2" type="text" name="champ2">
<INPUT tabindex="3" type="submit" name="submit">
</FORM>
</BODY>
</HTML>
Touches de tabulation. La séquence de touche effective qui provoque la navigation tabulée où la sélection d'un élément particulier dépend de la configuration de l'agent utilisateur (ex., la touche "tab" sera utilisée pour la navigation tandis que la touche "enter" servira à activer l'élément sélectionné).
Les agents utilisateurs définiront de plus des séquences de touches pour effectuer la navigation en sens inverse. Lorsque la fin (ou le début) de la séquence de tabulation est atteinte, les agents utilisateurs pourront reboucler la navigation.
Définition des attributs
L'action de presser une touche d'accessibilité assignée à un élément donnera le "focus" à cet élément. L'action exécutée par l'élément, lorsqu'il acquiert le "focus", dépend de la nature de celui-ci. Les liens spécifiés par un élément A serotn en génral activés par l'agent utilisateur, un bouton radio activé changera d'état, les champs de texte se mettront en mode saisie, etc.
Les éléments suivants supportent l'attribut accesskey : LABEL, A, CAPTION, et LEGEND.
L'exemple qui suit assigne la touche "U" au label associé à un contrôle INPUT. En tapant cette touche d'accessibilité, le label acquiert le "focus" qui est alors immédiatement redonné à l'élément associé. L'utilisateur peut alors entrer du texte dans le champ INPUT.
<FORM action="..." method="post"> <LABEL for="user" accesskey="U"> User Name </LABEL> <INPUT type="text" name="user"> </FORM>
Dansl'exemple suivant, nous assignons une touche d'accessibilité au lien défini par un élément A. Taper cette touche d'accessibilité amènera l'utilisateur au document pointé par ce lien, dans ce cas, une table des matières.
<A accesskey="C"
href="http://somplace.com/specification/sommaire.html">
Table des Matières</A>
L'invocation des touches d'accessibilité dépend du système sous-jacent. Par exemple, sur des machines sous MS Windows, la touche "alt" doit être appuyée pour que les touches deviennent des touches d'accessibilité. Sur des systèmes Apple, c'est la touche "cmd" ("pomme !") qui provoque ce basculement.
La représentation des touches d'accessibilité dépend de l'agent utilisateur. Nous recommandons que les auteurs mentionnent les touches d'accessibilité dans les labels associés aux éléments qu'elles contrôlent. Les agents utilisateurs afficheront cette mention d'une façon qui rende cet affichage explicite, et parfaitement distinct des caractères usuels (par soulignement, par exemple).
Dans un contexte où la modification de valeur par un utilisateur n'est pas souhaîtable, ou n'a pas de sens, il est important de pouvoir désactiver un élément, et de pouvoir l'afficher de sorte qu'il ne puisse qu'être lu. Par exemple, on souhaiterait pouvoir désactiver un bouton de soumission, jusqu'à ce que l'utilisateur ait rentré une certaine donnée obligatoire. De même, un concepteur souhaiterait pouvoir afficher des valeurs qui doivent être soumises par le formulaire, mais que l'utilisateur ne doit pas modifier. Les sections qui suivent décrivent ces éléments désactivés ou verrouillés en écriture.
Définition des attributs
La présence de l'attribut disabled a les effets suivants sur l'élément :
Les éléments suivant supportent l'attribut disabled : INPUT, TEXTAREA, SELECT, OPTION, OBJECT, LABEL, et BUTTON.
La façon dont des éléments désactivés sont affichés dépend de l'agent utilisateur. Par exemple, certains agents "grisent" les éléments de menus désactivés, les libellés de boutons, etc.
Dans l'exemple qui suit, le champ INPUT désactivé ne peut recevoir d'information, et sa valeur ne sera pas émise lors de la soumission du formulaire.
<INPUT disabled name="fred" value="stone">
Note : La seule façon de modifier la valeur dynamiquemnt d'un élément disabled est l'usage d'un script.
Définition des attributs
L'attribut readonly spécifie si l'élément peut ou ne peut pas être modifié par l'utilisateur.
La présence de l'attribut readonly a les effets suivants sur un élément :
Les éléments suivant supportent l'attribut readonly : INPUT, TEXT, PASSWORD, et TEXTAREA.
La façon dont les agents utilisateurs affichent les éléments en lecture seule dépend de chaque agent.
Note : La seule façon de modifier la valeur dynamiquemnt d'un élément readonly est par l'usage d'un script.
Tous les éléments ne sont pas soumis avec le formulaire. Les agents utilisateurs conformes ignoreront :