W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

proposed Form Techniques (Accessibility Topic 3.5)

From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Thu, 18 Nov 1999 00:40:00 -0500
Message-Id: <4.1.19991117210831.00a7b320@pop3.concentric.net>
Message-Id: <4.1.19991117210831.00a7b320@pop3.concentric.net>
To: User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
aloha, y'all!

the following would replace the 3 unordered list items that precede the line

quote
Statement of form submission problems from Gregory Rosmaita:
unquote

in the current (5 november) draft version of the UAGL Techniques document
located at (long wrapping URI warning):
http://www.w3.org/TR/1999/WD-WAI-USERAGENT-TECHS-19991105/#form-techniques

one note -- due to time constraints, i did not suggest specific references
which could be hyperlinked from the techniques proposed below, mainly because i
did not have the opportunity to quadruple check each URI, as is my wont, but
also because i did not want to clutter the proposal with extraneous
information...  however, i do have a (partial) listing of such references, and
will post them to the list (or simply send them to ian) as required slash
instructed, although, with only a few exceptions, the terms and specifications
which could be referenced are obvious...

gregory.

--- begin proposed techniques

the following would replace the 3 unordered list items that precede the line

quote
Statement of form submission problems from Gregory Rosmaita:
unquote

in the current (5 november) draft version of the UAGL Techniques document
located at (long wrapping URI warning):
http://www.w3.org/TR/1999/WD-WAI-USERAGENT-TECHS-19991105/#form-techniques

one note -- due to time constraints, i did not suggest specific references
which could be hyperlinked from the techniques proposed below, mainly because i
did not have the opportunity to quadruple check each URI, as is my wont, but
also because i did not want to clutter the proposal with extraneous
information...  however, i do have a (partial) listing of such references, and
will post them to the list (or simply send them to ian) as required slash
instructed, although, with only a few exceptions, the terms and specifications
which could be referenced are obvious...

gregory.

--- begin proposed techniques

