FORMs guidelines

It took us some time, but below you'll find a proposal for
form usage guidelines.
Be so kind to read them and ... comment to us:

	Gregory Rosmati
	William Loughborough
	Jaap van Lelieveld

Best regards,
Jaap

Message from: Jaap van Lelieveld      The Netherlands
              Chairman of EBU commission on Technical Devices and Services
E-mail:       Jaap.van.Lelieveld@inter.nl.net

USING: YARN V0.92 as an offline reader, and
       UQWK / OLMENU under UNIX for mail and news transfer
--------------------------------------------------------------------
Authoring guidelines:

Proposal for a basic set of guidelines on the use of forms in HTML pages:

[new]      Like in the current guidelines.

 -    When you use a form to collect information always clearly indicate
      where your form starts and stops, so the user knows what data will be
      transferred if SUBMIT is used.

 -    Always clearly indicate whether each field or group of fields in the
      form is "required" or "optional".

 -    Make sure you clearly specify which prompts and fields belong
      together. The preferred sequence is prompt: field (from left to right).
      Empty space--particularly between the ':' and the data-entry field--is
      essential. It is recommended that you outline all data-entry fields, i.e.
      the first character of all data-entry fields should start in the same
      column.

 -    If you decide not to use the prompt: field sequence, either insert empty
      space (one empty line) between different fields, or clearly indicate how
      many fields comprise a group of fields or the whole form.
      E.g. (courier font expected):
....
Contact Information (4 Fields)
     First Name : _________________
     Last Name       : _________________
     E-mail Address  : ______________
     Phone Number    : _______________

 -    If separate groups of fields can be designated, choose the layout of the
      form to reflect this (see example above).

 -    If you are listing a static series of choices or options, you should at
      least indicate the last option explicitly e.g. by using the word 'or'. If
      you have designated a default option using the CHECKED attribute,
      you should also indicate this explicitly as well, e.g. by using the word
      "default". It is preferable to make the default option the first option.
      This is of course not true for a form that is used to update data.
      E.g. (courier font expected):
....
Search Type (3 options)
     ( ) Search using all terms (default)
     ( ) Search using any of these terms
or   ( ) Search using this exact term

 -    If you want to use concatenated prompts like Zip/City position both
      input fields on the same line as well.
      E.g. (courier font expected):
....
Zip/City: ________ _________________
      or (note the ':' and the empty space between the data-entry field and
      the next prompt)
      E.g. (courier font expected):
....
Zip: ________  City: _________________

 -    [new] Use the TABINDEX attribute to create a good tab sequence i.e. a
      tab sequence that increases the logical layout of the form. This
      sequence could well be different from the physical sequence. Make
      sure EACH field is in the TAB-sequence.

 -    If you are using the BUTTON element to achieve a push-button, always
      define a textual equivalent/alternative by using the ALT attirrubte in the
      IMG declaration. (see also ALT usage in these guidelines).
      E.g. (courier font expected):
....
<BUTTON NAME="submit" VALUE="submit" TYPE="submit">
<IMG SRC="icons/bozo_the_clown.gif" ALT="Submit">
</BUTTON>

 -    If your form appears in a FRAME, provide a NOFRAMES alternative
      for those using non-graphical/frames-incapable browsers/user agents. 
      The NOFRAMES alternative form should be marked up in plain, valid
      HTML. It should be free of: tables; forced font sizing; forced font
      colour changes; decorative graphics; graphically-defined SUBMIT and
      RESET buttons; use of the BUTTON element; etc. Structure the form
      so that all of the options are clearly outlined and defined in accordance
      with the guidelines above (See also NOFRAMES usage in these
      guidelines).

 -    [new] Use the FIELDSET, LEGEND, and LABEL elements.
      The FIELDSET element enables you to group thematically related
      controls and labels, making it easier for users to understand their
      purpose, while simultaneously facilitating tabbing navigation for visual
      user agents and speech navigation for speech-oriented user agents.
      The LEGEND element allows authors to assign a caption to a
      FIELDSET. The legend improves accessibility when the FIELDSET is
      rendered non-visually.
      E.g. (courier font expected):
