Form Controls (Strengthening Checkpoint 10.6)

Aloha, all!

Whilst I applaud the intent behind Checkpoint 10.6 (as 
contained in the 11 August 1999 draft),

quote
Allow the user to request to be prompted before a form is
submitted. [Priority 3]
unquote

I am troubled by its vagueness, the lack of associated
techniques, and by its classification as a P3.  The crux of
the problem, as I perceive it, is this:

A) As a user, I do NOT want to be prompted EACH time I
submit a form, provided that I submitted the form by
activating its SUBMIT mechanism.  If, however, I simply hit
the ENTER or the RETURN key from within a FORM control
(i.e., rather than explicitly activating the SUBMIT
mechanism), I would like the UA to request confirmation
before submitting the form content.

B) As a user, I do NOT want the form content automatically
submitted if I inadvertently press the ENTER or RETURN key.

  PROBLEM STATEMENT FOR POINT B: Inadvertently pressing the
  RETURN or ENTER key is quite a prevalent phenomenon
  amongst users of every level of expertise - especially
  those who often find it necessary to switch between user
  agents. Lynx, for example, uses the ENTER key within
  FORMs as a means of exposing drop-down (or pop-up,
  depending upon your point of view) SELECT menus.  Thus,
  when one encounters a SELECT menu using Lynx, one:
  exposes the content of the menu by pressing the ENTER
  key, and then is able to navigate between OPTIONs using
  the up and down arrows or via Lynx's text-search feature.
  When one finds the appropriate OPTION, it is selected by
  pressing ENTER, which causes the selected item to be
  displayed in the SELECT menu listbox.
  
  The problems posed by the default "submit on enter"
  feature of most GUI browsers, is not limited to the
  SELECT menu problem outlined above.  Lynx (as well as
  several other text-based browsers) uses the ENTER/RETURN
  key as a means of toggling several FORM controls, such as
  the selection of checkboxes and radio buttons.
  
  Moreover, I would like to stress that the "Auto-Submit-On-
  Enter" feature is not only quite problematic for one
  operating in an eyes-free environment, but for those
  unaccustomed to using online forms, and for those
  unfamiliar with a particular user agent's default key-
  bindings for forms, as well as those (like myself and
  countless others) who surf the web using a variety of
  browsers, often switching from browser to browser -- ALT-
  TAB-ing from Lynx32 to MSIE to Opera, for example -- in
  order to better comprehend the contents of a page or
  whilst attempting to navigate an poorly structured site
  or a poorly marked-up form
  