3.5 Form techniques
  
 * For labels explicitly associated with form controls, make available 
   label information when the user is navigating among the form 
   controls. This information must be provided in a device independent 
   manner, and the user should be able to choose from amongst a list of 
   mechanisms which provide access to the content of the LABEL.

 * For semantic information explicitly associated with groupings of form
   controls (i.e. groupings of radio buttons or checkboxes contained in 
   a FIELDSET), make available the information contained in the LEGEND 
   defined for the FIELDSET to the user. This information must be 
   provided in a device independent manner, and the user should be able 
   to choose from amongst a list of mechanisms which provide access 
   to the content of the LEGEND.

 * Provide information about the percentage of form which has already 
   been filled out as the user moves through the form controls. This 
   information must be provided in a device independent manner, and 
   the user should be able to choose from amongst a list of mechanisms 
   to ascertain what percentage of the form has been completed. The 
   user should also be able to query the user agent through a simple, 
   well documented mechanism (such as a keystroke or keystroke 
   combination) to ascertain the percentage of the form which has 
   already been completed.

     + Providing the user with a means of ascertaining what 
       percentage of a form has been completed as he or she 
       moves through the form (as well as on a query-on-demand 
       basis) would assist users from prematurely submitting 
       an incomplete form. This is particularly important for 
       anyone moving through a form serially (i.e. moving from 
       form field to form field), as the SUBMIT mechanism is 
       often interpreted by the end user as signifying the end 
       of the form. (Refer also to the technique detailing 
       methods of providing users with orientation information 
       about individual form controls when a form control 
       receives focus for a more detailed discussion of this 
       issue.)

 * Provide the user with orientation information about a form. 
   Users should be able to query the user agent for:

     + the presence of a form -- the user should be able to 
       query to user agent for the presence of a form within 
       the document being rendered. Some user agents (such as
       Opera and Netscape Navigator) already indirectly 
       provide such functionality in a non-interactive manner, 
       through the provision of "form navigation" keyboard 
       commands. When invoked, these "form navigation" 
       commands move the user agent's focus to the first 
       form field contained in the document currently being 
       rendered (provided, of course, that the document 
       contains a form. Although the provision of discrete 
       "form navigation" commands endows an end user with 
       the ability to quickly move to the first form field 
       within a document, the end user needs to be explicitly 
       notified if the document does not contain a form. Such 
       notification should be conveyed in a device independent 
       manner, and the user should not be limited to one 
       means of notification (i.e. display a message on the 
       status bar and play a sound).
       
     + the number of forms in a document

     + the dimensions of each form

 * Provide the user with orientation information about individual 
   form controls when a form control receives focus. For example, 
   the most basic orientation information would be to identify the 
   form control with focus as "Field X of Y", where "Y" is the 
   total number of fields contained in the form. 

     + This would prevent users accessing the form serially (such 
       as a blind user using a screen reader or someone using a 
       voice browser over a phone) from prematurely invoking the 
       form's SUBMIT mechanism. It is a common practice for forms 
       (particularly those used to query search engines) to be 
       laid out visually, so that the SUBMIT and RESET buttons (if 
       present) immediately follow a text-entry field, despite the 
       presence of other form controls (such as radio buttons and 
       checkboxes) within the FORM element. A user accessing such 
       a form in a serial manner, therefore, is likely to mistake 
       the SUBMIT button for the end of the form, and activate it, 
       unaware that it is followed by further form controls which 
       could--in the example of a search engine query submission 
       form--prove an invaluable aid in tailoring the content 
       being submitted via the form. Use of such orientation 
       information (i.e. "Field X of Y" or the percentage of the 
       form completed) will also decrease the amount of time needed 
       to submit the form (a crucial consideration when forms are 
       being used to facilitate bidding for online auctions) as 
       well as reduce the frustration of the end user, who--due to 
       the visually oriented layout of the form--is nonplussed when 
       the submission of the form repeatedly leads to a "Form 
       Incomplete--Use your browser's back button to return to the 
       form" message.

 *  When a document contains more than one form, form control 
    orientation information should also include data which will 
    identify to which form the form control with focus belongs. 
    Notification could take the form:

          Form Z: Field X of Y

    where "Z" identifies the form, "X" the form field with focus 
    and "Y" the total number of form fields contained in "Form Z"

 *  The provision of more detailed orientation information pertaining 
    to form is also highly encouraged:

     + When a grouping of radio buttons receives focus, identify the 
       radio button with focus as "Radio Button X of Y", where "Y" 
       represents the total number of radio buttons in the grouping. 
       HTML4 provides for the grouping of radio buttons using the 
       FIELDSET element, which allows authors to group thematically
       related controls and labels. The LEGEND element assigns a caption
       to a FIELDSET. If a LEGEND has been defined for the grouping  
       of radio boxes, use the information contained within the LEGEND 
       to more precisely identify the number of radio buttons in the 
       grouping. For example. if the LEGEND element has been used to 
       identify a FIELDSET of radio buttons, each of which has a LABEL 
       associated with it, as "Connection Rate", identify the radio 
       button as it receives focus as "Connection Rate: Radio button X 
       of Y: 28.8kpbs", where "Y" represents the total number of radio 
       buttons in the grouping and "28.8kbps" is the information 
       contained in the LABEL associated with the radio button with 
       focus.

     + When a grouping of checkboxes receives focus, identify the 
       checkbox with focus as "Radio Button X of Y", where "Y" 
       represents the total number of checkboxes in the grouping.
       HTML4 provides for the grouping of checkboxes using the 
       FIELDSET element, which allows authors to group thematically
       related controls and labels. The LEGEND element assigns a caption
       to a FIELDSET. If a LEGEND has been defined for the grouping  
       of radio boxes, use the information contained within the LEGEND 
       to more precisely identify the number of checkboxes in the 
       grouping. For example. if the LEGEND element has been used to 
       identify a FIELDSET of checkboxes, each of which has a LABEL 
       associated with it, as "Hobbies", identify the checkbox as it 
       receives focus as "Hobbies: Checkbox X of Y: Horticulture", 
       where "Y" represents the total number of checkboxes contained 
       in the grouping and "Horticulture" is the information contained 
       in the LABEL associated with the checkbox with focus.

 * Provide information about what is required for each form control. GUI 
   browsers, for example, could convey such information via context-
   sensitive help. Lynx conveys this information by providing information 
   about the currently selected form control via a status line message:

   (Radio Button) Use right-arrow or <return> to toggle
   (Checkbox Field) Use right-arrow or <return> to toggle
   (Option List) Hit return and use arrow keys and return to select option
   (Text Entry Field) Enter Text. Use UP or DOWN arrows or TAB to move off
   (Textarea) Enter text. UP/DOWN arrows or TAB to move off (^Ve for editor)

     NOTE: The ^Ve (caret-V, e) command, included in the TEXTAREA status 
     line message, enables the user to invoke an external editor defined 
     in the local Lynx configuration file (lynx.cfg).  For more information, 
     please refer to the following technique.

 * Allow the user to invoke an external editor when a TEXTAREA receives 
   focus.

   A user may wish to use an external editor, rather than enter text 
   directly in a TEXTAREA for myriad reasons, including:

     + the ability to more efficiently and expeditiously review the 
       text being input
     + the ability to spell check the text being input
     + the ability to use macros or other special features of the 
       external editor, including the ability to increase the 
       contrast between foreground and background colors, access to 
       a wider range of screen-display fonts, etc.
     + the ability to save a local copy of the text being input
     + the user's familiarity with the external editor will encourage 
       the user to actually enter text into a TEXTAREA--an exercise 
       which is often an extremely daunting task, given the 
       limitations imposed by the physical dimensions of the TEXTAREA. 
       A user will also find it much easier to review what he or she 
       has typed when using an external editor.

  * Provide information about the order of form controls (e.g., as
   specified by "TABINDEX" in HTML). This is important since:

     + most forms are visually oriented, employing changes in font 
       size and color
     + users who access forms serially need to know they have 
       supplied all the necessary information before submitting 
       the form.

 * Provide information about required fields. Since authors often use 
   color changes, font styling, or a graphical symbol alone to express 
   that a field is required, the user should be able to configure the 
   user agent so that it alerts him that the field is required for 
   submission of the form content.  Strategies for achieving this 
   include:

     + Allow the user to view a list of required form fields. Such a 
       list should be invokable via a simple and well documented 
       keybinding.
     + Allow the user to define an alert mechanism (such as the playing 
       of a sound) which will be invoked when a required field receives 
       focus. The user should be able to pick from amongst a list of 
       alert mechanisms (i.e. color or font-style changes to the field 
       label, the playing of a sound clip, a status line message, etc.), 
       and should not be limited to only one type of alert mechanism.
       Do _not_ rely on visual or aural prompts alone to signify a 
       required form field.

 * Allow the user to configure the user agent so that SELECT form fields 
   which use the "multiple" attribute to allow the end user to select 
   more than one OPTION can be transformed into a list of checkboxes. 

     + Preserve the LABELs set for the OPTGROUP and each individual 
       OPTION, and re-associate them with the user agent generated 
       checkboxes. The LABEL defined for the OPTGROUP should be 
       converted into a LEGEND for the resultant FIELDSET, and each 
       checkbox should retain the LABEL defined for the corresponding 
       OPTION.

     + Note: Lynx automatically transforms SELECT form fields which use
       the "multiple" attribute to allow the end user to select more than one 
       OPTION into checkboxes.

 * Allow the user to configure the user agent sot that SELECT form fields 
   can be transformed into a list of radio buttons.

     + Any such transformation should retain the accessibility information 
       defined for the original form controls.

     + Note: Lynx provides this functionality as a configurable option, 
       which can be changed on-the-fly while a page is being rendered. 
       To promote the comprehensibility of the transformed output for 
       users using screen-readers and refreshable Braille displays, 
       Lynx places each OPTION that it transforms into a radio button 
       on a separate line.
--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
   WebMaster and Minister of Propaganda, VICUG NYC
        <http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------
Received on Thursday, 18 November 1999 00:33:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:34 GMT