<FIELDSET>
<LEGEND>Personal Information</LEGEND>
<LABEL for="firstname">First name: </LABEL>
  <INPUT type="text" id="firstname" tabindex="1"><BR>
<LABEL for="lastname">Last name: </LABEL>
  <INPUT type="text" id="lastname" tabindex="2"><BR>
<LABEL for="address">Address: </LABEL>
  <INPUT type="text" id="address" tabindex="3"><BR>
</FIELDSET>

 -    [new] Use the ACCESSKEY attribute to assign an access (shortcut) key
      to an element. Pressing an access key assigned to an element gives
      focus to that element, thereby facilitating more efficient navigation of
      your form, especially by those with limited motor-skills. The action
      that is executed when an element receives focus depends on the
      element. For example, when a user activates a radio button, the user
      agent changes the value of the radio button. When the user activates a
      text field, it allows input, etc.
      The ACCESSKEY attribute is supported by the following elements: A,
      AREA, LABEL, INPUT, LEGEND, and BUTTON. The following
      example assigns the access key "U" to a label associated with an
      INPUT control; the access key "X" to the radio buttons; and "S" is
      associated with the SUBMIT button. Typing the access key "U" gives
      focus to the label which in turn gives it to the associated control, so
      that the user may then enter text into the INPUT area. Typing the
      access key "X" gives focus to the label, which in turn gives it to the
      associated control, so that the user may then either change or accept
      the radio button setting.  Likewise, typing the access key "S" gives
      focus to the Submit button.

      E.g. (courier font expected):
<FORM action="..." method="post">
ACCESS KEYS:
<DL>
     <DT> U <dd> User Name
     <DT> X <DD> Sex
     <DT> S <DD> Submit
</DL>
<P>
<FIELDSET>
<LEGEND>Personal Information</LEGEND>
<LABEL for="fuser" accesskey="U">User Name</LABEL>
User Name: <INPUT type="text" name="user" id="fuser"><BR>
<LABEL for="fsex" accesskey="X">Sex</LABEL>
<INPUT type="radio" name="sex" value="male" id="fsex"
CHECKED> Male (default)
or <INPUT type="radio" name="sex" value="female"> Female
<LABEL for="fsubmit" accesskey="S">Submit</LABEL>
<INPUT type="submit" name="submit" id="fsubmit">
</FIELDSET>
</FORM>
      NB:  Since the rendering of access keys depends on the user agent, it
           is highly recommended that you include the access key in the
           label text or wherever the access key is to apply.

 -    You should use a style sheet, and not HTML markup, to improve the
      visual presentation of your form (i.e. by aligning elements within each
      FIELDSET, adding colour and font information, etc.) The use of style
      sheets, when used in conjunction with the form-specific guidelines
      outlined in this section, will preserve the structure of your form,
      thereby ensuring that your form is accessible to users operating in a
      text-only, non-visual, limited mobility, and/or low-vision paradigm.

 -    Although only one form can be submitted at a time, it is possible for a
      page designer to put more than one form on a single page, in order to
      allow the user to select a specific form to be used for specific
      purposes. If you design a page containing more than one form, clearly
      indicate how many forms (the number) are available on that page and
      the purpose of and/or the intended audience for each form. E.g. begin
      the page with a description of and a link to each form.

 -    If you are using a TABLE and physical markup to achieve a desired
      visual effect, always provide a non-tablized, universally-accessible
      alternative form. A link to this form should be prominently displayed.
      The non-tablized form should be marked up in plain, valid HTML. It
      should be free of: frames, tables; forced font sizing; forced font colour
      changes; decorative graphics; graphically-defined SUBMIT and RESET
      buttons; use of the button element; etc. Structure the form so that all of
      the options are clearly outlined and defined in accordance with the
      guidelines above. Such a universally accessible form will not only
      greatly benefit disabled users, but low bandwith users as well.

Received on Wednesday, 8 April 1998 16:44:44 UTC