C) As a speech user, I am constantly frustrated and
misdirected by the use of javascript and event handler
controlled pseudo-forms, wherein the user is presented with
a menu (in the form of a listbox in GUI browsers), and is
redirected to a different viewport upon selection of an
OPTION.

  PROBLEM STATEMENT FOR POINT C: The markup behind such
  pseudo-forms is a mix of javascript (in particular the
  "function switchpage(select)" command) and HTML FORM
  controls, which utilize HTML4's event handler script
  attributes (in particular the "onchange" event handler
  attribute has been defined. An example (gleaned from the
  document source for <http://www.pricescan.com> follows:
  
  <SELECT NAME="condition" onchange="switchpage(this)">
  
  When such a menu Is encountered by a websurfer who is
  using speech synthesis in conjunction with a javascript
  enabled user agent, his or her instinctual reaction will
  be to use the UA's navigational mechanism (usually the up
  and down arrows) to review the available OPTIONs.
  However, each time a new OPTION is displayed, the user is
  abruptly taken to a new viewport. Conversely, if one is
  using a user agent that does not support javascript (or
  has javascript support disabled), then the menu is
  displayed, but since there is no SUBMIT mechanism
  associated with it, there is no mechanism by which one
  can use the menu to quickly switch viewports - the
  ostensive purpose of this type of pseudo-form.  And while
  one can avoid having the viewport abruptly changed when
  encountering the menu (at least in the Windows
  environment) by using the ALT-LEFT-ARROW keystroke to
  display the menu in a drop-down list, (a) very few users
  know this keystroke, and (b) when one encounters a
  listbox on a page in an aural environment, one usually
  assumes that he or she is navigating a valid FORM, in
  which there are no unexpected side effects to perusing
  the contents of a SELECT menu using the arrow keys
  
  NOTE: I have chosen to address the issue of pseudo-forms
  in this context, for, although they straddle the boundary
  between "Form Controls" and Checkpoint 5.8, pseudo-forms
  rely on FORM elements for activation  This issue has been
  raised in the past, particularly by Chris Kreussling  --
  consult (long wrapping URI warning!)

<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0276.html>

Therefore, I propose the following:

PROPOSAL 1. reword Checkpoint 10.6 as follows (note the
priority level change):

  Prompt the user to confirm the submission of form content
  if the submission mechanism is not directly activated.
  [Priority 2]
     NOTE: The issuance of the confirmation prompt should be
     controlled by a user-configurable schedule.
     Confirmation of "Submit-on-Enter" need not be the
     default setting.

  TECHNIQUE
     The issuance of the confirmation prompt should be
     controlled by the user, according to a user-
     configurable schedule.  The default setting should be:
       "Prompt Each Time Before Submitting Form Content"
     Other options could include:
       "Submit Form Content on ENTER for All Forms in this
       Site"
       "Submit Form Content on ENTER for All Forms in this
       Domain"
       "Submit Form Content on ENTER for All Forms "
     If possible, the user should also be offered a "Accept
     this Value and Don't Ask Me Again" option, when the
     confirmation prompt is first displayed

2. add the following checkpoint to the "Form Control"
portion of Guideline 10 and cross-reference it under
Checkpoint 5.8 (the only checkpoint I could find which
addresses scripting directly)

PROPOSED NEW CHECKPOINT (CHECKPOINT 10.x)
  When there is only one field in a form, or when the form
  lacks a user-addressable SUBMIT mechanism, prompt the
  user before automatically submitting the form content.
  [Priority 1]
  
TECHNIQUE 1
The issuance of the confirmation prompt should be
controlled by the user, according to a user-
configurable schedule.  The default setting should be:
       "Prompt Each Time Before Submitting Form Content"
Other options could include:
       "Submit Form Content on ENTER for All Forms in this Site"
       "Submit Form Content on ENTER for All Forms in this Domain"
       "Submit Form Content on ENTER for All Forms "
If possible, the user should also be offered a "Accept
this Value and Don't Ask Me Again" option, when the
confirmation prompt is first displayed
  
TECHNIQUE 2:
If the submission of the single field form is achieved 
via a script or an HTML4 event handler, such as 
"onchange", prompt the user for confirmation before
submitting the form content.
     
NOTE: I am not quite sure that this new checkpoint (which I 
have arbitrarily numbered 10.x) quite covers the concerns I 
outlined in PROBLEM STATEMENT FOR POINT C, above, or Issue 
#58 on the UA Issues List, and wonder whether what I have 
identified as TECHNIQUE 2 for Checkpoint 10.x doesn't merit 
a checkpoint of its own -- or, at least, be included as a 
NOTE: appended to Checkpoint 10.x.

In any event the Techniques for the proposed checkpoint
should also reference the WCAG's Checkpoint 6.3, which is
P1, and the WCAG Techniques Document's Topic 2.13, the
introduction to which states:

  Content developers must ensure that pages are accessible
  with scripts turned off or in browsers that don't support
  scripts.

In particular, Technique 2.13.2, which deals explicitly
with event handlers.

Gregory

--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <oedipus@hicom.net>
   President, WebMaster, & Minister of Propaganda, 
        VICUG NYC <http://www.hicom.net/~oedipus/vicug/>
--------------------------------------------------------

Received on Tuesday, 17 August 1999 23:58:47 UTC